English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 13 October 2017, 08:50   #1
redblade
Zone Friend

redblade's Avatar
 
Join Date: Mar 2004
Location: Middle Earth
Age: 33
Posts: 1,030
256 Colours, Chunky Vs Planar, what was better?

I know the Amiga used Planar graphics, but for 256 colours, would chunky be the best format?

Planar, 40 bytes * 200 lines * 8 bitplanes = 64,000 bytes
Chunky, 1 bytes (from 00 - 256) * 320 pixels a line * 200 lines = 64,000 bytes.

It just seems like a lot of effort on a planar system having to go through every one of those 8 bitmaps to set the bit for a colour change? Trying to shift some sprites across seems like it would be a nightmare on a planar system. Is there any advantage of a 256 colour planar system?

Thanks
redblade is offline  
AdSense AdSense  
Old 13 October 2017, 09:54   #2
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 356
One advantage of an 8 bitplane planar system is you can have 2 independent 4 bitplane
playfields, which would be good for parallax scrolling and other similar effects.
alpine9000 is offline  
Old 13 October 2017, 10:11   #3
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 891
Send a message via Yahoo to Samurai_Crow
Burst fetches and page fetches benefit chunky modes more. Likewise, narrow blits like the ones used in texture mapping favor chunky modes.

Planar modes are favored by a simpler GPU design and bitfield partitioning strategies. Among them are the ability to shade spread palettes algorithmically and the famous dual playfield mode, as mentioned.

Sent from my Prism II using Tapatalk
Samurai_Crow is offline  
Old 13 October 2017, 13:24   #4
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 126
Planar made sense initially because graphics performance was relatively low and planar made it easy to scale memory, DMA and performance. It was a good trade off of flexibility and a slightly awkward format.

When AGA was being designed they just wanted something quick, so they simply increased the number of available bitplanes and added 32 bit capability to support them. Even later the Akkiko chip was thrown in, but it was all just because unsufficient resources went to developing AAA with proper chunky modes.
zero is offline  
Old 14 October 2017, 14:23   #5
coder76
Registered User

 
Join Date: Dec 2016
Location: Finland
Posts: 20
Both chunky and planar modes have their own advantages. But there exists chunky to planar routines (c2p's), which converts a chunky screen held in fast ram to chip ram planar format. On a 68040/68060 its copyspeed, so this conversion does not slow down copy speed to chip ram. With Doom, you really see that planar format does not slow down faster Amigas. A 68030/50 MHz even outperforms a 386/40 MHz running Doom in benchmarks by a frame or two, despite doing the c2p. Also, a 68040 outperforms a 486 PC running Doom at same clockspeed. The chip ram access speed is more of a bottleneck on the Amigas, rather than the planar format.
coder76 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
Chunky to Planar (C2P) -- USELESS GIMMICK?! crosis38 support.Hardware 10 09 July 2016 04:17
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
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

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 06:55.


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