Chunk 2 planar graphics: the way to do it
Introduction
Hi freaks... I'm Ray, the new coder of .tSCc.
This is my first tutorial so let me explain some basic things:
First of all I got to tell you that all the examples will be plain 68000 asm code and sometimes it'll get quite machine-dependend. So my tutorials will only be useful with the ST and its "brothers" - so don't even get the idea of taking the following descriptions for valid on a TT or something, but I think that's clear somehow.
On the second I'm expecting you to understand the basics of 68k programing because I don't have the time to teach you 68k coding in all its sometimes 'bizarre' details like fx. The different addressing modes or something (but watch out 'cause I'm going to release a 68k-tutorial in one of the next magazines). And if there's something you don't understand just read it 2 or more times just until you got it - if this doesn't help just ask me.
So, if you wanna contact me don't hesitate:
- e-mail : reimund.dratwa@freenet.de
- homepage: http://rd-developments.de.gs (my page before I joined .tSCc.) (don't forget to grab the newest tutorial!)
Let's get it on
Let me tell you some sentences about the purpose of this tutorial. Today I'll try to explain how a technique called 'chunk 2 planar graphics', which is the secret of all those modern demos, can be realized on the ST. Now you might ask, what the hell means chunk to planar?!?
Since I think you know how the ST's bitplane-screen works (if that isn't the case read on in the next paragraph) you'll probably know how hard it is to set a pixel and even worse, how slow.
So chunk 2 planar 'conversion' means that the bitplanes bits are set according to byte-values in a so called chunky-buffer where every byte represents the color of one single plot on the screen (this buffer could be compared to the PC's VGA-memory of a 320x200x256 screen - don't get me wrong, Intel really suckz! - I just wanted to give an example).
First you set up your effect or what ever you want in that chunky-buffer by simply moving the according bytes into it and in a further step the chunky-buffer is converted to bitplane-data (hence planar simply means bitplane-graphics). How this works exactly will be described later on...
A brief description of the bitplanes
Skip this paragraph if you already know how the ST's screen is arranged. As already mentioned, it's hard to set pixels 'by hand' because the ST's screen is somehow splitted into bitplanes.
Ok I'll be some more exact, but notice: I'm only covering ST low rez 320x200x16. In this resolution the screen is divided into 4 so called 'bitplanes' every four 'corresponding' bits of these bitplanes indicate in which color one pixel on the screen should appear.
So lets take a look at the first 4 words of screen-memory.
The diagram should make it clear:
screen
0 319
-------------------------------------------
0 -* -
- -
- -
- -
- -
.
.
.
199 - -
-------------------------------------------Assuming we wanted to set the pixel in the upper left corner of the screen (0/0), marked with *, in color $D (=13 if you don't know what's hexadecimal just stop reading) this would mean we would have to manipulate the highest bit of the first 4 words in screen memory.
$D (hex) = %1101 (bin)screen memory:
bit 15 7 0
--------------------------------------------------------------------------------
bitpl/word 1 | 1 | | | | | | | | | | | | | | | |
--------------------------------------------------------------------------------
bitpl/word 2 | 1 | | | | | | | | | | | | | | | |
--------------------------------------------------------------------------------
bitpl/word 3 | 0 | | | | | | | | | | | | | | | |
--------------------------------------------------------------------------------
bitpl/word 4 | 1 | | | | | | | | | | | | | | | |
--------------------------------------------------------------------------------Got it, no - then let's do some more examples:
Just imagine we wanted set the pixel right beside the one before (ie. 1/0) in the same color. Then we'd just manipulate bit 14 of the 4 words.
But now be careful, what if we wanted to set pixel 16/0 (the 17th on the sceen)? The answer is just as simple as this: since every single of the 4 words only holds 16 bits (=16 pixels) we just had to skip over to the next 4 words in memory (5,6,7,8).
I think you're getting the idea, right? But I'll think now you'll see why setting pixels is really slow on the ST, as well. It's just because you have to 'bit set' 4 places in screen-memory just for one pixel - and I think you know that bit operations are kinda hard for a byte/word/long aligned cpu.
Now guys, I think it's time for some code at the end of this paragraph (let's go back to the first example when we wanted to set the upper left pixel with color $D):
move.l screen,A0 * assume the screen addr is stored in 'screen'
clr.w D0 * start at offset 0
ori.w #%1000000000000000,0(A0,D0.w) * set bit 15 of the 1st word of bitpl 1
ori.w #%1000000000000000,2(A0,D0.w) * set bit 15 of the 1st word of bitpl 2
andi.w #%0111111111111111,4(A0,D0.w) * clear bit 15 of the 1st word of bitpl 3
ori.w #%1000000000000000,6(A0,D0.w) * set bit 15 of the 1st word of bitpl 4Hey - we've just set the first pixel! Now try what happens if you fx. move #8 into D0 instead of clearing it...
The secret of c2p, how it works and why it's so quick
The only significant thing I can mention on top of this paragraph is that the whole let's call it secret of the c2p conversion is the 68k's movep-instruction: what movep actually does is moving word or long values 'byte per word' aligned by splitting them up into bytes, so let's take a look at a little example:
move.l #$FE23D2E0,D0
movep.l D0,(A0) * this instruction kinda covers 64 bit or in other
* words only the upper bytes of 4 following words in
* memory (already smelling what we'll do ? ;) )after the instruction:
(A0) = $FE
2(A0) = $23
4(A0) = $D2
6(A0) = $E0or if we start at an odd addr. (if A0 holds an even one):
move.l #$FE23D2E0,D0
movep.l D0,1(A0) * now movep will will use the lower 8 bits of the data-
* bus or some more simple : now it covers the lower
* bytes of 4 following wordsafter the instruction:
1(A0) = $FE
3(A0) = $23
5(A0) = $D2
7(A0) = $E0if we didn't have movep we'd have to to:
move.l #$FE23D2E0,D0
move.b D0,6(A0)
lsr.l #8,D0
move.b D0,4(A0)
lsr.l #8,D0
move.b D0,2(A0)
lsr.l #8,D0
move.b D0,(A0)I think then we could forget our chunk 2 planar graphics - thanx motorola!
And now go on reading very carefully because now I'll describe the core of the c2p conversion:
Well, what we need to do a c2p conv. is, like mentioned above, 1st a 'chunky- buffer' holding the chunky byte data and at 2nd a c2p table which is finally used for the conversion.
Don't be afraid I'll give you some more detail...first of all let's talk about the chunky buffer:
to get the conversion anywhere near reasonable quick we need to double the pixels horizontally and vertically, what means that one 'chunky-byte' in fact represents 2x2 pixels on the screen and it means that we'll get a virtual rez of 160x100 'chunky-pixels', of course that's why the chunky-buffer is sized 160x100 bytes = 16000 bytes (notice: the size of the chunky buffer may be variable but to keep it simple I'm talking of the fullscreen conversion).
Now some words on the c2p table and the actual conversion:
what we will do now - let's assume the first 4 bytes of the chunky buffer would have the values $03,$04,$0D,$02 (these 4 values represent 4 chunky-pixels or 4 double pixels on the screen).
because only the lower 4 bits of these values are used (16 colors!) we're now able to 'pack' those 4 bytes into one word the following way:
lea chunkybuffer,A0 * A0 now points to the chunky buffer
moveq #0,D0 * clear D0.l
move.w (A0)+,D0 * D0 = $0304 - 1st 2 values out of the chunky buffer
lsl.w #4,D0 * D0 = $3040 - shift them up one nybble
or.w (A0)+,D0 * D0 = $3D42 - that's the four 1st values in one wordBut stop, values 2 and 3 have been swapped somehow, wouldn't it be more simple if D0 would contain $34D2 like in the chunkybuffer??
That brings us to the next element of the c2p conv. - the c2p table (which is, apart from the low resolution of c2p graphics, a further disadvantage against the planar-graphics. ie. the high memory consumption!)
The chunk 2 planar table holds all the possible bitplane-combinations of 4 double-pixels on the screen. And since every one of those pixels can have 16 colors it's 16 * 16 * 16 * 16 * 4 bytes = 256 kb huge! (* 4 because we get longwords out of it).
But when we precalc this c2p-tbl we need to remember that pixels 2 and 3 of that 4 pixel 'quad' are swapped - because now we gonna use the value of D0 as offset:
lsl.l #2,D0 * get the longword alingment
lea c2p,A1 * set up the address of the c2p tbl
move.l screen,A2 * A2 points to our screen
move.l 0(A1,D0.l),D0 * move the needed value into D0
movep.l D0,0(A2) * set the first 4 doublepixels on the screen
movep.l D0,160(A2) * do the scanline belowWow, this little program-block has set 4 double pixles on the screen! It's also managed to skip the lower bytes of the bitplane words using the movep instruction, meaning that the other byte of the bitplane word won't be affected.
What you'll do now is getting the next for double-pixels and converting them to the next screenoffset and so on. But notice that you have to skip one scanline when you've done 160 double-pixels because the pixels are also doubled vertically. So, that's all. Did you get it? I hope so...
And now I think it's at the time to say a few words about the demo:
what it does is
1. setting up a pattern in the chunkybuffer
CHUNKYBUFFER: REPT 1000 * 16000 bytes
DC.L $00010203
DC.L $04050607
DC.L $08090A0B
DC.L $0C0D0E0F
ENDR2. doing the c2p conversion
(do this 100 times - one for each 2 scanlines)
move.w #20-1,D7 * convert one scanline
SETPIXEL: * = 20 * 8 doublepixels
moveq #0,D0
move.w (A0)+,D0
lsl.w #4,D0
or.w (A0)+,D0
lsl.l #2,D0
move.l 0(A1,D0.l),D0
movep.l D0,0(A2)
movep.l D0,160(A2)
moveq #0,D0
move.w (A0)+,D0
lsl.w #4,D0
or.w (A0)+,D0
lsl.l #2,D0
move.l 0(A1,D0.l),D0
movep.l D0,1(A2)
movep.l D0,161(A2)
addq.w #8,A2
bra D7,SETPIXEL
.
.
.3. scrolling the chunkybuffer
lea CHUNKYBUFFER,A3
lea CHUNKYBUFFER,A4
addq.l #1,A4
move.w #16000-1,D4
SCROLLLOOP: move.b (A4)+,(A3)+
dbra D4,SCROLLLOOP4. repeat step 2 until space is pressed
The whole thing runs at about 8.5 fps on a plain ST - which is as I think quite fast for a fullscreen fine-scroller (imagine how you would code this with planar graphics X(. but keep in mind this demo is very basic and not optimized, 'cause I wanted to keep it simple.
Last remarks
Some words on optimizing....one way to optimize this algo a little bit is to preshift every color up 2 bits (I mean your texture or image colors or whatever) before you store them in the chunky buffer. That saves the lsl.l #2,D0 when calculating the offset in the c2p-tbl.
There are even ways to let the chunky-buffer fall away completely. But believe me, it shouldn't be that hard to figure it out yourself and by the way it could be a real good practice for you.
Ok, I'll give you a little hint. Just write a rout that directly sets a 4 double pixel 'quad' not getting the data out of a chunky buffer...
Another way of speeding it up will be to just resize the chunky buffer when your effect will not take up the whole screen. Just keep coding, you'll get it ;)
What's for next time? Hmm... I'm thinking of doing something on raycasting, at least on the basics, so keep looking for my tuts, he he...
hope to see you next time,
.tSCc. Ray
