Hi,

I noticed that some of my A8-shaders, which deal with animated sprites, behave different under A7 -- or in other words: they work in A7 as one could assume and need extra overhead in A8.

In the A8-version I always got coordinates for the whole texture. That means, if I returned just the color * alpha, I stretched -all frames- on the texture surface. After some experimenting, I used the following construction in my vertex shader:



I wasted two material skills for the flag if this is an animated sprite and another one for which frame it is. I didn't knew if this is right or wrong, but hey, it worked

Now, when checking if they work with A7, I encountered that something went wrong. After some trial and error I recognized that I can simply do



without that matTexture-related instructions. I used a compiler switch to detect if this is A8 or A7 and set a float to see if this is A8, so that I can branch into this extra code-section (or better said: to leave it, if it is A7):



So, you might ask "what is the point? It works for him!"

Well, if you accidently changed this behaviour while migrating to A8, please fix it, because it saves me lots of overhead and additional shader cycles ;-)

Proper shader code makes no difference if sprites are animated or not.

Just use the standard shader functions and you will save yourself a lot of work. Correctly sending texture coordinates looks like this:

Out.Tex = DoTexture(inTex);

A8 and A7 are different engines and of course handle rendering in many different ways. A8 loads all frames in a single texture, A7 used a separate texture for every frame. But this is mostly irrelevant for your shader code because the standard shader functions take care of all such differences.

It could just be me, but I don't think the "standard shader functions" are particularly popular amongst shader programmers -- at least, I prefer to handle transformations myself in order that I can make changes as needed for the effect I need.

Jibb

It's just like programming: when you don't mind additional work, you can write everything yourself, without using any external function libraries. But normally, shaders are not done this way today. Shader programmers normally want to program only their effects and don't want to write 100 variants and branches for all different shader situations.

But the "standard shader functions" are just functions anyway, the majority of which contain no branches whatsoever. So whether we use the "standard shader functions" or not, it makes no difference to how many variants and branches we need to write for the shader situations in our games.

Surely the best answer would've been that the change between A7 and A8 is indeed intentional, but hasn't yet been documented?
@HeelX: This is A8's DoTexture. I don't know what A7's DoTexture looks like, but I imagine the difference is the way matTexture works rather than the actual DoTexture functions, since this function makes no attempt to do the animation itself.

Jibb

Thanks jcl and Julz for the insights and hints. I'll check 'em out.

...

But I don't like using your shader library for several reasons. The most important one is that your proposed method solely depends on that lonely default.fx file which is located somewhere, somehow in the Gamestudio installation folder.

I really like the idea to throw my shaders into a project and they run. If they depend on a shader library which is totally engine-related, than this .fx should always be included automatically by the compiler and not by hand with ambigue PRAGMA_PATH stuff.

Really, - how can I assert that the user copies the default.fx into his project? How can I assert that the default.fx is included if the user didn't before? How can I assert that the default.fx is the right one? How can I make sure that this file is published properly along my shaders in the release version of a project?

I can't. I could if it is automatically included and published during runtime. You have primitive models included in your engine, why not the compiled version of the default.fx??

So - the point is: if I could make sure with a single like of code, like

#include <default.fx>

that this library is loaded - than I would use it probably.

When you want to release something to the public, you must make sure to include all needed files. Including .fx files is absolutely no different then including models or any other resources.

I know :-)

What is nagging me is that I have to publish the code\ folder of the Gamestudio installation for loading the default.fx properly:



Which is only valid for dev-mode ... what if the user - or I for demo reasons - want to publish it? Then he/I have to add the default.fx into that folder (beside the compiled .exe, acknex.dll and so on).

That is an unconvinient situation, I also think that the publish dialog doesn't copy the default.fx...

So the only way to publish sourcecode to the public using the default.fx file is to do the #define as stated above for dev-mode and when publishing binaries loading the .fxo files instead. Isn't it?

I hope you understand this issue...

Best regards,
-Christian

BTW: can't you just place some #defines like #define A8 and/or version defines like #define A8_1_0 or so into acknex.h to enable engine(-version) dependent compiler directives?