121
Graphics / Proper ways of handling GL states with mixed rendering
« on: March 20, 2012, 05:08:47 pm »
2.0. One of the latest snapshots from after the naming convention change.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
122
Graphics / Proper ways of handling GL states with mixed rendering
« on: March 20, 2012, 03:53:03 pm »
When using sfml with mixed rendering, as in you have your own implemented openGL rendering which happens before or/and after calls to the sfml draw() method, it might often mess things up. For instance I know many people who use sfml to handle events/creating a window and drawing text while taking care of the rest of the rendering by themselves. Most if not all of those people have run into problems with the text not displaying properly, or their own rendering breaking after trying to draw text. I myself too have had problems with this. Apparently this is due to openGL states becoming changed and not reset by the draw method.
This seems to me as a quite big limitation when you want to use sfml in any project which needs any form of rendering which is not able to do with the sfml shapes/sprites classes and this is not a rare case. Even now, knowing this problem I still don't know how to handle it properly; which states to set before and after the draw method and it is often frustrating to solve.
What is the thought behind this behaviour and is it fixable? Perhaps it is intended even? To me it would make sense that sfml would set the things it needs for rendering, and then reset it back to the states they had to not conflict with other components. If this would add too much of an overhead, perhaps the RenderWindow could have a flag for it? Or as the very least, would this be documented so that the users would properly know which states they should themselves reset after calling the sfml draw method? It is a way too common problem.
This seems to me as a quite big limitation when you want to use sfml in any project which needs any form of rendering which is not able to do with the sfml shapes/sprites classes and this is not a rare case. Even now, knowing this problem I still don't know how to handle it properly; which states to set before and after the draw method and it is often frustrating to solve.
What is the thought behind this behaviour and is it fixable? Perhaps it is intended even? To me it would make sense that sfml would set the things it needs for rendering, and then reset it back to the states they had to not conflict with other components. If this would add too much of an overhead, perhaps the RenderWindow could have a flag for it? Or as the very least, would this be documented so that the users would properly know which states they should themselves reset after calling the sfml draw method? It is a way too common problem.
123
Graphics / Font drawing gives GL_INVALID_VALUE[Fixed?]
« on: August 07, 2011, 12:39:49 am »
Noone knows? D:
124
Window / Weird stuttering and freezing
« on: August 05, 2011, 10:06:13 pm »
I also had this problem and disabling the desktop composition helped as well. Not nice if every player would have to do that to play the game though. :/
Somebody who knows a workaround?
Somebody who knows a workaround?
125
Graphics / Font drawing gives GL_INVALID_VALUE[Fixed?]
« on: August 04, 2011, 10:06:32 pm »
I am also working on the same project as jefvel.
This is the code we add to the main loop that makes the text renderer's text rendering work. However, this code itself gives the same error:
http://pastebin.com/nNfFtERW
So with this code-snipped commented out, the text renderer breaks and gives the openGL error to the terminal. With it, the snipped itself breaks with that error, but the text renderer works.
The extra snippet is run before the text renderer.
We are using sf::RenderWindow for rendering and we draw stuff on it with raw openGL before rendering the text on it (in the case of the snippet, the text is rendered before the openGL rendering is done)
If we comment out our main loop that runs our whole game engine structure and replace it with this: http://pastebin.com/svFQb3RA
then it works flawlessly, drawing the text.
Can there be any conflicting openGL code in the rest of our rendering system that conflicts with the text rendering of sfml?
This is the code we add to the main loop that makes the text renderer's text rendering work. However, this code itself gives the same error:
http://pastebin.com/nNfFtERW
So with this code-snipped commented out, the text renderer breaks and gives the openGL error to the terminal. With it, the snipped itself breaks with that error, but the text renderer works.
The extra snippet is run before the text renderer.
We are using sf::RenderWindow for rendering and we draw stuff on it with raw openGL before rendering the text on it (in the case of the snippet, the text is rendered before the openGL rendering is done)
If we comment out our main loop that runs our whole game engine structure and replace it with this: http://pastebin.com/svFQb3RA
then it works flawlessly, drawing the text.
Can there be any conflicting openGL code in the rest of our rendering system that conflicts with the text rendering of sfml?