pouët.net

The Amiga video memory is organized in bitplanes, basically the same model that 4bit EGA/VGA modes use (except it's 5 bitplanes for OCS/ECS and 8 for AGA).

What does it mean? It means that a video memory byte doesn't contain the direct color value for a pixel (like in mode13h for example), but each byte contains 1 bit of the color value for a group of 8 pixels. That is, if you want to fill your background with color 19 (binary 10011), the byte values for bitplanes 0, 1 and 4 have to be FF hex (all one bits) while the byte values for planes 2 and 3 have to be all zeroes.

What does it mean for effect coding? Well, every effect that can use this concept in some way will of course benefit from it. For example, the "motion blur" like effect in State of the Art is achieved by drawing the vector shape for the current frame not in all 5 planes, but only in 1.
(On Frame 0 in plane 0, on frame 1 in plane 1, ... and on frame 5 again in plane 0). When setting up the palette in an appropriate way, you get the motion blur at about no cost at all. (The Amiga has the Blitter too, which can be used to draw polygons quite easily; i'll not go into detail here).

So ok, this is all fine for things like the beforehand mentioned "motion blur" and dot stuff etc., but gets a pain in the ass for everything that has to do with bitmap manipulation. You can fake quite some things by tweaking with the hardware registers (horizontal scaling for example; Chaos/Sanity vastly exploitet that one for his "Optimum Fuckup" effect. You can see a similar approach in Desert Dream by Kefrens for the X-axis rotating logo).
Other effects like Chaos' famous first rotozoomer in World of Commdore can be accomplished by doing "only" a 1bit rotozoom and using the motion blur technique I explained above - but about anything more advanced than that is pretty hard to do without C2P (chunky to planar).
Without going into details here, C2P rearranges bytes from a "framebuffer array" in a way that each byte value gets decomposed into 7 bits and written into the correct bitplane.

Ofcourse this is quite CPU-intensive, and even though there've been quite some techniques developed (some involving the blitter for help etc) to do it fast, it still requires a huge amount of processor time, making it for all pratical means next to impossible to do a fullscreen effect
that uses C2P even on the fastest m68k-based Amigas (has to do with chipram write speed, mostly).

But well, this posting is already MUCH too long, and I never really coded on Amiga so I can't tell you the whys and hows of everything exactly (I read a bit about it, but only out of curiosity :), but still, I think that should be enough of a introduction to understand the basic problems of current amiga demos :)

Thanks for the info.. but does that explain why Lapsuus looks blurred? Not so sure now..

interesting. didn't know that although i was sitting in front of an amiga as early as 1987. but then again, i'm not a coder, so i don't understand any of that technical crap ;)

yes, very interesting indeed. thanx ryg, it was fun reading and nice to know =) just wondering, is this how vga mode12h on the pc is arranged as well?

I've been fighting with banked framebuffers in dos/vesa back a few years ago.. and I thought banked framebuffer was hell compared to linear, but planar seems even worse =)

The reason that Lapsuus looks blurred could be that they use a faked truecolor mode using HAM8? I don't really know, I've not seen it running on an Amiga yet, only the divx/mpeg

Note that PowerPC can also speed-up the c2p, but write into
the chipmem is still very slowwwwwww. It's also the problem of current amiga demos.

damn!

I'm quite surprised to see that some sceners don't know how the good old computers works ( I maybe getting old, I started in 1989 )

just for information, the Ataris work exactly the same way, but with only 4bitplanes for STf/STe and up to 8bitplanes for Falcon (which also features "near true colors" mode (16bits per pixel ))

btw "near true color" is one of the reason that made me buy a Falcon instead of moving to A1200 at the time :)

these more user-friendly modes allow to do really neat things ways faster and easier than when having to use a C2P

I think lapsuus looks blurred, because the original image is 160x100, to gain speed, than extended with the c2p, and uses some blur effects to look less pixelated...

obviously C2P is most of the time done from a lower resolution and then extended to the display resolution

doing an extended BLURRED C2P would be even more CPU intensive than rendering the whole scene at the correct size and then using a 1x1 C2P

my idea on why lapsuus looks so blury is that it's renderered in an even lower resolution ( maybe a 4th of the display res ) to speed up the blurs that are applied to the scenes in chunky mode, and then extended via 2x2 C2P

