English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 22 January 2006, 21:40   #1
Alter
Oldskool
 
Join Date: Dec 2005
Location: Norway
Age: 46
Posts: 28
Chunky to planar on a500

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......
Alter is offline  
Old 22 January 2006, 21:54   #2
ant512
Registered User
 
Join Date: Dec 2002
Location: California
Posts: 943
Gloom did C2P in ECS.
ant512 is offline  
Old 22 January 2006, 22:08   #3
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 37
Posts: 2,297
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...
musashi5150 is offline  
Old 22 January 2006, 23:01   #4
Alter
Oldskool
 
Join Date: Dec 2005
Location: Norway
Age: 46
Posts: 28
Hmmmmm, thanx for your replys. So there is no point using c2p on a500 then as long as its not accelerated then ?
Alter is offline  
Old 22 January 2006, 23:21   #5
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 37
Posts: 2,297
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.
musashi5150 is offline  
Old 22 January 2006, 23:34   #6
Alter
Oldskool
 
Join Date: Dec 2005
Location: Norway
Age: 46
Posts: 28
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 ??
Alter is offline  
Old 23 January 2006, 11:17   #7
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 37
Posts: 2,297
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

Last edited by musashi5150; 23 January 2006 at 11:24.
musashi5150 is offline  
Old 23 January 2006, 16:29   #8
Alter
Oldskool
 
Join Date: Dec 2005
Location: Norway
Age: 46
Posts: 28
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 :-)
Alter is offline  
Old 23 January 2006, 22:20   #9
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 37
Posts: 2,297
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 is offline  
Old 23 January 2006, 22:44   #10
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 37
Posts: 2,297
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

Last edited by musashi5150; 23 January 2006 at 22:52.
musashi5150 is offline  
Old 23 January 2006, 23:36   #11
Alter
Oldskool
 
Join Date: Dec 2005
Location: Norway
Age: 46
Posts: 28
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 :-)

Last edited by Alter; 24 January 2006 at 00:18.
Alter is offline  
Old 24 January 2006, 02:11   #12
Mad-Matt
Longplayer

Mad-Matt's Avatar
 
Join Date: Jan 2005
Location: Lincoln / UK
Age: 39
Posts: 1,592
Send a message via ICQ to Mad-Matt Send a message via MSN to 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.

Last edited by Mad-Matt; 24 January 2006 at 13:34.
Mad-Matt is offline  
Old 24 January 2006, 10:46   #13
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 37
Posts: 2,297
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 is offline  
Old 24 January 2006, 21:59   #14
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 37
Posts: 2,297
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
musashi5150 is offline  
Old 24 January 2006, 23:33   #15
Alter
Oldskool
 
Join Date: Dec 2005
Location: Norway
Age: 46
Posts: 28
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.. :-)
Alter is offline  
Old 25 January 2006, 20:43   #16
Frog
Junior Member

Frog's Avatar
 
Join Date: Aug 2001
Location: France
Posts: 1,273
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
Frog is offline  
Old 26 January 2006, 11:00   #17
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 37
Posts: 2,297
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.
musashi5150 is offline  
Old 24 February 2006, 16:03   #18
Kalms
 
Posts: n/a
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:

Code:
  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:

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

Last edited by Kalms; 27 February 2006 at 23:38.
 
Old 24 February 2006, 19:41   #19
Frog
Junior Member

Frog's Avatar
 
Join Date: Aug 2001
Location: France
Posts: 1,273
Welcome Kalms.

Nice to have a new master of coding here.

Any good Atari ST demo'name with such effects ?

Last edited by Frog; 03 March 2006 at 21:26.
Frog is offline  
Old 24 February 2006, 21:45   #20
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 37
Posts: 2,297
Yes, welcome aboard Kalms! You can never have too many uber-coders on a board
musashi5150 is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Optimised Akiko Chunky-to-Planar emulation Mequa support.WinUAE 9 05 February 2012 03:47
Akiko Chunky-to-Planar conversion Mequa support.WinUAE 5 21 January 2012 11:50
Chunky looking Graphics. Washac support.Hardware 8 09 February 2010 18:52
Amiga Bitplanes & Planar vs Chunky - Technical Expert Required CodyJarrett project.APoV 4 12 November 2009 12:14
Chunky to planar pmc Coders. Tutorials 11 15 September 2009 17:20

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 21:43.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08916 seconds with 13 queries