Core improvement (Eric)

I was thinking, there may be a need to switch resolutions and/or fullscreen mode while an app is running. Think you could enable that in the display system?

I’m on it.

Hrmm. Well, I’ve found that it’s easy to implement badly. Simply switching between windowed/fullscreen or changing the resolution is a simple matter. Unfortunately, this has a far-reaching impact: for the rendering to continune to work correctly, OpenGL must be reinitialized. This includes all textures, vertex programs, etc. So, I’ve hit a bit of a brick wall. Any suggestions on how to go about reinitializing all these things from inside the DisplaySystem?



One “solution”: If the user is using AbstractGame, we can call initSystem and initGame - but this won’t really work. Ideas?

Oh wow, that’s not good. Hmmm, I’ll have to think about that. Calling init system and init game would reset the game state. Geez… I’m not sure what to do.

Just thought of something. Textures are the only thing we lose when resetting GL, right? If so, that means if you add a reinitialize in the TextureManager, that could reset all the textures. Maybe… :slight_smile:

Well, everything associated with the OpenGL context is lost. I searched for exactly what that encompasses, but didn’t get a good answer. I’m assuming it would also include things like display lists, shader programs, matrix settings, and so on. The brick wall looms higher, I fear. :?

Well, everything is set to identity at the beginning of rendering, so matrices are ok. Display lists are never used, as Vertex Arrays are. Shader Programs aren’t in yet, but we can deal with it when the time comes. I think the only think lost that is not reset anyway is the actual Texture id set by OpenGL. Fortunately, most things I abstract away from the rendering itself. So, jME keeps track of the rendering state. So, if we are able to reinitialize the textures using the TextureManager, I’m hoping that will take care of that, and the scenegraph will take care of the rest.

Sounds good. I’ll try that when I get a chance and see if everything works properly. If so, I’ll commit the changes, and that’ll be that!

Oops, TextureManager doesn’t bind. LWJGLTextureState does. It only binds if the texture id is set to zero. So, we’d have to go through every state and set texture to 0. Which isn’t good because we won’t know where these states are (they are assigned to scene nodes).



If Gl.glBindTexture(GL.GL_TEXTURE_2D, buf.get(0));



where buf holds the texture id would return something when bindings are screwed up we could set it there, but I still don’t think that will work.



Boy, I wish they didn’t destroy GL during a resolution change.

why dont you store the texture states in a stack (including their addresses), clear the actual state, and then reinitialise from the stack?

That’s just not how the scenegraph works. TextureStates can be set in one node, but not another. Texture States are created by models automatically and set. So, the user will not always be creating the textures themselves. I personally think the answer lies in making LWJGL better. I’ve talked to Cas about it, and he agrees. But who knows when it can be taken care of.



I’m starting to lean towards not allowing the user to change resolutions while running until then.