Hello, when I first saw SDL, I thought all the graphics routines would rely on DirectX under Windows and on OpenGL under Linux. Since then I read a lot of different things, but I'm not sure what's really going on. There's a thread in this forum where someone wants to make an isometric RTS and SDL is too slow for his high resolution, and someone said there that SDL Blitting is done completely on the CPU. But if it's based on DirectX, and all the graphics are in the graphic adapter's video RAM, shouldn't it be done by the GPU? Sorry if this sounds noobish but I don't know too much about video hardware. And I read that under Linux it's not using OpenGL by default, rather it uses some X11-stuff. Now, what's really going on? And is it always recommended to use real OpenGL functions instead of the SDL Blitting functions? Because for me, some REAL 2D blitting stuff would be perfect, since I found out that OpenGL 2D-projection is not always pixel perfect (I actually did some stuff with textures and displaying them on a 2D matrix, but when my level was scrolling around, some objects would be displayed one pixel further away to each other etc). So I'd rather use real 2D blitting instead of some 3D->2D projection. But still it should be fast enough of course ;) (EDIT: I focus on games for Windows, so it would be especially important to me if at least the Win/DirectX stuff would be fast enough with SDL)

SDL uses the DirectDraw component of DirectX, not Direct3D/DirectGraphics. Thus most of the work does not take advantage of advanced graphics hardware. In other words, it's relatively slow.

Where performance matters, you will need to use OpenGL. (Or the DirectX equivalents, but getting that to work with SDL is less well documented.)

OpenGL (and DirectX) 2D projection can be pixel perfect if you do it properly. I believe this involves using offsets in some cases to ensure that nothing rounds up to the next pixel, and so on. You will probably get better answers on that in the OpenGL forum however.

Well we developed a little game for school some months ago, where we were using the standard blitting functions. With 640x480 and a basic tile-size of 32x32 we got around 170 fps. I think I'll try running it with a higher resolution to estimate a little bit if it's still possible for my new engine. And of course I could make some abstract sprite class where I can encapsulate either the SDL_Surface or some OpenGL stuff.

For pixel perfectness, I also tried not to round values but just flooring them to int, so they should always be perfect aligned. But perhaps I overlooked something, I'll give it another try.

One concern I have with OpenGL is that Microsoft might continue restricting its use in Windows. Under Vista they have already begun... and perhaps they might push that further and further... it just seems a little unsecure and since I want my games to run primarily on Windows, this is one thing that is very important to me. On the other hand, I don't want to use pure DirectX, just for the case I want to make some Linux or Mac versions later.

Is there any lib that supports 2D sprites, which are really made of OpenGL / DirectX textures (depending on the operating system), and is completely pixel-perfect? I think this would be some great thing for future versions of SDL.

Quote:Original post by ZeHa
One concern I have with OpenGL is that Microsoft might continue restricting its use in Windows. Under Vista they have already begun...

How exactly have they began to restrict OpenGL?

I read some article where it said that Microsoft restricted OpenGL applications in disabling some fancy Aero stuff and running slower than comparable DirectX applications.

Its all bull-anti-microsoft/vista propaganda.
OpenGL and DirectX performance is as equal in Vista as it is in XP, they arent easy to compare as most games only use one or the other, and because games are written differently they have different performances and so saying a heavily unoptimised opengl program is proof that vista performance with opengl is bad is a stupid thing to say.

Well it was an article on a usual news page, where one should be able to believe what they say. But I re-checked it now and noticed that it was an article from 2005 ;)

Okay, then it seems there shouldn't be a problem with using OpenGL? Perhaps I'll just implement the SDL blit and OpenGL texture stuff in different sub-classes of a Sprite class, then I can switch on the fly and check out the FPS results...

hxRender can help you get started with your OpenGL blitting routines. Its source code is posted at the link above and the only restriction on its use is that you have to credit the author if you use it.

There are a few snags to using OpenGL textures in 2d graphics programs that hxRender works around. First of all, if your texture isn't a power of two height and width you'll need an OpenGL extension or use hxRender to divide the image into multiple blits (it's slow but it works and is functional on all graphics cards). Secondly, you have to know how to turn off the Z-buffering or your sprites won't overlap properly. Thirdly, you want to open the screen with an orthogonal projection with the y-axis inverted to get normal screen coordinates (hxRender does this for you).

Quote:Original post by ZeHa
Well it was an article on a usual news page, where one should be able to believe what they say. But I re-checked it now and noticed that it was an article from 2005 ;)

Okay, then it seems there shouldn't be a problem with using OpenGL? Perhaps I'll just implement the SDL blit and OpenGL texture stuff in different sub-classes of a Sprite class, then I can switch on the fly and check out the FPS results...

Well, it's tougher to switch on the fly because you need to re-establish the context.

Just make sure with SDL that all your surfaces are software and converted to match the screen format :)