Hello
I’m writing a game which has a window size of 320x240 pixels. As
this is probably too small for some users, I guess an option to
scale the screen would be a good idea.
Yep… The first few emails I got regarding my SDL port of XKobo, Kobo
Deluxe, was about the scaling feature, which was lost in the
conversion from X to SDL. 320x240 is a really low resolution, which
causes trouble with monitors in fullscreen mode, and is just too
small in windowed mode on any sensible desktop resolution.
Current versions of Kobo Deluxe scale the graphics when loading it,
using nearest, linear, oversampled linear, Scale2x or “Diamond2x”.
(Diamond2x is a simple 2D FIR filter, inspired by the diamond shaped
testing pattern of Scale2x. It sort of looks like an “analog” version
of Scale2x, and is more appropriate for 24 bit graphics.)
Now, I have already read at this list about using YUV overlays for
that purpose. I don’t know anything about that overlay stuff, so I
paid Google and the mailing list archive a visit and read that
using YUV overlays is a good solution for video players or JPEG
image viewers, but also that using YUV overlays would result in
rather poor quality images. However, could anyone tell my why I
should use YUV overlays then and what’s the benefit?
There’s at least a chance that you’ll get hardware accelerated scaling
on some hardware and some operating systems. Don’t rely totally on
it, though, unless you know exactly what kind of hardware your code
will run on.
I have looked at the “testoverlay2” demo provided with the SDL
source code, which actually looks like the thing I want But I have
also seen scaling the screen in some SDL demo which uses OpenGL.
So I’m wondering what’s the best (and fastest) way to scale the
screen, without making it look ugly.
Fastest:
Native OpenGL rendering, definitely - provided you have
acceleration, of course… If you’re doing lots of s/w
rendering, this won’t work too well, though, as that
means you rely heavily on the texture uploading speed,
which can potentially be as slow as writing to VRAM with
the CPU… (That is, really slow, compared to the
accelerated rendering.)
Best:
No such thing, really. It depends on your application
and target platforms. Are you doing lots of pixel level
s/w rendering, or just plain SDL blits? Do you need
alpha blending? Are you scrolling or otherwise animating
the whole screen, or do you have a mostly still image
with some objects moving around?
Most portable:
Scale at load time, and then use SDL, OpenGL or whatever
for blitting the scaled images. Scaling at load time
means you don’t have to scale, filter or anything when
the game is running, which gives you a much better
chance of getting acceleration, or at least fast s/w
blitting on pretty much anything supported by SDL.
Also, I would prefer not to
use OpenGL, because my application should have low requirements.
You don’t have to require OpenGL just to support it… If your
engine renders into an SDL surface, it should be quite trivial to
have it render into a s/w surface instead and pipe that through
OpenGL.
Another way is to scale the graphics at load time, and then render as
usual. That’s what I do in Kobo Deluxe, using either SDL 2D or OpenGL
via the glSDL wrapper.
Advice, anyone? I’m sorry if I just asked dumb questions, but the
SDL doc (and the site linked there for further information) didn’t
really help me.
There are no dumb questions, and this stuff is far from trivial.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 13 February 2004 17.02, Bernhard Bliem wrote:
I’ve made an