Is the A500 Blitter Any Good For Drawing Polygons?

[Gilbert]

I was reading an old Amiga magazine recently and they were interviewing the programmer for a flight simulator game (just at the moment I can't remember which one) for the A500.

He said the Blitter was only good for scrolling the (bitmap) mountains on the horizon.

Why is this? because wasn't the blitter designed to draw lines and fill areas too? A lot of Atari ST polygon based flight simulators are often described as slightly faster in multi format reviews which does seem to imply the blitter is not much use

So is the blitter really no good for drawing lines and polygons or is it just coders didn't know what they were doing back then?

[hooverphonique]

The blitter itself is fine for drawing lines and filling polygons.

It gets complicated when you have overlapping or concave objects, though, and when there's many of them, it may be easier to just use the cpu and e.g. draw everything back to front. Also, using the cpu will give a massive boost when using faster processors, where using the blitter might not.

[Ernst Blofeld]

I've done this. The payoff for using the Blitter only happens for fairly big polygons. But, if you can make a sensible split between small and big polygons then it can help. In my case the Blitter is clearing the screen, drawing the ground then drawing the big ground level details (concrete and water). Because I can intermix the calculations for this and other things with the blitting, the blitting becomes free. But I don't use the Blitter for drawing smaller things like other aircraft because it ends up costing more, and apart from the ground level details everything is very small, only a few words. For my next trick I'm going to try not using polygons for far away aircraft, but I'm not sure how bad that will look.

[Gilbert]

Interesting replies. Thank you

Originally Posted by Ernst Blofeld

I've done this. The payoff for using the Blitter only happens for fairly big polygons. But, if you can make a sensible split between small and big polygons then it can help. In my case the Blitter is clearing the screen, drawing the ground then drawing the big ground level details (concrete and water). Because I can intermix the calculations for this and other things with the blitting, the blitting becomes free. But I don't use the Blitter for drawing smaller things like other aircraft because it ends up costing more.

So if you use the Blitter in this way - how much speed increase would you get over if you only used the CPU for polygons and the Blitter for background bitmaps (e.g. mountains etc)?

[Ernst Blofeld]

Originally Posted by Gilbert

Interesting replies. Thank you



So if you use the Blitter in this way - how much speed increase would you get over if you only used the CPU for polygons and the Blitter for background bitmaps (e.g. mountains etc)?

I think that's too hard to answer without knowing exactly what's being compared. But, in my experience (only), without using the Blitter at all, about 1/3 of your time is spent clearing the screen and drawing the backround, about 1/3 is spent doing all the calculations, and about 1/3 is spent drawing foreground stuff like other aircraft.

By using the Blitter to do the clearing and background, you could get up to 1/3 of your time back. But that's less significant than it sounds, if you were getting 3fps you might get 4fps instead.

[Gilbert]

Originally Posted by Ernst Blofeld

I think that's too hard to answer without knowing exactly what's being compared. But, in my experience (only), without using the Blitter at all, about 1/3 of your time is spent clearing the screen and drawing the backround, about 1/3 is spent doing all the calculations, and about 1/3 is spent drawing foreground stuff like other aircraft.

By using the Blitter to do the clearing and background, you could get up to 1/3 of your time back. But that's less significant than it sounds, if you were getting 3fps you might get 4fps instead.

Yes that's pretty good! Maybe even keep the frame rate the same and increase the detail.

That must take the Amiga a little ahead of the ST with it's marginally faster processor.

You could even use Amiga sprites or BOBs for the small planes or small objects. There's a game on MEGA CD - Soulstar where all the animation frames (objects seen from different angles) are prestored - maybe like Wing Commander on Amiga. So could maybe do that with all objects of a smaller size and save even more cycles

[DanScott]

If you're using the blitter to draw your polygons, generally you have to do this:

Clear the polygon buffer (it's just one bitplane)
Draw lines to the polygon buffer
Fill the polygon buffer
Copy the polygon buffer to each bitplane of your frame buffer (by either 'or'ing of 'nand'ing)


As the blitter works on rectangular areas, there are many cases where you'll be blitting a lot of dead space (imagine a polygon that is long and thin and diagonal). You might be able to subdivide the rectangle into smaller rectangles, but this is going to add more overhead.

So there are many cases when a CPU based renderer would be faster (for example the diagonal example above, and probably small polygons where there is still a fair amount of blitter setup work to do), and there are also cases where the blitter will win hands down.

Unfortunately due to the nature of 3D, most scenes would contain a mixture of cases at once...

[sparhawk]

You may take a look at this thread http://eab.abime.net/showthread.php?t=99179 as deimos was coding a flight simulator using the blitter.

[Gilbert]

Thanks for responses. I am going to read up on this. I still don;t understand why the CPU doesn't also write to rectangular areas? Because it still has to write in words/bytes etc? I am not an expert coder. I just have working knowledge of things

[Ernst Blofeld]

Originally Posted by Gilbert

Thanks for responses. I am going to read up on this. I still don;t understand why the CPU doesn't also write to rectangular areas? Because it still has to write in words/bytes etc? I am not an expert coder. I just have working knowledge of things

Exactly that. The CPU does one instruction at a time, which may result in one word being written. The Blitter is different, set it running and it will write many words until it is done, skipping a few at regular intervals such that the result looks like a rectangular area.

[sparhawk]

Originally Posted by Gilbert

Thanks for responses. I am going to read up on this. I still don;t understand why the CPU doesn't also write to rectangular areas? Because it still has to write in words/bytes etc? I am not an expert coder. I just have working knowledge of things

The CPU has to work one instruction after the other. Doing what the Blitter does in code takes quite a complicated algorithm because of the bitplane organization. Moving the pixels to an arbitrary X position requires manual shifting accross word boundaries. The shifting is already expensive and doing it over word boundaries adds to it as well. The Blitter can do this automagically, which makes it much faster.

[Gilbert]

Originally Posted by Ernst Blofeld

Exactly that. The CPU does one instruction at a time, which may result in one word being written. The Blitter is different, set it running and it will write many words until it is done, skipping a few at regular intervals such that the result looks like a rectangular area.

Thank you, I think I understand now. If you use the blitter to render polygons and have fast ram then the CPU is free to do other calculations? maybe to start to calculate the next frame? Would that make using the blitter more efficient?

[Gilbert]

Originally Posted by sparhawk

You may take a look at this thread http://eab.abime.net/showthread.php?t=99179 as deimos was coding a flight simulator using the blitter.

I have been reading this. Is complicated stuff. In his particular example he found blitting was faster than CPU routines

A summary of what I've done this week, and how the different versions compared:

This is from memory, some minor details may be inaccurate. Timings are approximate. Bear in mind that I've only tested one situation, these numbers may not represent real world performance. Please ask questions, otherwise I'm guessing at what's important to state.

Interrupt Driven Blitter Queue with Callbacks

33s for 101 frames - 3.1 fps

Triple buffer system with proper decoupling from display refresh. Blits can be added to the queue at any time. The callback system allows mixing of non-blitter effects. Hard to write, test, prove. Possibly still fragile, even though it has been soak tested.

Poll Based Blitter Queue with Callbacks

31s for 101 frames - 3.3 fps

The same queue system as above, but no interrupt overhead as polling is used. Hard to know where to poll for best results.

Copper List Blitter Queue

30s for 101 frames - 3.4 fps

I would consider this one to be unfinished as there are still optimisations and improvements that can be done.

Currently queues need to be built completely and started at vertical blank time. Currently only double buffering supported and queues don't start until vblank. Queues are for pure blitter operations only, no mixing of other effects. Prevents practical use of copper effects such as split screens.

Direct Blitting

29s for 101 frames - 3.5 fps

Traditional WaitBlit() style. Easy to write, read, debug. Currently only double buffering supported.

CPU Based

17s for 101 frames - 5.9 fps

Draw polygons with an optimised assembly language scanline fill. Hard to write / debug / optimise. Currently not pixel precisely the same as the blitter versions, so mixing and matching might be limited (right now). Currently only double buffering supported.

[britelite]

Originally Posted by Gilbert

Is complicated stuff. In his particular example he found blitting was faster than CPU routines

The part you quoted shows the CPU routines were the fastest alternative

[Gilbert]

Originally Posted by britelite

The part you quoted shows the CPU routines were the fastest alternative

Yes sorry I misread fps as a time measurement