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

[grond]

All very true.

[grond]

It would be easy to allocate something like a MB of RAM for a binary log. Then every 50 VBlanks write the number of screenbuffer updates into the binary log and reset the screenbuffer update counter. This would be one byte per second. At the end before quitting, print out all bytes as FPS. This should be safe and relatively easy to implement.

[Karlos]

Originally Posted by grond

It would be easy to allocate something like a MB of RAM for a binary log. Then every 50 VBlanks write the number of screenbuffer updates into the binary log and reset the screenbuffer update counter. This would be one byte per second. At the end before quitting, print out all bytes as FPS. This should be safe and relatively easy to implement.

That's definitely how I'd think about doing it, via a buffer.

[Karlos]

Although I told myself I wouldn't, I have more changes to push. The urge to commit integer dividicide is a strong one.

[grond]

We could even use BFSET each VBlank to set a bit if the screenbuffer was updated since the preceding VBlank. Then we'd end up with a buffer with 50 bits per second size which would still mean well handable buffer sizes for long test playing. The average FPS could then be calculated and printed with any desired accuracy as a function of time.

[Karlos]

Originally Posted by grond

We could even use BFSET each VBlank to set a bit if the screenbuffer was updated since the preceding VBlank. Then we'd end up with a buffer with 50 bits per second size which would still mean well handable buffer sizes for long test playing. The average FPS could then be calculated and printed with any desired accuracy as a function of time.

I don't think we'd need to go that far

On a different note, once all bss-able globals are extracted I plan to try some automated code analysis to find reference that are commonly made together (within a short instruction distance) and see if they can be packed together into cache lines. Of course I also need to write that automation, lol

[AlphaAmiga]

Do you believe that their is still some room for frame rate improvements, or do you think its as fast as it will get on classic hardware?

[Karlos]

Originally Posted by AlphaAmiga

Do you believe that their is still some room for frame rate improvements, or do you think its as fast as it will get on classic hardware?

Personally I think there's scope, especially on RTG. With updated tooling we could probably get rid of the 32-colour asset limitations which in turn would allow for simpler drawing code. Right now the game uses 32 colour wall and sprite textures which seems primarily to be a memory saving exercise but it does mean texture sampling requires three different routines depending on which bitfield in a 16 bit word contains your data.

Ultimately the best option is to port or reimplement in C, with knowledge gleaned from the current version. A C version can be compiled for faster hardware and could make use of different rendering techniques.

[AlphaAmiga]

Originally Posted by Karlos

Personally I think there's scope, especially on RTG. With updated tooling we could probably get rid of the 32-colour asset limitations which in turn would allow for simpler drawing code. Right now the game uses 32 colour wall and sprite textures which seems primarily to be a memory saving exercise but it does mean texture sampling requires three different routines depending on which bitfield in a 16 bit word contains your data.

Ultimately the best option is to port or reimplement in C, with knowledge gleaned from the current version. A C version can be compiled for faster hardware and could make use of different rendering techniques.

That sounds great.

The work that is being doing on this game is amazing, as a big fan of the game (& AB3D 1) I cant wait to see where these improvements take it.

A couple of other things I would like to see (if possible - besides a "frame rate" tester/recording option) are;

The particle effect around the text in the main menu being toned down, its a nice effect but to me its a little too overused!

Is it possible to have a "Graphics Settings" option added to main menu where the pixel mode and the screen size can be adjusted before going into a game? With maybe suggested pre-sets based on Hardware?


Also Karlos, are you the person posting youtube vids of retextured levels & diff audio? They look & sounds so much better than the originals.

[paraj]