but I've only seen the DIVX version, so I may be wrong and I don't know the original display res.

On PCs in 4bit modes, bitplanes work about the same as on amiga, except that all 4 bitplanes are mapped to the same physical location in address space and you have to select which one you want to write to (you can write to multiple at a time too, ofcourse) by using the timing sequencer of your gfx card :)

Loonies Mekka 2001 demo "Hotstyle Takeover" runs at 50fps on 060 and has c2p-effects.However, it doesn't really look cool in divx :)

the blur in lapsuus is a normal blur, not some planar effect.

cd32 (an old commodore console) had an extension called AKIKO what allowed native chunky.

my computer is too slow to capture 50fps :)

" requires a huge amount of processor time, making it for all pratical means next to impossible to do a fullscreen effect that uses C2P even on the fastest m68k-based Amigas "

- i can't agree on this...i've seen a lot of fullscreen demos, even for 030, and the reason why 18bit demos arent 1x1 pixel is that the chipram is very limited :)
and blitter is damn slow, so noone uses it neither for poligons, nor for c2p, since it would be slower that way...

so better inform before telling wrong things.

Sorry, you apparently seem to be an (ex-?) Amiga Scener, so why didn't you simply explain it in the 1st place (when people kept asking what it is on the onliner) instead of keeping nitpicking now? I just don't get it.

well, i haven't seen when ppl asked for it in the onliner.sorry.
and since i'm not a coder, i couldn't really tell 100% correctly the basics of it, so i rather don't try.

http://members.nbci.com/amiga/c2ptut.html - some info here, where it's really good explained (maybe too amiga-coderish :))

Well guys, it looks like standard ham8 blur!!
Of coz the screen is 160x100, btw if the height can be increased, the witdh is fixed to 160 : this is the ham8 trick, a "visible" pixel is encoded on 4 chip pixels.
Doin' 2x2 c2p ?? in so low resolution?? The engine is fast enough to blur+renderscene fullscreen at each frame !! Moreover, i haven't seen any ham8 c2p routine usin' blitter, and ham8 means 24 bits (8*3), ham6 18 bits (6*3), but alot of ppl use, and i think this great demo do, rrrrrrr0ggggggg0bbbbbb0 to do the blur, it means 7*3 = 21 bits

hmm, If you watch Lapsuus in winuae the picture doesn't look so blurred, on the amiga it probably loses some sharpness because of the ham8 mode. I think the scene is rendered at 160x100, blurred, motion blur and then converted to ham8 with c2p.

tolkien: isn't ham8 18bit (262144 colors(or something)) and ham6 12bit (4096 colors)??

yop ur true! :)
Ham8 means 8 bits per component, but 2 bits r used for control (so 6 real bits used, ie 6+6+6=18). Btw to keep accuracy, alot of c2p convert 24->18 bits, so the effect (+blurs,etc..) won't less some color information :)
Thx for noticin' it

I don't know.

teo_exd:

Well, Akiko was a chip with integrated chunky-to-planar-converter. But as far as I remember it wasn't really used that much because some people figured out some trick to do the c2p-conversion faster with the CD32-CPU (68020) than with the Akiko-chip.

the point in HAM8 c2p looking blurry is:
HAM stands for "hold and modify". with 8 bits you can use 2 bits to state which color component to change (r,g,b) and the lower 6 bits give the actual value or some delta (cant remember...). you can use this to show non-palettized graphics but true-color-18bits ones.
this means per rgb value you need 3 screen pixels to set it and things get blurry because you can not set the components at once. this means for 320 pixel in x-axis you effectively get 100-something true-color pixels.
you can change to hires, getting around 200 pixels. however if you do so with a too big screen width (or at super-hires) the video hardware steals clocks cycles to access chip ram from the cpu, which means you make c2p-conversion much slower.

i hope this wasnt too confusing now...

hm... so this is how the BBS used to work in 2001. Volunteers would just start to explain things out of the blue.

and the issue of lapsuus being "less blurry" under winuae is probably just because it's running faster and thus making the motionblur less visible (i.e. less movement per frame).

Stelthz: yepps.. pretty much like when a mentally ill homeless guy stops you on the street to explain why all hats need aluminum foil linings..

It has come a long way.