X/Y-Flip from Surfaces

Hello !

I am coding on a little JumpNShoot Game. For that game i need blitting
of X and/or Y-flipped Surfaces. All the hero sprites for example
head to the right direction, now when the character sprite
should walk to the left i have to X-flip all frames.

At the moment i have 3 options doing that :

I can add to all sprites all 4 types of possible flips : Normal, X, Y, XY.
That would waste memory.

When i need a special flip, i create a new surface and then let my routine
flip the original surface into the new one and after that blit the new
surface.

I don’t create a new surface, instead i write to flipped pixels
directly the video surface. One problem of that i would lost the
SDL Alpha Blitting stuff. At the moment Alpha Blending is not
really needed by the game.

Or is there any other way to use an exisiting SDL function to
get X/Y-Flip from Surfaces ?

Thanks.

CU

Hello !

I am coding on a little JumpNShoot Game. For that game i need
blitting
of X and/or Y-flipped Surfaces. All the hero sprites for example
head to the right direction, now when the character sprite
should walk to the left i have to X-flip all frames.

At the moment i have 3 options doing that :

I can add to all sprites all 4 types of possible flips : Normal, X,
Y, XY.
That would waste memory.

When i need a special flip, i create a new surface and then let my
routine
flip the original surface into the new one and after that blit the
new
surface.

I don’t create a new surface, instead i write to flipped pixels
directly the video surface. One problem of that i would lost the
SDL Alpha Blitting stuff. At the moment Alpha Blending is not
really needed by the game.

Or is there any other way to use an exisiting SDL function to
get X/Y-Flip from Surfaces ?

Combine 2 and 3; hack your own code to flip, and use SDL for blitting
to the screen. This way, all you have to do is copy pixels around -
SDL still handles the blending.

//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.nethttp://www.reologica.se —On Sunday 03 April 2005 10.38, Torsten Giebl wrote:

Combine 2 and 3; hack your own code to flip, and use SDL for blitting
to the screen. This way, all you have to do is copy pixels around -
SDL still handles the blending.

That’s what I’m doing right now for my games, but with the volume of
graphics I’m handling, it’s a HUGE waste of memory, as the OP said. The
ideal solution would be to have “flipped” versions of the blitters.

Except for the RLE formats and hflipping case, the flipped blitters
wouldn’t be too complicated, right?

Combine 2 and 3; hack your own code to flip, and use SDL for
blitting
to the screen. This way, all you have to do is copy pixels around

SDL still handles the blending.

That’s what I’m doing right now for my games, but with the volume of
graphics I’m handling, it’s a HUGE waste of memory, as the OP said.

Then you’re either using tons of sprites on screen at once, or you’re
doing something wrong. You shouldn’t need more than one intermediate
surface per visible sprite. (If you’re really trying to minimize
memory use, that is.)

The
ideal solution would be to have “flipped” versions of the blitters.

Of course; no wasted memory, and minimal overhead for flipped
rendering.

The only bad news is someone has to implement it. :wink:

Except for the RLE formats and hflipping case, the flipped blitters
wouldn’t be too complicated, right?

Shouldn’t be too complicated with RLE either, I think… Just reverse
the motion of the write pointers instead, and keep parsing the RLE in
the forward direction.

Either way, people are asking for this every now and then, it’s
possible to h/w accelerate on some backends (well, at least one:
glSDL), and (unlike proper free rotation, scaling etc) it doesn’t
slow s/w blits down to a crawl… So maybe most of the usual counter
arguments are actually invalid?

Well, all but one: Bloat. To avoid impacting the normal (non-flipped)
cases, one would have to add at least one full set of new blitters.
With all the optimized pixel formats, blending, RLE etc, I suspect
that could add quite a bit to the size of the binaries.

//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.nethttp://www.reologica.se —On Sunday 03 April 2005 19.31, Gabriel wrote:

That’s what I’m doing right now for my games, but with the volume of
graphics I’m handling, it’s a HUGE waste of memory, as the OP said.

Then you’re either using tons of sprites on screen at once, or you’re
doing something wrong. You shouldn’t need more than one intermediate
surface per visible sprite. (If you’re really trying to minimize
memory use, that is.)

