@NutsAboutAmiga

We use a mixture of runtime and compile time abstraction for this. For example, if you run the 020+ generic build, it will choose an 030 or 040 optimised C2P path, depending on the CPU detected. This is no additional overhead since it's just a function pointer to call. We just set the pointers up as soon as we know the screenmode and use them from then on. This is a runtime abstraction.

If you run the 040 or 060 build, the same code path is just hardwired to use the 040+ C2P and the 030 C2P code isn't even present in the executable.

If you are running the 060 build, several inner loops are replaced entirely with their 060 optimised counterparts. These are less ameniable to call by indirection because that indirection happens on countless individual drawing calls, so we don't run-time abstract it, just use the 060 build. That's a compile time abstraction.

Usually the rendering paths are the same in all the builds (except for the inner loop optimisations above), but an example where rendering paths differ somewhat is the text message rendering. On fullscreen mode (RTG or AGA), the text is chunky-plotted to the fast ram chunky buffer every frame. In 2/3 RTG mode, the text is chunky plotted directly to the VRAM region (while locked) of the display/back buffers below the game view, when and only when the text updates.

In 2/3 AGA mode, a completely different, planar based plotter writes directly to a single plane in fast memory and is then longword copied to the display/back buffers. This is why the text in AGA 2/3 mode looks grey on black, because the single bitplane we write to corresponds to a grey colour in the palette. Another option to revisit later is to render it via sprites as this will work better with double height pixel modes and can support different colours again.

We already made most of the obvious low-level optimisations in the code quite some time ago. For example, at one point there were up to 8000 32-bit long division instructions per frame in my mod due to the greater use of polygon models which used it for perspective correction. They were mostly eliminated by converting division to multiply by reciprocal (which is a lookup). On the 060, the difference is significant because multiplication is so fast. However, division is still so slow on earlier CPUs that even 040 and 030 benefit, just by smaller margins.

The optimisations now are higher level and are largely being done in C. The primary issue is that of overdraw. There are examples in the original game where an entire complex scene is rendered and then completely drawn over by a wall. I've managed to eliminate a lot of that, but one of the worst offenders still remains which are door/lift zones. That's the area I'm working on next.

Last edited by Karlos on 22-Dec-2024 at 12:25 PM.

_________________
Doing stupid things for fun...

Just going to drop these here:

https://www.linkedin.com/pulse/software-shouldnt-exist-karl-churchill-vkqhe/

https://www.linkedin.com/pulse/software-shouldnt-exist-part-2-karl-churchill-fasae/

_________________
Doing stupid things for fun...

@Karlos

Nice read! Thanks! I feel privileged to have completed AB3D before Doom and still prefer the survival horror atmosphere it created! Masterful!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Karlos

Quote:

Karlos wrote: Just going to drop these here: https://www.linkedin.com/pulse/software-shouldnt-exist-karl-churchill-vkqhe/ https://www.linkedin.com/pulse/software-shouldnt-exist-part-2-karl-churchill-fasae/

For Alien Breed 3D 2's April 1996 release, the Amiga models that are 68060 accelerator capable are in the small minority i.e., A2000, A3000, A4000, and A1200.

A600 is not 68060 and RTG upgradable, and it was ignored by 3rd party 68060 CPU accelerator vendors until Vampire's AC68080 with RTG.

A500 is not an easy 68060 and RTG upgradable, and it was ignored by 3rd parties 68060 CPU accelerator vendors until Vampire's AC68080 with RTG. A500 with 1992-era 68040-28/68040-33 accelerator is missing RTG, hence it's half a solution.

CD32 was ignored by 3rd parties 68060 CPU accelerator vendors until the recent TF360's release.

Without RTG, A500 with PiStorm-Emu68 and OCS graphics are limited, e.g. Shapeshifter's interlace display is subpar, hence full ECS is needed.

PiStorm-Emu68 release was after Vampire's AC68080 V2 release.

Without targeting the A500's production scale and install base, #metoo Doom+ clones and CPU/RTG accelerators on the Amiga platform are weak in terms of economies of scale.

