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

[pipper]

https://www.linkedin.com/in/andy-clitheroe-97525392

That should be him. I wonder if he would like to come back to his opus magnum and fix it up the way it was meant to be :-)

https://fb.watch/fePUStM2iB/

[Angus]

Way back then, I persuaded him to write a review for the Amiga Games Database:

http://agdb.abime.net/AGDB.html


http://agdb.abime.net/DBA1/Exile.html

[Jacques]

I gave a try the AB3DII_fresh from the Zone and it's working fine on my Warp1260-equipped A1200. That said, it's OK when I run it by AB3DII-TKG script, using "hires"-icon directly causes black screen (assigns are made, of course) - I guess that's to be expected?

From what I can see the in-game F-keys don't display mode-changes texts - there aren't any? And what is the actual hi-res in the game, now?
The performance is way better than original for sure, thanks for the effort and eagerly waiting for more!

[Karlos]

The level intro texts and messages at the bottom of the screen require a 640 wide mode. Part of the work that has been done is to remove the dependency on hacks and to make it more system friendly. Reintroducing them is a lower priority.

The "hires" binary is the build target, it's just named after the main source file.

[pipper]

Correct, the level introduction text screen, the final winning screen and the bottom status text were disabled when moving to system friendly screen setup. Also missing: the red palette fade when being hit.
The level text is just a two (or four color) screen.
The status screen was done by switching to a two color screen via the copper. It used hardware scrolling to scroll the text. Not sure if it’s worthwhile to try get that working again if the goal is to run the whole thing on RTG later. Not saying the status text will stay disabled, but I guess it won’t smoothly scroll in future :-)

[Karlos]

I've been looking at some of the rendering code and I'm thinking an assumption I held may not be true. I've not finished yet, so it remains to be seen.

I was under the impression that the game engine actually does RGB pixel calculation that then goes back to a lookup table that maps RGB back to the closest palette entry (assuming that the RGB were say 15 bit, this would be a 32K table). The assumption comes from the fact that the engine is an evolution of the AB3D1 engine which does render RGB.

Now I suspect that what it could be doing instead is having a lookup table of input colour palette index and brightness and an output palette index for the colour that most closely matches the input colour at the target brightness. Pretty much all of the lighting effects in the game are based just in brightness alone. This wouldn't require any explicit RGB processing at any step. Having said that, the game also uses an additive transparency effect but there are probably non RGB ways of figuring that out too.

If the first hunch is correct though, then in theory, the palette/brightness table could be replaced with one that has actual RGB values rather than closest palette index entries and therefore RGB modes o RTG may still be doable.

[Karlos]

Just a note, utri007 on amiga.org reports that the executable runs fine on his Warp 1260 machine but not on a Blizzard 1260. Damn, be has two 060 powered A1200's the jammy git.

I've asked what other differences there are in the two.

[abu_the_monkey]

just a brain fart.
its not some odd vbr thing causing issues on start up is it?
wouldn't have thought so but you never know.
or maybe the blizzard sets up the caches, mmu, etc different?

[Karlos]

Not sure but my guess is something tries to access an address in the range 0x10000000 and 0x10ffffff. It could be a smaller range than this, but 16MB is the smallest chunk of "32-bit chip ram" that I can allocate on UAE and it's mapped to that range

Some accelerator boards may map their memory in that region and as such won't have a bus fault accessing, even if it's very naughty.

[Angus]

A lot of people with 060's have patches in their startup like Blizzkick, Fastexec, MuFastRom etc. etc. Might the program be tripping up over one of those?

[pipper]

Correct, the brightness calculations are all done via table lookup.
Not sure if it helped to lookup 16/24bit color values instead, as the input palette is already rather restricted, but I see what you're getting at: the brightness-adjusted color values then could the actual ones instead of being mapped into the palette again.

One thing I ran into in the 90's is that the game palette is fixed... one cannot change the entire palette for a mod. But we could make that happen.

WRT Warp vs Blizzard: do both machines run the same kickstart? Does he run Blizkick with some other modules on the Blizzard equipped machine?

One other difference is that the Blizzard allows for hardware kickstart remapping (without employing the MMU)... maybe that plays a role.

The VBR should not be touched, the only place I didn't look close at for interrupt handling is the music playback routine... that one could try to patch the ISR vector without looking at the VBR... but then again, this should have showed up in the 90's already. I wish we had the source for the various patches (and in particular the WHDLoad slave) to know what/how they fixed things in the past.

@Karlos: have you tried running a "regular" setup, but with a kickstart > 3.1? Would that work?

[Karlos]

Originally Posted by pipper

@Karlos: have you tried running a "regular" setup, but with a kickstart > 3.1? Would that work?

I can try that at some point

[Havie]

Tried the'Fresh' build from the Zone on my V1200 and it just locks up when the shell window opens. Is there something else I need to do first (I assume that all the files needed are included in the zip?).

[Angus]

Originally Posted by Havie

Tried the'Fresh' build from the Zone on my V1200 and it just locks up when the shell window opens. Is there something else I need to do first (I assume that all the files needed are included in the zip?).

I've not tried it yet but my assumption was you launched the exe in a pre-existing installation?

[Karlos]

Originally Posted by Angus

I've not tried it yet but my assumption was you launched the exe in a pre-existing installation?

Yes, you need to put it into an existing game installation. Also, it probably needs more stack than the default.

[Karlos]

https://forum.amiga.org/index.php?to...5503#msg855503

As anticipated, the warp 1260 maps it's fast memory in the same address window where UAE maps it's "32-bit chip" memory, whereas the Blizzard puts it somewhere else. Hence the code runs on the Warp1260 where the illegal memory access doesn't result in a bus error

[Karlos]

@pipper

Given how vexing the illegal memory access is proving to debug, what are your thoughts on implementing the basic screen/window allocation/management in standalone C code that can be properly implemented in isolation and just having it expose assembler friendly entry points to call from the main code?

Implementing these routines in C also makes it easier to work towards RTG, IMHO. I've certainly way more experience of doing RTG compatible code in C, at least.

[Angus]

Just to add, I tried to run the program on my Blizz 1260 AGA machine, when I ran it on Hires, all went black and stayed that way. When I tried the standard(?) exe I got nessages saying that Hires wasn't executable, then the same for segtracker, then for vbrmove.....

For installation I basically copied the contents of the data directory from the WHDLoad install into a new directory AB3D2_Run - then copied the contents of the Fresh archive over that.

[pipper]

Originally Posted by Karlos

@pipper

Given how vexing the illegal memory access is proving to debug, what are your thoughts on implementing the basic screen/window allocation/management in standalone C code that can be properly implemented in isolation and just having it expose assembler friendly entry points to call from the main code?

Implementing these routines in C also makes it easier to work towards RTG, IMHO. I've certainly way more experience of doing RTG compatible code in C, at least.

It’s certainly possible and not too hard. Bebbo’s toolchain produces hunk object files all throughout, thus linking C object files and the assembly ones into one should be covered. His GCC also supports passing parameters in specific registers (beware to not use a5 and avoid a4). Example code mixing C and assembly can be found in DoomAttack and ADoom (both also hosted on my GitHub).
But I’m having a hard time believing that the little bit of screen setup is to blame. It’s such simple code, just a few calls into the OS. But something is surely upsetting the OS…

[Karlos]

Originally Posted by pipper

But I’m having a hard time believing that the little bit of screen setup is to blame. It’s such simple code, just a few calls into the OS. But something is surely upsetting the OS…

I am thinking something like an improperly initialised structure that perhaps in C code has the benefit of having some sort of zero initialisation generated by the compiler... *shrugs*