Chunky to planar

pmc · 14 September 2009, 13:23

Hello chaps.

More questions from me I'm afraid - so what's new?

Do all the more modern (AGA) Amiga demos use some kind chunky to planar conversion for their graphics?

I don't really understand or have any experience of c2p but I assume that the idea is that internally to your routine you represent graphics in chunky format and do all your graphics manipulations on this chunky graphics data before putting these updated chunky graphics through a c2p converter routine for display in planar format...?

I take it this is for reasons of speed? - ie. it's quicker to generate / change the chunky graphics data and do c2p ready for display rather than updating the planar graphics directly once you start getting to doing complex things like texture mapped 3d in multiple bitplanes...?

As usual, any info gratefully received.

I'm not necessarily trying to code this stuff at the moment, just thinking about my potential coding future.

musashi5150 · 14 September 2009, 13:58

Your hunch is right - it's for speed. Think about setting a pixel on a 256 colour planar display. You would need to do 8 writes (one for each plane) to set the pixel. With a chunky display you just write once. Think of this 8 write penalty inside an inner loop running many times...

Also with a planar display you cannot access all pixels of the display individually without some extra logic operations (mask/shift etc) - this adds a penalty too of course.

Basically the short of it is: it's faster to render your graphics chunky style and convert it all later than to convert every pixel as you go along

pmc · 14 September 2009, 14:49

@ musashi5150 - OK mate, nice one. Something for me to think about ways of achieving for the future then...

So we can add c2p to that (long) list of things you told me you had done / were doing in code.

See, I told you before you were a coding hero.

musashi5150 · 14 September 2009, 21:44

Quote:

Originally Posted by pmc

See, I told you before you were a coding hero.

I don't know about that... more like a failed teacher

NovaCoder · 15 September 2009, 07:58

Here's a nice tutorial it makes no sense to be me but at least it's pretty.

pmc · 15 September 2009, 08:06

@ NovaCoder - Nice one pal.

I'll check it out...

musashi5150 · 15 September 2009, 08:51

Yup and it's a good one as Kalms did it

Leffmann · 15 September 2009, 12:00

Scout (I think this is Kalms?) has uploaded a zip file to the Aminet with a collection of C2P routines as well. I remember using them cause I could never get my own to run as fast, and found his routines to be excellent.

Keep in mind it's not a rule that rendering in chunky format and converting is always faster, but depends on size and regularity in what you render. F.ex for some left to right rendering a sequence of ADD.L Dx, Dx OR.B x, Dx or similar to insert sequential pixels will most likely be faster.

Asman · 15 September 2009, 13:08

@Leffman - Can you post the link to this zip file ? Thanks

Leffmann · 15 September 2009, 14:02

I've uploaded the archive to the zone.

pmc · 15 September 2009, 14:14

@ Leffman - cheers for the archive upload.

It's nice to have source codes but the fun is in trying to get it working yourself - I've stored them in case but there'll be no peeking from me until I've at least had a go at it first.

Asman · 15 September 2009, 16:20

@Leffmann - Thank you.

14 September 2009, 13:23	#1
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Chunky to planar Hello chaps. More questions from me I'm afraid - so what's new? Do all the more modern (AGA) Amiga demos use some kind chunky to planar conversion for their graphics? I don't really understand or have any experience of c2p but I assume that the idea is that internally to your routine you represent graphics in chunky format and do all your graphics manipulations on this chunky graphics data before putting these updated chunky graphics through a c2p converter routine for display in planar format...? I take it this is for reasons of speed? - ie. it's quicker to generate / change the chunky graphics data and do c2p ready for display rather than updating the planar graphics directly once you start getting to doing complex things like texture mapped 3d in multiple bitplanes...? As usual, any info gratefully received. I'm not necessarily trying to code this stuff at the moment, just thinking about my potential coding future.

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
Chunky looking Graphics.	Washac	support.Hardware	8	09 February 2010 17:52
Amiga Bitplanes & Planar vs Chunky - Technical Expert Required	CodyJarrett	project.APoV	4	12 November 2009 11:14
Chunky to planar on a500	Alter	Coders. General	28	10 April 2007 02:53

14 September 2009, 13:58	#2
musashi5150 move.w #$4489,$dff07e Join Date: Sep 2005 Location: Norfolk, UK Age: 42 Posts: 2,351	Your hunch is right - it's for speed. Think about setting a pixel on a 256 colour planar display. You would need to do 8 writes (one for each plane) to set the pixel. With a chunky display you just write once. Think of this 8 write penalty inside an inner loop running many times... Also with a planar display you cannot access all pixels of the display individually without some extra logic operations (mask/shift etc) - this adds a penalty too of course. Basically the short of it is: it's faster to render your graphics chunky style and convert it all later than to convert every pixel as you go along

14 September 2009, 14:49	#3
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	@ musashi5150 - OK mate, nice one. Something for me to think about ways of achieving for the future then... So we can add c2p to that (long) list of things you told me you had done / were doing in code. See, I told you before you were a coding hero.

15 September 2009, 07:58	#5
NovaCoder Registered User Join Date: Sep 2007 Location: Melbourne/Australia Posts: 4,405	Here's a nice tutorial it makes no sense to be me but at least it's pretty.

15 September 2009, 08:06	#6
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	@ NovaCoder - Nice one pal. I'll check it out...

15 September 2009, 08:51	#7
musashi5150 move.w #$4489,$dff07e Join Date: Sep 2005 Location: Norfolk, UK Age: 42 Posts: 2,351	Yup and it's a good one as Kalms did it

15 September 2009, 12:00	#8
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	Scout (I think this is Kalms?) has uploaded a zip file to the Aminet with a collection of C2P routines as well. I remember using them cause I could never get my own to run as fast, and found his routines to be excellent. Keep in mind it's not a rule that rendering in chunky format and converting is always faster, but depends on size and regularity in what you render. F.ex for some left to right rendering a sequence of ADD.L Dx, Dx OR.B x, Dx or similar to insert sequential pixels will most likely be faster.

15 September 2009, 13:08	#9
Asman 68k Join Date: Sep 2005 Location: Somewhere Posts: 828	@Leffman - Can you post the link to this zip file ? Thanks

15 September 2009, 14:02	#10
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	I've uploaded the archive to the zone.

15 September 2009, 14:14	#11
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	@ Leffman - cheers for the archive upload. It's nice to have source codes but the fun is in trying to get it working yourself - I've stored them in case but there'll be no peeking from me until I've at least had a go at it first.

15 September 2009, 16:20	#12
Asman 68k Join Date: Sep 2005 Location: Somewhere Posts: 828	@Leffmann - Thank you.

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