I have a fragment shader that I am successfully using on plenty of objects, with the only exception being if orxObject_SetCurrentAnimation has been called on the object.
In this case, if I use AddShader and add that same shader, the object doesn't appear at all.
Is there something I need to do in the shader to support animation?
Mmh, no. Nothing really comes to my mind. I presume you want to use the current animation's graphic as input texture for your shader?
My first guess would then be some sequencing issues in the shader initialization/param querying, probably in the render plugin. I'll have a look at it tomorrow (2:30 AM here, I should already be asleep. ^^)
Which version of orx are you using, btw? The 1.3rc0 or the latest from SVN? Also, on which platform did you experience the issue?
Thanks for the quick reply! Yes, I want to use the current animation's graphic in the shader.
I have tried it on iOS and on the PC, with the same result each time (with all other objects using shaders being fine).
I just tried a basic shader that forces full-alpha as follows:
Code = "
vec4 color = texture2D(texture, gl_TexCoord);
color.a = 1.0;
gl_FragColor = color;
ParamList = texture
The result then is that I see a white square in the position the graphic should be, and the bounds of that square change each frame but it is just solid white.
Any help would be greatly appreciated
EDIT: And yes, this is with 1.3rc0
I've fixed a related issue a few weeks ago. Actually it might be the same issue: if your animation's graphic a full texture or a sub-region of a bigger texture/spritesheet (or texture atlas, depending on the terminology you prefer )?
If so, that'd probably be the bug I've fixed in revision #2731.
I'd suggest using the svn version (it compiles out of the box for all the platforms, just make sure to sync the /trunk folder) as there has been over 200 fixes/improvements since the 1.3rc0.
To date, we have been using the precompiled distribution. I just pulled down the bleeding edge from SVN and compiled the libs then linked it into our project, but now when we launch we get a crash with the following output on the console:
CEGUI::RendererException in file c:cegui-0.7.5ceguisrc
enderermodulesopenglceguiopenglrenderer.cpp(641) : OpenGLRe
nderer failed to initialise the GLEW library. Missing GL version
But then that will probably be on our end, I guess. Still, I'm not quite sure why changing the orx version would cause CEGUI to not initialise :S
I assume that happens for your windows build? Wild guess: could it be some incompatibility of the GL version linked with orx as it's now linked against your own local GL version and not mine.
Just to be sure, you compiled the embedded dynamic versions of orx (and not one of the non-embedded ones)? And, also, did you make sure that you're using all the new include headers and libraries and don't have something that's still using the old code (in which case verifying the paths + clean/rebuild should do the trick).
Again, sorry about those obvious advises but I can't think of anything else for now.
is null. But when I switch back to the old version, it has no problem with it :S
Here is the ini file in full:
EDIT: I have cleaned and rebuilt and checked paths etc. and I am sure it is using the new code
Only UTF-8 (and plain ANSI) is supported by orx and I recently added a check (+ error message in the debug log when trying to read a config file with an incorrect BOM).
Is the file actually being loaded? Maybe some working directory issue, I don't remember if 1.3rc0 was forcing the exe's directory to be the current working one, but it's now the case. (You can override this by calling orxConfig_SetBaseName() in your init and reload the config.)
I tracked down where the viewport creation is failing, it's in orxStructure.c on line 368 inside orxStructure_Create:
That if statement check fails (although I don't get that debug output, strangely) and returns null.
That function was called from line 247 in orxViewport.c:
Like if you were using a release build (orx.lib/orx.dll) with __orxDEBUG__ defined or using a debug build (orxd.lib/orxd.dll) without defining __orxDEBUG__.
Or not using the new headers from the /code/include of the svn repo but the old ones. Or using the new .lib with the old .dll. Well, I won't do all the combinations but you see what I mean.
I have, however, come up with a test-case for you using the latest SVN code:
In the 04_Anim example, add the following to the end of 04_Anim.ini:
And change 04_Anim.c like this:
Normally, the output of this example project is:
But with the shader loaded, the output is:
So the coordinates must still not be passed through correctly. Hope this helps. Thanks!
EDIT: Note also that the image *does* change each frame, so it is possibly just the UV scale that is wrong? Also, the shader is being loaded properly, as I am able to alter the fragment alpha etc.
I found that particular issue and fixed it on the SVN. Hope that was the same you were experiencing on your side.
If you're curious, the coordinates were actually correct. It's simply that the default texture sent to the shader was the one of the object's main graphic, not the texture holding the current animation frame. However the UV coordinates were actually the ones of the current frame.
I didn't encounter that issue earlier as in most of my projects I use the same spritesheet for both the main graphic and the animation frames.
Orx will now use the current frame's texture as default texture parameter. Let me know if that fixed your problem.
Thanks, it now works! Thanks for taking the time to help out with this, it's going to make a big difference to the polish of our title being able to have shaders on our animated objects
I'm glad it worked. Sorry I couldn't check it earlier I was busy with IGF judging last week end.
If you have any details you can communicate on your title, don't hesitate, I'm always curious to know what's made with orx.