Sign in to follow this  
HexorBlue

SDL rendering vs OpenGL rendering

Recommended Posts

Which is faster: using an SDL_Surface with draw and flip or using that surface to create an OpenGL texture and rendering it with OpenGL's blitting and rendering functions? Keep in mind this is in reference to 2D rendering. And another question: Does SDL use video hardware as efficiently as OpenGL?

Share this post


Link to post
Share on other sites
SDL_Surface blitting does not use any acceleration at all. Unless you plan on targeting computers without 3D cards or have some special per-pixel rendering, OpenGL will afford you far more speed and flexibility.

Share this post


Link to post
Share on other sites
I just went through this whole thing some months back. I began using SDL with C++ trying to make a 2D scrolling background. Then I found Python and Pygame and this increased my coding efficiency an enormous amount. But still when I finished despite all the optimizations I still had problems. Everyone said that it was next to impossible to create smooth scrolling backgrounds with just SDL.

Then I switched back to C++ and SDL with OpenGL and was just blown away. The results are simply night and day. The only problem I experienced was VSYNC issues for LCD monitors. You have to set swap enable in the code or make sure that the video card enables it.

I read that the next release of SDL will make better use of hardware surfaces.

The other thing I noticed was that SDL with software surface rendering used much more cpu than OpenGL. ( I noticed this on Windows task manager. People have said that this is not a good way to measure cpu usage, but I had my SDL program use 80-90% cpu and the OpenGL use 6%. The only thing different was rendering method. )

I am now able to do smooth scrolling in x and y, manage my game entities (including AI), do collision checking for all of them, and render them as necessary. With just SDL this would not be possible. The other thing is that SDL is helped when you can exploit dirty rects, but some applications require updating the whole screen each frame.

Share this post


Link to post
Share on other sites
Quote:
@signal_:

You could have stuck with Python and still got the benefits of OpenGL (yes - this implies that I believe that almost all your speed gains have been OpenGL and not C++ related).

I agree with this. I still like and use python. Although I have not used PyOpenGL or whatever it is called. I think python/pygame/pyglet is excellent for quick coding or prototyping ideas.

I just switched back to C++ when I was paranoid about game speed. Most likely python with OpenGL could achieve similar results to what I am seeing now.

Share this post


Link to post
Share on other sites
Quote:
Original post by signal_
I agree with this. I still like and use python. Although I have not used PyOpenGL or whatever it is called. I think python/pygame/pyglet is excellent for quick coding or prototyping ideas.

But pyglet can give you almost all the coding efficiency of pygame with almost all the performance of OpenGL. Worth bearing in mind.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this