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

[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 ]

Yet I keep hearing from everyone that the Amiga sucks at rendering Polygons, that using blitter to fill polygon is slow etc. etc. This statement is not wrong of course - as we all know just about all the games that use polygons are very slow on OCS, to the extent that they're almost unplayable. Games like Zeewolf for instance. 11:08 is rather painful to watch...

[ Show youtube player ]

So what exactly are these demo scenes people doing that enables them to achieve this kind of result. Or more precisely, why can't commercial game developers replicate the technique? Is the technique used in the Hologon demo not at all practical in real life gaming situation? Or is it because these 3D routines are closely guarded secrets, and since the demo scene people don't mix with game devs, the secret goes with them to their graves? If any one from the Demo scene can shed light on this mystery would be much appreciated!

[chip]

Amiga demo scene rulez !

[carlosgod]

Originally Posted by chip

Amiga demo scene rulez !

Yes they do!

I wish some of them make games...

[britelite]

Originally Posted by carlosgod

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

That's pretty much the answer to your question. 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.

So what exactly are these demo scenes people doing that enables them to achieve this kind of result. Or more precisely, why can't commercial game developers replicate the technique?

Commercial game developers can definitely replicate the techniques, but you would probably want something a bit more complex in a game than only a rotating cube on screen, and that's where things quickly get way too slow.

[grond]

Amazing demo indeed! The thing with demos is that a lot of the stuff gets precalculated while you are looking at stills or less demanding effects. A lot of effects also have a certain amount of "replay" in them (frames or graphics that were rendered and/or displayed before get reused). Then a lot is based on tables that only have a certain size and thus only work for objects within a certain very limited range such as tables used for 3D projection. In a game you need to be able to allow any kind of movement at any time and therefore need an engine that can display anything and not just scenes which are constructed to match the limitations of the hyperoptimised engine. (When you have eliminated all crappy coding, each further optimisation relies on an assumption which may break in a general setting). This said, a lot of demo sceners went into games coding. Probably less these days because there is so little need to actually optimise anything any more.

[carlosgod]

Originally Posted by britelite

Commercial game developers can definitely replicate the techniques, but you would probably want something a bit more complex in a game than only a rotating cube on screen, and that's where things quickly get way too slow.

Okay, so in the Hologon example, would I be correct in saying that they're making the polygon object rotate in a pre-determined manner. As a result, the CPU doesn't actually have to perform a lot of calculations, so all they have to do is optimize the hell out of that with blitter/copper routine?

But in a 3D game (say, a space sim), because the engine is constantly waiting for movement input from the user, it means the CPU has to become heavily involved in figuring out how the polygon object will rotate based on the user's input/interaction, and this causes massive slowdown in the polygon movement to the level that we're seeing in games like Frontier or Hunter for OCS?

[AestheticDebris]

Originally Posted by carlosgod

.
So what exactly are these demo scenes people doing that enables them to achieve this kind of result.

Cheating.

