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....

[bifat]

In the case of Hologon, I'd like to point out that the degrees of freedom are demonstrated in the second run, when every single effect can be interactively controlled with the mouse. Interactivity is always a triumph over the temptation of having zero degrees of freedom = animdemo.
Certainly a lot of the engineering details can be used in games also.

YES: All hail to Da Jormas, who are super innovative. Although a similar thing was already used in the Interphase intro on Atari ST - in 1989! The problem with this particular effect on the Amiga is that you need barrel shifting on three blitter channels, while only two are provided by the hardware. So you need to overcome this obstacle (which wasn't THAT difficult), and this is not exactly stencil vectors. I even came from a different angle - I wanted that double texturing (texture + fake phong combined) and needed to understand how this could be done. But having the fakephong/mirror effect running standalone looked also good.

[d4rk3lf]

In my mind, none of that is cheating.

Demos (in majority of cases) are not supposed to be interactive, but audio video presentation, and anything that will create Wow effects using regular hardware is not cheating.
It's like saying, after watching some Hollywood blockbuster movies, with great destruction 3D effects, that the cheating is, because background footage was from real video, and everything was not full 3D... that's not cheating... it's common sense to do, and not waste time on something that is not needed.

The only thing I would say someone cheated, is if they promote demo to be OCS, running on A500, and inside A500 is some other hardware running it.

[Cyprian]

Originally Posted by carlosgod

I know that making a Demo is completely different from making a game.

Having said that, I noticed that the 3D polygon routines in the Hologon demo by The Electronic Knights (2020) running on A500 is really fast and quite sophisticated (ie, not just solid color fill, but also using dynamic texture and some sort of lighting techniques). Honestly, it's something you'd expect from an N64 or SNES with SuperFX chip, not a 16-bit machine from the 1980s.

(skip to 24 seconds, 1 min 6 seconds and 3 min 59 seconds to see what I'm talking about)

[ Show youtube player ]

great demo.


two first are regular blitter vectors:

- 24 seconds: flat filled vectors
- 1 min 6 seconds: stencil vectors (no texturing, just copy flat bitmap to each vector)



this one is textured (looks like 2x2 C2P):

- 3 min 59 seconds

[khph_re]

Originally Posted by d4rk3lf

In my mind, none of that is cheating.

Demos (in majority of cases) are not supposed to be interactive, but audio video presentation, and anything that will create Wow effects using regular hardware is not cheating.

I can see both points of view. As an artist, I just want to see a beautiful looking and sounding production.

But I also remember video playback (some demo with a rollercoaster?) presentations pretending to be real-time, and I wasn't impressed.

Obviously creating real-time 3D effects is more difficult than a Fantavision like vector Anim, and yet Vector Anim's can still have artistic merit - especially if not pretending to be real-time.

[Mad-Matt]

Ah the Dataworld demos. Still impressive in their own right as they show streaming animation on a modest Amiga 1200 hd setup. (better than cdxl) To bad the anim system never really got used in anything.

[AestheticDebris]

Cheating was perhaps the wrong word. I meant it in the sense of doing less than a full implementation, in order to fake the right result rather than doing something and dishonestly claiming you're doing something else.

I don't see it as a bad thing. Elite couldn't handle arbitrary shaped ships, but it was still good 3D for the time. PlayStation games all used integer maths and warped textures as a result, but the end product was "good enough" to do a reasonable job, even if the 3D maths in place was occasionally a bit fudged.

With demos I think the end result is how pleasing it is to watch and it doesn't necessarily need to be technically adept if it is aesthetically appealing. Granted something that just plays back a prerendered animation is less technically adept (although arguably playing back a full screen animation on an OCS Amiga from a floppy is pretty impressive in and of itself) but it's probably also going to feel less impressive anyway. Obviously it's a bit different on modern PCs where playing back high Def video for hours on end is a trivial task, but you're also going to notice the lack of any kind of interaction more compared with "real" demos.

[grond]

Um, I don't think that anyone was using "cheating" to mean anything negative. But oftentimes in demos effects are used that look "as if" but just don't do at all what they seem to be doing at first glance. Phong shading is a primary example. There is no lighting calculation at all (other than primary direction of incidence perhaps which is basically just determining an offset into the lightmap), the light distribution is hardcoded into the lightmap which then is applied in standard texture mapping. Glass effect: just texturemapping from back to front using the partly rendered image as the texture for the next triangle. Transparency: ADDing in new pixels into the framebuffer rather than MOVEing them there which is only slightly slower than standard texture mapping.

There are many more such examples. They are far more ingenious than doing the physically exact thing like a raytracer (which is more of a result of assiduity) but that is also why you can detect the differences on close inspection. Because you are cheating, i.e. not doing the real thing. But that is the reason why you can do it in realtime while the raytracer takes hours to compute a scene (well, back then anyway...).

[saimon69]

Originally Posted by carlosgod

You're right - now that I had time to examine it more closely, it is indeed another layer of images scrolling around independent of one another. That is a really clever trick!

The technique has a name, i think is called stencil polygons - however before TEK and Jormas was kinda forgotten and instead i feel might be useful also in gaming sometimes