If AGA sales numbers are treated as worldwide
44,000 (the UK has 30,000 during its launch),
100,000 (AF50, Sep 1993),
170,000 (AF56, Feb 1994),
166,000 (CD32, Commodore US president, Jan 1994),
7,500 (Germany's A4000/030),
3,800 (Germany's A4000/040),
Total: 491,300 AGA units.

For 68060 capable AGA Amigas,
44,000 (the UK has 30,000 during its launch),
100,000 (AF50, Sep 1993),
170,000 (AF56, Feb 1994),
7,500 (Germany's A4000/030),
3,800 (Germany's A4000/040),
Total: 325,300 AGA units, which is a similar magnitude for A2000's install base.

That's many magnitudes less than A500's customer base.

We're not even considering the 68060 attachment rates with the minority A2000, A3000, A4000, and A1200 install base.

This is the "chicken and egg" problem.

https://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node033C.html
From AmigaOS 3.1 documentation's WriteChunkyPixels

Bugs: Not very fast on systems without chunky-to-planar conversion hardware.


John Carmack just repeated Commodore's official position on this issue. Commodore effectively told their desktop Amiga customers to buy a Commodore 32-bit PC clone.

Commodore hates Amiga and it's documented. Should I post Herni Rubin's action that promoted ATI graphics over the Amiga?

Last edited by Hammer on 04-Jul-2025 at 08:09 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Man, this feels like unlocking cheat codes for the CPU… just skipping those long divisions like "nah, not today."

@cip060

Division is poison. If you can avoid it, you should. There are even semi modern CPU that don't even implement it. The muls/asr combo on 060 is so much faster than divs that it's not even funny. For the older CPUs, it's less dramatic but still quite a bit faster.

I wasn't able to eliminate all of it, of course, but it was massively reduced.

There were lots of small changes like this, some not so small, that in isolation looks like microoptimisation but work together to give a sizeable speedup. The remaining heavy hitters are things like RTG chunky pixel displays that totally circumvent C2P and finally reducing overdraw. The last one is a pretty big force multiplier for all the prior optimisation.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: Division is poison ...

Division and modulo are poison but you can't tell it to people who like code like this:

for ( i =0;  1; i++)
{
   if (DoSomeThing( i % 11))
      break;
} 

@Hammer

It's not obvious what point you are trying to make. What I can say is that the game was released in what is essentially an unfinished, suboptimal state because it ultimately came to the crunch of release it as is, or not at all.

Andy Clitheroe himself lamented how all the programming effort went into expanding the capabilities of the renderer. The only other major new features were the team AI. Releasing the sources - of both games - was a great gesture, particularly when this wasn't an especially common thing for companies to do.

Much of the game internals, including the PVS solution where almost unchanged from AB3D1. It's likely that the PVS issues went unnoticed in AB3D1 due to the tiny render area. Or even if they were noticed, careful level design probably eliminated some of the worst cases. The engine does not use a BSP, nor is it a Portal renderer. The truth is, it has elements of both.

For TKG, the render area is an order of magnitude greater. Combine that with more complex rendering code of and you pay a pretty heavy price for drawing anything that shouldn't be visible.

The game should've been playable on an 030 ideally, even if you had to opt for reduced visuals. It's not quite there yet, but it's getting closer.

_________________
Doing stupid things for fun...

@OneTimer1

Surely nobody in gainful employment anywhere writes code quite like that. That's pretty special.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: Surely nobody in gainful employment anywhere writes code quite like that. That's pretty special.

Sometimes you are reading a pattern from an array or data out of a ring buffer, if the buffer has the right size you can use a mask (f.e. DoSomeThing (i & 7) ) or a 'if then' construct with an additional counter but some people are seeing the modulo operator as an elegant alternative.

I have seen many 'beauty coders' who made nice looking impractical, slow and 'hard to debug' code.

---

Back to "Alien Breed 3D" I have not looked much into the details you posted, but I knew some programmers made really good C2P converters, handling data nearly as fast as a chunky mode frame buffer would have done it.

I was a big fan of "Nemac IV" had a A2000 + B2060 + Z2-RTG, speed was better than AGA and I could play it full screen. Some games had the opportunity to switch between different C2P modules and some supported 3D glasses. But this was out of reach with a naked A500 / A1200 and the best of those games where published when the Amiga was on its end.

@OneTimer1

We are now using the fastest Kalms C2P routines for 040/060 but also for 030, if the generic build is used. I modified them all to work with the small screen mode and double height modes. There's even Akiko support for those that want to try it.

On 060, the routines become bottlenecked by AGA write speeds, which is around 7MB/s. This is actually faster than some Zorro 2 RTG cards

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @Hammer It's not obvious what point you are trying to make.

Guess why...

@cdimauro

I think the point he's trying to make is that the AGA/060 market was too small and that the A500 market was much larger. I mean that's not incorrect. It doesn't matter though. You'd need GRIND in released in 1996 to penetrate that market. Since I don't have a Delorian equipped with a flux capacitor...

It doesn't change anything. Originally everyone was under the impression that an 030/50 would be a viable machine spec to play the game. When the first playable demos came out, I'd already gotten a 040/25 and realised that it probably wasn't going to be the case. I finished the game on that card and it wasn't exactly the smoothest experience. Doom itself, particularly the DoomAttack build was much more playable.

What I will say is that we've squeezed a lot more performance out of the engine since and I think there's still some more left to go. For example, there's a similar overdraw issue with lifts that I've already started working on. There's also the room over room upgrade to the entire edge PVS solution. Right now, got still waste cycles drawing the upper and lower parts of each visible zone but there's often not a line of sight for the upper or lower part. And buy extension, the edge PVS itself for any given zone might be much smaller when that is taken into account.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: Originally everyone was under the impression that an 030/50 would be a viable machine spec to play the game. When the first playable demos came out, I'd already gotten a 040/25 and realised that it probably wasn't going to be the case.

ChipRAM write on 030/50 AGA was bettern than on 040/060 AGA, the 040/060 are tuned for Burst Read/Write to RAM, if this can't be done they can't deliver their full performance, some 060 cards on A4000 may have a better ChipRAM speed because, they have some kind of a single word buffer (especially Cyberstorm 060 I) .

All my comment to R/W speed on AGA CS A1200/A4000 are seen as 'IMR' and 'AFAIK'

@OneTimer1

C2P wasn't the biggest bottleneck in the end. There were still monstrous dips in performance with RTG on a graphics card having write performance far higher than AGA. My BlizzPPC/040 with BVision had copy fast to vram faster than you could just write to chip.

C2P was not as efficient as it could've been, but the performance of TKG was lost by a few big things and very many smaller ones.

The overdraw problem is definitely one of the big killers here, since it acts as a multiplier. The sum total of every small efficiency losses in rendering a pixel is multiplied by how many times that pixel is drawn over. Sometimes this is actually desirable - if you are blending, which the game has support for. But most of the time, it's not that.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro I think the point he's trying to make is that the AGA/060 market was too small and that the A500 market was much larger. I mean that's not incorrect. It doesn't matter though. You'd need GRIND in released in 1996 to penetrate that market. Since I don't have a Delorian equipped with a flux capacitor... It doesn't change anything. Originally everyone was under the impression that an 030/50 would be a viable machine spec to play the game. When the first playable demos came out, I'd already gotten a 040/25 and realised that it probably wasn't going to be the case. I finished the game on that card and it wasn't exactly the smoothest experience. Doom itself, particularly the DoomAttack build was much more playable. What I will say is that we've squeezed a lot more performance out of the engine since and I think there's still some more left to go. For example, there's a similar overdraw issue with lifts that I've already started working on. There's also the room over room upgrade to the entire edge PVS solution. Right now, got still waste cycles drawing the upper and lower parts of each visible zone but there's often not a line of sight for the upper or lower part. And buy extension, the edge PVS itself for any given zone might be much smaller when that is taken into account.

It was clearly an unfinished product, so that was the primary problem. The second one is that the Amiga had its own issues with accessing the Chip RAM and with the missing support to the packed/chunky pixels (and for both we've to "thank" the "geniuses" that worked at our beloved platform, once the original team was moved out).

As you stated, we can't go back to the past and change it with the hindsight of today.

The only positive thing is that the company decided to release the game anyway, despite that on '96 the Amiga market was basically gone (Fighting' Spirit, which was released on the same here, sold only a bunch of copies).

@Karlos

DOOM on Amiga with 68020 Akiko and FAST RAM run as good as on cheap 386:
https://www.youtube.com/watch?v=-kDM3S7gQTk
Commodore bankrupt because AGA has not chunky pixels rest is history

Alien Breed 3D 2 I never heard about this back before 2000
060 was too expensive
I remember year 1998
060 cost as much as cheapest ppc card for a1200 with 603/040 and bvision

@ppcamiga1

AB3D2 is actually - as an engine - a touch more complex than Doom.

It was playable back in the day on an 030 - I managed to get as far as level D on my 1200 with 1230/IV and 4MB Fast. And that wasn't the cut-down version but it was definitely not fullscreen :)

Karlos' Engine now is much improved and his modded levels are great fun.

@ZXDunny

Fun, eh? I'll have to see about that....

On a serious note, the next big modding feature I want to add is the concept of objectives. For this to work, I'm going to need to be able to define them in a manner that's easy to define and interpret for the engine.

_________________
Doing stupid things for fun...

@Karlos

Great idea! Will develop it into a living breathing single player game like the 2D games in the series! Any chance of a self destruct type objective with screen shake and red flashing lights and klaxons etc?

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios