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

[Karlos]

@pipper - YouTube just gave me this [ Show youtube player ]

I thought it was interesting because the aspect and perspective issues were really conspicuous, both in fullscreen and 2/3 size. However, it was posted a fortnight ago so I don't know which version it is. The effects are a lot less noticeable on my machine.

[pipper]

This version may be the first one I posted which was made to look right in the 2xn mode

[Karlos]

@pipper

But boy - the gameplay... It really shows that it got not much polishing. Repetitive non-sensical texturing, ... nonsensical map layouts

I dunno. Get a nice 1970's style yellow wallpaper with a small skirting board, a brown carpet and office ceiling tile and the odd light for a ceiling and you've got a Backrooms mod right there. Alien Backrooms 3D - the liminal grounds.

You could fill it with hidden door sections that rearrange when you walk over an invisible trigger so that backtracking changes it. Though the automap would fettle that.

[Karlos]

@pipper

Walls and 2D sprites are stored in 32 colors (5bit per pixel). To not waste memory, 3 columns of pixel data are packed into one 16bit word each. During rendering of a vertical strip, a specific routine is used to unpack one of the 3 columns.

Damn, I am glad I just read this. I previously assumed that the 32-colour limit for these was some tooling problem, perhaps with AMOS when importing the original assets etc. I was planning to write a replacement that would use 256. That would not have ended well.

Possibly related, the waterfile, which contains the animation frames for the water, appears to be stored as 8 64x64 tiles, but each pixel is 2 bytes, where every odd byte is zero. The even bytes appears to be a shade palette index. I was trying to make sense of these data just now. There's more to it, frames seem to be interleaved.

[Karlos]

@pipper - Candidate PR raised for issue 9 (floor swimming)

[abu_the_monkey]

@Karlos

Just tested it and it is a vast improvement but with a subtle 'sway' maybe linked to the player bobbing motion?

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

Just tested it and it is a vast improvement but with a subtle 'sway' maybe linked to the player bobbing motion?

Yes, I noticed this too.

[abu_the_monkey]

you have to really be looking for it mind.

[pipper]

I merged it anyways. Yeah, I noticed, too that when the player goes up and down, the floor seems to shift left and right. Is that what you are talking about?

[Karlos]

Originally Posted by pipper

I merged it anyways. Yeah, I noticed, too that when the player goes up and down, the floor seems to shift left and right. Is that what you are talking about?

Correct. I'm going to check the original. It's possible that it's a consequence of my division approximation.

[abu_the_monkey]

just had to check the original also. yes, the original does the same.

[abu_the_monkey]

@pipper

yes that is correct.

[Karlos]

Originally Posted by abu_the_monkey

just had to check the original also. yes, the original does the same.

So not a new bug then? Nice. I will do the boy scout thing and raise a cleanup PR later

[abu_the_monkey]

top stuff guys

[Karlos]

Originally Posted by Karlos

So not a new bug then? Nice. I will do the boy scout thing and raise a cleanup PR later

Done. The code should now work with the original 288 width too. I also removed an increased approximation precision for the floor texturing that saves a pair of instructions since it wasn't the new code creating the "bobble wobble"

[pipper]

Actually far in the future I'd like to revisit the precision of the rendering in few places. If you play doom, you'll notice how solid everything feels. In Ab3D everything seems to wobble, shift and jump around. For instance if you look down at the floor one should see perfect little squares (enlarged floor tile pixels), but in AB3D it actually looks rather messy.

[Karlos]

Originally Posted by pipper

Actually far in the future I'd like to revisit the precision of the rendering in few places. If you play doom, you'll notice how solid everything feels. In Ab3D everything seems to wobble, shift and jump around. For instance if you look down at the floor one should see perfect little squares (enlarged floor tile pixels), but in AB3D it actually looks rather messy.

Indeed. In this specific case I don't believe the division approximation has made anything worse though. I was surprised to see just how much there is too. Doom uses 16.16 fixed point arithmetic and is generally pretty strict about it. TKG doesn't seem to be quite as rigidly defined.

If we are targeting 060, I was thinking to add an FPU option to the makefile. Then we could build a version that uses the FPU for the transformation steps. Almost all the integer division logic disappears then and scaling factors can just be specified directly and achieved via multiplication. Since none of the FPU registers are currently used, we could save them all on start up and restore them on clean exit (when that's a thing).

Having said all that, I don't know that the precision is necessarily the cause of all the wobbles. If you look at the edge of a wall and floor, especially it rarely dorms a straight line, but appears to have steps in it that correlate with the wall texel width on screen. I wonder if that's due to some algorithm shortcuts

I've often thought about writing a replacement engine in C and providing the option for a hardware renderer. There are some features of the game that make this a challenge however. First being to understand how it actually works now.

[Karlos]

@pipper

Just to confirm my previous claim, I temporarily replaced the 320 scaling from

muls.l #171,d6
asr.l #8,d6

with

fmove.l d6,fp0
fsmul.s #0.6,fp0
fmove.l fp0,d6

And there was no change in quality or "bobble wobble" in fullscreen.

Ironically this is probably still faster than the original divs.l code.

[pipper]

An 060 version would be great, but I don't want to loose the ability to run it on 030 either... its a matter of where to invest time. 060/FPU Could make the walls look nice and if we manage to overlap perspective division with the strip rendering we'd get it "for free", similar to how the Quake renderer works. I think right now perspective division is not done per strip. Additionally subpixel correct sampling/rendering could reduce wobble and make the world feel more solid.

But lets focus on fixing bugs first. Your contributions are greatly appreciated!!!

[Karlos]

Originally Posted by pipper

An 060 version would be great, but I don't want to loose the ability to run it on 030 either...

I was definitely thinking this would be a conditional assembled feature, though the code is somewhat complex enough without adding more compilation paths.

...its a matter of where to invest time. 060/FPU Could make the walls look nice and if we manage to overlap perspective division with the strip rendering we'd get it "for free", similar to how the Quake renderer works. I think right now perspective division is not done per strip. Additionally subpixel correct sampling/rendering could reduce wobble and make the world feel more solid.

I definitely get the impression the game takes shortcuts with perspective correction. If you look at the sections of walls closest to you, the texels look more like voxels, and if you look closely as the edge of a wall, you'll see it's not a straight line either. There are horizontal spans. I'll try to get a screenshot later to clarify what I mean.

But lets focus on fixing bugs first. Your contributions are greatly appreciated!!!

Definitely. I'm contemplating creating a completely new mod just to be able to test features.