Compileable version of Alien Breed 3D II - The Killing Grounds

[coachman]

When playing on classic hardware, I prefer using 2/3 regime instead of full screen - it gives much better flow. However, in that case the text messages are not visible. How complicated would it be to print the text at the usual location even if that's not in the area covered by the reduced 3D view?

[Karlos]

Originally Posted by coachman

When playing on classic hardware, I prefer using 2/3 regime instead of full screen - it gives much better flow. However, in that case the text messages are not visible. How complicated would it be to print the text at the usual location even if that's not in the area covered by the reduced 3D view?

That's the plan. It's a question of how best to do it, because that varies depending on whether or not you are on AGA or RTG.

Doing the messages "in display" is easy because the overhead is next to nothing as the whole frame is either C2P'd to Chip RAM on AGA or copied to the locked bitmap in RTG.

However, in both cases, on 2/3, we are only updating the small region (and borders). To reuse the the space below 2/3 view (which is my preference) clearly has a number of "best ways" to do it.

For AGA it seems overkill to have to C2P a new region to the display so we want some sort of optimised plotter that can operate in planar space. We may also want to the blitter to clear the region*. For RTG, given the total number of pixels written for text is quite small, we probably want a rectangle clear call first, followed by direct writes to the locked bitmap for the text.

* the tricky bit for AGA is trying to find a good, single colour index for text. One that would require manipulating only a single bitplane, ideally. That depends on how the palette is set up, which is a bit odd. We might get away with a brightish white by sticking to bit 5 (colour index 32).

In both cases, we definitely don't want to do any more work than is strictly necessary, so we probably only want to do that redraw when the text changes. Since those regions are not overdrawn by anything, this could be very efficient as we'd be updating the text only once every few seconds.

[Karlos]

First work in a while, but I've done some spring cleaning which has mostly been around removing the various unused historic menu code, of which there is far too much. It's like picking at a thread in a jumper, as you identify something unused, it leads to the next thing and so on, unravelling the whole thing.

[Karlos]

@abu_the_monkey

Just saw and merged your PR for the message buffer fix.

[abu_the_monkey]

Originally Posted by Karlos

@abu_the_monkey

Just saw and merged your PR for the message buffer fix.

cool

also there was a fix for the '*' quit key from paraj
https://eab.abime.net/showpost.php?p...postcount=4366

[Karlos]

Top banana

[abu_the_monkey]

I didn't include the fix from paraj in the pr I raised as they were separate issues. If your happy with it you could include it with your next merge perhaps.

[Karlos]

Sure. I want to merge my "nonfunctional" changes separately anyway.

[Karlos]

Merged and included the submenu exit fix. That's a lot of old menu code finally laid to rest.

[Karlos]

In a feature that literally nobody asked for, I have an experimental makefile for creating a whole matrix of different builds.

Modes
* Dev: devmode features + debug
* Test: debug
* Release: no debug, stripped

Code Models:
For each of the above modes:
* Pure ASM: AGA only
* ASM / C: AGA + RTG

Targets:
For each mode/code model:
* Generic 020-060: 030 tuned C, 020/030 optimisations
* 040: 040 tuned C, Specific 040 optimisations
* 060: 060 tuned C, Specific 060 optimisations

Specific optimisations for 020/030 would include specific C2P routines, avoidance of multiplication where other options are possible, re-enabling of cache freezing tricks.

Specific optimisations for 040 would avoid cache manipulation, specific C2P, potential limited use of move16 operations etc.

Specific optimisations for 060 are as above but with inner loops tuned for superscalar and a general preference for integer multiplication rather than other tricks, where this makes sense.

Runtime indirection can be removed - each target will conditionally include/assemble the appropriately tuned code.

[abu_the_monkey]

Originally Posted by Karlos

In a feature that literally nobody asked for, I have an experimental makefile for creating a whole matrix of different builds.

Modes
* Dev: devmode features + debug
* Test: debug
* Release: no debug, stripped

Code Models:
For each of the above modes:
* Pure ASM: AGA only
* ASM / C: AGA + RTG

Targets:
For each mode/code model:
* Generic 020-060: 030 tuned C, 020/030 optimisations
* 040: 040 tuned C, Specific 040 optimisations
* 060: 060 tuned C, Specific 060 optimisations

Specific optimisations for 020/030 would include specific C2P routines, avoidance of multiplication where other options are possible, re-enabling of cache freezing tricks.

Specific optimisations for 040 would avoid cache manipulation, specific C2P, potential limited use of move16 operations etc.

Specific optimisations for 060 are as above but with inner loops tuned for superscalar and a general preference for integer multiplication rather than other tricks, where this makes sense.

Runtime indirection can be removed - each target will conditionally include/assemble the appropriately tuned code.

cool

[Karlos]

Pushed do a branch build/cpu-targets on my fork if anyone wants to try it out.

