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

[alexh]

I don't know what is possible with the WinUAE debugger and modern assemblers/compilers but I imagine it should be possible to a code profile, see what parts of the code the CPU spends most of the time during execution.

It would be good if you could "see" the cache performance, see if it is being used effectively or if the code is not cache optimised causing lots of misses and stalls etc.

This is obviously a tool that no-one "back in the day" would have had. Could benefit projects like this trying to wring out the last bit of performance.

I might be dreaming and non of this is available today but I thought it was.

[trixster]

Originally Posted by fryguy

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

Wouldn’t a 1x1 AB3D require higher resolution textures to make use of the 1x1?

[pipper]

I don’t know of any particular good profiling tools, especially with the system taken over.
I once watched a YT video on making modern demos on 060 Amigas where they wrote a CPU emulator to see the cache activity and optimize the code for it.
Right now I’m focusing on getting the 2x1 and 2x2 rendering modes working with Kalms routines. It looks like the way it works right now is to first render everything at full resolution (but skipping every second pixel column) and then the C2P function will fill the missing column in as copy of the previous column. This is obviously inefficient as we’re loading lots of empty data into the cache during C2P conversion.
The way the Kalms routines work is to take an actually smaller image and blow it up 2x1 during C2P.
This already works, but the rendering is off as if we’re only looking at the left half of the image. Need more debugging.

Once that is working I’m going to focus on removing the hardware banging stuff, so TKG can run on a regular screen, just like doom does. This will take some time…

AB3D should be able to profit from 1x1 even with an unchanged texture resolution for the walls, IF we also increase the render window size. Especially stuff at the distance will look more crisp.

[paraj]

Just in case you aren't aware Kalms has a whole family of C2P routines (and some of them do support modulo). The 2x1 format used in the game is a bit unusual (and non-optimal). If the C2P routines don't fit exactly they can be adapter with not too much work (at a slight performance cost).

Even without having looked at the rest of the code I'm willing to bet that the original spends most of it's time doing C2P (in particular chipram writes) on 030+. Might be interesting to make a modified build of WinUAE that uses the debug information in the executable to get a good profiling result (even if it isn't 100% accurate).

[Estrayk]

amazing !! I join the request for someone to implement a way to run it in RTG mode cleanly.

[pipper]

I do know that the Kalms repo has specialized routines for 2x1 and 2x2 and I'm trying to make use of them.
Unfortunately, just decreasing the renderbuffer size and not using the skip-odd-columns draw routine for 2x1 is not enough. Everything now looks warped and the textures start "swimming" :-( The maths in the texturing routine are apparently not flexible enough to just do what I did... need to dig some further tonight

[pipper]

This is taking longer than expected. I tried to decipher how wall rendering works, in particular I'm trying to find the code that relates the field of view with the width of the render buffer. But so far I have not been successful.
But some findings on the way:

• some old chunky-copper code and tables are still in there and can safely be removed.
• the fullscreen mode looks like an afterthought; it will even be punished in a few places with extra divs.l #3,x (to achieve a 2/3 scaling from 196 to 288 wide rendering) and other shenanigans. Because of this extending the FS mode to 320 causes slight texture swimming for the floors (floor rendering not 100% matching wall rendering).
• the double width mode is doing all the wall strip setup for a regular rendering, only to then throw away half of the setup work to skip every other column during rendering. I don't know if it does the skips when doing floors and 3d objects. It does not seem to do it to render 2D objects. So lots of work is still done and then just thrown away.
• the screen resolution seems to be inherently hardcoded with not only constants (that could be replaced), but also in other assumptions like table sizes for screen offsets and renderoffsets.
• the vertical wall srip/rendering setup is interesting. It first determines the width of a wall on screen, then chooses the closest power-of-two that encompasses the wall width. This determines the number of steps through the polygon (going left to right). It then loops forward (while forward-differencing the polygon attribs like texture coords and gouraud shading) until it hits the current left global clip, then it starts producing output strips until it hits the right clip edge.
  In theory this samples the source polygon more densely than needed and would produce strips on fractional pixel columns. But the routine is made such it would only output a new strip to render, once we hit a new integer column.
  As a sideeffect we get texture swimming for the wall strips as we will likely not sample the texture at perfect pixel centers.
  Maybe this can be reworked later - at the expense of more divs/muls when setting up the loop.
  I have not figured out how it does the projective foreshortening/prespective correction as the strips all use linearly interpolated coordinates/attributes. Maybe there's some polygon subdivision going on in the outer loop where the endpoints are correctly calculated and then just linearly interpolated inbetween (similar to what quake does). The "render quality" setting may be involved here.
• The 2x2 an 1x2 modes are implemented via line repetition coded into the copperlist. I have not replaced the C2P routine for these modes yet. But it looks like its possible the game is producing a _full height_(!!) image in fastmem and then chooses ton only C2P every other line. Will double check when I get to Xx2 modes.
• The interactive map rendering was hardcoded to clip against the 192x160 small window coordinates. I removed that such that the map now appears centered in fullscreen and can cover the whole screen.
  

[pipper]

Made some progress with the "double width" rendering.
I identified all places that do perspective projection and inserted code such that it achieves a half-width rendering in branch DOUBLEWIDTH_test.
(Since this is hardcoded right now, the regular rendering looks weird as its FoV is too wide now)

There are actually multiple rendering routines that each perform some form of projection work:
1) wall rendering
2) floor rendering
3) 2D billboard rendering, with and without bumpmapping
5) 2D glare billboards
6) 3D polygon rendering

