Quote:

Actually it doesn't matter what I want to try
But well, you answered your question yourself already: "manually".

I don't want to multiply each UV "manually".
I want to use the core feature GL_TEXTURE-matrix that last not least was invented to avoid such manual multiplications.

It boils down to this:

1. the UV-scaling itself needs to be done because many textures in my project aren't POT and need to be made POT during run-time on devices that don't support NPOT.

2. if the underlying system doesn't support NPOT then such a texture is blowed up to the next POT-size and pixels are either scaled (that's the fallback I currently use, results in poorer quality) or not (that is the texture's significant pixels remain top-left and the additional POT-pixels are filled with 0, then the texture-object is marked as being POTified and a UV scaling factor is calculated).

3. the point is: I don't know during compile-time which textures end up POTified and which don't and if POTified, which algorithm was chosen. In my layouts I asume the original assets size and UVs.

4. so I could either chose the unelegant variant you propose and multiply every UV I use by the factors of the bound texture manually.
Bad idea, for several reasons. One being that the UVs may be floats or ints or whatever. Another being that the stride between the UVs is varying. So I would have to implement either a smart and slow version that handles all possible cases or a ton of variants that handle each case. And I would have to call that before issuing a draw-command.
Oh, but wait, there's a pitfall: I will have to be really careful when I want to reuse a UV-array for another draw-call. Was it already multiplied or not?
You see: manually multiplying is a really bad idea.

5. therefore I want to use the texture-matrix. This solves all those issues. If it would work.

I know that modifying the texture-matrix for each such texture is not the most performant way to draw things. But it is not more performant to do UV-scaling manually neither (at least not on systems that cannot do NPOT... , and the texture-matrix scaling is only done if it really needs to be done, of course).
Of course it would be best if the assets would all be prepared in a prescaled way and the layout-definitions would use the "pre-scaled" UVs in the first place. But this again makes no sense in my case, since a) the performance gain is neglectable and b) it would make designing the game more time-consuming, it is easier to just use pictures as the artist designed them and be done and c) most systems (including AOS4 compositing) I target can do NPOT, actually MorphOS is the only one that can't .

[ Editiert durch Daytona675x 30.01.2014 - 09:37 ]