Demo coding is all about cutting the absolute maximum number of corners to make it look like you're doing something that you really aren't. Precalculations can play heavily into it, as can taking shortcuts that would break in the general case but work for very specific scenarios (f.e. not redrawing all of a polygon if you know it hasn't moved much and will never be obscured etc).

In an actual game, you typically have a lot less control over things - not none, but less, Elite for example carefully constructs all the spaceship models to remove a bunch of difficult to render edge cases.

[carlosgod]

Originally Posted by AestheticDebris

Cheating.

Demo coding is all about cutting the absolute maximum number of corners to make it look like you're doing something that you really aren't. Precalculations can play heavily into it, as can taking shortcuts that would break in the general case but work for very specific scenarios (f.e. not redrawing all of a polygon if you know it hasn't moved much and will never be obscured etc).

In an actual game, you typically have a lot less control over things - not none, but less, Elite for example carefully constructs all the spaceship models to remove a bunch of difficult to render edge cases.

Okay, this starts to make sense. So eliminating the need to redraw parts of the polygon that you know won't crop up again in the next frame can probably save you a clot of CPU cycles.

But while we've seen some innovation for FPS type games like Dread/Grind (which I understand has to more to do with Blittler C2P techniques), do you know if there has there been any innovation in fast polygon rendering for the Amiga? Or are we pretty much at the same spot as when David Braben made Frontier?

[a/b]

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

[carlosgod]

Originally Posted by grond

Amazing demo indeed! The thing with demos is that a lot of the stuff gets precalculated while you are looking at stills or less demanding effects. A lot of effects also have a certain amount of "replay" in them (frames or graphics that were rendered and/or displayed before get reused). Then a lot is based on tables that only have a certain size and thus only work for objects within a certain very limited range such as tables used for 3D projection. In a game you need to be able to allow any kind of movement at any time and therefore need an engine that can display anything and not just scenes which are constructed to match the limitations of the hyperoptimised engine. (When you have eliminated all crappy coding, each further optimisation relies on an assumption which may break in a general setting). This said, a lot of demo sceners went into games coding. Probably less these days because there is so little need to actually optimise anything any more.

I see, so they reused frames that were rendered previously as well. I guess that makes a lot of sense in the rotating cube demo.

Sorry, I am not a developer - what do you mean by 'tables' that are used for 3D projection? Is that like a pre-written array of vertices and coordinates for each points in the polygon that you tell the program to render for specific frames, instead of calculating them on the fly?

[alexh]

Ambermoon 3D sections. Work well on A500. Written by Demo scene coders who were moving to the PC. (certainly not on par with the techniques in Dread/Grind)

[carlosgod]

Originally Posted by alexh

Ambermoon 3D sections. Work well on A500. Written by Demo scene coders who were moving to the PC. (certainly not on par with the techniques in Dread/Grind)

Ah, so that was an example of a demoscene developer moving to game... and the result shows! Thanks for the info.

[AestheticDebris]

Originally Posted by carlosgod

Is that like a pre-written array of vertices and coordinates for each points in the polygon that you tell the program to render for specific frames, instead of calculating them on the fly?

In a simple case, yes. More complex effects might store tables of partial calculations etc that cut down the amount of maths required to produce the required result but the principle is still the same. It's pretty much always quicker to look something up rather than calculate it, unless the maths is trivial (since finding a lookup entry might well involve some maths itself).

[grond]

Originally Posted by carlosgod

I see, so they reused frames that were rendered previously as well. I guess that makes a lot of sense in the rotating cube demo.

One example would be a 2D effect that gets calculated in real time like a roto-effect. After some time the effect gets more exciting and it does roto-zoom. You could now just use the rotated frames you calculated before to do the zooming (this example probably doesn't make much sense but anyway). Now you have a lot of rotating/zooming frames recorded in memory and then you just redisplay them for another few spins. During this time you calculate an object you are going to display flying in front of the rotating-zooming background. And so on...

Sorry, I am not a developer - what do you mean by 'tables' that are used for 3D projection? Is that like a pre-written array of vertices and coordinates for each points in the polygon that you tell the program to render for specific frames, instead of calculating them on the fly?

That would be one possibility but I was referring to sine-tables or tables for division. Instead of calculating what sin(x) is, you simply have a table with sine values for a number of different values of x and then use you actual x to access the table to find sin(x). Of course, tables can grow very large and you'll run out of storage space. Hence, you limit the number of possible x values to input which then means you can only use the table under specific circumstances which may be too limiting for a game engine.

[carlosgod]

Originally Posted by grond

One example would be a 2D effect that gets calculated in real time like a roto-effect. After some time the effect gets more exciting and it does roto-zoom. You could now just use the rotated frames you calculated before to do the zooming (this example probably doesn't make much sense but anyway). Now you have a lot of rotating/zooming frames recorded in memory and then you just redisplay them for another few spins. During this time you calculate an object you are going to display flying in front of the rotating-zooming background. And so on...




That would be one possibility but I was referring to sine-tables or tables for division. Instead of calculating what sin(x) is, you simply have a table with sine values for a number of different values of x and then use you actual x to access the table to find sin(x). Of course, tables can grow very large and you'll run out of storage space. Hence, you limit the number of possible x values to input which then means you can only use the table under specific circumstances which may be too limiting for a game engine.

Ah that's a pretty clever trick. Thank you!

[TCD]

Originally Posted by carlosgod

Or more precisely, why can't commercial game developers replicate the technique?

While I wouldn't call it 'commercial game development', the Dread/Grind dev comes from a demo background: https://amiga.abime.net/artists/view...czek-kk-altair

[carlosgod]

Originally Posted by TCD

While I wouldn't call it 'commercial game development', the Dread/Grind dev comes from a demo background: https://amiga.abime.net/artists/view...czek-kk-altair

Looks like there's a common thread here for Amiga games that achieve technical breakthroughs (Ambermoon being the other one). Thanks for the info!

[khph_re]

It does look fantastic :-)

The scene at 1.06, I don't think it's texture mapped. I think the facets are looking through to other bitplane's that are scrolling a picture. Similar to how Da Jormas fake their Phong shading.

Could be wrong though, I'm not a coder.

[carlosgod]

Originally Posted by khph_re

It does look fantastic :-)

The scene at 1.06, I don't think it's texture mapped. I think the facets are looking through to other bitplane's that are scrolling a picture. Similar to how Da Jormas fake their Phong shading.

Could be wrong though, I'm not a coder.

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!

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