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

[Karlos]

Originally Posted by grond

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

Yeah, but there's slow and slow. For rendering proportionally spaced glyphs, you pay more clock cycles but need fewer instructions and have less state to manage. You'll only be doing this when the text changes.

[paraj]

Originally Posted by Karlos

Yeah, but there's slow and slow. For rendering proportionally spaced glyphs, you pay more clock cycles but need fewer instructions and have less state to manage. You'll only be doing this when the text changes.

Don't have UM at hand but IIRC it's probably not going to be big deal compared to chip speed (on 060). Like hand crafted equivalent of e.g. bfset will be faster, but it will only really matter if you already had destination in fast mem (or register). If (source and/or destination) is in chip mem it will matter a lot.


Cycle counting is great, but what matters is memory speed (and cache effects). Inner loop optimizations only mattered (a bit) due to being very frequently called.

[Karlos]

Hmm. Well, the plan is to use the bitfield instructions to plot to the fast ram intermediate. I'm going for simplicity first. The glyph data is already planar, so the reasoning goes that inserting spans of glyphs into the destination at some arbitrary bit position is simpler. This is, in fact, how the original game renders the mission text proportionally. However, in that case it was rendering straight into chip ram.

The alternative seems to be to have a lot of shifting and masking.

[abu_the_monkey]

Originally Posted by 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.

seems to be ok on the A4000/040 CV643d.

didn't test much, no time

[Karlos]

Originally Posted by abu_the_monkey

seems to be ok on the A4000/040 CV643d.

didn't test much, no time

That is quite promising though. Something definitely feels hackish about the approach. I'm too scared to risk turning on the 1200T to test it

[Karlos]

In a facepalm moment, I just burned half an hour trying to figure out why a very low hanging fruit task - extracting the runtime-calculated character spacing information into a binary include - was resulting in a 8000 0005.

I thought it was all sorts of possible nonsense. In the end, it was simple. The code that builds the table was also keeping track of some maximum value that we later need to divide by (this is code I wrote, so I should've remembered) when initialising the messaging system. As the binary extracted version no longer calls the generator (or even has it), that value stays zero.

What a muppet.

[Karlos]

I genuinely thought my char spacing data had an off by one error in the left margin that was being compensated for by a second one in the width, because to my surprise. the left margin nybble was mostly zero.

So I wrote a quick plotting utility and the result was a surprise... https://github.com/0xABADCAFE/alienb...scrollfont.txt

The character glyphs do seem to mostly have no left margin at all.

[Karlos]

I have a slightly buggy working implementation of the planar mode proportional text plot for 2/3 mode and it doesn't use any bitfield ops. I opted for simple C code that can be trivially reimplemented and improved in assembly.

There are bugs which are a bit odd due to the fact a pure C standalone prototype worked flawlessly, but I did make a few minor changes on adding here so that's probably the cause, lol. There's also some border corruption due to the fact I'm blindly overwriting a screen wide region of bitplane 4 just below the 3D area. This was chosen as it gives an easily legible shade of grey that's not too bright. There's no colouring because I wanted to minimise the overhead and a single plane is the best way to do that.

Other than this it has all the same features as the RTG version, namely is redrawn on update only rather than per frame. Overhead should be next to nothing.

[Karlos]

Yep, the glyph rendering bug was something incredibly trivial and obvious on revisiting it.

Here's how it looks in AGA Lores

[Karlos]

I made a bit more progress and pushed all the changes to the branch. I haven't fixed the cosmetic issues with the border yet but the single plane text rendering is stable and (I hope) fast in 2/3 screen AGA. Fixing the corruption just needs the first and last 16 bits of each scanline of bitplane 4 in the text draw area backing up somewhere, or alternatively not usimg a block copy. I prefer to use the copy as is as I think it's the most efficient approach for it. so I'll look into the first approach later. As it goes, I am not allocating any new buffers in AGA 2/3 mode since the bottom of the fast ram chunky buffer is still free.

The next thing to figure out is what to do in 1x2 mode. In fullscreen, you are a bit boned, but in 2/3 mode, there's no reason to apply the pixel doubling after the bottom of the 3D area.

[abu_the_monkey]

@Karlos

top stuff!

I may have some time to build and test this on the A4000 tomorrow (depends on how long my hospital appointment takes I guess )

[Karlos]

It has taken far longer than it should have because I'm lucky to get 10 minutes every few days lol

[abu_the_monkey]

time. there never seems to be enough of it to do the fun stuff

but at least you have made some great progress in bringing all the major features in line across the different modes

[Karlos]

There's an issue in 320x240 RTG mode. Essentially, the text draws over the bottom of the HUD. I suspected this would be the case.

It looks too weird having the 3D area right at the top, so I think that we should move the HUD lower border to the top of the display when on a 240 high screen. That gives enough space on the bottom for the current amount of text output (4 lines plus one for overflow).

Attached a mock of how that might look at 240. I don't think we should aim to support resolutions below 240, to be honest.

Also there's the N pages ago idea of an in-display HUD for fullscreen that I still want to do at some juncture.

[abu_the_monkey]

no doubt 320x200 will be even worse in that respect.

could the 'letter boxing' be use to develop the extra space required? just throwing out ideas that spring to mind.

[Karlos]

I dunno. Maybe 320*200 is okay in full screen with an in-display HUD, but there's definitely no real point to it in 2/3 because you aren't saving anything performance wise. We don't redraw the whole display in 2/3 mode, just the small window and any border elements that updated. And now a message block too. Which on AGA is just a single bitplane at that.

[abu_the_monkey]

Originally Posted by abu_the_monkey

no doubt 320x200 will be even worse in that respect.

could the 'letter boxing' be use to develop the extra space required? just throwing out ideas that spring to mind.

what I meant by this is, in 320x240 even in full screen you have to reduce the screen size by using the letter box feature, so, if you have selected a screen mode less that 320x256 force the max letter box to whatever makes it fit and in 2/3 mode leaves enough space below the render area and draw the text from where the 3d render area ends.

hope that makes some sense.

[pipper]

Originally Posted by abu_the_monkey

what I meant by this is, in 320x240 even in full screen you have to reduce the screen size by using the letter box feature, so, if you have selected a screen mode less that 320x256 force the max letter box to whatever makes it fit and in 2/3 mode leaves enough space below the render area and draw the text from where the 3d render area ends.

hope that makes some sense.

I was thinking about this. I think it may be a good idea to dynamically place and size the render window. For instance, I believe the HUD still leaves room at the bottom for the text scrolling we no longer use thanks to Karlos’ efforts. Also, in 320x240 and 320x200 the letterbox is not centered and one has to reduce the vertical size quite a lot, so much so that there’s no output at the top just to make the HUD reappear.

[Karlos]

Definitely, the layout needs to be more adaptive, especially at lower screen height.

I'm going to try and finish the 2/3 text stuff today for 320*256. I don't want to muddy the waters just yet. Since that means pretty much just fixing the border corruption, I'm hopeful I can find that 10 mins during a break

[abu_the_monkey]

Hi Karlos,

I could not get the latest build from misc/messages-redux to run in AGA screenmode.

I just get a black screen when starting a level. It is working in the background and I can esc back to the main menu and quit using '*'

RTG is working with the same builds, I only tried the release 020 and 040 versions.

Is worth posting a binary for someone else to test on a different 'real' amiga as mine can be a bit flaky ( I noticed today all the fast ram sockets have let go and do not hold the simms in place properly anymore )

edit: just so you know, the same build is working in winuae in AGA screen mode just not on my real A4000.