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

[r.cade]

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.

[ReadOnlyCat]

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.

[meynaf]

Originally Posted by ReadOnlyCat

This is why the Atari ST only has a 16 colors mode and no 32 or 64 colors mode like the Amiga can.

Not exactly. The Atari ST uses planar graphics, not chunky. But it's made in such a way that adding new planes isn't as easy as on the Amiga.

[robinsonb5]

Originally Posted by crosis38

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.

I think you're underestimating how expensive that process of manually breaking down 1 byte chunky colour values actually is.
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.

[debiani386]

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).

[ReadOnlyCat]

Originally Posted by meynaf

Not exactly. The Atari ST uses planar graphics, not chunky. But it's made in such a way that adding new planes isn't as easy as on the Amiga.

I just mentioned it as an example of the inconvenience of having non continuous bit planes. But you are right that it looks like I am saying it is chunky when it is not exactly so.

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.

[meynaf]

Originally Posted by ReadOnlyCat

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.

You can access them without masking, just 16 bits at a time.
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.

[ReadOnlyCat]

Originally Posted by meynaf

You can access them without masking, just 16 bits at a time.
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.

Damn, you are right. For some reason I keep thinking they are grouped by nibble rather than by word.

[Khyron]

Originally Posted by ReadOnlyCat

Welcome on the EAB!

And when the Amiga was designed, neither Catacomb..

Catacomb was planar...
Did anyone ever try to port it?

[ReadOnlyCat]

Originally Posted by Khyron

Catacomb was planar...
Did anyone ever try to port it?

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.