glTexCoord2f and glMultiTexCoord2fARB

in my program, the following things happen:




and everything looks fine. I guess that when enabling only texture unit 0, glMultiTexCoord2fARB and glTexCoorf2f work just the same!? or why does my program look fine?


If everythings look fine. so what’s your problem here,enn?

sounds right somehow… i will go on working on it and post againg if it does not look fine anymore


Of course glTexCoord2f works when the texture unit is set to zero.
Why shouldn’t it? Everybody uses unit 0, regardless if you are doing
multi-texturing or not.

But I would only use glMultiTexCoord2fARB if you doing multi-texturing
on more than 1 texture unit as that’s what it’s there for.

i thought it could be a problem because there are parts in the scene of which some have multitexturing and others COULD have but in fact do not, and they are treated the same internally. so the parts who COULD have more than one texture but do not have use glMultiTexCoord2fARB while other parts of the scene, who definitley have only one texture, use glTexCoord2f. But it seems to work fine (as it looks fine).


I see immediate mode more as a utility for prototyping and testing. Somewhat more finished code will probably use vertex arrays, and then the difference between unit 0 and higher units will vanish.

what kind of difference do you mean? btw everything is inside of display lists…


Originally posted by JanHH:
what kind of difference do you mean?
Nothing big … let’s rehash this.
In immediate mode you have two basic ways to specify unit 0 texcoords.

One could argue that the second option adds additional function call overhead and should be avoided, but that’s borderline irrational. If you want performance, you shouldn’t be using true immediate mode (as in “not a display list”) in the first place. Hmmm. I see you have that one covered.

However, there’s no such alternative with vertex arrays. glTexCoordPointer always follows the selection made by glClientActiveTexture.

So the difference is that a choice goes away.

[b]btw everything is inside of display lists…

Interesting. Geometry inside a display list behaves just like a vertex array in fast graphics memory, I’d say. I don’t think it’ll make any difference whatsoever in that case.

before i started posting here i thougt that display lists are the best solution in terms of performance (if the geometry data is not too big), but when i wrote about that here, people seemed shocked g, one said “never use display lists” or “use them very rarely” but i never got explained WHY this should be the cause.

Theoretically DL should be the fastest possible solution because every data is already inside of the graphics card memory, and also in a precompiled way. So does anyone know what is wrong with this and WHY vertex arrays are faster/better??

Originally posted by JanHH:
Theoretically DL should be the fastest possible solution because every data is already inside of the graphics card memory

There is no guarantee that this is true. The driver may use vertex array like calls to speed things up.

Don’t worry about performance if you started to learn GL.

Why should display lists be bad? Seriously, I don’t know. You only need to know that they’re immutable (which I think you do).

There’s one usage model I can think of that’s bad. I don’t think many people will want to try it, as it’s somewhat obvious:
Compile a display list, call it once, and delete it (or at least never use it again).

Otherwise just use the right tool for the job. If you have static geometry that you’re going to draw again and again, a display list is the right tool for the job.

Maybe that was just an incentive for you to get some practice with vertex arrays. It’s important to be able to handle dynamic geometry well, too. It’s also more difficult than handling static geometry (optimum performance requires a vertex transfer extension such as vertex_buffer_object).

In the program there are clouds which consists of several thousand particles, I guess for such things vertex arrays (or vertex_buffer_object) are much better than drawing them immediately? But the particles have different colors and are drawn depth sorted, so the order changes… which is the best way to handle this?

I use NV_Point_Sprite and it is faster than drawing quads but not really useful as a point_sprite is limited in size (64 on my ti4200) and the particles can become much larger, in fact nearly screen size, when flying THROUGH a cloud. Any workarounds for this, or do I have to draw quads :frowning: ?