Faster way of scaling-up an image before render? (SDL)

[treefitty]

Hello,

I have a small, simple graphics project I'm working on, and I'm using SDL. Currently, the "default" resolution is 320x240, but my default scale is '2', so, after I get my Screen surface, I copy the pixels to an array of (unsigned long), and copy them back to the Screen's pixels, but scaled-up, with a loop, so the final product is rendered in 640x480. (So, 1 pixel turns into 2x2 px or 4 pixels total.) (Also, it ends up being pixelated, but that's actually what I want)

This works, but it UNDERSTANDABLY starts getting an FPS drop when I increase the scale to something like '4' or above, since it's copying/writing pixel data every frame, and the work increases exponentially the higher the scale.

I'm actually interested in any online topics that cover better ways of doing this. Would anyone happen to have any links to material or theory regarding this topic?

[Disch]

This is why I try to steer people away from SDL 1.x whenever threads about it pop up.

Software rendering is FREAKING SLOW. The only way to speed it up is to do it in hardware, and SDL 1.x doesn't typically do hardware rendering because it's so ancient and was written at a time when the hardware worked differently than it does today.

So yeah.. you're going to get crap performance with SDL 1.x. Best way to speed it up is to choose a better lib. Upgrading to SDL 2.0 should suffice, though I personally prefer SFML.

I'm actually interested in any online topics that cover better ways of doing this. Would anyone happen to have any links to material or theory regarding this topic?

There aren't really articles on the topic* because it's a non-issue with modern graphics hardware. If you want to stretch an image, you just render a bigger polygon and the pixels are stretched automatically.


_{* or at least I should say there aren't any worth reading}

[treefitty]

Thanks for the reply! I believe there is an option to declare a surface as a hardware surface, but I don't know much about it. Should/could I be doing this for my screen instead, to increase performance?

(I would be willing to re-do the project (in SFML for example), however I'm using it as a graded project/experiment and may not have time.)

[Disch]

Thanks for the reply! I believe there is an option to declare a surface as a hardware surface, but I don't know much about it. Should/could I be doing this for my screen instead, to increase performance?

That probably wouldn't help for 2 reasons:

#1 it's more of a request for SDL. If your hardware doesn't actually have hardware surfaces (which... if you have hardware that was made in the last 8 years, it probably doesn't), then SDL will just give you a SW surface anyway.

#2 - It's not that software surfaces are slow... it's that transferring data from the CPU to the GPU is slow. Scaling up a 320x240 image to 640x480 then sending each pixel of that 640x480 surface across the bus to the GPU is what kills you.

Rendering to a HW surface, only to pull the pixels out of the GPU into the CPU... scaling up 2x, then sending back to the GPU would be even slower. So if you're doing any sort of CPU work on individual pixels, you probably want a SW surface.


To speed this up you need to do the stretching in HW. For that... both the source surface and the destination surface need to be in hardware... and the hardware has to be able to stretch it.

AFAIK, SDL 1.x provides no way to do this... as there is no way to stretch any surfaces. So the only way to stretch it is through software.... so you're SOL.

[treefitty]

So, your suggestion would be to use SFML instead, or SDL 2.0? and just to reiterate, either should support what I'm trying to do--but faster?

(I also found this http://lazyfoo.net/SDL_tutorials/lesson36/index.php
which claims that dealing with surfaces may be faster, but am not able to test until later tonight.)

Thanks :)

[Disch]

I haven't looked at SDL 2.0 in great detail so I can't say whether or not it actually does it. Though I'm 95% sure it does (if it doesn't, I'd be REALLY surprised and disgusted).

SFML definitely supports it.

[LazyFoo article] claims that dealing with surfaces may be faster,

I only roughly skimmed but didn't see where it made that claim.

That article looks to be talking about OpenGL, which is an entirely different graphic lib (you could still use SDL for the windowing/audio framework, but all the SDL blitting and stuff would be useless... you'd do your rendering with OpenGL calls instead).

OpenGL is certainly going to be faster (unless you have REALLY junky video drivers), but as that article mentions it's also significantly more complicated, and might be overkill for what you want to do.

That said... I would certainly sooner recommend OpenGL to anyone than I would SDL 1.x... so you can decide for yourself ;P


I have a link to a really good modern OpenGL tutorial that I often refer people to, but I'm at work now so I don't have it handy. When I get home, if I remember, I'll post it. But again.... significantly more complicated.