I think this design debate over basic assumptions in SDL 2D rendering has raged on for quite some time.
If designing a 2D convenience library that wraps 3D APIs (GL/D3D/etc) then one naturally assumes certain things are easy, and exposes them as easy in that API, for example rotation, scaling, and
flipping would be exposed as conveniently available options in such an API.
If designing a 2D convenience library that writes directly to software surfaces, then one naturally assumes certain things are fast, certain things are slow, and avoids designing an API that offers
the slow things - for example, rotation being a heavy operation, flipping being a heavy operation, these operations may not be available or may require extra steps to make use of, because the API
designer did not want to encourage their use.
A fine example of these underlying assumptions is that on many of the sprite-based game consoles, they had X and Y flip options on all sprites (and also background tiles for that matter), some even
had rotation and scaling on sprites. So games written for these consoles made the assumption that this functionality was free and beneficial to use, hence the art was designed for this…
Where as in a more basic rendering system without this functionality, for example on the Amiga blitter hardware there was no X flip (Y flip could be performed by reversing the pitch register, so that
was supported but almost never used in that way), games that were adapted to the Amiga blitter hardware after coming from another platform, found themselves having to have a specialized routine to
flip a sprite’s image to emulate this functionality, rather than doing so during the blit itself, they did it beforehand on the CPU and then invoked their regular blitting function.
More commonly they DID store X flipped versions of such images, to avoid this extra cost, and the images may even be different (appropriate shading, for example), so the X flip issue became a
non-issue once it was worked around with the basic approach of duplicating all the images that could be viewed both ways…
Getting back to the subject at hand, SDL 2D rendering has a software implementation, and its 2D API is designed around that software implementation, so it does not expose things that are hard/slow to
do in software (scaling, flipping, rotation, blending), but at the same time it also exposes features that are hard/slow to do in hardware, for example color key masking (rather than alpha testing) is
simple in software but in hardware it requires special functionality to emulate the missing color key masking operation, because the 3D hardware was designed for a different set of basic assumptions.
Good luck with finding a solution to your problem, but I think the workarounds proposed were appropriate given the limited information provided.
If duplicating the images is not an option, then you may have to write your own routine to do the flip into a new surface before blittering, and see what the hardware performance is like.
P.S. yes I am aware of rotation/zoom functionality, but it is obviously not an encouraged API feature.On 07/12/2010 10:35 AM, Alex Barry wrote:
Well, if you’re using SDL for the purpose of making games, yes, it’s
good to assume that your audience is people who have some sort of
Most computers are capable of hardware acceleration in terms of
operating system and software ability, but the next deciding factor is
if all systems have hardware to do it. Most built in cards have very
minimum capability, and that’s just for basic functionality.
On Mon, Jul 12, 2010 at 1:27 PM, Mason Wheeler <masonwheeler at yahoo.com <mailto:masonwheeler at yahoo.com>> wrote:
>From: Alex Barry <alex.barry at gmail.com <mailto:alex.barry at gmail.com>>
>Subject: Re: [SDL] how to draw an image mirrored?
>Mason, you seem to be ignoring one fact - that's all new devices.
>joe usually doesn't have the most up-to-date system, and may or may
not have a
>hardware accelerated system available to them. I would say it's a
safe bet that
>if they don't have a computer that's hardware accelerated, they
>have a hand-held device that is either.
I'm not ignoring that. I'm taking it into account. Like I said,
were new since before the turn of the century have 3D acceleration.
everyone has a brand new system, but how many people are still using
from the 90s. And how many of those who are actually expect to be
able to play
games created today on them? If the answer's not "zero" it's close
enough as to
make no difference.
Bottom line, in 2010 "the average joe" is running Windows XP, and
and OpenGL both installed out of the box whether he knows it or not.
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
SDL mailing list
SDL at lists.libsdl.org
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier