GP2X Experiences With The Hw Blitter [sdl]

[synkro]

As I was recently coding a simple particle system, I was wondering what is the best way to keep the blitter busy. I just went with a traditional approach:

CODE

<update all particles>
<draw all particles>



Because of the asynchronous nature of the blitting I am doubting this approach. The idea is, while the blitter is busy drawing one particle you could update the next one. This might be the better approach:

CODE

...
<update particle>
<draw particle>
<update particle>
<draw particle>
...



But you can also argue that the average game loop update and render calls are already interleaved enough.

CODE

<update backgroud>
<draw bakcground>
<update layer 1>
<draw layer 1>
...
<update particles>
<draw particles>



In YOUR experience, what granularity seems to be more beneficial? Did anyone actually try to profile both? As I am a lazy bum I am asking YOU. The deciding factor for me is the length of the blitter queue. After how many blitting request doe the blitter discard blit requests? Is this a fixed number or does it depend on the number of pixels to blit?

 

[paeryn]

The blitter can only start a second blit after the first finishes. The way it's implemented at the moment is that when you call the second blit all the data the blitter needs is calculated and loaded into the blitter's registers but SDL then has to wait for the blitter to finish the first blit before the second can be sent. This allows SDL to do as much as it can whilst the blitter is busy. Hopefully (on small blits at least) the blitter will be ready by the time we're done with the calculations so as to keep the wait to a minimum.

I'd say that firing blits off one after another with little to no processing in between is likely to stall. I'll run a test later to see how much time is actually spent waiting in this sort of scenario with various blit sizes.

I'm looking into how I can run the blitting code in it's own thread so as to not hold up your program. Ideally I'd like to use the fact that the blitter can send an interrupt signal to say it's ready for the next blit - unfortunately that means either using the 940 or a kernel module to run the blitter queue.

 

[Trenki]

I'm looking into how I can run the blitting code in it's own thread so as to not hold up your program. Ideally I'd like to use the fact that the blitter can send an interrupt signal to say it's ready for the next blit - unfortunately that means either using the 940 or a kernel module to run the blitter queue.

If at all I would definitly prefer the kernel module but I think this is overkill. Waiting for the previous blit to have finished isn't that bad. I don't like the idea of SDL using the second cpu. If it did anyone using SDL would be unable to use the 940 for its own purposes!

 

[paeryn]

If at all I would definitly prefer the kernel module but I think this is overkill. Waiting for the previous blit to have finished isn't that bad. I don't like the idea of SDL using the second cpu. If it did anyone using SDL would be unable to use the 940 for its own purposes!

That's why I've refrained from using the 940, even if it was free (not being used) there'd be the cost of the extra power drain from running it for a fairly trivial task. And running the queue from within a kernel module means added overhead of servicing an interrupt.
It'll more than likely stay like it is and leave it up to the programmer to space out the blits appropriately.

 

[synkro]

I have trouble stalling the Blitter. I am rendering more than 512 animated (8 frames), color keyed 8x8 sprites in both cases (block render/update & interleaved render/update) and I see no change in FPS. While fooling around I found that reducing usage of DIVs in those calls way more benefical than changing the render scheme itself.

 

[Series-8]

I think the MMSP is supposed to have two Register sets, one for a current command and one for a next buffered command. --Its in the docs.

What are you doing with the particles? Physics? 3D Particle effects? particles are always neat. (ever see Liero water and sand effects?)

 

[paeryn]

I think the MMSP is supposed to have two Register sets, one for a current command and one for a next buffered command. --Its in the docs.

When you start the blitter the first thing it does is to swap the data registers internally. This means you can straight away start writing the next blit data to the registers but that is as far as it goes, you cannot start the second blit until the first one has finished. That is what I do in SDL, you can call a second blit straight away and SDL will do all it's calculations and load the registers before waiting for the blitter to finish.