Using blitter for filling 3D polygons

[kovacm]

Hi,

I read from time to time (or to much time ) two type of arguments:

1) Atari ST has 10% faster CPU so 3D polygone games are faster
2) 3D games are ports from ST to Amiga so they do not use blitter otherwise they would be much faster on Amiga

I personally find "10% faster" argument irrelevant (unnoticeably).
but I am curios if there is any game on Amiga game that use blitter for 3D polygon fill?

or, even better: does somebody, with knowledge, can make explanation how much theoretical gain could be in game (not in demos!) using blitter for poly-fill?

I have no knowledge about blitter: e.g. how much time would you spent on setting it up for fill vs filling with CPU alone? How much time is left for CPU while blitter doing fills (in case that there is no fast ram, and case with fast ram)...
Amiga 1200 case: if there is FastRAM, CPU could calculate 3D vertices while blitter filling polygons so filling could be almost "free"? Can copper somehow help with setting up blitter...?

I would really appreciate if someone could made technical analyse.


---
btw all 512KB expansion for Amiga 500 back in 80s and 90s were chipram? right? FastRAM was not common expansion in Amiga world until Amiga 1200?

[hooverphonique]

Originally Posted by kovacm

btw all 512KB expansion for Amiga 500 back in 80s and 90s were chipram? right? FastRAM was not common expansion in Amiga world until Amiga 1200?

actually, they were mostly what would fall into the fastram category (so-called 'slow fastram'), but they were interfaced to the system like chipram, but in an address range outside the chipram regionen. This results in access speeds similar to chipram while not being addressable by dma.

[Photon]

All Amigas could have up to 2MB chipmem, above that, up to 512MB fastmem is possible. For A500 (only) there was an expansion of up to 1.8MB on top of this, called "slowmem" or "fake fastmem" because it didn't give the 33% speed boost, the reason being that it was connected to the same local bus as the chips.

Blitter setup only takes a few cycles, and it can be done with the copper or the CPU, no difference and not a factor for speed.

Most games shrunk the screen buffer to make the polygons tiny, so that the render time would be small for the CPU. Then it would be small for the Blitter also, and the calculation overhead for each small polygon would be the same. Many demos have larger polygons on full screens, running at fast framerates, and also use features of the Blitter with more insight than games did.

[Thorham]

Seeing how the copper has a resolution of eight pixels in 16 color lowres, why not use the copper for partial fills? You could even use sprites to fill in the rest. Should be much faster.

Never tried it, of course

Edit: Thought this was in the coding forum

[NovaCoder]

Originally Posted by kovacm

Hi,


or, even better: does somebody, with knowledge, can make explanation how much theoretical gain could be in game (not in demos!) using blitter for poly-fill?

No sure about filling polygons? The blitter isn't very programmable, it's just a basic memory mover.

The Blitter has been used to help with making C2P faster if that counts? This is only useful for 030 and below, anything faster and it's better to just use the CPU.

[kovacm]

Originally Posted by NovaCoder

No sure about filling polygons? The blitter isn't very programmable, it's just a basic memory mover.

...but if it can work in parallel with CPU than using blitter have even more sense?

Originally Posted by NovaCoder

The Blitter has been used to help with making C2P faster if that counts? This is only useful for 030 and below, anything faster and it's better to just use the CPU.

It is about Amiga 500 - many Amiga users say that 3D games would be faster if programers used blitter for polygon fill instead of CPU.

[frank_b]

If the Amiga blitter had programmable x increments and access to a 16 bit per pixel chunky video mode you could do this http://s390174849.online.de/ray.tscc.de/gouraud.htm Blitter rendered gourad shading is pretty cool!

[britelite]

Originally Posted by frank_b

If the Amiga blitter had programmable x increments and access to a 16 bit per pixel chunky video mode you could do this http://s390174849.online.de/ray.tscc.de/gouraud.htm Blitter rendered gourad shading is pretty cool!

Actually, that's possible with the Amiga blitter, for example combining it with a HAM6 c2p-routine.

[frank_b]

Originally Posted by britelite

Actually, that's possible with the Amiga blitter, for example combining it with a HAM6 c2p-routine.

