One of my games consumes a lot of memory, most of it in SDL surfaces. I
want to reduce this consumption. The game has a lot of characters who
walk left and right; these images are horizontally symmetric. So a good
place for optimization would be have flipped blitters and store just one
copy of the image, not two (right-facing and left-facing).
For my use case, it would be enough to have a per-surface flag saying
SDL_HFLIP for example. I wouldn’t need to support blitting OVER an
hflipped image. So if I’m not mistaken I should implement flipped
versions of every blitter.
I’m saying this because I don’t want to break anything, and ideally I’d
like to contribute the code back to SDL because I know other people
would find it useful. So any suggestions about how to do this as SDL-
maintainer-friendly as possible is welcome.
Thanks,
–Gabriel
Hello !
Yup. It would be really cool to have something
in SDL that would allow to H/V-Flip Blits, maybe
something like SDL_BlitSurfaceHV (Parameters for the normal
SDL_BlitSurface, int or bool hflip, int or bool vflip)
CU> One of my games consumes a lot of memory, most of it in SDL surfaces. I
want to reduce this consumption. The game has a lot of characters who walk
left and right; these images are horizontally symmetric. So a good place
for optimization would be have flipped blitters and store just one copy of
the image, not two (right-facing and left-facing).
For my use case, it would be enough to have a per-surface flag saying
SDL_HFLIP for example. I wouldn’t need to support blitting OVER an
hflipped image. So if I’m not mistaken I should implement flipped versions
of every blitter.
I’m saying this because I don’t want to break anything, and ideally I’d
like to contribute the code back to SDL because I know other people would
find it useful. So any suggestions about how to do this as SDL-
maintainer-friendly as possible is welcome.
Thanks,
–Gabriel
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Not a bad idea. Any reason why flipping-as-you-blit isn’t sufficient
in your case, though?
Torsten’s comment about this being hardware-accelerated is definitely
interesting, too. :^)
One thing to worry about in either (non-hw-accel’d case), though, is
when images are stored RLE’d. It could degrade performance, or something.
-bill!
(I’m tired, sorry 
)On Tue, May 24, 2005 at 07:19:39PM -0300, Gabriel wrote:
One of my games consumes a lot of memory, most of it in SDL surfaces. I
want to reduce this consumption. The game has a lot of characters who
walk left and right; these images are horizontally symmetric. So a good
place for optimization would be have flipped blitters and store just one
copy of the image, not two (right-facing and left-facing).
For my use case, it would be enough to have a per-surface flag saying
SDL_HFLIP for example. I wouldn’t need to support blitting OVER an
hflipped image. So if I’m not mistaken I should implement flipped
versions of every blitter.
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…
Anyway, what I did is adding a d_inc member to SDL_BlitInfo (in
SDL_blit.h) which is set to dst->BytesPerPixel or -dst->BytesPerPixel by
SDL_SoftBlit(), depending on whether SDL_HFLIP (new flag) is set in src-
flags. SDL_SoftBlit() also sets up d_skip and d_pixels so the blit
starts where it should (right end or left end).
Finally, I modified the blitters to do dst += d_inc instead of ++dst.
This worries me because I thought an ADD would take longer than an INC,
but I did some preliminary benchmarking and it doesn’t seem to be the
case. In fact there’s an IF inside the block repeated by DUFFS_LOOP4,
which I thought made it slower because it’s per-pixel, but removing that
IF makes the blit go slower. This has me very confused - I thought
removing branching would have the opposite effect. Can any optimization
guru clarify this? The good thing about this is that there’s no need to
duplicate the code of each blitter, meaning easier maintenance and
minimal impact on the library size.
About the flag, I’m doing pSurf->flags |= SDL_HFLIP instead of adding a
function to do that; the advantage of my implementation is that the blit
map doesn’t need to be invalidated when this flag changes so there’s no
need for a different function, making this non-API breaking (except for
the new flag which is just a constant).
The other thing I’m not sure about is the semantics of the source
rectangle for blit functions. Should that be flipped or not?
I think this can work very well and that vertical flipping would be very
similar. I ask the gurus to clarify these points for me so I don’t screw
up, and I’ll do the rest of the job after that.
Thanks,
–Gabriel
Not a bad idea. Any reason why flipping-as-you-blit isn’t sufficient
in your case, though?
What do you mean? Keep a flipped copy? Memory problems, my motivation.
Just flip? Some images are shared by many characters so I can have a
left-facing character and a right-facing character at the same time.
One thing to worry about in either (non-hw-accel’d case), though, is
when images are stored RLE’d. It could degrade performance, or something.
I made the same wrong question earlier. No problems, you just need to
reverse the direction of the destination pointer. The images are un-RLEd
and re-RLEd at a higher level than this. And I’m not even supporting
blitting TO an hflipped image yet.
--Gabriel
Not a bad idea. Any reason why flipping-as-you-blit isn’t sufficient
in your case, though?
What do you mean? Keep a flipped copy?
No, I just mean, when you go to blit, don’t simply blit the entire thing
at once, but slice it into 1px-wide lines and blit it ‘backwards.’
I made the same wrong question earlier. No problems, you just need to
reverse the direction of the destination pointer. The images are un-RLEd
and re-RLEd at a higher level than this. And I’m not even supporting
blitting TO an hflipped image yet.
If I didn’t say I was tired earlier, then yeha, I was tired. :^)
I’m not actually all that familiar with the RLE accel. stuff inside SDL.
My brain is having a hard time even remembering when/where it happens.
Anwyay, sorry for the noise. Adding a simple H-flip and V-flip flag will
definitely be welcome, I think!On Tue, May 24, 2005 at 10:03:22PM -0300, Gabriel wrote:
–
-bill!
bill at newbreedsoftware.com
http://newbreedsoftware.com/
If your main concerns are memory, you could use OpenGL, where
"blitting" can be accomplished with plenty of hardware acceleration
while utilizing any sort of flipping / mirroring, rotating, scaling,
etc.On May 24, 2005, at 6:19 PM, Gabriel wrote:
One of my games consumes a lot of memory, most of it in SDL surfaces. I
want to reduce this consumption. The game has a lot of characters who
walk left and right; these images are horizontally symmetric. So a good
place for optimization would be have flipped blitters and store just
one
copy of the image, not two (right-facing and left-facing).
For my use case, it would be enough to have a per-surface flag saying
SDL_HFLIP for example. I wouldn’t need to support blitting OVER an
hflipped image. So if I’m not mistaken I should implement flipped
versions of every blitter.
I’m saying this because I don’t want to break anything, and ideally I’d
like to contribute the code back to SDL because I know other people
would find it useful. So any suggestions about how to do this as SDL-
maintainer-friendly as possible is welcome.
Thanks,
–Gabriel
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
If your main concerns are memory, you could use OpenGL, where
"blitting" can be accomplished with plenty of hardware acceleration
while utilizing any sort of flipping / mirroring, rotating, scaling,
etc.
I know, but then the problem is one of compatibility. Believe me, I do
need flipped blitters 
--Gabriel
Hello !
I know, but then the problem is one of compatibility. Believe me, I do
need flipped blitters
SDL was started as a Library for Game Porting.
And nearly every 2D Game needs H/V-Flip.
JumpNruns, Adventures …
CU
Where is OpenGL not compatible? Come on man, set yourself some
practical limits. Every system sold for years and years now has been
able to run OpenGL-employing applications. I’m writing a 2D game using
OpenGL right now. And I never make mistakes. So OpenGL was the correct
decision.On May 25, 2005, at 1:56 AM, Gabriel wrote:
If your main concerns are memory, you could use OpenGL, where
"blitting" can be accomplished with plenty of hardware acceleration
while utilizing any sort of flipping / mirroring, rotating, scaling,
etc.
I know, but then the problem is one of compatibility. Believe me, I do
need flipped blitters
--Gabriel
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hello !
Where is OpenGL not compatible? Come on man, set yourself some
practical limits. Every system sold for years and years now has been able
to run OpenGL-employing applications. I’m writing a 2D game using OpenGL
right now. And I never make mistakes. So OpenGL was the correct decision.
When coding an oldskool game, why should
i set the limits for using my game higher than needed ?
CU
Really?!? Me too! That’s so cool. I’ve never met anyone as flawless as me.
;)On 5/25/05, Donny Viszneki wrote:
And I never make mistakes.
Not necessarily. Sometimes it looks nice if a sprite has lighting and
shading, and it looks silly if the lighting angle suddenly changes when
the character turns around. :^)On Wed, May 25, 2005 at 01:48:04PM +0200, Torsten Giebl wrote:
Hello !
I know, but then the problem is one of compatibility. Believe me, I do
need flipped blitters
SDL was started as a Library for Game Porting.
And nearly every 2D Game needs H/V-Flip.
JumpNruns, Adventures …
–
-bill!
bill at newbreedsoftware.com
http://newbreedsoftware.com/
Hello !
Not necessarily. Sometimes it looks nice if a sprite has lighting and
shading, and it looks silly if the lighting angle suddenly changes when the
character turns around. :^)
Okay. What about adding that features to SDL 1.3 ?
As SDL 2.0 and SDL 1.3 should start somewhere
What are the actual differences between SDL 1.2 and 1.3 ?
CU
Where is OpenGL not compatible? Come on man, set yourself some practical limits.
Of course, that’s why I won’t use OpenGL except as an optional,
secondary renderer for a few years. You’d be surprised to know how many
people don’t have a working OpenGL setup out of the box. And our
customers are casual gamers, so forget about an error message saying
"Please update your OpenGL drivers".
It’s simple as this : if it doesn’t work out of the box, it’s a lost
sale. So I’m thankful even for the windib driver!
--Gabriel
Oh, I wasn’t arguing against the flip. I’m just saying that not every 2D
game would necessarily benefit from it. I think it would be a welcome
addition to the library, especially if it didn’t affect the API’s backwards
compatibility, which it sounds like it wouldn’t.
-bill!
bill at newbreedsoftware.com
http://newbreedsoftware.com/On Wed, May 25, 2005 at 08:49:46PM +0200, Torsten Giebl wrote:
Hello !
Not necessarily. Sometimes it looks nice if a sprite has lighting and
shading, and it looks silly if the lighting angle suddenly changes when the
character turns around. :^)
Okay. What about adding that features to SDL 1.3 ?
As SDL 2.0 and SDL 1.3 should start somewhere
What are the actual differences between SDL 1.2 and 1.3 ?
I thought I was the only one like that…guess I was mistaken…
-Matt Bailey
On Wednesday 25 May 2005 10:01, Casey ODonnell set 1,000 monkies in front of
keyboards and came up with the following:> Really?!? Me too! That’s so cool. I’ve never met anyone as flawless as me.
On 5/25/05, Donny Viszneki wrote:
And I never make mistakes.
On Wednesday 25 May 2005 13:54, Gabriel set 1,000 monkies in front of
keyboards and came up with the following:
> Where is OpenGL not compatible? Come on man, set yourself some
> practical limits.
Of course, that’s why I won’t use OpenGL except as an optional,
secondary renderer for a few years. You’d be surprised to know how many
people don’t have a working OpenGL setup out of the box. And our
customers are casual gamers, so forget about an error message saying
"Please update your OpenGL drivers".
Are you talking about folks with stock WinXP installs?
-Matt Bailey
There’s also my wife, who has a Thinkpad T20. It’s quite usable, but
due to the built-in graphics chip and it’s [currently] poor support under X,
no 3D acceleration for her. No reason to prevent her from playing a 2D game
like Wesnoth, though! (And man, we can’t stop playing Wesnoth :^) )On Wed, May 25, 2005 at 03:30:41PM -0500, Matt Bailey wrote:
Are you talking about folks with stock WinXP installs?
–
-bill!
bill at newbreedsoftware.com
http://newbreedsoftware.com/
do multiple characters in the game have identical sprites… i.e.
you load the same imge fiel multiple times.
as an newb to sdl i did this, and today or tomorrow i have decided to
implement a reference system in my game.
when a player wants an image, it calls a certain class function. this
checks whether an image has been loaded. if it has, i copy the pointer
refernce. when a sprite no longer needs an image, it ‘releases’ it.
when my class detects all references are gone it freees the surfaces.
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.