Except for the floor rendering it seems to work.
Goal is to roll the "divide X by two" into the regular projection math and then remove the hardcoded stuff again along with the old, now unnecessary "DOUBLEWIDTH" routines. After that, tackle the "double height" rendering.

I think, playability of fullscreen-2x1 rendering should already have improved significantly on 030 based machines.

Some more insights gained:

• Walls and 2D sprites are stored in 32 colors (5bit per pixel). To not waste memory, 3 columns of pixel data are packed into one 16bit word each. During rendering of a vertical strip, a specific routine is used to unpack one of the 3 columns.
• There's one routine that does the transformation from worldspace to camera space (in the x-z plane, rotation around the Y axis) for either a subset of the level vertices or _all_(!) level vertices when the map rendering is turned on. This is done once a frame.
  Thus turning on the map rendering on a complex level can cost performance. This could be done better by limiting how far away from the player the map shows level outlines.
• The transformed points and their projected X coordinate are stored for later reference. Other code that needs to perform line clipping will produce more projected points on demand.
• 3D polygon rendering is separate as it deals with 3D points to project, not only 2D ones.
• 2D billboard rendering, floors and 3D objects where rendered at full resolution even with 2x1 rendering enabled
• There are object types that the engine supports (likely in a broken way), but are not used in the final game: glass objects and 'curves' as well as translucent walls.

Currently, the executable will run on real machines, but for some reason the load/game menu is broken and just hangs. The music and sound playback is also broken... don't know what's going on there; in emulation it works. I guess I'll get back to that when starting to work on system friendliness.

[vulture]

@pipper

that's all very interesting!

[khph_re]

This is fascinating, I remember when the code was released I expected a wave of new games/levels but nothing really happened.

Perhaps this will finally be a useful engine for people to base new projects on.

Dread on the low end, and AB3DII for those with a bit more grunt.

Well, we can dream!

[abu_the_monkey]

@pipper

