Me again, HUGE Alpha blit problem

Well I tried the suggestions for the cross-fader and used alpha values and
now my cross-fader updates at a whopping 1 frame a second. Thats right it
takes 700-900 ms to blit the alpha channeled bitmap.
I supply my code below

#include <stdio.h>
#include <stdlib.h>
#include “SDL-1.1.6\SDL.h”

int done;
SDL_Event event;
Uint8 *keys;

int frames = 0;
float fps, t;
Uint32 t1;

int ScrW = 800;
int ScrH = 600;

main(int argc, char *argv[])
{
SDL_Surface *screen;
SDL_Init(SDL_INIT_VIDEO);
screen = SDL_SetVideoMode(ScrW, ScrH,32, SDL_SWSURFACE | SDL_SRCALPHA |
SDL_DOUBLEBUF | SDL_FULLSCREEN);
SDL_WM_SetCaption(“Text Test”, “test”);
SDL_ShowCursor(0);

SDL_Surface *pic1 = SDL_LoadBMP(“Data\pic1.bmp”);
pic1 = SDL_DisplayFormatAlpha(pic1);
SDL_Surface *pic2 = SDL_LoadBMP(“Data\pic2.bmp”);
pic2 = SDL_DisplayFormatAlpha(pic2);

while (done == 0)
{
while ( SDL_PollEvent(&event) )
{
switch (event.type)
{
case SDL_QUIT: done = 1; break;

case SDL_KEYDOWN:
 if (event.key.keysym.sym == SDLK_ESCAPE) { done = 1; }
break;

}
}

SDL_BlitSurface(pic1, NULL, screen, NULL);
SDL_SetAlpha(pic2, SDL_SRCALPHA | SDL_RLEACCEL, 128);
SDL_BlitSurface(pic2, NULL, screen, NULL);

SDL_Flip(screen);

}
SDL_FreeSurface(pic1);
SDL_FreeSurface(pic2);
Arial.Free();
SDL_Quit();
exit(0);
return(0);
}

The code above that basically shows half of each picture runs at 1 frame a
second. Any suggestions

Piotr Dubla

Well I tried the suggestions for the cross-fader and used alpha values and
now my cross-fader updates at a whopping 1 frame a second. Thats right it
takes 700-900 ms to blit the alpha channeled bitmap.
I supply my code below

I’m having similar problem, just with the fade-in/fade-out. I’m also using
alpha channel for this effects.

I blit one picture on the screen and then in a loop blit black picture over
it with increasing alpha from zero to 40 or so. Util previos picture is
completely covered.

The results are pretty much the same.

Anyone else got a better idea on how to do a fade-in/out on a video that has
more than 8bpp?

David!On Tue, Nov 14, 2000 at 10:11:00AM -0800, Piotr Dubla wrote:

9:04am up 65 days, 10:21, 9 users, load average: 82.18, 73.83, 55.16

SDL_Surface *pic1 = SDL_LoadBMP(“Data\pic1.bmp”);
pic1 = SDL_DisplayFormatAlpha(pic1);
SDL_Surface *pic2 = SDL_LoadBMP(“Data\pic2.bmp”);
pic2 = SDL_DisplayFormatAlpha(pic2);

Only use SDL_DisplayFormatAlpha if you need an alpha channel. An alpha
channel associates an alpha value with each pixel. You don’t need one since
you are using one value for the entire surface. Use SDL_DisplayFormat
instead.

If the pictures have a large part in common (a background, say), try
blitting that part first and use RLE acceleration on the two you want to
fade. That way you’ll have less pixels to process each frame

I blit one picture on the screen and then in a loop blit black picture over
it with increasing alpha from zero to 40 or so. Util previos picture is
completely covered.

You can do it that way if you like; you save one blit each time. But
beware of the difference: the fade level will accumulate, and the result
can be hairy to calculate. If you apply a constant alpha value a each time,
you get an effective fading level of 1 - (1-a)**n at the nth step.

It’s of course easy to compensate for the cumulative effect. If the current
fade level is a, and you add another layer with alpha a’, then the composite
level will be 1 - (1-a)(1-a’). Thus, to get a linear fade level f[i] = ki,
use the alpha value

a[i] = 1 - (1-ki) / (1 - k(i-1)), i = 1, 2, 3…

Whether roundoff errors will get you is another matter.

Anyone else got a better idea on how to do a fade-in/out on a video that has
more than 8bpp?

Since many people asked about this, I made a tiny demo:

ftp://ptah.lnf.kth.se:/pub/misc/fade.tar.gz

It’s pretty slow, but it shows the principles

“Mattias Engdeg?rd” wrote

Since many people asked about this, I made a tiny demo:

ftp://ptah.lnf.kth.se:/pub/misc/fade.tar.gz

It’s pretty slow, but it shows the principles

just in case any are curious about the performance
on machines other than their own;

Pentium2-300, NT4, at 640x480, has stats like this:

50 frames blit A blit B update total
total: 594 1406 1328 3328
per frame: 11 28 26 66

this is leaving the bpp field alone, which defaults to
32bpp on this machine. fullscreen had no effect (as expected
with the gdi driver). Anyways, that comes out to about 15
frames per second. at anything less than ~50 frames, the
dissolve feels a bit “steppy”.

50 frames blit A blit B update total
total: 594 1406 1328 3328
per frame: 11 28 26 66

That’s a fair bit faster than on the machine I tried it on, but can still
be improved. The “blit A” may be eliminated by using the cumulative alpha
effect as I described previously; that would cut it down to about
55 ms/blit. We can’t do much about the update cost, and here Amdahl’s Law
kicks in: Even if we optimize the second blit infinitely well (so it takes
zero time), we can never do better than 1/0.026 = ~38 fps.

There’s still the project of reworking the software blitter architecture
so that parts can be written in assembler, but I prefer first having
well-tuned generic C implementations. This will be a later project

use the alpha value

a[i] = 1 - (1-ki) / (1 - k(i-1)), i = 1, 2, 3…

Whether roundoff errors will get you is another matter.

Anyone else got a better idea on how to do a fade-in/out on a video that has
more than 8bpp?

I just solved my problem with fading.

It turned out that I was loading an image and didn’t call SDL_DisplayFormat
before blittig it to surface and updating screen.

Now it’s working like it should… :slight_smile:

David!On Wed, Nov 15, 2000 at 12:40:00AM +0100, Mattias Engdeg?rd wrote:

Windows 95 - A 500MB multimedia solitaire game!

I just solved my problem with fading.

It turned out that I was loading an image and didn’t call SDL_DisplayFormat
before blittig it to surface and updating screen.

Now it’s working like it should… :slight_smile:

Glad to hear it! :slight_smile:

-Sam Lantinga, Lead Programmer, Loki Entertainment Software