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 ]

[NorthWay]

Demos can go "all out" in their cheating, pre-calculating all the points/lines in a scene, or even better; just store the complete set of blitter register contents for each frame (if using blitter at least).

[TCD]

I sense an incoming Photon post

[Photon]

Remember that demo effect authors, which is most democoders, deserve trust and anticipation from you the audience in the hope to deliver the magic feeling of the unexpected that you love in demos.

Cheating seems hell-bent on killing that feeling. Through the decades, only a few cheat, and to a very varying degree.

I make enemies of friends by thumbing down only demos cheating with datalumps, because that is objectively wrong and also unproductive. But only a few groups do that.

Interactivity

What counts for an effect being interactive is the DOF (degrees of freedom). Doom has 1, 3 is enough for Quake, 6 is max for Descent and any game with a free and rotating camera. 2.5D or less, and you didn't do 3D (all effects, all platforms.) I think we see this and understand. DOF is more or less why someone like Carmack can appreciate the Demoscene.

Many demos also follow a script (to not require democompo organizers to interact every scene...), and to sync with music. This means that a demo not being interactive is not grounds for accusations of cheating. There are many, many demos that have 'just 3D' + a script to make it a good show.

An example of this would be Vector Eye-Candy, which was deemed "too slow" because it's real, and now we have the crossover into games with Flying Shark, and his flight sim vids, which shows he's a good coder.

So, cheating or not depends on the coder, and demos can be interactive or not.

On topic, Bifat's demos specifically go out of their way to demonstrate (after full run-through) partial or full 3 DOF interactive parts!

Here's an excellent, progressive, partially interactive scripted awesome line vector demonstration with more extra that is still one of the best demos for any platform ever, and additionally, I'm sure all non-interactive parts are effects. <3

Originally Posted by britelite

You can take way more shortcuts and make assumptions about things when making effects for a demo than when making something interactive like a game.

I know where you're coming from, but many demos didn't and don't take shortcuts from my research.

Here's another scripted example which demonstrates just a normal proper 3D engine that can be used in a game interactively. The same goes for this "preview".

So a scripted demo can have a real engine with effects.

Originally Posted by carlosgod

waiting for movement input

Input is just few bytes read per frame to shift or rotate the scene, it shouldn't affect any 3D engine in a major way, including those with shortcuts as Britelite points out.

Only datalump demos can't have interaction. So some nerd in spandex will figure out a datalump with some interaction. The antidote to which is to measure if it has 3 DOF. If not it's a normal datalump again. So this is the test.

Originally Posted by a/b

cheating = specialization (in a very controlled environment, without user interaction) :P

In opposition to this, I mean that it's cheating only if you present animation as effect in a Demoscene demo. PD and games can cheat all they want, Another World obviously hasn't a 3D engine but is fine just like cutscenes in games.

Games don't have infinite worlds, so they're special-cased, etc etc. Just take all the 3D games with the tiny screens and the tiny culling distance, or Stunt Car Racer.

Originally Posted by grond

precalculated

Precalc and prerender will never reach 3 DOF + cause delay affecting presentation, maybe with decrunch-like flicker No, don't go suspecting, again only a few groups cheat.

As an aside, if you want to practice prerender detection,this is quite clear. Try to click to the fast parts when text is displayed. Then watch the slow part which is normal.

Originally Posted by grond

tables

This old chestnut is sometimes used as a lame excuse for "anything goes".

Tables won't make a proper effect much faster, and lack of it won't make it much faster. Besides, if you updated from 1992 and know what you're doing you can rid them all including sine, div etc which is only for the small calculation part anyway.

Tables can become prerender or datalumps, but this is not what most people throwing it around mean. I don't think they know what they mean. If you say you don't use tables you better not have a color LUT anywhere. No colors for you, you have to precalc them now.

That discussion is just stupid, sorry.

Motivation

I dislike datalumps particularly

• because I would like coders to not treat the Amiga as another platform to replay data on (from over there on the PC),
• because I would like to see new code, effects, and algorithms developed and published for the Amiga,
• because a platform is as alive as the amount of new software coming out for it,
• and datalumps will kill the platform as efficiently as game ports instead of new games.

End anthem. <3

[carlosgod]

Originally Posted by 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 ]

Thanks for this - yes I forgot about No Second Prize, and it was made by the Thallion team which I guess included people from the Demo Scenes. So once again, the result shows when these wizards get involved in making games!

I didn't know about this Wolfenstein 3D demo from Britelite.... interesting that this came out a few years after KK/DMA's demo Wildcat in 2015

[ Show youtube player ]

I wonder if the two (KK, Britelite) ever collaborated on 3D engine or share knowledge in the past decade, or they all came out with their own codes independently. If the latter then it seems like the Amiga Demosceners figured out the tech breakthrough for fast Wolfenstien engine roughly around the same time, which suggests that there may have been a point of origin for these separate teams to come up with their own idea. Or may be I am overthinking this....