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

[Karlos]

Has anyone found a misplaced motivation lying around anywhere? I seem to have misplaced mine :/

[abu_the_monkey]

Originally Posted by Karlos

Has anyone found a misplaced motivation lying around anywhere? I seem to have misplaced mine :/

back from the lakes early due to the weather, not feeling super enthusiastic about anything having been drenched every day till the wife couldn't continue on the hike.

@Karlos
Its ok to take a break from it for a bit chap. I am sure your motivation will return, remember this is not work, its for fun

[grond]

Originally Posted by Karlos

Has anyone found a misplaced motivation lying around anywhere? I seem to have misplaced mine :/

You've done so much work already and there are no obligations. Look back on all the amazing improvements you have done. You managed to fix so many bugs and to make this game enjoyable on much lower-specced machines than the original was. What is left do be done anyway? I believe you are almost done with the level reworks, right? The low-level optimisations of the asm code have already achieved great improvements. Of course, it's the very nature of optimisation to never really come to an end unless you decide the diminishing returns aren't worth it any more. The biggest subproject seems to be the RTG/os-friendly branch. That would certainly be something that needs an extra amount of motivation to tackle but it's such a big task that putting it off for a few weeks doesn't really change much.

[Karlos]

So the main issue has been mostly external in nature. Lots of other problems to deal with leaving me flat as a fart by the end of each day.

In terms of what's left, well I did have a list of things that should be easier now that there's C interoperability. Let's see:

Reintroduce in-game messaging (on screen, proportional font) and level introduction texts. That was part done already.

Add support for a mod properties file. This will allows the mod to set limits on ammo and health counts and allow other engine parameters to be tweaked that are otherwise fixed, e.g. audio sample rate (I wanted to try 16kHz samples).

Add support for floor texture set per level override. This should be pretty easy, you load the data if the file exists in the level directory and fall back to the global set if it doesn't. It should be possible to do the same thing for the model textures too, if you have some unique models / bosses in a specific level.

Add sound slot variations. The game has a fixed limit of 64 sample slots, so, to remain backwards compatible, we could add support for "bank variation" on these, that are selected at random (perhaps with some probability, defined in the mod properties) at runtime.

Allow for taller wall textures. The current limit is 128, so anything taller repeats vertically. Given how large vertical differences can be, it might be nice to support at least 256.

Then there are more ambitious ideas:

Redo the wall texturing and sprite texturing, getting rid of the 32 colour limitations. This made sense for working well within 4MB, but the texture memory footprint increases going to 256 colours is only 50%. It would allow for simplified inner loops too.

Mip mapping. This probably only needs to be applied vertically, given the columnar nature of the rendering. This might improve performance on distant large walls, but even if not, could at least improve the rendition.

RGB framebuffer for RTG. The game does a lot of shading, that has to map brightness variations of palette colours back to the nearest colour in the palette. Instead, a lookup can be computed, potentially factoring in brightness/gamma settings (whenever these are changed) that returns the appropriate RGB value ready to roll.

[Karlos]

As for the mod itself, there are still a lot of levels that need reworking or even replacing. There's also pacing and enemy introduction to think about.

[trixster]

Sorry to ask what has probably been asked countless times before, but where can an 020 executable be downloaded from to give this a try? I’ve recently downgraded my 1200 from 060 to 28mhz 020 (like I had in the 90s) and I’m keen to try an optimised AB3DII

[abu_the_monkey]

Originally Posted by trixster

Sorry to ask what has probably been asked countless times before, but where can an 020 executable be downloaded from to give this a try? I’ve recently downgraded my 1200 from 060 to 28mhz 020 (like I had in the 90s) and I’m keen to try an optimised AB3DII

the executable from KarlosTKG
https://github.com/0xABADCAFE/karlos-tkg
should be 020 friendly, unless things have changed while I was away?
I think it has options for 060 optimised code but starts in a generic mode.

[Karlos]

There are numerous 060 optimisations but nothing dependent on 060 to run. Would recommend 2/3 screenmode, maybe 1*2 pixel mode. You can also enable simplified lighting for an extra boost.

[trixster]

Thanks!

[Dunny]

Biggest thing for me right now would be mouse invert. Just cannot get on with it being the wrong way around

[Karlos]

Originally Posted by Dunny

Biggest thing for me right now would be mouse invert. Just cannot get on with it being the wrong way around

Turn your mouse the wrong way around and use the opposite hand. Problem solved!

[abu_the_monkey]

in the asm version a bitwise NOT on the data read from the mouse port worked to invert the mouse look

Sys_ReadMouse:
				move.l	#$dff000,a6
				clr.l	d0
				clr.l	d1
				move.w	$a(a6),d0
				tst.b	invertMouse
				beq.s	.notInverted
				not.w	d0;to invert mouse look
.notInverted
				lsr.w	#8,d0
				ext.l	d0
				move.w	d0,d3

tried the same in the C version which worked but it causes the screen to 'roll' through when the bottom of the screen is hit (or I am missing something)

void Sys_ReadMouse()
{
    static WORD oldMouseY;
    WORD diffY = ~joy0dat >> 8;
    diffY -= oldMouseY;
    if (diffY >= 127)
        diffY -= 255;
    else if (diffY < -127)
        diffY += 255;
    // Emulate weird add.b stuff in original code
    oldMouseY = (oldMouseY & 0xff00) | ((diffY+oldMouseY) & 0xff);
    Sys_MouseY += diffY;

[Karlos]

It'll be exactly the same class of issue the original C code had with vertical wrapping. What's the implicit type of joy0dat in the first place? (AFK until later today, cant look yet). It might need some parentheses to work around precedence if we are expecting a signed 16 bit result for diffY

[abu_the_monkey]

Originally Posted by Karlos

It'll be exactly the same class of issue the original C code had with vertical wrapping. What's the implicit type of joy0dat in the first place? (AFK until later today, cant look yet). It might need some parentheses to work around precedence if we are expecting a signed 16 bit result for diffY

Yes, for sure the same issue as the original C code, but, as it is moving to a more os friendly way of doing things maybe reading the hardware directly is not the right way to do this?

[Karlos]

Originally Posted by abu_the_monkey

Yes, for sure the same issue as the original C code, but, as it is moving to a more os friendly way of doing things maybe reading the hardware directly is not the right way to do this?

For sure. At some point we'll probably want to move to IDCMP message processing. However, there is something to be said for the current approach, especially as regards input latency.

[abu_the_monkey]

Originally Posted by Karlos

For sure. At some point we'll probably want to move to IDCMP message processing. However, there is something to be said for the current approach, especially as regards input latency.

that was going to be my next question, how much latency would using interrupts and the input.device introduce?

[abu_the_monkey]

@trixster

please let us know how it performs on your system.

the 28mhz 020 that is

[Karlos]

Originally Posted by abu_the_monkey

that was going to be my next question, how much latency would using interrupts and the input.device introduce?

I'm not sure. I was thinking about the latency of IDCMP. The current solution is very predictable which is a good thing

[amipal]

Originally Posted by abu_the_monkey

@trixster

please let us know how it performs on your system.

the 28mhz 020 that is

I'd be interest to know too. We've got some good stats on '030 and '060 systems.

[grond]

Originally Posted by Karlos

For sure. At some point we'll probably want to move to IDCMP message processing. However, there is something to be said for the current approach, especially as regards input latency.

I'd recommend going through lowlevel.library. That's certainly going to be quicker and was designed for this exact purpose.