How are the Demo scene people able to create very fast 3D polygon routines for OCS?

[carlosgod]

Originally Posted by arcanist

An old scene trick I've reused very recently divides a bounding box (cube) into evenly spaced points, allowing polygon vertices only at these points. This is sufficient to represent many nice shapes with subdivision.

Instead of rotating/scaling every vertex of the object, which is expensive, rotate/scale three unit vectors only, one for each axis. Build a vector lookup table for each axis by successively adding this vector to itself. Finally, to rotate/scale any point of the object, look up its position in the three tables and sum the vectors together.

I've also made extensive use of log/exp lookup tables to turn multiply/divide into add/subtract. And of course sin/cos tables.

So the log/exp/sine/cosine lookup table seems to be a standard fare for the demo scene.

I wonder if this is what Amiga 3D polygon engines can do as well though? I assume this kind of short cut must be applicable for real games. Same as the vector look up table concept that you mentioned to avoid rotating all the vertices in a 3D polygon game.


I'm just wondering if past Amiga 3D polygon games are as optimized as they could have been. Games like Zeewolf for instance which is all polygons, but runs pretty poorly on OCS. Makes me wonder if they had someone from the demo scene working on this game, it might be possible to use all these trickeries to make it run at 12-15FPS for OCS instead of 4-5 that we're seeing - just like how Dread/Grind now runs at that speed for OCS (at least, the version that is downloadable).

[ Show youtube player ]

[DisasterIncarna]

Originally Posted by arcanist

An old scene trick I've reused very recently divides a bounding box (cube) into evenly spaced points, allowing polygon vertices only at these points. This is sufficient to represent many nice shapes with subdivision.

Instead of rotating/scaling every vertex of the object, which is expensive, rotate/scale three unit vectors only, one for each axis. Build a vector lookup table for each axis by successively adding this vector to itself. Finally, to rotate/scale any point of the object, look up its position in the three tables and sum the vectors together.

I've also made extensive use of log/exp lookup tables to turn multiply/divide into add/subtract. And of course sin/cos tables.

WITCHCRAFT!!!! er the good kind.

[carlosgod]

Originally Posted by DisasterIncarna

WITCHCRAFT!!!! er the good kind.

I personally believe that all Amiga Demo scene devs weigh the same as a duck!

[arcanist]

Originally Posted by carlosgod

So the log/exp/sine/cosine lookup table seems to be a standard fare for the demo scene.

I wonder if this is what Amiga 3D polygon engines can do as well though? I assume this kind of short cut must be applicable for real games. Same as the vector look up table concept that you mentioned to avoid rotating all the vertices in a 3D polygon game.

Demos have the advantage of being very choosy about what to show.

e.g. One reason transparent polygons ("Glenz") are popular in demos is because they're easy to draw with bitplanes and look flashy. But most games want solid polygons. This adds significant overhead in depth sorting and clipping.

For a deeper look inside a 3D engine that is both slow on 68000 but also very well implemented, here's a good deconstruction of Frontier: https://watsonmw.com/fintro/

Originally Posted by DisasterIncarna

WITCHCRAFT!!!! er the good kind.

I didn't invent the magic, I just found the spellbook.

[carlosgod]

Originally Posted by arcanist

Demos have the advantage of being very choosy about what to show.

e.g. One reason transparent polygons ("Glenz") are popular in demos is because they're easy to draw with bitplanes and look flashy. But most games want solid polygons. This adds significant overhead in depth sorting and clipping.

For a deeper look inside a 3D engine that is both slow on 68000 but also very well implemented, here's a good deconstruction of Frontier: https://watsonmw.com/fintro/

Ah so I was under the impression that transparent and translucent polygon is hard to do... I guess I was tricked!

Read through FE2 notes. So it seems like they could have made it better if they had done more stuff with Blitter (I didn't realize they only used it to just clear the screen!). But yes, I can imagine that it would have probably resulted in a very different look and feel, possibly more like the PC version but slower. Since they're trying to do everything (ST, Amiga and Mac) in one go they probably can't afford to do split resources to create an Amiga Vanity projection version. So I guess Amiga FE2 was another victim of ST port though like you said, it was probably done as well as it could under the circumstances.

[alexh]

Zeewolf is a very good game (well I liked it) but it is unfortunately an example of how later Amiga games could have been much better with very small changes to their rendering pipeline.

The CPU renders directly into ChipRAM which is incredibly slow for reads and writes, instead it could have used a FastRAM back buffer and copy it over. Also it used the blitter to clear the screen.

Paraj did a few hacks and increased performance to "unplayable" on Fast Amiga's.

https://imgur.com/JqW9UCf

https://eab.abime.net/showthread.php?t=116267

[d4rk3lf]

If this thread is partly searching for impressive 3D games for Amiga 500, then I can recommend looking into a No second Prize game.
It's insane how fast it runs on Amiga 500:

[ Show youtube player ]

There is also Dread, as you already know.

But there is also Britelite (he commented on this thread) amazing Wolf3D clone, that runs amazingly fast on Amiga 500.

[ Show youtube player ]