I thought we could maintain a copy of the OpenGL machine state (e.g. if tex units are enabled, or lights, or whatever), so unnecessary calls are avoided (we check if it's already in the good state and if it isn't we call the state change method).

I thought we could maintain a copy of the OpenGL machine state (e.g. if tex units are enabled, or lights, or whatever), so unnecessary calls are avoided (we check if it's already in the good state and if it isn't we call the state change method).

What do you think of that ?

We had to investigate this. But I don't think one or two redundant state changes per frame aren't that expensive. And we would do just more state maintaining.

I thought we could maintain a copy of the OpenGL machine state (e.g. if tex units are enabled, or lights, or whatever), so unnecessary calls are avoided (we check if it's already in the good state and if it isn't we call the state change method).

What do you think of that ?

We had to investigate this. But I don't think one or two redundant state changes per frame aren't that expensive. And we would do just more state maintaining.

I said there was no performance-difference, so appearantly the JNI wasn't significant (1100ns on a P4 2.4GHz - Java 1.5)

Further, you don't need to speak in CAPITALS to make it clear. For more complex states (switching texture-units, setting lots of lighting-parameters) is ofcourse good to keep a local state, but beware, by the time you're storing your states in (hash)maps/stacks, you're probably starting to lose performance.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org