How to scale to resolution in SDL?

10
votes

I'm writing a 2D platformer game using SDL with C++. However I have encountered a huge issue involving scaling to resolution. I want the the game to look nice in full HD so all the images for the game have been created so that the natural resolution of the game is 1920x1080. However I want the game to scale down to the correct resolution if someone is using a smaller resolution, or to scale larger if someone is using a larger resolution.

The problem is I haven't been able to find an efficient way to do this.I started by using the SDL_gfx library to pre-scale all images but this doesn't work as it creates a lot of off-by-one errors, where one pixel was being lost. And since my animations are contained in one image when the animation would play the animation would slightly move up or down each frame.

Then after some looking round I have tried using opengl to handle the scaling. Currently my program draws all the images to a SDL_Surface that is 1920x1080. It then converts this surface to a opengl texture, scales this texture to the screen resolution, then draws the texture. This works fine visually but the problem is that its not efficient at all. Currently I am getting a max fps of 18 :(

So my question is does anyone know of an efficient way to scale the SDL display to the screen resolution?

1
c++openglsdl
are you drawing,converting and scaling on the fly when you're using opengl?? – silent
Also ask the guys on the gamedev forum, they should be able to help you. – silent
Yes I am that's why it is so inefficient. But currently I can't find any other way of doing it that works. Ok will do. – David Saxon
why scale every time you draw. Just scale the loaded texture store that in memory and then delete the large texture from memory. It's not likely that the user is going to be changing the scale they are running at while running the game. This will increase load time but its a lot more efficient than doing it on the fly each render. You should be able to use the same method you are currently using ont he fly to get the texture scaled down. – Brendan
Because the texture I scale each time is effectively the display of the game. So I have to convert it each frame as it is has new surfaces drawn to it each time. If there was a way of drawing sdl surface to an opengl texture then I would only have to load and scale the texture once. – David Saxon

1 Answers

10
votes

It's inefficient because OpenGL was not designed to work that way. Main performance problems with current design:

  • First problem: You're software rasterizing with SDL. Sorry, but no matter what you do with this configuration, that will be a bottleneck. At a resolution of 1920x1080, you have 2,073,600 pixels to color. Assuming it takes you 10 clock cycles to shade each 4-channel pixel, on a 2GHz processor you're running a maximum of 96.4 fps. That doesn't sound bad, except you probably can't shade pixels that fast, and you still haven't done AI, user input, game mechanics, sound, physics, and everything else, and you're probably drawing over some pixels at least once anyway. SDL_gfx may be quick, but for large resolutions, the CPU is just fundamentally overtasked.
  • Second problem: Each frame, you're copying data across the graphics bus to the GPU. This is the slowest thing you can possibly do graphics-wise. Image data is probably the worst of that, because there's typically so much of it. Basically, each frame you're telling the GPU to copy two million some pixels from RAM to VRAM. According to Wikipedia, you can expect, for 2,073,600 pixels at 4 bytes each, no more than 258.9 fps, which again doesn't sound bad until you remember everything else you need to do.

My recommendation: switch your application completely to OpenGL. This removes the need to render to a texture and copy to the screen--just render directly to the screen! Also, scaling is handled automatically by your view matrix (glOrtho/gluOrtho2D for 2D), so you don't have to care about the scaling issue at all--your viewport will just show everything at the same scale. This is the ideal solution to your problem.

Now, it comes with the one major drawback that you have to recode everything with OpenGL draw commands (which is work, but not too hard, especially in the long run). Short of that, you can try the following ideas to improve speed:

  • PBOs. Pixel buffer objects can be used to address problem two by making texture loading/copying asynchronous.
  • Multithread your rendering. Most CPUs have at least two cores and on newer chips two register states can be saved for a single core (Hyperthreading). You're essentially duplicating how the GPU solves the rendering problem (have a lot of threads going). I'm not sure how thread safe SDL_gfx is, but I bet that something could be worked out, especially if you're only working on different parts of the image at the same time.
  • Make sure you pay attention to what place your draw surface is in SDL. It should probably be SDL_SWSURFACE (because you're drawing on the CPU).
  • Remove VSync. This can improve performance, even if you're not running at 60Hz
  • Make sure you're drawing your original texture--DO NOT scale it up or down to a new one. Draw it at a different size, and let the rasterizer do the work!
  • Sporadically update: Only update half the image at a time. This will probably close to double your "framerate", and it's (usually) not noticeable.
  • Similarly, only update the changing parts of the image.

Hope this helps.