How is 3D 3.456 dots possible on Amiga 500?

[crf45]

I used to program a few demo on A500 in the 90s and there are several tricks I'd like to understand. For example 3.456 dots 50FPS on A500 with shape that change made by Hannibal on Anarchy's 3D Demo 2. Do you have some pointers on how this is possible? at 2:52 [ Show youtube player ]

I asked this question here as well with interesting answers but no concrete code ,trick or algorithm.
https://www.reddit.com/r/amiga/comme..._on_amiga_500/

[grond]

They probably use cylindrical coordinates for the landscape dots and tables for projection on the screen. That's why the landscape can rotate easily, that's just one addition for the angle-offset. I assume there is no perspective in the z-direction, then the height info of the dot directly translates to the screen. Similarly the sphere and cube are probably done using spherical coordinates. Again only some adds needed for the two angles of rotation, tables for projection.

[a/b]

- no depth/perspective (parallel perspective, meaning z is ignored for speed but it will look 2D/flat-ish)
- 4x mirroring/symmetry, and thanks to no perspective maybe the entire thing is just only x and y, and lots of tables (entirely fake 3D)
- morph is very limited: only dots that are part of a group of e.g. 64 dots can morph between eachother, and every group morphs in the same way (probably precalc and then use a set of tables to scale to appropriate size in real-time)
- don't know whether it's a 3-axis rotation or maybe simplified as 2-axis, or entirely faked in some other way (because of the above)
The point being, it's not entirely what it appears to be .

[crf45]

The thing is that I remember having done a 2048 dots sphere with all coordinate precomputed and only 5 simple instructions (no mul/div) to get each dot coordinate and print it on bitmap, this is why I am wondering how this is possible? One day I will take the time to decompile it 100%

[grond]

You don't happen to have that code anymore?

[chb]

Rock Lobster by Oxyron has a pretty impressive dot routine and the source is on github. From the doc:

Vectorplots:

One of the technical hi-lights in the demo.
2816 z-shaded morphing vectorplots. Before adding sprite-overlays and design-stuff I had 3172.
A transformation matrix is generated every frame.
The morphing is just the result of using lots of prescaled sintables.
Half of the pixels are transformed with one add.l for X, Y & Z.
Then the blitter extracts the bits and adresses for the plots including z-shading.
The blitter also mirrors the bits, adresses and shading for the other half of the symmetric object.
The CPU sets the pixels with a bset.b per pixel.

Might be worth a look.

[zero]

The blitter is a very powerful tool for accelerating these kinds of bit handling functions that the 68k is bad at. It's also pretty complex to get it to do what you want, really need to wrap your brain around how it works.

[ImmortalA1000]

Starfield at 3.55 is nice. Problem was demo coders never made kick-ass game engines in my time with Amiga so I was always suspicious by default otherwise it would be more than just a demo segment

[Hannibal]

So i don’t remember all the details, but I remember that it did 4 dots at a time, in 14 instructions. It was based on symmetric dots within a slice, and on the slices being symmetric too. - so when it drew a dot in a slice, it also drew the opposite dot in the same slice, and those two dots in the opposite slice. I believe it was loop unrolled for a full slice, and used self modifying code to store a rotated x/y values for each dot in the slice (and all slices look the same. So I think the only math that happened per 4 dots was to scale the x/y for that slice (a lookup table), add and subtract the x/y for the center of the slice - the rest was bit manipulation and bsets

Also, all credit where due, I saw a very similar technique in another demo before, it just didn’t have anywhere near as many dots.

And complex did a version with 4096 dots with a super clever trick - they just calculated the X/Y coordinates and stored them in a list, and had the blitter build a list of bset commands, which the cpu then executed. Since the bit manipulation was the most expensive part of dot routines, this was worth the complexity of having multiple steps

[chb]

Originally Posted by Hannibal

And complex did a version with 4096 dots with a super clever trick - they just calculated the X/Y coordinates and stored them in a list, and had the blitter build a list of bset commands, which the cpu then executed. Since the bit manipulation was the most expensive part of dot routines, this was worth the complexity of having multiple steps

Ah, I guess you are referring to the "A500 Homage" 40k?
https://www.pouet.net/prod.php?which=9268

There's some amazing code in that one indeed... (and great music and a nice design).

[VladR]

Originally Posted by ImmortalA1000

Starfield at 3.55 is nice.

Yes, it is
But, even if it seems like this is one section that perhaps, could, be used in a game (say, as an hyperspace effect), we already have a precedent from 1979 that this kind of effect is actually interactive - Star Raiders I (on 1.79 Mhz 6502) made it an actual gameplay element where you are in control of the direction where you fly through hyperspace.
Meaning, all those dots are rotated each frame based on your input - hence no symmetry and no Copper mirroring tricks are possible anymore.

And, even if you designed the game so that hyperspace wouldn't be interactive (in which case you could use this FX), the transition from 3,000 (FX) dots to just 32 (in-game) would be quite jarring and WTF-esque

Originally Posted by ImmortalA1000

Problem was demo coders never made kick-ass game engines in my time with Amiga so I was always suspicious by default otherwise it would be more than just a demo segment

Of course, most of them didn't. It wouldn't make them look good if the 3D scene complexity suddenly dropped by about 2 orders of magnitude to account for random player input, clipping, AI and other boring pesky details that one doesn't have to take into account when coding a 20-second FX using ~95% of available RAM for tables (that took about a minute to compute)