English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 23 February 2015, 11:12   #1
kovacm
Banned
 
Join Date: Jan 2012
Location: Serbia
Posts: 275
Using blitter for filling 3D polygons

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?
kovacm is offline  
AdSense AdSense  
Old 23 February 2015, 18:28   #2
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 710
Quote:
Originally Posted by kovacm View Post
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.
hooverphonique is offline  
Old 24 February 2015, 03:32   #3
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,452
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.
Photon is offline  
Old 24 February 2015, 04:41   #4
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
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
Thorham is offline  
Old 24 February 2015, 05:01   #5
NovaCoder
Registered User
NovaCoder's Avatar
 
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 3,444
Quote:
Originally Posted by kovacm View Post
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.

Last edited by NovaCoder; 24 February 2015 at 06:19.
NovaCoder is offline  
Old 24 February 2015, 08:36   #6
kovacm
Banned
 
Join Date: Jan 2012
Location: Serbia
Posts: 275
Quote:
Originally Posted by NovaCoder View Post
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?

Quote:
Originally Posted by NovaCoder View Post
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.
kovacm is offline  
Old 24 February 2015, 08:58   #7
frank_b
Registered User
 
Join Date: Jun 2008
Location: Boston USA
Posts: 332
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!
frank_b is offline  
Old 24 February 2015, 09:05   #8
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 276
Quote:
Originally Posted by frank_b View Post
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.
britelite is offline  
Old 24 February 2015, 09:09   #9
frank_b
Registered User
 
Join Date: Jun 2008
Location: Boston USA
Posts: 332
Quote:
Originally Posted by britelite View Post
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.

Last edited by TCD; 24 February 2015 at 15:55. Reason: Back-to-back posts merged.
frank_b is offline  
Old 24 February 2015, 09:13   #10
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 276
Quote:
Originally Posted by frank_b View Post
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).
britelite is offline  
Old 24 February 2015, 09:15   #11
frank_b
Registered User
 
Join Date: Jun 2008
Location: Boston USA
Posts: 332
Quote:
Originally Posted by britelite View Post
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

Last edited by frank_b; 24 February 2015 at 09:20.
frank_b is offline  
Old 24 February 2015, 09:18   #12
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 276
Quote:
Originally Posted by frank_b View Post
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.
britelite is offline  
Old 24 February 2015, 09:19   #13
frank_b
Registered User
 
Join Date: Jun 2008
Location: Boston USA
Posts: 332
Quote:
Originally Posted by britelite View Post
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
frank_b is offline  
Old 24 February 2015, 09:20   #14
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 276
Quote:
Originally Posted by frank_b View Post
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
britelite is offline  
Old 24 February 2015, 09:21   #15
frank_b
Registered User
 
Join Date: Jun 2008
Location: Boston USA
Posts: 332
Quote:
Originally Posted by britelite View Post
It's already possible with copper chunky
You're making me want to dig out my a1200 and ASM one
frank_b is offline  
Old 24 February 2015, 15:11   #16
AJCopland
Registered User

 
Join Date: Sep 2013
Location: Beeston, Nottinghamshire, UK
Posts: 83
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
AJCopland is offline  
Old 24 February 2015, 16:04   #17
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by kovacm View Post
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.

Quote:
Originally Posted by kovacm View Post
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


Quote:
Originally Posted by kovacm View Post
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).
pandy71 is offline  
Old 25 February 2015, 00:05   #18
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 25 February 2015, 04:46   #19
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 281
Quote:
Originally Posted by pandy71 View Post
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.

Last edited by mc6809e; 25 February 2015 at 07:45. Reason: error in formula
mc6809e is offline  
Old 25 February 2015, 11:12   #20
kovacm
Banned
 
Join Date: Jan 2012
Location: Serbia
Posts: 275
Quote:
Originally Posted by mc6809e View Post
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.
kovacm is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Blitter poly-line draw & filling - the 100th Herpes Coders. Asm / Hardware 12 14 May 2014 02:34
CPU Filling vs. Blitter Filling Routine victim Coders. General 18 26 January 2014 03:15
Blitter filling routine used in games Codetapper Coders. General 2 26 January 2012 11:20
Filling with the blitter... Lonewolf10 Coders. Tutorials 7 13 September 2011 15:30
Would you like some polygons? Dalai Retrogaming General Discussion 7 05 October 2004 01:20

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 02:24.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 1.61853 seconds with 11 queries