Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Save/Restore - GLStates got me really confused  (Read 1815 times)

0 Members and 1 Guest are viewing this topic.

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Save/Restore - GLStates got me really confused
« on: June 02, 2011, 12:38:20 am »
Well yeh. The title says it all. I hope this is getting changed when the new graphics API comes because it's like try and error to get it working.

First and foremost, it was like if not all values were being saved, I have to implement my own "Graphics::Context::State" class to keep track of the values that were not properly set which was back face culling and setting polygon mode to only render lines(wireframe).

This behaviour can be replicated by just adding this to the opengl example:
Code: [Select]
glEnable( GL_CULL_FACE );
glCullFace( GL_BACK );
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);


No sprite nor text will be shown when these is enabled. Commenting out glPolygonMode so we do a fill instead of a line between vertexes will still not render any sprite or text. Doing the same with culling but leaving glPolygonMode on will make it so that only a wire frame for the sprite and text is shown. Shouldn't Save/Restore - GLStates handle this so that these values are properly set?

Like I said would be much nicer if we had some cleaner more secure way to do this. Maybe some kind of state class? So we can save away several states and then push them into the render target?

Something like this:
Code: [Select]
sf::State stateFor2D = window.GetDefaultState();
sf::State stateFor3D = stateFor2D;
stateFor3D.SetWireframe( true ); // Not that wireframe is useful in 2D rendering but the only value that came to mind right now.
// Set some more values for our 3D view.

window.SetState( stateFor3D );
// Render 3D
window.SetState( stateFor2D );
// Render 2D
window.Display();


NOTE: After thinking about it, this ain't needed just need to force ALL values in SaveGLStates to be values that SFML drawables expect and then reverse it in RestoreGLStates. Though I feel this approach would be nicer actually.

I don't know if I'm missing some vital point here or something? Just me getting annoyed that I have to try-and-error my way trough to get it working.

Also having another problem that might be related to this but not sure quite yet so I'm holding it off for the time being.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Save/Restore - GLStates got me really confused
« Reply #1 on: June 02, 2011, 10:32:01 am »
You're right, right now it's a big mess and I'll definitely make it much nicer for SFML 2.0.

The problem is that there are hundreds of OpenGL states, some of them are even part of extensions that may or may not be supported by the target GPU, so there's simply no way to reset everything in SaveGLStates.

But don't worry I have other solutions to try ;)
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Save/Restore - GLStates got me really confused
« Reply #2 on: June 02, 2011, 11:26:23 am »
Quote from: "Laurent"
The problem is that there are hundreds of OpenGL states, some of them are even part of extensions that may or may not be supported by the target GPU, so there's simply no way to reset everything in SaveGLStates.


Well then re-factoring it out to a new class which sole purpose is to handle this might be a solution. Also being able to have a list of state-snapshots that you can choose from might be pretty useful. So instead of calling a "Turn on/off wireframe" function you just tell the render target that I want to use my "wireframe snapshot".

Though as you said, there's a LOT of OpenGL states so creating a state snapshot class might be a bit too huge.

NOTE: Also the last problem that I wrote in the bottom of the original post was apparently not part of this. When I removed my threads it disappeared so I'm using contexts wrong somehow. If I can't get it to work I'll post a new thread.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio