Chunky to planar on a500

[Alter]

Im wondering about c2p and how to do it on a a500 with only 5 bitplanes. I read some stuff on the net and I understand the concept behind c2p. Im wondering though if it can only be done with AGA chipset since it has 8 bitplanes and thus 256 colors. As c2p uses chunks of i byte and 1 byte has a value of 256 im wondering if this will be a problem to develop a c2p routine on the ECS chipset with the limitation of only 5 bitplanes? Please someone enlighten me......

[ant512]

Gloom did C2P in ECS.

[musashi5150]

As you said - A500 will only use 5 planes/32 colours. You can think of this as 5 BITS of colour, or the decimal values 0-31.

You can use a standard byte chunky screen on A500 with no probs - but only plot pixels using values 0-31 instead of 0-255. Then when doing C2P you don't need to bother with data for planes 6,7,8.

But this is going to be very slow indeed unless you have an accelerated A500...

[Alter]

Hmmmmm, thanx for your replys. So there is no point using c2p on a500 then as long as its not accelerated then ?

[musashi5150]

Depends - if you want fast results or if you are looking for techy fun

But I'd say a plain 68000 probably wouldn't be up to the job, no.

BUT...

You could use a copper-based chunky screen. This IS possible on A500 and looks cool. For examples you should check out the Rotozoomers in part 2 of 'Desert Dream' by Kefrens and 'Rampage' by TEK.

[Alter]

Yes Ive seen that rotozoom effect, do you have any tut or something to give me some pointers on a copperbased c2p ? By the way I read something about the movep instruction which can take a word/longword and the output would be in bytes. This was done on the atari, or is it possible maybe to use the blitter ??

[musashi5150]

No, tut.... but the basic idea is pretty easy. The 68K doesn't directly write to the colour registers - the copper renders the entire display from it's copperlist and no bitplanes are used (although you can mix the effect with planes to get a higher res, but this is more advanced)

How it works: If the copper continually writes to a colour register with no waits then the copper will 'paint' along a rasterline. By doing this for many rasters you can build up an image

I'll assume you can write a normal copperlist on your own. The copper list would then look something like this (pseudocode, with the xxxx being COLOURS)

Wait for raster position
move xxxx,$0180
move xxxx,$0180
move xxxx,$0180
move xxxx,$0180
.....
Wait for next raster line
move xxxx,$0180
move xxxx,$0180
move xxxx,$0180
etc.....

Now you have 2 choices:

1) You can write your graphics directly into the copperlist (hard)
2) Or make a word-chunky buffer and then write code (like c2p) to convert from your chunkybuffer to the copperlist.

If you choose option 2 and keep your buffer in chipmem you can use the Blitter to accelerate the conversion a lot

To start with get it working on 1 rasterline, writing the copperlist by hand. Once you have nailed that you can then move onto a fullscreen effect and write code to generate the copperlist for you at runtime....

If you want more help to get started let me know and I'll write you a simple copper list showing a few rasterlines one evening after work

[Alter]

Yesss thanx alot, Ofcourse by writing the colors with no wait each color will be displayed on one rasterline in one byte chunks . So on a normal screen one raster line will consist of 40 chunks/colors of one byte each ? Am i right ? I would appreciate it very much if you would give me some more pointers on the option 2 , how to use the blitter in this case. :-) Is this the way to make plasma also but instead of just using the background color alone you mix it with bitplanes to make it a 1 pixel plasma ? I am a oldskool coder ( very old 1987-88) and I just try to refresh my coding skills and have some fun. I however never made any plasma effect and certainly not any rotozzom effect though, I quit coding long berfore that.. Thanx alot for your help... I really enjoy coding again and when i see all these "new" demos and what they can do I must try to code it also..... thanx again :-)

[musashi5150]

Yep, 40 is about right - but you can get a couple more by using 'overscan' and writing colours at the sides of the screen (not just where bitplanes would be)

Now onto the Blitter

We have our (for example) 40x256 WORD buffer in chipmem... and we want to copy this into our offscreen copperlist (using 2 for double buffering of course - or even 3 if your routine sometimes flops over 1 frame).

You remember the copperlist from above:

Wait for raster
move xxxx,$0180 **
move xxxx,$0180
move xxxx,$0180
....
Wait for raster
move xxxx,$0180 **
move xxxx,$0180
move xxxx,$0180
.....