Just compiled it with Devpac and OMG! it works! (for the most part) a few objects not being rendered (wepons and some glow/lighting effects) and can crash randomly (probably what the compiler complained about during the build,
haven't checked) but, yeah, AMAZEBALLS!!!

the best I found before giving up was a compileable, but, very broken source of the 2mb version.

again, just AMAZING

[pipper]

I am still in the process of reverse engineering and documenting the floor rendering - arguably the most involved part of all rendering.
I’m having a hard time reverse engineering the maths involved and figuring out what it all means. But I’m getting close.
I’m hoping to be able to remove all the duplicated code dealing with double width and double height rendering to unify these code paths.

Btw, is there any known assembler that would perform more advanced optimizations, for instance reordering independent instructions for better pipelining (in particular for 060 dual issue instructions)?

[abu_the_monkey]

I recompiled with Devpac again this evening and the log was as follows,

GenAm Macro Assembler Copyright © HiSoft 1985-1997
All Rights Reserved - version 3.18

Assembling AB3:ab3d2_source/hires.s
Pass 1
Pass 2
Error: linker format restriction at line 2781 in file OBJDRAWHIRES.S
2781 01.0002EFBC 323A0002 move.w Left(pc),d1
Error: linker format restriction at line 2782 in file OBJDRAWHIRES.S
2782 01.0002EFC0 3E3A0004 move.w Right(pc),d7
Error: linker format restriction at line 3593 in file OBJDRAWHIRES.S
3593 01.00030596 B87A0004 cmp.w Right(pc),d4
Error: linker format restriction at line 3618 in file OBJDRAWHIRES.S
3618 01.000305EA BC7A0002 cmp.w Left(pc),d6
Error: linker format restriction at line 3669 in file OBJDRAWHIRES.S
3669 01.00030642 987A0000 sub.w offleftby(pc),d4
Error: linker format restriction at line 3672 in file OBJDRAWHIRES.S
3672 01.0003064A 4A7A0000 tst.w offleftby(pc)
Error: linker format restriction at line 3675 in file OBJDRAWHIRES.S
3675 01.00030652 383A0000 move.w offleftby(pc),d4
Error: linker format restriction at line 3716 in file OBJDRAWHIRES.S
3716 01.000306AC B87A0004 cmp.w Right(pc),d4
Error: linker format restriction at line 3741 in file OBJDRAWHIRES.S
3741 01.00030700 BC7A0002 cmp.w Left(pc),d6
Error: linker format restriction at line 3791 in file OBJDRAWHIRES.S
3791 01.00030758 987A0000 sub.w offleftby(pc),d4
Error: linker format restriction at line 3794 in file OBJDRAWHIRES.S
3794 01.0003075E 4A7A0000 tst.w offleftby(pc)
Error: linker format restriction at line 3797 in file OBJDRAWHIRES.S
3797 01.00030766 383A0000 move.w offleftby(pc),d4
Error: linker format restriction at line 3863 in file OBJDRAWHIRES.S
3863 01.000307F0 B87A0004 cmp.w Right(pc),d4
Error: linker format restriction at line 3888 in file OBJDRAWHIRES.S
3888 01.00030844 BC7A0002 cmp.w Left(pc),d6
Error: linker format restriction at line 3948 in file OBJDRAWHIRES.S
3948 01.000308B2 987A0000 sub.w offleftby(pc),d4
Error: linker format restriction at line 3951 in file OBJDRAWHIRES.S
3951 01.000308BA 4A7A0000 tst.w offleftby(pc)
Error: linker format restriction at line 3954 in file OBJDRAWHIRES.S
3954 01.000308C2 383A0000 move.w offleftby(pc),d4
Error: linker format restriction at line 3999 in file OBJDRAWHIRES.S
3999 01.00030926 B87A0004 cmp.w Right(pc),d4
Error: linker format restriction at line 4024 in file OBJDRAWHIRES.S
4024 01.0003097A BC7A0002 cmp.w Left(pc),d6
Error: linker format restriction at line 4084 in file OBJDRAWHIRES.S
4084 01.000309E8 987A0000 sub.w offleftby(pc),d4
Error: linker format restriction at line 4087 in file OBJDRAWHIRES.S
4087 01.000309EE 4A7A0000 tst.w offleftby(pc)
Error: linker format restriction at line 4090 in file OBJDRAWHIRES.S
4090 01.000309F6 383A0000 move.w offleftby(pc),d4
Error: undefined symbol at line 83 in file PLR1CONTROL.S
83 03.000001F4 0839000E00BFE007 btst #CIAB_GAMEPORT0,$bfe001+ciapra ; left button
Error: undefined symbol at line 314 in file MENU/MENUNB.S
314 03.0000F674 33FC000F00DFF096 move.w #DMAF_BLITHOG!DMAF_MASTER!DMAF_RASTER!DMAF_COPPER!DMAF_BLITTER!DMAF_SPRITE,$dff096 ; disable DMA
Error: undefined symbol at line 319 in file MENU/MENUNB.S
319 03.0000F696 33FC000F00DFF096 move.w #DMAF_BLITHOG!DMAF_MASTER!DMAF_RASTER!DMAF_COPPER!DMAF_BLITTER!DMAF_SPRITE,$dff096 ; disable DMA
Error: undefined symbol at line 320 in file MENU/MENUNB.S
320 03.0000F69E 33FC000F00DFF096 move.w #DMAF_SETCLR!DMAF_BLITHOG!DMAF_MASTER!DMAF_RASTER!DMAF_COPPER!DMAF_BLITTER!DMAF_SPRITE,$dff096 ; enable DMA
Error: undefined symbol at line 722 in file MENU/MENUNB.S
722 03.0000FB8C 3D7C000F0096 move.w #DMAF_SETCLR!DMAF_MASTER!DMAF_BLITTER,$96(a6) ; Enable blitter dma

27 errors found
71670 lines assembled into 781960 bytes, Amiga executable relocatable code
2159653 bytes used, took 0.426091 seconds

after removing the (pc) from the errors from the linker for OBJDRAWHIRES.S the random crashing seems to have stopped and all objects are rendered correctly (at least in winuae).
the remaining 'undefined symbol' errors I did not check but they didn't stop it working.

[pipper]

As you probably know, I'm cross-compiling things with vasm/vlink on Linux. I don't get these warnings. Its possible that these pc-relative lines create 32bit offsets that your linker can't deal with (though 32bits offsets kind of defeat the performance purpose of pc-relative addressing)

The undefined symbols look like they require the inclusion of dmabits.i, included via system.i. Did you setup your assembler's include directories accordingly?

[phx]

Originally Posted by pipper

Its possible that these pc-relative lines create 32bit offsets that your linker can't deal with

Correct. Looks like

Left

and

Right

are defined in a different section. vasm accepts that and defers the problem to the linker. There are file formats which support such a type of reference. Amiga hunk format only via 68020+/OS3.0+ RELRELOC32.

[abu_the_monkey]

thanks for the info guys

@pipper Devpac was using its own system.gs now sorted and builds fine

the only issue I can find so far is when completing a level the screen warping effect is wrong and trashes the border when starting the next level and also applies to teleports. see attached screenshots.

I moved offleftby:,Left: & Right: from the bss section near the end to directly before doapoly: in objdrawhighres.s and put back the pc relative calls. It builds without warnings/errors and seems to run fine except the warping effect mentioned above.

[pipper]

Yes the teleport effect is broken atm. It is not properly setup and still using the old C2P routine. I didn’t fix it yet because it wasn’t important enough and I wanted to figure out the DOUBLEWIDTH/DOUBLEHEIGHT stuff first.

[pipper]

[ Show youtube player ]

With this explanation, many things make more sense looking at the floor drawing.

[khph_re]

That was really informative. I missed the whole dev cycle of 2.5D, everything was GPU freeform poylgon driven by the time I got into things (from an art side
rsather than code).

[abu_the_monkey]

Originally Posted by pipper

Yes the teleport effect is broken atm. It is not properly setup and still using the old C2P routine. I didn’t fix it yet because it wasn’t important enough and I wanted to figure out the DOUBLEWIDTH/DOUBLEHEIGHT stuff first.

indeed functionality over aesthetics is much more important, I eagerly await your next update.
you must have a brain the size of the planet or the patience of a saint to go through the code and understand it