Hw Sdl Blitter Question

[paxl13]

Hi there,

I started writing one game for the gp2x. So I figured out that I'd like to have a frame rate of 60. So I setuped an Idle loop. Until I try to
do some alpha blended blit everything was fine. So the trouble come from the Alpha Blended blit . What I do is an alpha blened blit from
a surface of 256 * 160 to the main screen. My FPS got down from 60 to ~34 and I was seeing the refresh at the screen. So 1st question:
- Is there a way to ENSURE that the hardware blitter has ended is job before Dooing the SDL_Flip ? I tryed to SDL_LockSurface(MainScreen) / SDL_UnlockSurface(MainScreen) without any success.
2nd question : Can the MMU Hack help me, or It'll only help me if I do some direct access to the HW surface [ witch SDL is dooing because of the alpha blitting is rendered in software. ] If so, what do I have to do, do I have something else to do that `insmod mmuhack.o' before the start of SDL ? do I need ot modify the open in SDL from /dev/mem to /dev/mmuhackmem or how it is called.

Thanks for your help all, I was planning to write my own alpha blitter in ASM, but for this I think I should use the MMU hack. So can somone give me advice.
paxl13

EDIT:

After rereading the post I said to myself that I wasn't clear so ! What I want to know is :
- How to make sure that the HW blitter has ended before calling SDL_Flip ?
- What do the MMU Hack and can it help me in coding a Alpha blitter ?
- Thanks for your support !

 

[Mudi]

Alpha blitting is usually too slow on GP2X, mostly because the blitter does not support alpha blending and software is too slow because of no floating point unit. I've gotten good results doing add/subtract transparency, is this something where that would be possible?

 

[paxl13]

What do you mean by add/substract transparency. Ie passign pixel by pixel and dooing this :

Res = X * BG + Y * FG where The multiplictaion are Done with bitshift ?

Yeah It could, I was to try this in a few.

To do this, should I use a Hardware surface or a Software surface ? and thus how to create on
or the other ?

Thanks

 

[paeryn]

If you're using mmuhack then either an hardware or software surface is fine, if not then use software surfaces if you are going to do a lot of pixel manipulations like this.
Then again, I can't remember off the top of my head but I'm sure I force surfaces with alpha to be software regardless of what you ask for since the extra pixel data would mess up the blitter.

As for SDL_Flip(), it automatically waits for the blitter to finish before swapping the screens - are you using double buffering? Single buffering doesn't do the v-sync step, and sometimes even with double buffering the v-sync polarity gets reversed although I've only seen it happen if the gp2x has been in and out of tv-out mode.

 

[paxl13]

Thanks paeryn, now can give me a simple MMU Hack Howto ? I'm using DoubleBuf and 2 hardware surface...

The next test I tryed is this :


SDL_LockSurface(Grid_BG);
SDL_LockSurface(MainScreen);

Uint8 *From = Grid_BG->pixels;
Uint16 PFrom = Grid_BG->pitch;
Uint8 *To = MainScreen->pixels;
Uint16 PTo = MainScreen->pitch;

for(i=0; i<Grid_BG->w ; i++)
for(j=0; j<Grid_BG->h; j++)
{
To[j * PTo + i * 2] = (From[j*PFrom + i * 2]);
To[j * PTo + i * 2 + 1] = (From[j*PFrom + i * 2 + 1]);
}


SDL_UnlockSurface(MainScreen);
SDL_UnlockSurface(Grid_BG);

Using this copy, the max framerate I can acheive is 28. so if we make some calculation :
2 * 256 * 160 = 84 800 * 2 [ read / write ] = 169 900 byte / frame. at 28 fps this give us
a bandwitdh of 4.7 MB/s... without the mmu hack is that normal ?
The two surface are Hardware.
So I need to look into the mmu hack.
I tryed to start insmod mmuhack.o before my program but this didn't do anything. Do I need
to change something into SDL. I'm using the one that came with opoo toolchain.

Can you give me a little MMU Hack tutorial ?

Thanks for your help.

 

[paeryn]

Sorry I can't help on mmuhack as I've never used it myself but I'm sure there's plenty of others who do. The only thing I know is that you have to make sure you flush the caches after you've modified any HW surfaces before using SDL functions again (as the blitter doesn't have access to the 920's cache.)

You're getting poor bandwidth in your example because (a) the processor can't cache HW surfaces without mmuhack and
(b) you're doing 8-bit read/writes, this gives especially bad performance since the processor has to fetch/put the same 32-bit word 4 times.

As to the version of SDL, the last time I used opoo's toolchain it contained a snapshot of all the source code so it won't be up to date, that could explain why double buffering is flickering (the v-sync polarity was hard-coded and doesn't work well on firmware 2.)
You can download the latest version from the links in the first post here

 

[Blah]

MMU Hack Kernel Module by NK + Squidge

 

[rixed]

Alpha blitting is usually too slow on GP2X, mostly because the blitter does not support alpha blending and software is too slow because of no floating point unit.

Why do you need floating points for alpha ? Is alpha not always between 0 and 1 ?

 

[Mudi]

To answer the above, yes you can represent alpha values using ints, but then you have to do integer divides, which are also very slow on ARM. So either way you are doing something slow.

 

[rabidcow]

To answer the above, yes you can represent alpha values using ints, but then you have to do integer divides, which are also very slow on ARM. So either way you are doing something slow.

Only if you need 100% accurate alpha, which you don't. Fast alpha is usually done with a range of 0 - 255/256 or similar. It's still not going to be blazing fast, you have to do two reads and one write for every pixel, plus you have to unpack the color components to do the actual processing. You just don't want to do full screen alpha blending.

There is some hardware per-pixel alpha support, but you have to deal with palletized YUV to get it.

 

[grzywacz]

If you're using mmuhack then either an hardware or software surface is fine, if not then use software surfaces if you are going to do a lot of pixel manipulations like this.
Then again, I can't remember off the top of my head but I'm sure I force surfaces with alpha to be software regardless of what you ask for since the extra pixel data would mess up the blitter.

Right. If I use "software surfaces", do they end up being allocated in the "lower" 32 megs of memory available to the os? Or does it only disable the hardware blitter for them?

I also deal with alpha blending, but I might try to use colorkey and some kind of dithering, because the details are hardly visible. Are colorkey operations accelerated in you version of SDL?

 

[Mudi]

Yes, colorkey is accelerated in Hardware SDL.