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

[pipper]

You can check out the “DOUBLEWIDTH_test” branch. I updated it last night. It will only render the 2xY modes correctly. On the Amiga you can switch it via the left bracket on the numpad. In WinUAE this key is likely not mapped, so you’ll have to set it up first. Fullscreen is switched via numpad enter. Switching fullscreen and small screen also restores the window frame (after corruption from the teleport)

I added lots of comments wading through the code. I also see lots of opportunities for optimizations and fixed a few low hanging fruit. I _think_ it’s already much more playable on 030 50Mhz in 2x1 mode. It’s sad that there were ludicrously simple optimizations for code muls.s #64, d0 left on the table, showing that TKG was a rushed product. On the other hand we might be thankful to have gotten it at all…

[abu_the_monkey]

thanks i will check it out

[jotd]

muls.s #64, d0 is a crime when you can use asl !!

after a while I guess they just applied formulas without trying to optimize them. And at the time, there were less knowledge about instruction cycles too.

Great job understanding the source and hacking through it to speed it up

[vroom6sri]

Originally Posted by pipper

I _think_ it’s already much more playable on 030 50Mhz in 2x1 mode. It’s sad that there were ludicrously simple optimizations for code muls.s #64, d0 left on the table, showing that TKG was a rushed product. On the other hand we might be thankful to have gotten it at all…

I'd be interested to try that out on my A1200 with ACA 1230/56 but is there an executable version I can download yet please?

[pipper]

I put an executable in the zone (TKG_doublewidth.zip)
This one is compiled to render properly in doublewidth (2x1,2x2) modes, switchable via left bracket on numpad. It has issues with music and the load/save menu on a real machine.

I also merged a couple of commits back into master. The DOUBLEWIDTH_test branch now has one commit dedicated to all the places that need either a "multiply by two" or "divide by two" to achieve the doublewidth rendering.
Now it would be interesting to figure out how to roll these multipliers into few "higher up" places and thus unify 1x and 2x modes. Maybe someone has ideas to join in?
A similar effort will have to be done for double-height rendering.

There's also an interesting issue with the floor still "swimming" a bit wrt to the walls. I think this is due to me extending the render area from 288x232 to 320x232 in fullscreen. Walls and floor use slightly different formula to express the field of view. I think this peculiar code here https://github.com/mheyer32/alienbre.../hires.s#L9550
is doing that for the floor (the multiplication of 0.75 in there). It would be good to somehow consolidate this, too.
So much to do, so little time :-(

[alexh]

You're doing a great job. This game is a title worthy of being preserved and enhanced.

So many Amiga users including myself drooled during its developments and at the previews in magazines, myself I bought it on launch and was a bit disappointed that my Amiga wasn't fast enough for it to play well... but played it anyway.

Keep writing up the questions for people and maybe we can answer and if not maybe writing it down gives you inspiration.

Team17 we still love you, especially as my shares in your company have gone up +10% in the last few days.

[abu_the_monkey]

when I build the latest version with Devpac I get the following errors.

Error: data too large at line 7679 in file AB3:ab3d2_source/hires.s
7679 01.000236A0 CCFB72CC mulu.w OneOverN(pc,d7.w*2),d6
Error: data too large at line 8937 in file AB3:ab3d2_source/hires.s
8937 01.0002B1B4 CEFB02B8 mulu.w OneOverN(pc,d0.w*2),d7 ;

edit: forgot to mention it (Devpac) also does not like the 'align 4' at line 421 in plr1control.s so commented it out, is this to add padding?

is this a limitation within Devpac?

the executable runs but has a 'hall of mirrors' effect rendered on the floor and celling.

Maybe I should move to vasm

Keep up the amazing work pipper

edit: the doublewidth version runs very well (unfortunately not able to test on a real amiga at the mo)

[pipper]

Are you compiling for 68020+ CPU?
I chose to remove the according option from the source file and move it into the assembler invocation, so in your case it might actually fall back to assembling for 68000.
Also, this might be a similar issue to the linker problem we had before, try moving the OneOverN table closer to the code using it.

[abu_the_monkey]

yes compiling for 68020.
I will have a look. thank you.

[vroom6sri]

I just tried the file you left in the zone but I only have the WHDload version of the game so I’m not sure if that’s why nothing seems to happen when I run your file. All I get is what looks like a small Workbench window at the top of the screen where I can see the mouse pointer moving. Nothing else happens.

[pipper]

The WHDLoad Slave is not going to work with my executable. But the datafiles should be compatible. Place the new executable into the data/ directory; then make a few assigns to there:

assign tkg1: ""
assign tkg2: tkg1:
assign sfx: tkg1:
assign ab3: tkg1:
assign ab3d2: tkg1:

(preferably put this in a script). Now the new executable should startup.

[vroom6sri]

Many thanks, Pipper. That did the trick. I will have a play on it later today or tomorrow and see how it feels but first impressions were that it was definitely improved performance-wise.

[abu_the_monkey]

So I decided to compile with the latest version of vasm68k/vlink (1.9/0.17) and all compiles out of the box (mostly as I don't know what the 'CHEESEY' option is meant to be set to so set it to 0 in the makefile).
no errors and plays fine with no 'hall of mirrors' effect

[pipper]

I think CHEESEY denoted the cut down 2mb version. You can actually try and build cheesesauce/cheesey.s
The executable runs but seems confused about not finding certain files to load. I didn’t find a fix for that.


On another note, I made some headway in replacing the direct hardware poking with OS friendly calls. I have replaced the screen with an intuition screen and even managed to replicate the menu scrolling / fire effect in a totally OS friendly manner. Some things are still poking the head registers directly, like input and audio. But the groundwork is there to eventually use RTG.
I created a sidebranch for that.

[vroom6sri]

Amazing work. Thanks so much for your efforts. Did they ever release source materials including the original green aliens from the playable AB3D demo? As I have said in a thread of my own that version had a much better feel in my opinion. From what I have seen from AB3D and AB3DII I have to admit I think my dream scenario would be a version of AB3D with a better resolution options but still playable on a 56Mhz 030 and with those green aliens reinstated.

Don't get me wrong though, what you're doing is amazing and your explanations can help other geniuses (geniui?) adapt the code. Bravo!

[abu_the_monkey]

@vroom6sri

the source only contains the face on frames for the green alien from the original ab3d demo.

[vroom6sri]

That’s cool to see how it looks behind the scenes. Now that you’ve said/shown that I don’t recall ever seeing in that demo level the green alien from any other angle other than straight on. I guess this is why!

[abu_the_monkey]

THIS is how ab3d2 could have looked!

Karlos must have spent more time than I can imagine working on this with the rather temperamental tools supplied with the game.
not sure if he ever made it available anywhere but, god dame it's is even more difficult than the original.

[trixster]

What version is that, Abu? The demo map?

[abu_the_monkey]

@trixster

its a mod that Karlos over on amiga.org made. its all the original TKG levels with a ton of polish