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

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

there seems to be an issue with the asm version being run first then quitting and then running tkgc.

if I do it in this order it results the previously reported 'death at the first door' for me at least.

after deleting the 'game.stats' and 'game.prefs' tkgc works fine.

hope this helps.

I wasn't able to reproduce this, but as a precaution, the assembler builds (in the new CPU target branch) now use gamea.prefs and gamea.stats as their persisted files, so there can be (in theory) no issues caused by inconsistent structure between the two.

While I doubt this has anything to do withe the death at the door situation, I should also point out that the game.stats / gamea.stats files shoud not be copied between different installations of the game as they are dependent on the mod (or not) being ran.

[Karlos]

I've merged the branch now, since the main thing it does is make it easier to add optimisations for specific targets and makes sure the existing ones are not lost. I don't want to add too many things to the PR that is only supposed to introduce the ability to build said targets. I did add the change to make sure the asm build doesn't read/write the same files as the C one as a safety measure though.

*damn* I forgot to update the readme.

[abu_the_monkey]

Top stuff

[Karlos]

As a lowish hanging fruit to get me back into the mood, I'm probably going to work on the in game messages next. There are a few issues:

1. Only works in the C build
2. Doesn't work in 2/3 size
3. No options to adjust verbosity.
4. Is implemented in a manner that requires transformation of the originally incbin'd glyph data at startup. It's not a big deal but it's also something that could just be totally done offline and swapped out for the proportional version.

[Karlos]

Damn, I just can't make time for any of this at the moment, lol

I did at least update the readme.

[Karlos]

I've made a start on this. There are really three different rendering paths, each with different injection points. For fullscreen mode, the current mechanism is fine. As soon as you go into 2/3 mode, you have an RTG path that requires plotting direct to the bitmap inside the existing lock. The AGA case is similar. By far the biggest obstacle is finding time.

[abu_the_monkey]

Originally Posted by Karlos

By far the biggest obstacle is finding time.

this!

[Karlos]