Well, if we were trying to render the screen in the 'normal' way (render along each raster) the Blitter cannot help us? Why? Because after each 'pixel' in our copperlist we have a COLOR REG ($0180) in the way

But all is not lost

Just use the Blitter to render the display in vertical strips. This way the MODULO can be used to skip 1 whole raster line to the SAME X pixel on the NEXT line. (I have marked the values with ** to help show the example). Using this method the rendering can be done MUCH faster than using CPU only

I hope this helps you out to have some more fun on your Amiga

Btw, what kind of Amiga setup do you have? I did a small intro for #amigascne competition once - it uses copper ONLY and no bitplanes and shows a few lame effects But it kinda sucks on <68030.... but I'll upload it for you if you'd like to see

[musashi5150]

It's probably not what you meant by "plasma" but I've whipped up a very basic plasma type effect and upped it to The Zone for you. I've included an ADF and the executable file.

It's kinda like the cracktro for PP Hammer by N.O.M.A.D./Crystal

I enjoyed coding this effect and it only uses around 50% of the rastertime on A500

[Alter]

Again thanx ALOT , I bought an old a500 with 1mb chipmem and I use Asmone as my assembler, before I used Seka v3.2 by PROMAX which i was quiet happy with at that time. Usually I code on my Laptop now using UAE, not the same but its alot more comfortable :-) I test my source though on my a500. I feel that things dosent run very smoothly on UAE, scrolltext dosent scroll perfectly and so on , but when I test it on my a500 its OK. I will check out your plasma routine now........:-) and by the way I would very much like to see your intro :-)

[Mad-Matt]

There was a game called Citadel which im sure used c2p that even worked on a basic 68000 machine. Slow, but it worked.

Additional: and maybe perhaps Deathmask, which wasnt a bad game when it came out.

[musashi5150]

I remember being impressed by Citadel at the time, maybe I should dig it out again

I'll assembly up my intro when I get home again

[musashi5150]

My intros in The Zone for you This was my entry to the #amigascne 'fast intro' comp back in 2003. You had about 4 days to code something to enter... and this intro took less than 2 It came #2 to 'Enter the DotMatrix' by Xeron - which is much better...

It is made for 030+ and doesn't use any Blitter acceleration or other opts It does work on ANY amiga though...

I agree with you that there is no substitute for running code on a REAL Amiga! Although UAE is getting better all the time, and I often use it as an Amiga replacement for doing some cracking or gaming while at work

I've always been a DevPac3 man myself - never used anything else except AsmOne occasionally. I hope I've helped you a little with your copper coding... and if there's anything else I can help with - just ask

[Alter]

Impressive intro, I really like it !! Yes I must say that you already helped me alot. I forgotten that little trick with the copper and the colors but suddenley now I remember it when you told me. I didnt imagine though that you could actually do a kind of c2p effect with it. I remember now that the only thing I used that trick for was a poor cycling effect on the top and bottom border :-) I see many possibilities now and now Im just going around thinking about ways to do stuff. I cant get any piece....Thanx , I appreciate your help and I will take you up on that offer and ask you if I feel to stuck.. :-)

[Frog]

there's a really really nice A500 demo done by Da Jormas and the source code is include. check http://ada.untergrund.net/showdemo.php?demoid=394

[musashi5150]

Yes, I like this one

I also like 'Coppershock' by Amonia as it's a nice copper-type demo - even though it's very old.

In Major Release, the bitmap distorter (between screenshot 5 & 6), the colourful swirl (screenshot 6) and the eye-ball (somewhere near the end) are all rendered in a pseudochunky mode with 3 or 4 bitplanes. Textures are scrambled a bit (that does half of the 'c2p' work and the horizontal pixel doubling), and then the final bit mangling is performed using the blitter.

Here's one way of performing it for 4 bitplanes output...

First, the texture is scrambled: a pixel whose value normally would be stored in one byte as %0000abcd is expanded to one word in the format %00aa00bb00cc00dd. The bits are repeated for horizontal 2x resolution, and spread out to make the rest of the conversion into planar format easier.

Make another version of your texture where the pixel's bits are shifted up two steps (aka %aa00bb00cc00dd00).
Now you can collect two pixels together using the following sequence:

  move.w offset1(a0),d0    ; fetch pixel 1
  or.w   offset2(a1),d0    ; fetch pixel 2
  move.w d0,(a2)+          ; store pixel-pair to memory

