I have seem some old posts on the SDL site on fading in and out. I found
Patrick Kooman’s technique using alpha blending in
http://www.2dgame-tutorial.com/sdl/fading.htm interesting, not to mention
simple enough to implement (as I’m not in the mood to write or understand
something else right now, after converting my first SDL game project from
8bpp to 16/32bpp mode and with some work to do).
While the windowed version worked perfectly and very smooth (as smooth as
my old palette based code), when I tried to do the same on full screen the
result was just awful, I could count 5 frames between black and my actual
image (I’m using the system ticks to time my events), and even Patrick’s
code suffer from the same problem. Does anyone has done this before and has
any thoughts to share?
I am running Windows XP, with a GeForce II MX400 set to 1280x1024x32bpp
and my game is set to fullscreen 640x480x16bpp (yep, I tried just for fun
32bpp and the results are the same).
Paulo
While the windowed version worked perfectly and very smooth (as
smooth as
my old palette based code), when I tried to do the same on full
screen the
result was just awful […]
In windowed mode you were blending on a software surface, but in
fullscreen mode the screen is probably a hardware surface. If your
hardware doesn’t accelerate alpha blits, then blending on a
hwsurface will be much slower, as you have observed already 
You
may want to blend on a software surface first, and blit the result
to the screen.–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com
I know my GeForce3 Ti 500 supports Alpha Blit with the NVidia 40.71
drivers under Windows XP. But that’s with Direct3D 6.0. I don’t know if
the older GF2 or MX cards support it. Or if there’s a specific driver
version that provides it. Alpha Blits on my card seem to be only a few
frames faster, but they do look better IMO.On Tue, 2002-10-08 at 03:54, Matthijs Hollemans wrote:
While the windowed version worked perfectly and very smooth (as
smooth as
my old palette based code), when I tried to do the same on full
screen the
result was just awful […]
In windowed mode you were blending on a software surface, but in
fullscreen mode the screen is probably a hardware surface. If your
hardware doesn’t accelerate alpha blits, then blending on a
hwsurface will be much slower, as you have observed already You
may want to blend on a software surface first, and blit the result
to the screen.
In windowed mode you were blending on a software surface, but in
fullscreen mode the screen is probably a hardware surface. If your
hardware doesn’t accelerate alpha blits, then blending on a
hwsurface will be much slower, as you have observed already You
may want to blend on a software surface first, and blit the result
to the screen.
Thanks Matthijs (and DrEvil for the considerations on the driver and Direct X version).
The surface I am fading in and out is a bitmap I loaded from disk (standard SDL function). I suppose that this surface is a software surface, unless I use SDL_DisplaySurface to get a new surface based on my display surface (again, I suppose that if the display is a hardware surface, the new surface will be a hardware surface also).
I am not with my code right now to test it, but if I followed right the thread, we have a simple fade or cross-fade function, which uses three software surfaces: one for the image, one for the black alpha surface and one “transport” surface. All one have to do is to blit the image over the transport surface, set the alpha on the black surface and blit over the transport surface to finally blit this surface on the screen and flip it.
Seems it may work, but only some coding may say it for sure ^_-.
Paulo
The surface I am fading in and out is a bitmap I
loaded from disk (standard SDL function). I suppose
that this surface is a software surface
Correct.
[…] unless I use SDL_DisplaySurface to get a new surface
based on my display surface (again, I suppose that if the
display is a hardware surface, the new surface will be a
hardware surface also).
Correct again
I am not with my code right now to test it, but if I followed
right the thread, we have a simple fade or cross-fade function,
which uses three software surfaces: one for the image, one for
the black alpha surface and one “transport” surface. All one
have to do is to blit the image over the transport surface, set
the
alpha on the black surface and blit over the transport surface to
finally blit this surface on the screen and flip it.
That is exactly how I do it. If you’re running your app in windowed
mode, then SDL already takes care of the “transport” surface, but
with a HWSURFACE you will have to do that yourself.
By the way, for the fastest results, make sure all of your source
bitmaps are the same format as the display (except for the HWSURFACE
flag, of course). Don’t use SDL_DisplayFormat for this, but
SDL_ConvertSurface. Without this, each blit will have to convert
between pixel formats, which takes time.–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com
By the way, for the fastest results, make sure all of your source
bitmaps are the same format as the display (except for the
HWSURFACE
flag, of course). Don’t use SDL_DisplayFormat for this, but
SDL_ConvertSurface. Without this, each blit will have to
convert
between pixel formats, which takes time.
I’m doing a sprite based 2D vertical shooter, so it’s actually
faster to do everything on a software surface, using a "transport"
surface that will be blited later to the screen (what I would do on
the good old days of DOS), than using hardware surfaces for the
sprites and scenery? I thought that blitting between hardware
surfaces would be faster than between software surfaces if they
where just regular or colorkey blits.
The pixel format conversion was easy to find, as it’s the same
that would happen under DOS or any other graphic library (“if
you’re not converting it, be sure that someone is doing it” ^_-),
but this consideration on hardware surfaces is something new to
me, as the only common sense I had was that blitting between a
hardware and a software surface would be slower.
Anyway, thanks again :).
Paulo
I’m doing a sprite based 2D vertical shooter, so it’s actually
faster to do everything on a software surface, using a "transport"
surface that will be blited later to the screen (what I would do
on
the good old days of DOS), than using hardware surfaces for the
sprites and scenery? I thought that blitting between hardware
surfaces would be faster than between software surfaces if they
where just regular or colorkey blits.
You are correct: blitting hardware-to-hardware is faster that
software-to-hardware. Unless you are doing an alpha blit, which you
were already noticing – I guess whether alpha blits are slower or
faster with hardware surfaces depends on the capabilities of your
video card.
But I never claimed anything to the contrary; I just mentioned that
SDL takes care of the “transport” surface if your main screen
surface is a SWSURFACE instead of a HWSURFACE, which is the case if
you are running your app in windowed mode. After all, SDL first
renders everything on the main software surface (which in this case
is the same as your “transport” surface), and finally copies it to
the screen. But it doesn’t do that in fullscreen mode if the main
surface is a HWSURFACE, so there you have to manage the "transport"
surface yourself.
but this consideration on hardware surfaces is something new to
me, as the only common sense I had was that blitting between a
hardware and a software surface would be slower.
Common sense isn’t often right, but in this case it is ;-)–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com
But I never claimed anything to the contrary; I just mentioned
that
SDL takes care of the “transport” surface if your main screen
surface is a SWSURFACE instead of a HWSURFACE, which is
the case if
I know Matthijs, sorry, I wrongly assumed a generalization and
there was I saying that. Anyway, this thread provided me some
valuable information on SDL surfaces that no FAQ would be able
to do so :).
me, as the only common sense I had was that blitting
between a
hardware and a software surface would be slower.
Common sense isn’t often right, but in this case it is
Common sense told me that my GeForce II would be capable
of alpha blending on hardware surfaces and got me stuck for
some hours :P.
I will change my code tonight, perhaps I will have an
alpha version of my game good enough to release along with the
source code in the few next days :).
Paulo