Interesting. I'd be interested in hearing the technique described.
I was always surprised the Amiga blitter had hard coded x increments. Programmable ones would have been more flexible.

This is a fairly interesting paper on using bitblit http://pdos.csail.mit.edu/%7Ersc/pike84bitblt.pdf

The Xor polygon filling is quite smart. Not really so useful on the Amiga as it already has area fill but cool nonetheless.

[britelite]

Originally Posted by frank_b

I was always surprised the Amiga blitter had hard coded x increments. Programmable ones would have been more flexible.

It has a modulo, which can be used as x increment, and which is perfect for this kind of gouraud shading (and other effects too).

[frank_b]

Originally Posted by britelite

It has a modulo, which can be used as x increment, and which is perfect for this kind of gouraud shading (and other effects too).

It's a y modulo though. Better if it had X and Y for each source. Would have been nice to have an indirect addressing mode too. With halftone/smudge combined with destination f/l/m mask you can hflip or do brush magnification in 4 passes.
You can even do bitmap to b/w 16 bpp colour expansion

[britelite]

Originally Posted by frank_b

It's a y modulo though. Better if it had X and Y for each source.

Sure, but when doing this kind of gouraud shading, you only draw one line at a time, so a y modulo is not needed.

[frank_b]

Originally Posted by britelite

Sure, but when doing this kind of gouraud shading, you only draw one line at a time, so a y modulo is not needed.

That's a good point. X increment and masks would allow this kind of trick to be used with chunky copper though

[britelite]

Originally Posted by frank_b

That's a good point. X increment and masks would allow this kind of trick to be used with chunky copper though

It's already possible with copper chunky

[frank_b]

Originally Posted by britelite

It's already possible with copper chunky

You're making me want to dig out my a1200 and ASM one

[AJCopland]

I'm surprised no-one has posted a link to Scali's work with subpixel precision blitter accelerated polygon rendering yet... so: https://scalibq.wordpress.com/2012/0...real-part-5-1/

Andy

[pandy71]

Originally Posted by kovacm

Hi,

I read from time to time (or to much time ) two type of arguments:

1) Atari ST has 10% faster CPU so 3D polygone games are faster
2) 3D games are ports from ST to Amiga so they do not use blitter otherwise they would be much faster on Amiga

I personally find "10% faster" argument irrelevant (unnoticeably).
but I am curios if there is any game on Amiga game that use blitter for 3D polygon fill?

or, even better: does somebody, with knowledge, can make explanation how much theoretical gain could be in game (not in demos!) using blitter for poly-fill?

Game or demo no difference - code is code - (assumed skilled developer use blitter).

HW data says on 1 plane up to 1 million pixels can be draw on screen - line mode (and up to 16 million pixel fillrate), count four planes (16 colors) so divide those figures by 4 and to be realistic by another 4 (25% efficiency, setup need time, short length vector may be more efficient draw by CPU).
Probably some work can be made on hybrid mode - CPU + Blitter + Copper and this can provide some gain.

Originally Posted by kovacm

I have no knowledge about blitter: e.g. how much time would you spent on setting it up for fill vs filling with CPU alone? How much time is left for CPU while blitter doing fills (in case that there is no fast ram, and case with fast ram)...
Amiga 1200 case: if there is FastRAM, CPU could calculate 3D vertices while blitter filling polygons so filling could be almost "free"? Can copper somehow help with setting up blitter...?

Good question - Blitter use 20 registers so in worse case scenario setup may require to set them all so 20 R/W cycles (but it should be less than that).
http://www.winnicki.net/amiga/memmap/LineMode.html
http://eab.abime.net/showthread.php?t=68708
http://eab.abime.net/showthread.php?t=63090

Originally Posted by kovacm

btw all 512KB expansion for Amiga 500 back in 80s and 90s were chipram? right? FastRAM was not common expansion in Amiga world until Amiga 1200?

Most of them - easy to connect and cheap, required by lot of software.
On some motherboards boards it can be mapped as CHIP RAM on some mobos not (with all OCS Agnus and presumably ICS Agnus this will be non CHIP RAM with speed limited by HW side aka SLOW RAM).

[Mrs Beanbag]