If you are going to do a table-based tunnel, then the 'offset1' and 'offset2' values would be coming from the tunnel-table itself.

Once you have rendered an entire screen in this fashion, you have data for 4 bitplanes in an interleaved format: in each word, there is one 4-bit block with bitplane data for each of bitplanes 3 through 0. Let the blitter collect the 4-bit blocks into 8-bit blocks in one pass, and then the 8-bit blocks into 16-bit blocks in a 2nd pass. The output of the 2nd pass is the one which actually writes final bitplane data to display memory.

You might get better performance if you let the blitter process the previous frame's pixels while the CPU is generating pixels for the current frame.

You choose yourself the tradeoff between CPU and blitter work. Perhaps it is more efficient in your case to write out bytes instead of words? (That would probably require you to do one extra blitter pass, so it is probably a downtrade.) Perhaps scrambling the contents of the texture in another manner will allow you to drop one of the blitter passes? Perhaps a solution involving MOVEP to interleave pixel-data on byte level in memory will allow you to drop one of the blitter passes?

... the latter could actually work quite well. Consider the following fragment:

  move.w  offset1(a0),d0   ; fetch pixel1, %aa00bb00cc00dd00
  or.w    offset2(a1),d0   ; fetch pixel2, %00ee00ff00gg00hh
  movep.w d0,0(a2)         ; store         %aaeebbffccggddhh
  move.w  offset3(a0),d0   ; fetch pixel3, %ii00jj00kk00ll00
  or.w    offset4(a1),d0   ; fetch pixel4, %00mm00nn00oo00pp
  movep.w d0,4(a2)         ; store         %iimmjjnnkkoollpp

  move.w  offset5(a0),d0   ; fetch pixel5, %qq00rr00ss00tt00
  or.w    offset6(a1),d0   ; fetch pixel6, %00uu00vv00ww00xx
  movep.w d0,1(a2)         ; store         %qquurrvvsswwttxx
  move.w  offset7(a0),d0   ; fetch pixel7, %yy00zz00AA00BB00
  or.w    offset8(a1),d0   ; fetch pixel8, %00CC00DD00EE00FF
  movep.w d0,5(a2)         ; store         %yyCCzzDDAAEEBBFF

now the four words at (a2) will contain the following data:
aaeebbff qquurrvv
ccggddhh sswwttxx
iimmjjnn yyCCzzDD
kkoollpp AAEEBBFF

Notice where the data is supposed to go? bitplane number...
33332222 33332222
11110000 11110000
33332222 33332222
11110000 11110000

and if you merge together all the bits for bitplane #3 by taking line #3, masking it against $f0f0, shifting it right by 4 bits, and then inserting those bits into line #1, then you have a full word's worth of bitplane data.

The byte shuffling done by the MOVEP allows you to get rid of the 8-bit blitter pass, so now you only need to do the 4-bit blitter pass:
* Point BLTAPT to (a2)
* Point BLTBPT to 4(a2)
* Set BLTAMOD and BLTBMOD to 6
* Set BLTDMOD to 0
* Set BLTCDAT to $f0f0
* Use the blitter operation D = A*C + ((B >> 4)* NOT C), ascending
* Activate blitter DMA for channels ABD
* Perform a blit with width = 1, height = <number of words to output>

The output should be a coherent bitplane #3. Bitplane #1 is retrieved in
a similar fashion (just set BLTAPT and BLTBPT 2 bytes ahead), while bitplanes #0 and #2 are extracted through a descending blit (start at end of buffer, invert BLTCDAT, set descending operation).

This is off the top of my head, so there may be some mistakes in the above excursion. If you need code for some blitter-based solution, check the Major Release source code, it seems to be fairly clean and well documented.

(And, regarding performance: On the Atari ST (where the interleaved bitplanes allow you to trade the 4bit blitter pass for a table lookup) people are doing table-based tunnels in roughly 160x100 chunky resoloution, 4 bitplanes, at roughly 25fps. So the method is not to be disregarded altogether.)

[Frog]

Welcome Kalms.

Nice to have a new master of coding here.

Any good Atari ST demo'name with such effects ?

[musashi5150]

Yes, welcome aboard Kalms! You can never have too many uber-coders on a board