do multiple characters in the game have identical sprites… i.e. you load the same imge fiel multiple times.
Yes the characters share sprites, no of course I don’t load any image
more than once.
See here - http://www.mysterystudio.com/screenshot.php?id=www&img=3
Notice how many of the characters share identical shirts, for example.
In fact the two lower-right characters share all their clothing, just
their faces and skin are different (yes, we have a LOT of multi-layered
sprites)
you could then either have two copies of a given surface, one flipped and one not, or have your reverse blitting function and the one surface.
The first option is what I’m doing, the problem is that it consumes
twice as much memory. Which is why I’m making the flipped blitters. So
we’re back to where we started 
--Gabriel
you could then either have two copies of a given surface, one flipped
and one not, or have your reverse blitting function and the one
surface.
The first option is what I’m doing, the problem is that it consumes
twice as much memory. Which is why I’m making the flipped blitters. So
we’re back to where we started
--Gabriel
Well, you can sacrifice performance or memory, personally I’d have made
the same decision you made for most games. Perhaps it should be an
option for the user though, since the bottleneck will vary from system
to system. My bottleneck is /always/ memory, so even though I’d have
chosen a hit to my memory, it would have been the wrong choice for my
particular system.
Anyhow, the first step will be implementing a flipped blitter at the
SDL level, as a fail-safe for any driver that has yet to have flipped
blitting support implemented. The next step would be for more optimized
flipped blitters to be written for any and every driver that can
feasibly benefit from some optimization. For some, it would be
incredibly simple, for instance IIRC DirectX supports flipped blitting.
And obviously it would be just as easy to implement flipped blitting
for an OpenGL back-end. If SDL has been ported to any
primarily-two-dimensional game consoles, there exist invariably
hardware support for mirrored blitting.
For software flipped blitting, here are some considerations to take
into account. First, the difference between the smallest quantity of
addressable memory on a system and the size of a pixel in the video
mode used by your application, will be proportional to the performance
hit incurred when flipping your sprite horizontally. On a 32 bit
system, the smallest performance hit you can incur will be using 32 bit
color. Using 8 bit color however, about 4 times as many operations will
have to be used to copy a mirrored image of your sprite. Under the most
conditions, optimizations could be made. For instance you might be able
to read in 32 bit chunks, then flip the contents of this 32 bits on the
CPU without accessing RAM outside the CPU, finally storing the
resultant mirror-image 32 bits at the destination of your blitting
operation.
I hope this helps you on your quest for flipped blitting. I personally
will continue using OpenGL 
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: text/enriched
Size: 2400 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050530/c9a84e59/attachment.binOn May 26, 2005, at 1:50 PM, Gabriel wrote:
Well, good news - I think I found a way to implement horizontal flipping
at least with minimal changes to the SDL source code. Note that I only
analyzed software alpha blits, but I guess this would work for any
software blit. Will have to check hardware blits but I’m not using them,
so…
Very cool! Go ahead and send the patch to the SDL mailing list.
I’m not sure if it’ll get included in the official SDL distribution
(at least not before 1.3), but I’m sure it’ll be useful to many people!
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
El s?b, 20-08-2005 a las 10:50 -0700, Sam Lantinga escribi?:
Well, good news - I think I found a way to implement horizontal flipping
at least with minimal changes to the SDL source code. Note that I only
analyzed software alpha blits, but I guess this would work for any
software blit. Will have to check hardware blits but I’m not using them,
so…
Very cool! Go ahead and send the patch to the SDL mailing list.
I’m not sure if it’ll get included in the official SDL distribution
(at least not before 1.3), but I’m sure it’ll be useful to many people!
I got it done for 24 and 32 bit surfaces, but I never got around to
doing it for 16 bit surfaces… I didn’t want to submit such an
incomplete patch. I can send it to the list in case someone wants to
finish it though.
--Gabriel