make clean && make rel
* This builds the generic 020-060 release versions: tkg / tkgc
* Tuned for 030, no debugging, stripped binaries

make clean && make test
* This buids the generic 020-060 test versions: tkg_test / tkgc_test
* Tuned for 030, debugging, unstripped binaries

make clean && make dev
* This buids the generic 020-060 dev versions: tkg_dev / tkgc_dev
* Tuned for 030, devmode features, debugging, unstripped binaries

For 68040 tuned, you do:
make clean && make rel040
make clean && make test040
make clean && make dev040
* Binaries will have _040 suffix

For 68060 tuned, you do:
make clean && make rel060
make clean && make test060
make clean && make dev060
* Binaries will have _060 suffix

Right now, the CPU tuning doesn't make much difference (except to C code) with the exception of the 060 build, which unconditionally enables optimisations made previously requiring -DOPT060 in the flags.

There's no CPU separation for object files during generation so it's important to make clean before switching cpu targets. If you are cross compiling, this adds approximately 0.01s to your workflow.

Also, my makefile utterly sucks, but I make no apologies for the repetition as it will allow per individual binary specifics to be set. That's my excuse and I am sticking to it.

[abu_the_monkey]

I will try to get to it tomorrow, absolutely cream crackered tonight

[Karlos]

Originally Posted by abu_the_monkey

I will try to get to it tomorrow, absolutely cream crackered tonight

They all build for me, I just need to test them in UAE as a starter. The 040 and 060 versions should still work on 020/030 as there are no special instructions used yet.

455084 Apr 23 20:09 tkg
455084 Apr 23 20:12 tkg_040
455044 Apr 23 20:13 tkg_060
428760 Apr 23 20:09 tkgc
430020 Apr 23 20:12 tkgc_040
429480 Apr 23 20:13 tkgc_060
830972 Apr 23 20:09 tkgc_dev
832188 Apr 23 20:12 tkgc_dev_040
832004 Apr 23 20:12 tkgc_dev_060
829128 Apr 23 20:09 tkgc_test
830344 Apr 23 20:12 tkgc_test_040
830160 Apr 23 20:13 tkgc_test_060
795504 Apr 23 20:09 tkg_dev
795504 Apr 23 20:12 tkg_dev_040
795688 Apr 23 20:12 tkg_dev_060
783632 Apr 23 20:09 tkg_test
783632 Apr 23 20:12 tkg_test_040
783632 Apr 23 20:13 tkg_test_060

[Karlos]

Assuming they all work and aren't horrifically bust, I'll start removing some runtime indirection after...

[abu_the_monkey]

Originally Posted by Karlos

Assuming they all work and aren't horrifically bust, I'll start removing some runtime indirection after...

sounds like a plan

[Karlos]

Each of the builds runs fine for me in UAE, which is a relief. I though certain somethiing would go bad.

Most of the 060 optimisations are build-time, but at least one depends on the runtime cpu detection. I don't think it makes sense to rely on that now. The only runtime control should be limited to things that just might not work safely/at all depending on your specific configuration, like using move16.

[Dunny]

Originally Posted by Karlos

Most of the 060 optimisations are build-time, but at least one depends on the runtime cpu detection. I don't think it makes sense to rely on that now. The only runtime control should be limited to things that just might not work safely/at all depending on your specific configuration, like using move16.

PiStorm is usually identified as a 68040, but also has 68060 features too. I'm interested to see how these binaries perform

[Karlos]

Originally Posted by Dunny

PiStorm is usually identified as a 68040, but also has 68060 features too. I'm interested to see how these binaries perform

The binaries don't contain any special instructions yet, it's just that some routines are optimised for execution on a particular cpu. You can safely run the 060 build on an 030 currently.

Anything fundamentally incompatible will need to be runtime selectable, so I'm still relying on detecting your CPU at runtime.

It still makes sense for some things to always depend on the real CPU. Take C2P for example. We call the code to do that once a frame. So the "generic" version can still check the CPU and call the 040/060 tuned version of that if you have an 040 or better, and call an 030 tuned version otherwise. The cost of doing that check is insignificant. The same is not true with all the inner rendering loops. The code can be much more cleverly optimised when the entire path into them can be specifically tuned.

However, there's no reason the 040 and 060 specific builds should bother with doing that - they can just use the 040/060 code because the whole point of tuning is to target the specific CPU.

I think on yout PiStorm/CM4 it will all be the same tbh - you'll probably pin the FPS to whatever cap is currently set.

[Dunny]

Originally Posted by Karlos

I think on yout PiStorm/CM4 it will all be the same tbh - you'll probably pin the FPS to whatever cap is currently set.

I think you're probably right tbh. Hey, would a true-colour RTG version be on the cards at some point? That might be a fun thing for PiStorm owners to experience.