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