blitter polygon filling is quite nice and simple, draw the lines in 1 pixel per line mode with XOR minterms, you can do any complex shape of polygon even with holes in. The problem you need to be careful with though is because naively, you simply fill a bounding box, if you have a long thin polygon that goes diagonally across the screen, you can end up blitting an entire screen's worth even though there are less than 16 pixels of fill per scanline.

If you are clever you can fill multiple polygons using a single fill operation, though. It is good for completely convex shapes or concave interiors.

[mc6809e]

Originally Posted by pandy71

Game or demo no difference - code is code - (assumed skilled developer use blitter).

HW data says on 1 plane up to 1 million pixels can be draw on screen - line mode (and up to 16 million pixel fillrate), count four planes (16 colors) so divide those figures by 4 and to be realistic by another 4 (25% efficiency, setup need time, short length vector may be more efficient draw by CPU).
Probably some work can be made on hybrid mode - CPU + Blitter + Copper and this can provide some gain.

But you can't usually render a poly directly to a frame buffer unless it's the only poly to be rendered, unless I'm missing something.

The best way, IMO, is to first render/fill the poly to a single plane in a cleared buffer using AD copy blit with fill on. Then blit the poly using an ACD blit to each plane setting LF for each plane to control color.

This means that a generic poly fill and render (ignoring line draw stage), takes (3*(planes+1)+2)*2 = 34 CPU cycles per 16 pixels on a 16-color screen (ignoring interference from other DMA).

Poly fill on the Amiga comes with the bonus that interior areas can be unfilled/filled. Very irregular shapes can be handled. A star shape can be quickly filled, for example.

That doesn't happen that often, though, in a 3d poly game. Typically triangles or quadrilaterals need to be rendered.

Using the CPU, these simpler shapes can be rendered by the CPU directly to the frame buffer. A clever technique I've seen documented involves using the CPU to draw horizontal lines between to two points, moving line by line through a portion of the frame buffer. A table driven approach allows the ends of the lines to be rendered quickly using masks and MOVEM is used to fill in the middle of the line.

On the ST, the best case is when a horizontal line is drawn entirely with a MOVEM. In that case it takes 16+(line_length) CPU cycles. The ST's otherwise odd interleaved bitmap scheme actually helps here, making long runs of writes to the frame buffer more likely.

Of course calculating a new horizontal line length and position for each scanline is time consuming.

With a fill rate that asymptotically approaches 1 CPU cycle per pixel (for only simply polys, of course), I can see how a programmer might be inclined to stick with the CPU-based solution rather than explore an unknown gain by using the Amiga's specialized hardware. And considering that more time is spent calculating the 3d world than poly filling/rendering, the investment of time might not seem worth it. To an expert Amiga programmer it might, but not a programmer writing for multiple platforms.

This whole discussion of speed ignores one important point, however, and that's the ability of the Amiga to perform operations concurrently with the CPU. For 3d games where many multiplies and divides are performed, many cycles are left free for the blitter. Huge gains are possible.

But again there's a problem. To gain maximum concurrency, poly fill/render must happen with data that has already been computed since poly render order can only be known after all calculation have been performed. This means that calculations for the next frame must occur while the previous frame is being built. That greatly complicates the design. A programmer used to a simple calculate/render loop would have to make serious changes to the programs logic to take advantage of that, possibly using interrupts or the copper to render.

I hate to be down on the Amiga here. Watching simple 3d demos on both the Amiga and ST suggests that, for simple scenes, the Amiga is several times faster rendering filled polys than is the ST.

But for a large world and complicated game logic, if the programmer can't find a way to take advantage of concurrency, the gains probably aren't that great.

If the programmer can find some way to pipeline blitter operations while doing calculations, then I think the gains can still be large.

[kovacm]

Originally Posted by mc6809e

This whole discussion of speed ignores one important point, however, and that's the ability of the Amiga to perform operations concurrently with the CPU.

I imply this in first post: "How much time is left for CPU while blitter doing fills (in case that there is no fast ram, and case with fast ram)..."

inspired by discussion at atari forum in topic about ST and Amiga blitter (where you also take part! )

you are right, using blitter in parallel with CPU would complicated entire process but it would be probably biggest gain in speed.