| |
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? |
|
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
some samar demo, cant recall the name now |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote: some samar demo, cant recall the name now
Yep, it's Air Power
---
-= Silicon Ltd. =-
http://forum.siliconlimited.com
Commodore 64 Scenemusic Podcast
http://8bitmayhem.blogspot.com/ |
| |
peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
That's right, I missed that demo from Samar. Thanks.
The effect is too slow for my taste anyway, what a pity. |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
too slow, bah, codewise its 20 out of 10. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Still, what's the point in doing an effect if you can only make it run at 1-2 fps? Some very advanced code, yes, but I don't think it looks particularly good... Except in screenshots. :-) |
| |
Slator
Registered: Jan 2002
Posts: 273 |
You all better try to share a session of hollowmans samar demo show at some swedish party ;-D
flawless victory.... |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote: Still, what's the point in doing an effect if you can only make it run at 1-2 fps? Some very advanced code, yes, but I don't think it looks particularly good... Except in screenshots. :-)
In screenshots *and* in the emulator using Alt-W :D
---
-= Silicon Ltd. =-
http://forum.siliconlimited.com
Commodore 64 Scenemusic Podcast
http://8bitmayhem.blogspot.com/ |
| |
peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
Well Oswald, if you say the code is something special I guess I have to take a peek.
I found this in the doughnut effect, is this a chunky to planar routine?
,16AA: BE 00 98 LDX 9800,Y
,16AD: BD 00 0C LDA 0C00,X
,16B0: BE 80 98 LDX 9880,Y
,16B3: 5D 00 09 EOR 0900,X
,16B6: BE 00 99 LDX 9900,Y
,16B9: 5D 00 0E EOR 0E00,X
,16BC: BE 80 99 LDX 9980,Y
,16BF: 5D 00 0B EOR 0B00,X
,16C2: 91 58 STA (58),Y
I have never seen one on c64, although I programmed plenty of them when I coded Amiga demos.
I am not sure using this kind of code is useful on a c64. On Amiga we used it mostly because:
a) Coding directly for planar was difficult.
b) Redrawing was faster. Graphic memory was sooo slow, it was better to have a chunky buffer on FAST RAM. If you had to draw graphics several times over the same area if was far better to do so on FAST RAM.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
It's a simple bit depth conversion. You cannot call it a C2P routine since the C64 doesn't have bitplanes. On C64 pixels are either 1 bit, 2 bit chunky, 4 bit chunky or 8 bit chunky. |
| |
peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
Point taken, but that's a question of naming. If I understood correctly the code, the source of data in this conversion is a chunky buffer: 1 pixel -> 1 byte. And the result data is the native c64 multicolor format, 2 bits for each pixel, which is nearly planar.
Naming questions aside, the routine seems to be throwing around 60.000 cycles just doing the screen conversion. The code is neat, but it seems a bad choose to me. Direct draw to screen seems to be a better option here. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
It's not planar, it's chunky. The 2 bits are directly next to each other as a "chunk".
The direct drawing could be an option, but it wastes many cycles for the edges. Propably more than you lose by simply doing an 8 bit -> 2 bit conversion. |
| |
peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
I don't think I agree with your naming convention.
Bitplane and byteplane (like in the old RGB true color systems) are clear concepts.
However, planar and chunky are a bit fuzzy. After all, a byte-plane is not planar in the bitplane sense, but still is considered a system of planes. Is an RGB byteplane system chunky or planar?
You say that the c64 sytem (01010101) is chunky, but then how an Atari ST-like system (00000000111111112222222233333333) should be called?
In this case, at byte level the cpu can access bitplanes, but at long word level it can access 8 pixels at once.
I heard the term chunky for first time in the early nineties, and in that time we used the term to speak about system were you could read and write pixels directly without modifying the neighbour ones. A pixel system like 0X1X2X3 would still be called chunky despite the bits not being serially disposed, because it can be accesed in one "chunk".
Aside of that, I am aware of the edge problem implied in direct draw. If the polygons are big enough direct draw should be better, however I am not so sure in this case. My intuition says it would work better, but I am not skilled enough in 6502 to know for sure. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
I doubt that 8 bpp is better for big polygons on C64. The time wasted on the edges is really lots of time. In my gouraud vector in oneder i spend about 95% only drawing the edges, filling the rest of the polygon nearly takes no time. After all, 6502 code is a strange world where often the inner loops take less time than supporting code. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Please stop using weird Amiga-words like "planar". Just call it what it is, in this case multicolor mode.
Btw, I agree that most effects in Air Power are only good for making cool screenshots. I think I'll take this concept one step further in my next demo and simply include some pre-generated IFLI-pics, which look like really cool effects :-) |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quote:Btw, I agree that most effects in Air Power are only good for making cool screenshots.
...and the rest aren't even good for that. :-P (Interlaced 8x8 sucks more than anything else in the world, including such diversities as terminal stomach trauma, Woody Allen flicks, Mexican beer and herpes.) |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
peskanov:
hm, well I tried to find arguments, but I realised that it indeed could have been done without that conversion table.
although it would need a lot of calculations on paper to decide which is faster.
the routine has "only" 9 cycle drawback compared to one without a c2p routine. (not counting that it also does empty pixels)
but it might cost more than that in the inner loop to texturemap directly into the multicolor mode. reaching out for 4 different textures would cost cycles.
anyway I thought that the routine has balls, coz I believed it does texturemapping directly.
|
| |
peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
Graham,
yes, I have to re-program my own brain to adapt myself to the 6502. It's a real change after so many years of 68000, PowerPC and MIPS.
BTW, your goraud routine is the one featured in One-der? I will take a peek.
Cruzer, no more planar mentions here, promised ;)
Oswald, I was not being negative towards the demo. It's simply that the effect does not fit my taste; however I find the code interesting. In fact I usually like goldhand code, I think the first real texture mapping code I saw on c64 was on a Samar demo. The question about the chunky buffer was just curiosity.
I am more interested in seeing his rasterizer code, but I have not identified it.
There is a problem more using a chunky buffer: you must also clear more memory . The size of the effect seems to be something like 64x100 pixels.
In MC mode that's only 1600 bytes, taking only 6400 cycles to clean.
In a chunky buffer we need four times more: 64x100 = 6400 bytes = 25600 cycles just to clean the chunky buffer.
1 frame to clean the buffer and 3 more for doing the conversion. That's an extreme penalty for real time effects. In Amiga I used a rule of thumb, I tried to limit my conversion routines to 1 frame. From time to time I wasted 1'5 frames, but that was the maximum. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
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: 2940 |
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: 2940 |
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: 5076 |
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.
|