I have text rendering in the 2/3 mode (direct plot to the RTG bitmap data while locked, with a blitter clear first) but it's currently far from the efficiency I want as it's drawing every frame rather than on change only (though that's not difficult to fix). Also, I think I need to move the display around a bit and work out what's a realistic number of lines that can be displayed etc.

[Karlos]

Work in progress shot. The grey background is just for visual confirmation that the RectFill() clear is working. It does beg the question if this is hte most effective use of the screen space if I want more text visible.

Moving the 3D view area further up just looks weird. The only other option would be to move the lower HUD to the top and leave the rest of the space below the 3D area for messages.

[Karlos]

I've pushed the changes so far to the misc/messages-redux branch of my fork. The 2/3 mode is now using up to 5 lines (4, with one for overflow) in the space between the 3D view and the bottom hud, as per the screenshot. The text is only redrawn once per message tick (about every second) and stops being drawn at all once the last redraw was blank, until something adds a new message line. Hopefully that keeps the overhead to a minumum.

The dev build can use the H key to disable the devmode HUD overlay which is pretty clashy.

This needs testing on real hardware ideally because I'm doing something I am not entirely sure is safe to do - namely invoking RectFill() on a bitmap that I currently have locked. The fill is assumed to be quicker than clearing the region using the CPU and the existing text plotting routines only render set pixels (so that they draw nicely over the background in fullscreen).

I do the RectFill before doing any CPU writes and expect this to be a synchronous operation. It certainly "works" in UAE, but the idea that the call happens while the bitmap is locked does worry me a bit.

[Karlos]

Independently from that, I need a planar plot routine for AGA only.

Inspired by the work @paraj has done for TFX, etc. I am thinking that the best way to approach this is to have a planar version of the text plotter write to a single plane in fast ram. This plane can be qucikly zeroed first, written to and then copied wholesale to a bitplane in the display.

The plan here is to forego having different coloured text and choose an index that hopefully lets me get away with just writing a single bitplane. The assumption here is that if you are in 2/3 mode on AGA you probably want to be as fast as possible.

I will also add an option to enable/disable messaging entirely.

[DanyPPC]

Very appreciated your effort to optimize the AGA, even at 2/3 of the screen.

I will wait patiently.
Many thanks.

[Karlos]

Originally Posted by DanyPPC

Very appreciated your effort to optimize the AGA, even at 2/3 of the screen.

I will wait patiently.
Many thanks.

Are you on an AGA only system?

[DanyPPC]

My brother has an A1200 + Blizzard 1260 on a Elbox Tower and only AGA.
I have an A1200 + Blizzard 1230 (desktop case)

Then I have an A1200 Tower with BlizzardPPC 240/060 and BVision 3D and an Apollo V4 Standalone.
With these I can play a RTG version of TKG, but I hope to play also the AGA version on the desktop 1230, because the original TKG isn't very playable on this configuration.

[paraj]

Originally Posted by Karlos

Independently from that, I need a planar plot routine for AGA only.

Inspired by the work @paraj has done for TFX, etc. I am thinking that the best way to approach this is to have a planar version of the text plotter write to a single plane in fast ram. This plane can be qucikly zeroed first, written to and then copied wholesale to a bitplane in the display.

The plan here is to forego having different coloured text and choose an index that hopefully lets me get away with just writing a single bitplane. The assumption here is that if you are in 2/3 mode on AGA you probably want to be as fast as possible.

I will also add an option to enable/disable messaging entirely.

I don't recall the details of the engine, but is it an option to plot the characters to the chunky buffer? I suspect that will be the fastest. Of course if the words are "pre-wrapped" or the C2P introduces distortion that might be a problem.

[Karlos]

Originally Posted by paraj

I don't recall the details of the engine, but is it an option to plot the characters to the chunky buffer? I suspect that will be the fastest. Of course if the words are "pre-wrapped" or the C2P introduces distortion that might be a problem.

We are doing exactly that in fullscreen regardless of AGA or RTG.

In 2/3 mode only the small 2/3 region is updated (C2P for AGA, memory copy for RTG) and I want to draw the text
completely outside of that area because it's basically unused.

Other than being unused space, you also get the advantage that you don't have to plot the text every frame, just when it changes. These are all highly desirable for 2/3 mode. For planar display I just want to go one step further and make that rendering as fast as possible. As I see it, plotting the text to fast ram and copying that straight to the least number of planes would be ideal.

[Karlos]

Does anyone here know if the 060 continues to have bitfield insertion instructions or are they emulated?

[paraj]

Originally Posted by Karlos

We are doing exactly that in fullscreen regardless of AGA or RTG.

In 2/3 mode only the small 2/3 region is updated (C2P for AGA, memory copy for RTG) and I want to draw the text
completely outside of that area because it's basically unused.

Other than being unused space, you also get the advantage that you don't have to plot the text every frame, just when it changes. These are all highly desirable for 2/3 mode. For planar display I just want to go one step further and make that rendering as fast as possible. As I see it, plotting the text to fast ram and copying that straight to the least number of planes would be ideal.

Right, now I think I see what you're getting at. Fastest way on 060, I think, would be to plot 32 pixels (long word aligned) at a time to one LONG, transfer that to chip mem, and start computation on next block. If my reading of the long coders/asm thread is right though it won't really help 030.. Your way is probably best What you really want to avoid on all CPUs is RMW to chip mem.

[Karlos]

Originally Posted by paraj

Right, now I think I see what you're getting at. Fastest way on 060, I think, would be to plot 32 pixels (long word aligned) at a time to one LONG, transfer that to chip mem, and start computation on next block. If my reading of the long coders/asm thread is right though it won't really help 030.. Your way is probably best What you really want to avoid on all CPUs is RMW to chip mem.

For simplicity (at least for version 0) I just plan to have a fast ram buffer for a single bitplane the size of the text area. This isn't very big, certainly less than 2000 bytes (exact value depending on the exact spacing between the lines). This can be zeroed out and plotted into "on change" and then copied to the correct location in chip ram. Perhaps 040 and 060 can optionally use move16 for this, the source should be cached by then and the destination isn't cache enabled. I say optionally because just doing it is probably violating something and I might get mjolnir'd over the head by ThoR

[grond]

Originally Posted by Karlos

Does anyone here know if the 060 continues to have bitfield insertion instructions or are they emulated?

It does have them all but the way I remember it all bitfield-instructions are slow, even on the 060.