I copy-and-flip every animation frame at startup. Doing it before
drawing each frame would kill my framerate. So I don’t think I’m doing
it wrong, it’s just that I have a TON of sprites
(http://www.mysterystudio.com/_wendy_1.jpg,
http://www.mysterystudio.com/_wendy_2.jpg)

Shouldn’t be too complicated with RLE either, I think… Just reverse
the motion of the write pointers instead, and keep parsing the RLE in
the forward direction.

embarrasment

Either way, people are asking for this every now and then, it’s
possible to h/w accelerate on some backends […] and […] it doesn’t
slow s/w blits down to a crawl… So maybe most of the usual counter
arguments are actually invalid?

Well, all but one: Bloat. […] With all the optimized pixel formats,
blending, RLE etc, I suspect that could add quite a bit to the size of
the binaries.

In my case, and for many others, I’d gladly trade a 100KB increase in
the (uncompressed) lib size for the kind of memory footprint reduction
I’d get. But I understand the concern. And in this case I’m not sure a
separate lib would do, since many SDL_Surface members are supposed to be
opaque outside the SDL code itself. What to do, what to do…

David: With that combination do you mean each sprite has it’s own
SDL-surface, which you “manually flip” as needed by accessing the
pixels data?

/OlofOn Apr 3, 2005 12:23 PM, David Olofson wrote:

On Sunday 03 April 2005 10.38, Torsten Giebl wrote:

Hello !

I am coding on a little JumpNShoot Game. For that game i need
blitting
of X and/or Y-flipped Surfaces. All the hero sprites for example
head to the right direction, now when the character sprite
should walk to the left i have to X-flip all frames.

At the moment i have 3 options doing that :

I can add to all sprites all 4 types of possible flips : Normal, X,
Y, XY.
That would waste memory.

When i need a special flip, i create a new surface and then let my
routine
flip the original surface into the new one and after that blit the
new
surface.

I don’t create a new surface, instead i write to flipped pixels
directly the video surface. One problem of that i would lost the
SDL Alpha Blitting stuff. At the moment Alpha Blending is not
really needed by the game.

Or is there any other way to use an exisiting SDL function to
get X/Y-Flip from Surfaces ?

Combine 2 and 3; hack your own code to flip, and use SDL for blitting
to the screen. This way, all you have to do is copy pixels around -
SDL still handles the blending.

//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.nethttp://www.reologica.se


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[…]

I copy-and-flip every animation frame at startup. Doing it before
drawing each frame would kill my framerate.

Actually, if you’re doing s/w rendering into VRAM now (and you’ll have
to do that for “live” flipping with most backends!), it won’t make
that much of a difference, except on very slow CPUs. Somewhere around
Pentium and P-II, the CPU starts working so much faster in system RAM
than in VRAM that some extra copying around in system RAM won’t make
that much of a difference.

However, one should keep in mind that antialiasing with alpha becomes
very expensive without RLE - and RLE encoding isn’t free either,
though it should be a lot faster than alpha blending every single
pixel…

So I don’t think I’m doing it wrong, it’s just that I have a TON of
sprites

Well, “wrong” was a bit harch; it really depends on what you need, and
what kind of hardware you can expect or require. If you’re very low
on both CPU and memory, there’s basically no way around implementing
true “flip blitters”, one way or another.

(http://www.mysterystudio.com/_wendy_1.jpg,
http://www.mysterystudio.com/_wendy_2.jpg)

Kewl. :slight_smile:

[…]

In my case, and for many others, I’d gladly trade a 100KB increase
in the (uncompressed) lib size for the kind of memory footprint
reduction I’d get. But I understand the concern.

Yeah… One could make it a compile time option, disabled by default,
but I don’t like that either… Stuff should be used (which means
properly tested and known to work), or it shouldn’t be there at all,
basically.

And in this case I’m not sure a separate lib would do, since many
SDL_Surface members are supposed to be opaque outside the SDL code
itself. What to do, what to do…

Actually, the only problems are RLE and h/w accelerated backends. For
all other cases (ie plain s/w blitting), you don’t need to mess with
anything that’s not public and documented.

And I’m not even sure any significant accelerated 2D APIs support
flipping anyway… Well, there is glSDL, but OTOH, if you can use
that, can you really be running on a system where it would matter how
you implemented the flipping? Then again, that depends on how much
graphics we’re talking about.

Anyway, RLE is probably the hardest one. Unfortunately, it’s probably
also the one you need the most, since that’s what you get whenever
you use alpha, or run on a platform without accelerated 2D rendering.
And alpha (for AA) is where RLE really helps…

//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.nethttp://www.reologica.se —On Sunday 03 April 2005 22.17, Gabriel wrote:

Something like this:
Have one work surface for each visible sprite.
For each frame:
For each visible sprite that changed sprite frame:
Blit/flip gfx into the work surface.
For each visible sprite:
Blit the work surface to the screen.

That is, unless your sprite animations have very high frame rates,
you’ll only be doing an actual flip blit for a sprite every few
rendered frames, and you need only one work surface per visible
sprite.

//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.nethttp://www.reologica.se —On Sunday 03 April 2005 23.39, Olof Bjarnason wrote:

David: With that combination do you mean each sprite has it’s own
SDL-surface, which you “manually flip” as needed by accessing the
pixels data?