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

Hi all,

I put a compileable version of Alien Breed 3D II - The Killing Grounds under:
https://github.com/mheyer32/alienbreed3d2
This may be the first time in 25 odd years that the code had been compiled into a working executable :-)
(With the notable exception of John Girvin's AB3D-RTG, also preserved here: https://github.com/mheyer32/ab3d-rtg )

The source is to be cross-compiled via vasm/vlink. Apart from making it run and changing the control scheme to AWSD+mouse I have not made any particular changes yet. Faster C2P, RTG, AHI, system friendly takeover & exit are all venues that should be explored, but I have very little time. Merge requests are welcome :-)
Happy hacking!

Amazing work!

Great work. Does it make binary identical executable files to the commercial version?

just GREAT!!

as 99% of game source code remains private or is lost...

They are not binary identical, so don’t assume existing patches will work.
I removed all the scattered copy protection stuff and had to do some arm twisting to get the Load Game menu to work.
But from observed behavior, it looks like they at least behave the same.
I used Ghidra on the executable that came with the WHDLoad slave for TKG(I wish they had released the resourced/disassembled version!) and compared a few key functions - they were the same.

The original source archives contains multiple copies of the source folder - all in a different state of disarray. The source_4000/hires.a main source file is the one that I had most success in compiling and running. I don’t know if that is 100% the released version of the game, but it seems very very close.

It is a great job you've done and I hope you continue to tinker with it. There are coders on this forum that have "retired" that might be pursuaded to come forward to give suggestions if you're continuing.

I used to like playing this game on my A4000 + Picasso IV using the RTG Master patch but it was very buggy and crashed a lot but it was soooo much faster than AGA so the occaisional crash was not enough to put me off using it.

looking at it quickly, there are still micro-optimizations that could be done, for instance here:

https://github.com/mheyer32/alienbre...ource/chunky.s

lsl #2,d2 => add d2,d2 (x2)

There are other examples. Maybe it could be even faster than it is.

@Alexh, you are actually the reason this release got this far :-D

I had shelved this project for years in a semi-compilable state, but I was always under the impression I need once specific file that was incbin'd into the source ("shadefile"), but missing from the source release. Now recently I followed a thread of yours where you were talking about how Ambermoon was completely resourced, disassembled and fixed up via Ghidra (btw, is this project open somewhere?). So I had the idea "maybe I can find that table and its size by disassembling the original executable and thus reconstruct the missing file?!" and started tinkering with Ghidra.
I slowly started matching up the source code with what I can see in Ghidra and eventually realized I don't even need this file - d'oh!

Older versions (I _think_ the ones based on the copper chunky rendering) may still need it.
Since the AB3D2 source release also contains the original AB3D source, it may be possible to get it to compile, too. It is missing quite a few media files, though (some vector objects).
I think that is what John Girvin did. I should probably take a look at his ab3d-rtg source first on how he achieved that.


This whole endeavor made me also play the game some more, in WinUAE, set to "fastest". Actually, when it plays fluently it is a good game and the lighting effects like "bullets lighting up walls and objects", "search lights on robots illuminating the environment" and the bumpmapping on the enemies start to shine (literally). Play it with headphones on and in a dark room and it becomes outright creepy.

But boy - the gameplay... It really shows that it got not much polishing. Repetitive non-sensical texturing, unfair enemy placement, being constantly short of ammo, nonsensical map layouts (that's supposed to be the insides of a spaceship??) really show more of "programmers art" than a game with an art direction.
Maybe one day people could create an "Alien Breed 3D II Remastered" were these issues are fixed...

I did not yet attempt to replace the C2P routine with a faster one (I read that the Kalms' ones are good/best?!) yet. From the source its evident that Andrew Clitheroe knew of and may have dabbled with multiple approaches. I do not know if the currently used routine is particularly good or bad...

It's here: https://github.com/Pyrdacor/Ambermoon

Ah, okay. I thought that https://github.com/Pyrdacor/Ambermoo...rseEngineering contained the source code, but I don't understand enough about it :)

Yes, the coder knows his stuff I'm not going to tell that he sucks because pulling a whole 3D game in asm is something, but in 2022 there are a lot of micro-optimizations that coders weren't aware of at the time

It's well established for instance that 2 add instructions are faster than one lsl #2 for instance.

My reasoning is: if the assembler doesn't optimize that (check the original disassembly to find out) and other stuff (non-PC relative addressing...), it means that if you optimize it manually + assemble with optimizations on + verbose to see what the assembler is actually optimizing, you may speed this up even more. Of course, always make sure that the code you're optimizing is actually called!! with breakpoints or just with "move.w #$F00,$DFF180" to create big flashes when the code is called. If the screen flashes all the time, you can bet that it's called a lot :)

On the other hand, I would not "replace the c2p routine by another one" because I'm pretty sure that inputs & outputs would need to be adapted. Non trivial task. Micro optimizations are trivial.

It's not because it's in assembly that it's fast. It can be made even faster with more work.

Had a look, and it doesn't look it would be that much effort to replace the C2P routines (assuming we're talking about ab3d2_source/chunky.s). All of the routines use more or less standard input/output formats. All of the routines read 8 chunky pixels and output 8 planar bytes at a time, so so extra parameter fiddling might be required (all optimized C2P expect to be able to output 32 pixels at a time).

NEWCHUNKY does a standard 1x1 c2p. DOUBWIDTHCHUNK does 2x1, but I think it uses the same buffer format as the 1x1 one (just doubling every other pixel), don't think this is what most 2x1's expect, but shouldn't be hard to adapt if you're OK with just doing a few unnecessary fast ram reads.

NEWCHUNKYTEL is a bit weird. It seems to use the table in "shimmerfile" as offsets into a chunky buffer before converting 8 pixels? Not sure what it's used for, and if it's critical for game speed that could take a bit more work. Looking at where CHUNKYTOPLANAR is called maybe it's only for transitions in which case it'd be easier to just leave it alone.

(Never played the game so I could be off :))

NEWCHUNKYTEL very likely implements the “teleporting shimmer effect” which in game looks like a distorted TV signal

Makes sense, guess it's fine if that's kept slow then. Just "found" the gamefiles and had quick go at using Kalms' C2P by replacing NEWCHUNKY with:
and miraculously it seems to work with very light testing. No idea if it'll actually work for all cases or whether it provides a speedup on a real amiga (haven't bothered testing on my 060), but in theory it should be quite a nice improvement (If you adapt it to the screen size).

I updated the source to use Kalm's 040/060 routine for the fullscreen C2P. Fullscreen also now drops the left and right borders.

Great work!

Something that would be really cool would be of it was possible to get the first AB3D to run in 1x1, but I suppose thats a lot for work. I felt that AB3DII was more of gfx demo than a game that was fun to play.

That said I still think its cool if you can improve the speed and other things of AB3DII too

There is something like that out there already,“AB3D-RTG”. I have the sources (kindly provided by the original Author) uploaded to my GitHub page, but did not dive into it yet.
One possible way to achieve this would be to render to a 16bit RTG screen and then just write/translate the chunky copper values from 12 to 16 bit.

That would be really awesome.

Cool stuff, thanks OP :)