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

[Karlos]

Originally Posted by Seiya

ok

I will also say, the mod is becoming increasingly dependent on the new engine build which fixed a number of historic bugs, so for the best experience, use the builds posted in this thread.

[abu_the_monkey]

Originally Posted by Karlos

I tried to make update my toolchain but despite having never made any changes, many of the component repos ended up conflicted to death, so I'm just reinstalling it from scratch. I've chosen NDK=3.2 in the build options this time so that should fix things... I hope!

Any joy after re installing the tool chain?

[Karlos]

@pipper, @abu_the_monkey

I did a completely fresh checkout and rebuild of the toolchain, this time with NDK=3.2 but it seems like adtools isn't present - the build fails on finding SDI_compiler.h, which doesn't appear to be present anywhere.

Did I miss a step?

[pipper]

Did you also make the “all-sdk” target?

[abu_the_monkey]

I just followed pippers instructions on page 6 or 7 of this thread, and all (bar me screwing up when installing Ubuntu and having to change permissions ,owner/user stuff) went ok.

[Karlos]

Originally Posted by pipper

Did you also make the “all-sdk” target?

Damn. I bet I didn't.

-edit-

Yep. That was it.

So, the C build compiles now but I am getting a lot of warnings for the use of the __saveds__ attribute only being usable with fbaserel. Do you get the same warnings?

[Karlos]

Now that this is done, I think a devmode with C target seems like a useful addition.

[pipper]

Yes, that’s normal. The current build is not an -fbaserel build, but it might in future. So I added __saveds where needed. This is what the compiler complains about. I could try suppressing the warning…

[Karlos]

Originally Posted by pipper

Yes, that’s normal. The current build is not an -fbaserel build, but it might in future. So I added __saveds where needed. This is what the compiler complains about. I could try suppressing the warning…

It's fine as long as it's expected

[Karlos]

Just examined the output of the compiler for system.c and a few things caught my eye:

The code for clear keymap is basically the same loop unrolled 32-bit clr.l (a0)+ that was in the original assembler, which is reassuring to see the compiler understands this sort of code is unrollable.

On the other hand, I think tuning for 030 introduces some stuff that may be bad for 060:

In Sys_EvalFPS:

    Sys_FPSFracAvg_w = 1000 % (UWORD)avg;
    Sys_FPSIntAvg_w = 1000 / (UWORD)avg;

Is correctly reduced to a single division operation. However, rather than the 32/16 => 16:16, it generates this one:

	move.l #1000,d2
	divsl.l d0,d1:d2
	move.w d1,_Sys_FPSFracAvg_w
	move.w d2,_Sys_FPSIntAvg_w

It feels like the compiler plays it too safe here. I think that particular incantation will be a lot slower (admittedly it's once per frame, but still). The 32/16 => 16:16 only needs around 18 cycles, in the worst case.

[pipper]

Yeah, it’s a mixed bag. Sometimes it generates good code, sometimes you wonder why it replicates so much code to save a few jumps…
I mean, look at the code for mnu_pass1!

But for the parts we replace, it should be good enough, though. Maintainability and extensibility imho outweighs the slightly larger code. You can try playing with the -m -mtune and -O settings… -Os could also be a good choice. -fomit-frame-pointer may also help a bit, freeing up a5.
Maybe at some point having a dedicated 060 version makes sense.

[Karlos]

Or just being wary that 32-bit int is the default and C will always widen to the largest type of an input to an operator. For example:

    Sys_FPSFracAvg_w = (UWORD)1000 % (UWORD)avg;
    Sys_FPSIntAvg_w = (UWORD)1000 / (UWORD)avg;

gives:

	move.w #1000,d2
	and.l #0xFFFF,d2
	divu.w d0,d2
	move.l d2,d1
	swap d1
	move.w d1,_Sys_FPSFracAvg_w
	move.w d2,_Sys_FPSIntAvg_w

which is almost identical to the hand rolled version. A bit surprised it didn't just clr.l d2 then move.w #1000,d2 (or even just move.l #1000,d2... shrug)

Incidentally, I always use -fomit-frame-pointer. I thought that was standard at -O3 ?

[Karlos]

If you are looking for another relatively low hanging fruit to convert to C, I would suggest the whole IO subsystem for loading and saving would be good. It needs a bit of an overhaul if we want to be able to load additional custom stuff, which will be a lot easier in C.

[saimon69]

At this point given the differences are growing i think is good to give the refactor a new name, like, thinking at Doom, something like Chocolate Breed or similar?

[Karlos]

Originally Posted by saimon69

At this point given the differences are growing i think is good to give the refactor a new name, like, thinking at Doom, something like Chocolate Breed or similar?

I dunno. That sounds kinda racist...

[abu_the_monkey]

Originally Posted by saimon69

At this point given the differences are growing i think is good to give the refactor a new name, like, thinking at Doom, something like Chocolate Breed or similar?

maybe if/when RTG is introduced as an option?

[abu_the_monkey]

Originally Posted by Karlos

I dunno. That sounds kinda racist...

[Karlos]

I know it sounds like a lot has changed, but in reality it hasn't. The display handling is all peripheral, really. Figuratively and literally. The vast corpus of the code is the same

[Karlos]

Originally Posted by abu_the_monkey

maybe if/when RTG is introduced as an option?

Speaking of which, I may have a stab at this on the weekend. No promises, but I have more recent experience with RTG, in that I've written code for it this millennium.

[abu_the_monkey]

Originally Posted by Karlos

I know it sounds like a lot has changed, but in reality it hasn't. The display handling is all peripheral, really. Figuratively and literally. The vast corpus of the code is the same

exactly this.

to me its more finishing off things that weren't back in the day, so far