23 February 2015, 10:12 | #1 |
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? |
23 February 2015, 17:28 | #2 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,634
|
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.
|
24 February 2015, 02:32 | #3 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,642
|
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. |
24 February 2015, 03:41 | #4 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,806
|
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 |
24 February 2015, 04:01 | #5 | |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,406
|
Quote:
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 05:19. |
|
24 February 2015, 07:36 | #6 | |
Banned
Join Date: Jan 2012
Location: Serbia
Posts: 275
|
Quote:
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. |
|
24 February 2015, 07:58 | #7 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
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!
|
24 February 2015, 08:05 | #8 | |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 819
|
Quote:
|
|
24 February 2015, 08:09 | #9 | |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Quote:
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 14:55. Reason: Back-to-back posts merged. |
|
24 February 2015, 08:13 | #10 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 819
|
|
24 February 2015, 08:15 | #11 | |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Quote:
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 08:20. |
|
24 February 2015, 08:18 | #12 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 819
|
|
24 February 2015, 08:19 | #13 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
|
24 February 2015, 08:20 | #14 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 819
|
|
24 February 2015, 08:21 | #15 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
|
24 February 2015, 14:11 | #16 |
Registered User
Join Date: Sep 2013
Location: Beeston, Nottinghamshire, UK
Posts: 238
|
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 |
24 February 2015, 15:04 | #17 | |||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,855
|
Quote:
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:
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:
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). |
|||
24 February 2015, 23:05 | #18 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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. |
25 February 2015, 03:46 | #19 | |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 372
|
Quote:
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 06:45. Reason: error in formula |
|
25 February 2015, 10:12 | #20 | |
Banned
Join Date: Jan 2012
Location: Serbia
Posts: 275
|
Quote:
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. |
|
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 01:34 |
CPU Filling vs. Blitter Filling Routine | victim | Coders. General | 18 | 26 January 2014 02:15 |
Blitter filling routine used in games | Codetapper | Coders. General | 2 | 26 January 2012 10:20 |
Filling with the blitter... | Lonewolf10 | Coders. Tutorials | 7 | 13 September 2011 14:30 |
Would you like some polygons? | Dalai | Retrogaming General Discussion | 7 | 05 October 2004 00:20 |
|
|