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

[Karlos]

Originally Posted by grond

Storing row pixels together only makes sense with mip-mapping where the probability is high that the next texel will be one of the two subsequent ones. Storing rows in one set implies shifting and masking which wastes precious clock cycles per pixel.

The current implementation is clearly a memory saving device. The inner loops of wall and bitmap drawing render vertical pixel strips that read successive words of the texture using one of three custom sets of code depending on which packed 5-bit texel is needed.

The code would be a lot simpler if this was dispensed with and we just used 1 byte per pixel and allow walls to use the whole palette.

To gain performance with large textures at a distance, we need mip mapping. However, due to the way the columnar rendering works, you'll only get a performance increase by using vertically halved MIP maps. Horizontal reduction doesn't help performance as much but it could definitely improve visual quality as you would reduce moiré and aliasing artefacts. However due to the palette based rendering you would likely want to precompute all mip maps to ensure they are good.

One thing I really like the idea of is computing the shade table without mapping back to the palette and just having RGB values that can be rendered to an RTG display. There are 21 brightness levels, 256 basic colours, allowing for over 5000 colours. Direct render to RGB16 is probably within reach of 040/060.

[Karlos]

@pipper

Regarding C, I was thinking about coming at the problem from the opposite direction. For example, writing a self contained C module for video. This could assume the responsibility for opening the screen, flipping buffers and transferring the fast buffer to the display. It could also collect idcmp events and all that stuff, in theory, but the main impetus is for a clean room reimplementation of the display logic so that RTG can be fitted easily.

From the assembler side it would have very simple call hooks that work the same whether you are on an AGA/C2P screen or an 8-bit RTG one.

Something similar could be done for audio, allowing AHI and proper audio mixing perhaps.

[vroom6sri]

Is there a new engine file and/or level designs to test? I’ve got some spare time for a change!

[Jacques]

Originally Posted by abu_the_monkey

a .lha of the latest build from main

includes both a dev and release version, and a readme.

Thanks! Would it be possible to add a description of new keyboard functions to the future readme files, please?

[Karlos]

Originally Posted by vroom6sri

Is there a new engine file and/or level designs to test? I’ve got some spare time for a change!

The level reworking is an ongoing thing in a branch. I'm only halfway through getting rid of a pair of wall textures that I wanted to free up.

[amipal]

Originally Posted by vroom6sri

Is there a new engine file and/or level designs to test? I’ve got some spare time for a change!

See post https://eab.abime.net/showpost.php?p...postcount=2449

[abu_the_monkey]

Originally Posted by amipal

See post https://eab.abime.net/showpost.php?p...postcount=2449

and here for a (wip) reimagined version of TKG by Karlos

https://github.com/0xABADCAFE/karlos-tkg/tree/main

and the thread for it here

https://eab.abime.net/showthread.php?t=111637

[Karlos]

I've been having a look at the wall rendering code again, trying to make a bit more sense about a few things. I can't be sure just yet, but I think the lack of dithering on Gouraud shaded walls might be an unintentional defect and not as I initially assumed a performance trade off. If that's true, then fixing it could result in some overall improvement to the render quality, especially where complex lighting arrangements are in effect.

[pipper]

I made some progress with the C migration stuff. PoC is here
https://github.com/mheyer32/alienbre...e/migrate_to_c
(moving the screen allocation to C)

[Karlos]

Originally Posted by pipper

I made some progress with the C migration stuff. PoC is here
https://github.com/mheyer32/alienbre...e/migrate_to_c
(moving the screen allocation to C)

Looking good! Any unintended side effects or issues?

There are a bunch of already refactored functions for system setu and IO that could be moved to C too.

[Karlos]

It goes without saying that moving the display setup to C should simplify RTG support

[pipper]

I didn’t observe any negative consequences. But I didn’t do a lot of testing either.
Making it so that assembly calls into C function is easy. The other way around we need to be more careful (in ab3d functions generally don’t care much about saving and restoring registers)But maybe some inline assembly to declare “all registers clobbered” will be enough to make the compiler save registers before calling into assembly. We’ll see. I’ll try to pull more stuff over in the next few days.

[Karlos]

Yeah It's even worse than not saving and restoring registers, there are quasi-global registers that contain values that span across multiple calls. Once or twice I've observed that the traditionally volatile registers need to be preserved too.

[daver]

Amazing work ! want to test it on my a4000 with 3660 @ 50mhz, witch files do i need and how do i install it ?

[Karlos]

Originally Posted by daver

Amazing work ! want to test it on my a4000 with 3660 @ 50mhz, witch files do i need and how do i install it ?

If you have the original game, you just need the replacement engine files from here https://eab.abime.net/showpost.php?p...postcount=2449

[Karlos]

I've not really done much engine work lately. I've been leveraging the last few bugfixes to tart up my mod a bit

[daver]

no sorry i have the whdload only. always wonder why it never was ported to ppc but your work have made it playable on 68ks

[Karlos]

Originally Posted by daver

no sorry i have the whdload only. always wonder why it never was ported to ppc but your work have made it playable on 68ks

It was never ported to PPC because it was entirely written in 68K assembler. Except for the editor tools, which were written in AMOS.

However, porting the display and audio components to C, on their own, would pretty much allow for an RTG/AHI version that would run on PPC under emulation.

[ZyBeR]

How much, if any negative impact on performance can we expect porting the code to C would have? I would guess todays compilers generate more optimized binaries compared with what was available when this game originally was developed.

From my understanding by just following the discussions here the original assembly code have room for optimization. If we just play with the thought and compare that with a highly optimized C version, compiled with the tools available back then, how much did they gain by using assembly?

[pipper]

The goal is should be to not compromise on speed. Karlos invested lot of time in shaving off cycles - these efforts will not be wasted. At first I’d like to mostly to replace higher level functions like screen setup, system setup etc which are often on-offs. I imagine moving up the outer most game loop to C would also work. The innermost renderloops will very likely stay assembly.
Having the C environment available allows for easier prototyping and testing. I don’t know if anyone has really appetite to move everything to C. But if you did, the game could then also be ported to other platforms… but let’s focus on RTG first.