SDL: sprites vs opengl
Author
Hi all
First post and first question. Actually my second, but it seems my first didnt go through.... and was solved by finding some examples anyways.
In general, which is more efficient: a scrolling tile system that uses SDL sprites, or billboards in opengl? Seems to be the latter with D3D. What about openGL via SDL vs opengl directly? Im looking to change a small DirectX program into a platform independent one.
Another one of those that is best to find examples :o) But I would like to do this without the need for more modern cards (Im using an older one at the moment) and am curious about what experiences others have had.
Cheers
Billboards in OpenGL? The closest thing to SDL's 2D functions would be to use OpenGL in 2D (Ortho) mode.
OpenGL is going to be faster for most sprite engines, but it requires more hardware. (So you lose compatibility with older PCs)
Keep in mind though; don't underestimate software blitting. If your game uses non-alpha-blended largish (say, 32x32 and up) sprites on a low resolution (640x480 or below, for example), SDL's software blitting will probably be plenty fast.
However, if you need alpha-blended sprites, lots of little sprites (Particles, for example), at high resolution, or sprite rotation... OpenGL will almost certainly be faster.
OpenGL is going to be faster for most sprite engines, but it requires more hardware. (So you lose compatibility with older PCs)
Keep in mind though; don't underestimate software blitting. If your game uses non-alpha-blended largish (say, 32x32 and up) sprites on a low resolution (640x480 or below, for example), SDL's software blitting will probably be plenty fast.
However, if you need alpha-blended sprites, lots of little sprites (Particles, for example), at high resolution, or sprite rotation... OpenGL will almost certainly be faster.
Quote:Original post by Sammy0037
In general, which is more efficient: a scrolling tile system that uses SDL sprites, or billboards in opengl?
I doubt you're going to find a system with OpenGL installed where SDL sprites outperform it.
Quote:What about openGL via SDL vs opengl directly? Im looking to change a small DirectX program into a platform independent one.
Using SDL incurs no performance overhead compared to OpenGL on its own. All it does is handle the set up for you - beyond that point you use OpenGL directly and SDL stays out of the way.
Quote:But I would like to do this without the need for more modern cards (Im using an older one at the moment) and am curious about what experiences others have had.
How modern is modern? I'm guessing that on anything from a Riva TNT 2 onwards, an OpenGL implementation will outperform a plain SDL sprite (ie. DirectDraw) implementation, certainly if you do any alpha blending.
Quote:Original post by KylotanQuote:Original post by Sammy0037
In general, which is more efficient: a scrolling tile system that uses SDL sprites, or billboards in opengl?
I doubt you're going to find a system with OpenGL installed where SDL sprites outperform it.
The only time i've seen SDL sprites outperform OpenGL is on a linux system with an integrated graphics chipset, or using the open source drivers for for a video card. In which case I've seen a 2D game in OpenGL get about 2 frames per second (though after installing the drivers directly from nvidia the frame rate improved dramatically).
I think this is largely a linux issue though, so if you are't going to make a linux executable you won't have the problem.
It is also possible (though not necessarily the best idea) to use a scrolling tile system and use OpenGL to render it.
Quote:What about openGL via SDL vs opengl directly? Im looking to change a small DirectX program into a platform independent one.
All SDL really does in OpenGL is create a window that you can draw the opengl stuff to, you're going to need to do this regardless and SDL makes it easy.
Here's a good overview of Direct3D vs. OpenGL at wikipedia.
Author
The background tiles will be 32x32 as a minimum. Quite likely they will be a bit larger as it will be kept simple. As it stands now, the game objects themselves are xfiles. A few are simple squares using textures with alpha channels. Yes its ortho. Simple overhead game, but with a playing area larger than the screen.
As for cards, and processors, I was thinking a max of 5 years old. So if there are parts that will be pushing it too much, now is the time to think about it. Maybe the first thing to do is simply give the option to turn various things off and/or choose less complex items.
And thank you for the link. :o)
As for cards, and processors, I was thinking a max of 5 years old. So if there are parts that will be pushing it too much, now is the time to think about it. Maybe the first thing to do is simply give the option to turn various things off and/or choose less complex items.
And thank you for the link. :o)
Quote:Original post by Will F
The only time i've seen SDL sprites outperform OpenGL is on a linux system with an integrated graphics chipset, or using the open source drivers for for a video card. In which case I've seen a 2D game in OpenGL get about 2 frames per second (though after installing the drivers directly from nvidia the frame rate improved dramatically).
I think this is largely a linux issue though, so if you are't going to make a linux executable you won't have the problem.
AFAIK it's a general problem on every OS - when video card drivers are very old, or default ones.
My friend tried running "Herbata ... kroliczek" (that game in my sig) with default drivers on his AMD 700 Mhz, GeForce 4 MX and 256 RAM - moving mouse, you could see that mouse cursor had 1 second of delay before it changed its position, and you had to click many times before it was recognized by event manager. And all of that happened in main menu, where all what is rendered, are 10 textured quads... imagine what would happen in real game - 15 seconds per frame, anyone? :-)
Of course, when we installed normal drivers, all problems disappeared.
Author
When I was thinking platform independent, I was figuring: cool, this little game will work in Linux too. Of course I expect its not as simple as some things Ive read make it out to be. But sometimes I can be pessimistic.
Case in point: On the quest to remove windows-specific code and move more to OpenGL and STL, I figured I would start with some of the more basic functions first. Just to get my feet wet in what I figure will be a long process. Im not a code wiz. Example: I couldnt figure out why a simple BOOL datatype just didnt work anymore. I looked and looked and looked, until I found that the word BOOL (capital letters) itself IS windows specific, and required the stdafx header I removed. Change to 'bool' (lowercase), and voila.
Please feel free to laugh. I was mad at myself for missing something so simple ;-)
Case in point: On the quest to remove windows-specific code and move more to OpenGL and STL, I figured I would start with some of the more basic functions first. Just to get my feet wet in what I figure will be a long process. Im not a code wiz. Example: I couldnt figure out why a simple BOOL datatype just didnt work anymore. I looked and looked and looked, until I found that the word BOOL (capital letters) itself IS windows specific, and required the stdafx header I removed. Change to 'bool' (lowercase), and voila.
Please feel free to laugh. I was mad at myself for missing something so simple ;-)
Another thing to watch out for is that filenames in linux are case sensitive. For example #include <sdl.h> should work with windows, but won't on linux (it needs to be SDL.h)
This will also be the case with loading images, on linux Bricks.bmp and bricks.bmp are two different files.
This will also be the case with loading images, on linux Bricks.bmp and bricks.bmp are two different files.
Also, some windows compilers think that the variable 'x' below:
has scope outside of the for loop. C++ does not. More often a problem when porting _to_ windows, but still worth being aware of.
VC6 and previous also tend to get templates wrong, but chances are this won't be an issue, and certainly not in the direction you are porting.
After that, so long as you are using SDL and OpenGL and a cross platform sound library, I have found nothing actually needs changing when going to a windows platform from linux. The other way shouldnt be too much worse :)
for (int x = 0; x < 6; ++x){}has scope outside of the for loop. C++ does not. More often a problem when porting _to_ windows, but still worth being aware of.
VC6 and previous also tend to get templates wrong, but chances are this won't be an issue, and certainly not in the direction you are porting.
After that, so long as you are using SDL and OpenGL and a cross platform sound library, I have found nothing actually needs changing when going to a windows platform from linux. The other way shouldnt be too much worse :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