For the FPS measurements, I'd recommend going for consistency above all if you're going to be making optimization decisions based on the results. Something like "timedemo" in quake is great since you get a good blend of different orientations/sitatuions into the mix, but it's probably too noisy (and takes too long) if you're trying to optimize e.g. wall rendering. Of course general support for recording/playing back demos would be awesome, but might be too much work (and I don't know if the engine is deterministic enough).

Something I've used in other cases is to just hardcode a few representative view orientations, sample framerate for a while (say 1 second), and then switch to the next one. Enemies etc. can make that hard, but you can probably get a good idea just from a few quiet spots in the first level.

Once you have a decent baseline benchmark you can try to disable different parts of the game (e.g. water rendering, updating enemies or whatever) and see how much faster it gets - this should provide easy insight into where it's worth spending time optimizing. Moving commonly used variables together sounds like a good idea, but it sounds like a lot of work, and I doubt it will give much performance compared to the work involved (but looking forward to hearing the results!). I conjecture (based purely based on speculation) that any significant benefit will come from somehow avoiding work and optimizing a few key functions.

Just some thoughts

[Karlos]

Originally Posted by AlphaAmiga

Also Karlos, are you the person posting youtube vids of retextured levels & diff audio? They look & sounds so much better than the originals.

Assuming you are referring to 0xABADCAFE, then yes. It's a mod I initially started back in 1996/1997 whenever it was the source was released. With the renewed interest in the game I hunted through some old backups and found it. Or some iteration of it. Now it's on GitHub so that I can pick up where I left off. Having an improved engine helps a lot.

[pipper]

Originally Posted by Karlos

Personally I think there's scope, especially on RTG. With updated tooling we could probably get rid of the 32-colour asset limitations which in turn would allow for simpler drawing code. Right now the game uses 32 colour wall and sprite textures which seems primarily to be a memory saving exercise but it does mean texture sampling requires three different routines depending on which bitfield in a 16 bit word contains your data.

Ultimately the best option is to port or reimplement in C, with knowledge gleaned from the current version. A C version can be compiled for faster hardware and could make use of different rendering techniques.

I have been thinking about how to go about porting to C. It would allow easier development and debugging. Time critical routines can be left in assembly.
The way I would approach this is to work outside-in. We would create a new C executable next to the current assembly code. We start with a new main that just calls into the assembly’s main. Then we port the game’s outermost loop and screen handling, opening of system
Libraries etc.. To make the assembly accessible to C and vice versa we’d need to start export symbols from Asm via xdef/xref (and potentially introduce underscore prefixed names) This will be a pain. But I think we should be able to slowly grow the C side while keeping the assembly executable fully compilable. Karlos’ work on restructuring of the source should help with all of this.

[Karlos]

@paraj

Moving commonly used variables together sounds like a good idea, but it sounds like a lot of work,

Not as much as it sounds. I've been raking through the code and extracting many scattergunned variables into new bss files where I can rearrange and realign them quite readily. It's only the analysis step that would take time.

That said I don't expect major gains from it but making the data more structured rather than a massive list of arbitrary globals is better for moving to C.

[Karlos]

Originally Posted by pipper

I have been thinking about how to go about porting to C. It would allow easier development and debugging. Time critical routines can be left in assembly.
The way I would approach this is to work outside-in. We would create a new C executable next to the current assembly code. We start with a new main that just calls into the assembly’s main. Then we port the game’s outermost loop and screen handling, opening of system
Libraries etc.. To make the assembly accessible to C and vice versa we’d need to start export symbols from Asm via xdef/xref (and potentially introduce underscore prefixed names) This will be a pain. But I think we should be able to slowly grow the C side while keeping the assembly executable fully compilable. Karlos’ work on restructuring of the source should help with all of this.

I think moving all the resource management to C would be an early low hanging fruit that would make life a lot easier, especially moving to RTG, etc.

[abu_the_monkey]

regarding repeatable performance testing like timedemo in quake, in the source there did appear to be some provision for pre recorded/defined paths for the player to follow (maybe it was for rolling demos) but probably is not in a working state at present.

[Karlos]

Originally Posted by abu_the_monkey

regarding repeatable performance testing like timedemo in quake, in the source there did appear to be some provision for pre recorded/defined paths for the player to follow (maybe it was for rolling demos) but probably is not in a working state at present.

I saw that. I wondered if it even predates TKG. Do you remember the AB3D rolling demo?

[abu_the_monkey]

Originally Posted by Karlos

I saw that. I wondered if it even predates TKG. Do you remember the AB3D rolling demo?

yeah, probably from ab3d1.
and,
yeah! it was on all the cover disks of the time.

[abu_the_monkey]

interestingly enough, the path follow option does work (of sorts) as I commented it back in and set the control method to 'path' in the source and the 'player' just moves around in the first room bumping into walls lol

[Karlos]

Originally Posted by abu_the_monkey

interestingly enough, the path follow option does work (of sorts) as I commented it back in and set the control method to 'path' in the source and the 'player' just moves around in the first room bumping into walls lol

I've been removing stuff that's not used in the latest PR and that might be one of them.

[OldB0y]

@Karlos - I've been playing your graphically improved version, absolutely love it, looks great!

Have you re done the whole game, or just a few levels?

Also, is there a way to switch it to use the original music?