8-bit demos with environment mapping?
category: code [glöplog]
As the subject says, I know I've seen at least one C64 and one Atari 8-bit demo with an environment-mapped torus, but for the life of me I can't remember their names. Any help?
I think the Atari one may be Total Daze.
Also Numen perhaps?
The torii in Total Daze look like animations to me. Numen is most likely what I was thinking of for the XL/XE, thanks!
Anyone produced similar on the C64? Or Speccy? Or any other 8-bitters?
Anyone produced similar on the C64? Or Speccy? Or any other 8-bitters?
I sincerely don't remember any C64 demo with env mapping, though if I have seen one, it would be on some ugly demo with very slow chunky 3d that nobody cared about, and I wouldn't even have noticed it's envmap by the resolution.
Moreover, I see newschool 3d more usually on AtariXL and Spectrum than C64. But still nothing that I can easily identify. Check Refresh, on youtube link at 2:45 there is something that I think is envmap. At 2:19 there is even 3d bump map (but you can't see with that res if it's real bump mup or 2d bump effect on cube).
Moreover, I see newschool 3d more usually on AtariXL and Spectrum than C64. But still nothing that I can easily identify. Check Refresh, on youtube link at 2:45 there is something that I think is envmap. At 2:19 there is even 3d bump map (but you can't see with that res if it's real bump mup or 2d bump effect on cube).
Atari 8-bit demoscene really loved slow env mapped toruses, probably the world first was in Asskicker
C64? Try watching some Smash Designs demos.
C64? Try watching some Smash Designs demos.
Oh, and ZX, Dogma has one at 4:00.
Relightening has a phong torus which mentions env-mapping, but I dunno if it uses it.
If it does, he means using a texture of a blob of light and enviroment mapping with this texture, to fake phong.
I checked all the linked prods and didn't see any environment mapping.
Apart from that, it is of course not impossible for any platform, but what you will be actually watching would extremely likely be a quarterchar/stippleshade/"whatever-chunky" low-res animation. You can do the math yourselves.
The formula is: likely 1-2 frame per second, n seconds of animation, 1 nibble per quarterchar=2 bytes/char, roughly 1k per frame uncompressed. Compression will not near 2:1. Ubound of framerate and compression gives that if the effect runs unrepeating for "1x-2x the RAM in KB for the platform" seconds, it's not an animation.
You can also catch animations by loading time or demo filesize if onefiled.
"Animation" above is only for scenes with discernable objects. It's not necessarily true for lookup-table effects like "raycasting" or "tunnels", they only require a text/pic screen before them while calculating the table. Some calculate while emulating decrunch.
If you're an experienced coder you may be able to call what effects are real-time and not from video, else look for these cues.
If something looks like "modern 3D-rendered graphics, just in lower resolution", then you are right to be suspicious. Simply because if modern performance was scaled down to retro, the frame size would be 1/128th of a char, not half a screen or full screen.
No, not in your wildest dreams.
Some few special cases remain truly amazing.
Apart from that, it is of course not impossible for any platform, but what you will be actually watching would extremely likely be a quarterchar/stippleshade/"whatever-chunky" low-res animation. You can do the math yourselves.
The formula is: likely 1-2 frame per second, n seconds of animation, 1 nibble per quarterchar=2 bytes/char, roughly 1k per frame uncompressed. Compression will not near 2:1. Ubound of framerate and compression gives that if the effect runs unrepeating for "1x-2x the RAM in KB for the platform" seconds, it's not an animation.
You can also catch animations by loading time or demo filesize if onefiled.
"Animation" above is only for scenes with discernable objects. It's not necessarily true for lookup-table effects like "raycasting" or "tunnels", they only require a text/pic screen before them while calculating the table. Some calculate while emulating decrunch.
If you're an experienced coder you may be able to call what effects are real-time and not from video, else look for these cues.
If something looks like "modern 3D-rendered graphics, just in lower resolution", then you are right to be suspicious. Simply because if modern performance was scaled down to retro, the frame size would be 1/128th of a char, not half a screen or full screen.
No, not in your wildest dreams.
Some few special cases remain truly amazing.
If you're an experienced coder you may be able to call what effects are real-time and not *from video*, else look for these cues *playing the real thing on a real machine*.
But of course. When I say "modern" I mean 1993-5 PC era. Not debris or something.
In most examples above env-map is on a light blob (fake phong). And it's very hard to notice with low res. I short of notice it on the speccy examples though.
In most examples above env-map is on a light blob (fake phong). And it's very hard to notice with low res. I short of notice it on the speccy examples though.
I never said modern :)
Please educate a PC scener, is there a reason why there are so few of these around? After all, fake env mapping is just texture mapping with a different set of UV coords. Is the extra set of points/normals to rotate too computationally expensive, do the texture fillers rely on some special tricks that make env mapping unviable (what would they be?) or is it just that to look good, env mapping needs a bit more complicated objects and more resolution than your simple cube with 16x16 texture?
@Preacher: Keep in mind that (for a 6502) you operate on 8 bits and you have no multiply-instruction. So normal-calculations and variable UV-coords are very expensive.
Preacher: i don't see a lot of texture mappers in the first place on 8bit either.
Quote:
Please educate a PC scener, is there a reason why there are so few of these around? After all, fake env mapping is just texture mapping with a different set of UV coords. Is the extra set of points/normals to rotate too computationally expensive, do the texture fillers rely on some special tricks that make env mapping unviable (what would they be?) or is it just that to look good, env mapping needs a bit more complicated objects and more resolution than your simple cube with 16x16 texture?
Yes, good thought. I thought it would be no that hard too, even in not good framerates. Rotating lot's of points, either vertices or normals shouldn't be that hard, we have seen more than 256 3d dot rotations on C64 demos already. Texture interpolation can be optimized, but more in Z80 than 6502 I think (because of pseudo 16bit regs and 16bit adds, for 8-8 fixed point arithmetic). UV displacement is the default for classic envmap. I think it's just the last one, more curvy objects would be needed to look interesting, and the amount of preprocessing work for each triangle, also sorting/culling, makes me scared. And then, most coders don't prefer such effects, because it looks slow and ugly. And the effort maybe.
Quote:
I checked all the linked prods and didn't see any environment mapping
Apart from that, it is of course not impossible for any platform, but what you will be actually watching would extremely likely be a quarterchar/stippleshade/"whatever-chunky" low-res animation.
Bullshit.
Also, check out Reditus.
Shouldn't environment mapping be simple lookup table operation? =) Sure, there's no memory and the little there is, is slow as heck..
You mean the precalculated mapping effects, aka scroll texture over a non moving 3d surface?
"environment" mapping:
vertex.uv = vertex.rotatednormal.xy;
no tables there...
vertex.uv = vertex.rotatednormal.xy;
no tables there...
there are numerous env mapped phongs on atari and speccy. On c64 I only know of two, relightening already mentioned, and this one: http://csdb.dk/release/?id=36663
as one said its indeed easyer to do this on speccy because of the 16 bit regs. on the 6510 you need 4 8bit additions per pixel which is fuckin lot cosidering the 1-2 mhz it runs on the machines having it. And a 4 bit addition is 3-4 instruction on the 6510, you have to load the value, clear carry if needed, add to it, and store again.
To get a picture of the performance: on a c64 per pixel texture displace style effects on a 80x50 screen run at ~12-25fps only if you can do it in 2-3 instructions PER PIXEL. And you better pick the faster ones (4 cycles vs 6).
So the main speed hog is the inner loop not the 3d calculations. (at the usual case of a handful of vertex objects). One mentioned c64 can rotate 256 dots, yes it can but its cheating like hell. Dot sphere's only rotate a handful of points the rest is mirrored and scaled from these, just table lookups. Another trick is to calculate the rotation of 3 orthogonal vectors, then use the scaled versions (table lookups again!) to make rotated dots at various places out of it.
It's also a problem to get the du/dv for texture interpolation, but most demos use huge divtables to get these.
You can also do a phong/textured torus as clever table lookups, with free (!) rotation about any angle:
[url]http://csdb.dk/release/?id=3581[/url) here you have a double lookup, one for Z rotation (screen space sotospeak), and one into a 16x16 texture (in case of the tmapped torus), finally the lookup tables are animated to have the torus rotate around some other axis.
Finally env mapping a "light blob" texture has its benefits: it hides a lot of calculation errors which come from all the compromises to get it somewhat working at all. Also at such a low res with huge pixels you're not likely to have an env mapped object that looks good.
as one said its indeed easyer to do this on speccy because of the 16 bit regs. on the 6510 you need 4 8bit additions per pixel which is fuckin lot cosidering the 1-2 mhz it runs on the machines having it. And a 4 bit addition is 3-4 instruction on the 6510, you have to load the value, clear carry if needed, add to it, and store again.
To get a picture of the performance: on a c64 per pixel texture displace style effects on a 80x50 screen run at ~12-25fps only if you can do it in 2-3 instructions PER PIXEL. And you better pick the faster ones (4 cycles vs 6).
So the main speed hog is the inner loop not the 3d calculations. (at the usual case of a handful of vertex objects). One mentioned c64 can rotate 256 dots, yes it can but its cheating like hell. Dot sphere's only rotate a handful of points the rest is mirrored and scaled from these, just table lookups. Another trick is to calculate the rotation of 3 orthogonal vectors, then use the scaled versions (table lookups again!) to make rotated dots at various places out of it.
It's also a problem to get the du/dv for texture interpolation, but most demos use huge divtables to get these.
You can also do a phong/textured torus as clever table lookups, with free (!) rotation about any angle:
[url]http://csdb.dk/release/?id=3581[/url) here you have a double lookup, one for Z rotation (screen space sotospeak), and one into a 16x16 texture (in case of the tmapped torus), finally the lookup tables are animated to have the torus rotate around some other axis.
Finally env mapping a "light blob" texture has its benefits: it hides a lot of calculation errors which come from all the compromises to get it somewhat working at all. Also at such a low res with huge pixels you're not likely to have an env mapped object that looks good.
Thank you a lot for a good explanation. It makes a lot of sense.
Wow, thanks for the explanations!