07 July 2016, 21:08 | #1 |
Posts: n/a
|
Chunky to Planar (C2P) -- USELESS GIMMICK?!
I'm starting to get back into the Amiga scene. I used to own A1000, A500, A2000, A1200. Now i'm trying to understand the Amiga bit-planes vs the IBM PC chunky graphics at the time. I'm ignoring memory capacity and cpu speed limitations and trying to understand the limitations of the Amiga planar approach and why it was slower to the PC's chunky approach for Wolfenstein 3D or Doom.
Many have suggested a Chunky to Planar chip (Akiko) in order to speed things up. I just dont understand how this would speed things up beyond "porting" an existing chunky game into a viewable format for the original Amiga -- at least one doesnt have to manually break down the 1 byte chunky color value into 5 (or 8) bit planes the Agnus demands. It is done for you via the chip? There is still the bottle neck of all the memory writes and reads by the C2P operation AND then the Agnus to re-compose the index value for color register lookup (seems very inefficient like we are going back to the original chunky value). Love for someone to clear up for me how the Amiga really does work for Planar and why C2P is a benefit. From my understanding of Chunk and Planar display C2P seems pretty useless if one wants Doom on the Amiga. Again yes it helps me to port existing chunky related code and saves me from smearing out the color register across multiple bit planes but still the Amiga chipset itself is still the bottleneck. Blows me away the original amiga chip designers didnt have some 8 bitplane efficient approach implemented thereby switching to chunky mode once it became prohibitive to make so many read and bit operations. Again i'm still learning all this so PLEASE enlighten me where necessary. THanks Last edited by crosis38; 07 July 2016 at 21:30. |
07 July 2016, 21:49 | #2 |
Registered User
Join Date: Aug 2006
Location: Augusta, Georgia, USA
Posts: 552
|
https://en.wikipedia.org/wiki/Planar_(computer_graphics)
It's slower to modify a single pixel or group of pixels, because you aren't changing a contiguous block of memory. Most ray-casting engines are designed to work on "chunky" displays. As to the "why"- I guess it was the way it was done in 1982 when the chipset was developed. Most likely due to limitations of RAM speed or chip manufacturing at the time, so they added a blitter to help. You have to remember how far ahead Lorraine was at that time. Nobody even believed it was possible at 1983 CES. Last edited by r.cade; 07 July 2016 at 21:54. |
08 July 2016, 06:03 | #3 |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Welcome on the EAB!
C2P is not a benefit, it is a necessity because the Amiga had no chunky modes. And when the Amiga was designed, neither Catacomb nor Wolfenstein 3D and even less Doom existed in any form in John Carmack's brain. So it would have been quite extraordinary for the Amiga designers to anticipate that this would be needed 10 years later. Planar modes had some advantages over chunky ones, notably they use memory more efficiently: to increase the bit depth, just allocate a new plane. With chunky modes, one was limited to bit depths which could divide 8 (a byte): 1, 2, 4, 8, or accept that some bits are unused (which would be ridiculous since they consume bandwidth anyway) or even worse: alignment is going to be uneven and accessing or modifying single pixels becomes horribly expensive. This is why the Atari ST only has a 16 colors mode and no 32 or 64 colors mode like the Amiga can. In 1985, bitplanes made a lot of sense, in 1990, not so much alas. Also, note that the early Amigas had enough bandwidth to display 8bit graphics, alas they had only 32 color registers and sadly, they decided to not extend the halfbrite mode principle (6 bit graphics, with the upper 32 colors being deduced by halving the 32 lower ones) to higher bit depths. Last edited by ReadOnlyCat; 08 July 2016 at 06:10. |
08 July 2016, 07:34 | #4 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,359
|
|
08 July 2016, 13:42 | #5 | |
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,157
|
Quote:
To plot a single pixel, you have to read a byte from the bitplane, mask off the bits you're not going to change, shift and mask the relevant bit from the chunky colour value, merge with the existing colour value and write it back to RAM. For every plane. Which means you read and write every byte 8 times for a 256 colour screen. Chunky to Planar is about combining all that shifting and masking into a single, efficient pass. |
|
08 July 2016, 18:39 | #6 |
New generation Amiga user
Join Date: Jun 2016
Location: Phoenix
Posts: 32
|
The bitplanes are also read (and written?) in parallel by the ramdac, so the ramdac can keep up with the raster line with slower memory. The wikipedia article that was posted explains this as well (and in better detail than I can).
|
08 July 2016, 19:45 | #7 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
It is definitely not a full planar mode, more of a chunklar or planky since all the bits of a given depth are not stored together continuously (plane = countinuous surface). A bit plane is constituted of only bits of a given depth. The Atari bitplanes exist only virtually since one can never access or read them without masking other bit depths. |
|
08 July 2016, 20:00 | #8 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,359
|
Quote:
They are a lot closer to Amiga planar than to chunky. It's just ordered differently. Instead of full planes in separate memory regions, or planes alternating each line (aka interleaved), it's one word of each plane next to each other. Conversion from Atari bitplanes is a lot faster than a c2p ; even an unexpanded A1200 can go far over 50fps. You may think they are impractical. But in many cases they are not. You have ONE pointer to your screen, where on the Amiga you have several. |
|
09 July 2016, 01:45 | #9 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
|
|
09 July 2016, 03:04 | #10 | |
Registered User
Join Date: Feb 2010
Location: SnowLand, Canada
Posts: 74
|
Quote:
Did anyone ever try to port it? Last edited by Khyron; 09 July 2016 at 03:11. |
|
09 July 2016, 04:17 | #11 |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Correct! And I should not have made that mistake since I discussed with Bszili about it in this EAB thread.
We are completely off topic now but... Bszili did make a preliminary port which is 100%C and requires a 060 to run at acceptable frame rates and which I promised to attempt making faster but alas did not get to spend a single second on (yet!). Note though that this is only the code. The levels are still copyright and the game is sold on GOG by the guy who (rightfully) owns the rights for it and contracted id Software to write it at the time. So be cool and buy it from there, it is really cheap anyway ($8). But as I said the game is not playable at the moment so there is little point trying yet. Last edited by ReadOnlyCat; 09 July 2016 at 04:22. Reason: Added URL on GOG. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Optimised Akiko Chunky-to-Planar emulation | Mequa | support.WinUAE | 9 | 05 February 2012 02:47 |
Akiko Chunky-to-Planar conversion | Mequa | support.WinUAE | 5 | 21 January 2012 10:50 |
Amiga Bitplanes & Planar vs Chunky - Technical Expert Required | CodyJarrett | project.APoV | 4 | 12 November 2009 11:14 |
Chunky to planar | pmc | Coders. Tutorials | 11 | 15 September 2009 16:20 |
Chunky to planar on a500 | Alter | Coders. General | 28 | 10 April 2007 02:53 |
|
|