Quote:
Well, we all are used to wait in Amiga-land (and I mean all flavors by that)
That reminds me that I have to write a large bug-report regarding compositing-engine-flaws on R200-hardware on AOS4...

Quote:
That's right, it just came back to my mind during typing, should help to underline the importance of that feature

But the other points are answers to the question, why to prefer the texture-matrix over manual multiplying in general and why I want it in my case, to sum it up:

- it is a core feature of GL.
- it works with every texcoord-type out of the box.
- it works with every array-type / stride out of the box.
- you don't need to track if an array was already multiplied.
- it works with const arrays, no need to create a copy and change array-pointers etc.
- the key is that it works transparently, only the BindTexture-Wrapper has to do something for it to work.
- plus it offers additional features a simple mul-loop can't do (just as an example, it could be used to procedurally generate and use texture-atlases without the rest of the program knowing the final UVs, thanks to the possibility to also translate the matrix)

In my scenery, which I described in post #7, this is clearly the very best approach, because this scaling is used to compensate the non-existance of NPOT-texture-support. It would be insane to approach this manually, you'd end up adding lots of code and complexity, additional dependencies and potential source for problems or performance penalties on other systems, only to support that very rare case (well, not so rare on MorphOS ).
A simple five-line-multiplication-loop is just not enough to handle this in a correct way.

Cheers,
Daniel