Linux/OpenGL/SDL Rendering efficiency question
Author
Hello all
I'm wondering what would be the most efficient way to get stable rendering using openGL, on Linux with SDL_GL_SwapBuffers()
On Windows, its simpler because the OS will dispatch a WM_PAINT message, then you know your window is ready to render.
What about SDL ? theres no rendering message coming from the SDL_PollEvent() call.
Thanks for sharing your experience.
What do you mean?
On plain Windows OpenGL games you would bypass the WM_PAINT message in favor of your own gameloop, calling swapbuffers once per frame (when you're done rendering), with SDL on either platform you don't need to bypass it and you just create your own game loop.
If instead of a game you're creating an editor, and calling swapbuffers inside the OnPaint event, I recommend you use wxWidgets rather than SDL.
On plain Windows OpenGL games you would bypass the WM_PAINT message in favor of your own gameloop, calling swapbuffers once per frame (when you're done rendering), with SDL on either platform you don't need to bypass it and you just create your own game loop.
If instead of a game you're creating an editor, and calling swapbuffers inside the OnPaint event, I recommend you use wxWidgets rather than SDL.
Author
Quote:Original post by owl
What do you mean by "stable rendering"?
Reduced scattering, on windows(using openGL and the win api) the game is really stable.
Quote:Original post by Kwizatz
On plain Windows OpenGL games you would bypass the WM_PAINT message in favor of your own gameloop, calling swapbuffers once per frame (when you're done rendering), with SDL on either platform you don't need to bypass it and you just create your own game loop.
If instead of a game you're creating an editor, and calling swapbuffers inside the OnPaint event, I recommend you use wxWidgets rather than SDL.
Thanks, that's the kind of answer I was looking for.
What do you guys think about rendering in a thread ?
Quote:Original post by md_lasalle
What do you guys think about rendering in a thread ?
I don't think OpenGL is thread safe (though I guess it depends on the implementation), also I kind of recall reading somewhere that you cannot render to an OpenGL Context from a thread that did not created it, so keep all your OpenGL calls in a single thread (the main one to be safe).
You can however use multiple threads for other tasks like AI, Sound, Input, etc.
Author
what about the operation of swapping the buffers do you think it would benefit in any way for it to be on its own thread so that you can easily control the rate at which it is being called ?
let's say my target is 60 fps, meaning each frame has 16.7 ms to render, and that my last frame took 4 ms to render, I could make the thread sleep for 12.7 ms before swapping the buffer again.
what is your opinion on this kind of approach ?
let's say my target is 60 fps, meaning each frame has 16.7 ms to render, and that my last frame took 4 ms to render, I could make the thread sleep for 12.7 ms before swapping the buffer again.
what is your opinion on this kind of approach ?
That is indeed a common approach to limiting FPS. But I wouldn't create a separate thread whose sole responsibility is swapping buffers.
Imagine the situation where your program is running slower than 60FPS. What happens if your buffer-swapping-thread gets activated and swaps your buffers while you're still writing to the frame buffer? You'll get an awful mess -- I'd advise you to keep a maximum of one thread where all draw and swap calls get called per context.
Imagine the situation where your program is running slower than 60FPS. What happens if your buffer-swapping-thread gets activated and swaps your buffers while you're still writing to the frame buffer? You'll get an awful mess -- I'd advise you to keep a maximum of one thread where all draw and swap calls get called per context.
Quote:Original post by KwizatzQuote:Original post by md_lasalle
What do you guys think about rendering in a thread ?
I don't think OpenGL is thread safe (though I guess it depends on the implementation), also I kind of recall reading somewhere that you cannot render to an OpenGL Context from a thread that did not created it, so keep all your OpenGL calls in a single thread (the main one to be safe).
You can however use multiple threads for other tasks like AI, Sound, Input, etc.
Wrong, you can make the GL context current to any thread and start making GL calls. Read the msdn documentation.
Although I don't see why you would want to do that. All gl function calls go to 1 graphics card.
Quote:Original post by md_lasalle
what about the operation of swapping the buffers do you think it would benefit in any way for it to be on its own thread so that you can easily control the rate at which it is being called ?
let's say my target is 60 fps, meaning each frame has 16.7 ms to render, and that my last frame took 4 ms to render, I could make the thread sleep for 12.7 ms before swapping the buffer again.
what is your opinion on this kind of approach ?
Well, what would you be doing for the time you wait for the thread to wake up? probably lock the rendering thread until the other one calls swap buffers, so its really no use.
Rather than play catch up to a target FPS, you should strive for frame rate independent movement, its not that hard, and there are two articles about it right here and here.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
