SDL rendering vs OpenGL rendering

Started by
6 comments, last by Kylotan 15 years, 5 months ago
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?
Advertisement
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.
Thank you for the prompt reply. What you say is pretty much what I'm getting through various spots on the net.
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.
@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).
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.
A game that i'm making went from 80fps/15%CPU with SDL to 512fps/1%CPU after upgrading to SDL+OpenGL
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.

This topic is closed to new replies.

Advertisement