| |
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....
|
| |
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: 5018 |
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. |
| Previous - 1 | 2 | 3 - Next |
