| |
peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
Identify this doughnut
I was looking this page:
http://www.airport1.de/fs.php?/c64.htm
In the "c64 artwork" I can reckon nearly all images from known c64 demos. However, in the third image, there is a textured doughnut I can't identify.
Anybody knows this demo? |
|
... 17 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Interesting, i didn't know of any c64 effect using c2p before... how lame :D
"someone" has to code a better multicolour texture mapper ;) |
| |
peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
If I remenber correctly Fuben from Oxyron made something similar in a texture mapped cubed effect. Don't remenber the demo though. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Fuben, so most likely that was 4x4 mode? Though i cannot think of any routine were c2p would make sense when in the final hw-displayable bitmap you have 2 4-bit pixels per byte. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@Krill: If you wanna know about real C2P then look into the tunnel effect in the hidden part in Deus Ex Machina. The core problem of an Amiga C2P routine is rotating the bits of a square of pixels by 90 degrees. This problem is also solved there although it is not used as C2P :) It's simply used to rotate a quarter of the tunnel by 90 degrees...
An Amiga example might explain this:
8 bpp chunky is like this:
a0a1a2a3a4a5a6a7 (byte 0 of chunky buffer)
b0b1b2b3b4b5b6b7 (byte 1 of chunky buffer)
c0c1c2c3c4c5c6c7 (byte 2 of chunky buffer)
d0d1d2d3d4d5d6d7 (byte 3 of chunky buffer)
e0e1e2e3e4e5e6e7 (byte 4 of chunky buffer)
f0f1f2f3f4f5f6f7 (byte 5 of chunky buffer)
g0g1g2g3g4g5g6g7 (byte 6 of chunky buffer)
h0h1h2h3h4h5h6h7 (byte 7 of chunky buffer)
8 bpp Amiga bitplanes is like this:
a0b0c0d0e0f0g0h0 (bitplane 0)
a1b1c1d1e1f1g1h1 (bitplane 1)
a2b2c2d2e2f2g2h2 (bitplane 2)
a3b3c3d3e3f3g3h3 (bitplane 3)
a4b4c4d4e4f4g4h4 (bitplane 4)
a5b5c5d5e5f5g5h5 (bitplane 5)
a6b6c6d6e6f6g6h6 (bitplane 6)
a7b7c7d7e7f7g7h7 (bitplane 7)
So basically you only need to rotate the bits in that square by 90 degrees to do a chunky 2 planar or planar 2 chunky conversion. And this is not done in the Samar demo, so it cannot be some kind of C2P :)
It is not required that you do this with 8bpp. It works alike with 4 bpp or 2 bpp. |
| |
algorithm
Registered: May 2002
Posts: 705 |
There are so many different variations. One example was in one of my Amiga demo's 'Spice' where the chunky data simply pointed to a lookup table with precalculated planar pre-interpolated data. So easy and no eor/bit opcodes etc.
|
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Graham: I was not talking of Amiga C2P, and I was not using the C2P term in its narrow literal sense. I was just referring to peskanov's definition of the term, meaning rendering to an offscreen bitmap in whatever format and then converting it to a hardware-displayable format after the whole rendering process.
Anyways, thanks for pointing me to a C64 4x4 effect where C2P is making some sense. |
| |
peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
I found the demo made by Fuben, it was "Relightening/Oxyron". He used a chunky buffer in the latest effect, the texture mapped cube. Beware, it's very very slow. Uses multicolor resolution, 2x1.
BTW, speaking in general terms the c2p operation is a matrix transpose, not a 90o degree rotation. The difference being that the 1st and last elements of the matrix don't change positions.
It could be said c2p is a flip over the diagonal axis.
However most amiga c2p don't perform a full transpose. Some finish the work in a format quite similar to the c64 mc mode, for example the famous Azure c2p used in his first Artwork demos. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Huh? Ofcourse Amiga C2Ps do a full tranpose, else they wouldn't convert C2P :D I coded a number of C2P myself, multi-pass ones for 68030 which involve the blitter, single pass ones for 68060 or even lookup table ones. And Azure used similar C2P routines, have met him often at the old Scala meetings and even contributed to a demo of him (Exit Planet Dust).
Also there is no real difference between transpose or 90 degree rotation since you can "turn transpose into rotation" by simply changing the bitplane numbers (which doesnt change anything at all...) :) |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
to go back to c64 codings, texture mapping directly into the MC bitmap is probably more pain in the ass. But doing so probably doesnt result in a noticable speed result. if your effect spends anyway 37 frames calculating the next phase +- 2-3 frames doesnt count. |
| |
peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
Ok Graham, but you need to flip one axis to convert a transpose to a 90o rotation or viceversa. I know it's a question of simply writing in the apropiate order the bitplanes, I was just pointing that c2p was transpose, not rotation. They have different name for a reason.
Still some c2p routines did not fully transpose the bits. You will remenber the one used by Azure wich disposed the bits in pairs an then used a double resolution screen (640 to obtain 320 resolution) for example.
When I coded c2p routines for HAM modes I grouped the bits in packs of 4, rgbb, one pack for each bitplane. That way I had a functional chunky buffer wich only needed 3 c2p steps (16/8/4).
BTW, nice work in Exit planet dust. You released that demo at the time I was more active, I remenber it quite well.
Oswald, if the coder has already decided he is going to make a real slow effect (< 8 FPS), then using a chunky buffer is a good option.
But I would say that when writting a texture mapper for MC mode, one can try to reach ~20 cycles/pixel, and therefore is interesting to open the posibility of doing a fast effect also. If you choose the chunky buffer way, then you are closing all the posibilities from the start.
Still, I insist I am not criticising the code; I don't like it too much, but I know there is hard work there.
|
| Previous - 1 | 2 | 3 - Next |
