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

[Karlos]

Originally Posted by grond

Where do those zones come from? Are they defined as part of the level data?

Yes. Zones are convex polygons, roughly equivalent to the leaf of a BSP tree in other engine designs. In AB3D and TKG, zones are manually defined with a bunch of rules.

I've changed the code to be based on the player position, which works, but it does mean that the zone ordering is being recalculated all the time its not standing still (looking around is ok). This is still better than every frame. Just.

[abu_the_monkey]

For fun, try playing with F4 (disable dynamic lighting), F8 (use simple walls), F9 (double height) in 2/3 screen size (If you have an 040 or better, press F10 to go 2/3 from fullscreen)...

It's almost AB3D1...

yes it is, almost.

build from the current main.

edit: I have included a 'readme' for the new key definitions

can someone do a quick comparison with an older build on real hardware please

[grond]

Originally Posted by Karlos

Yes. Zones are convex polygons, roughly equivalent to the leaf of a BSP tree in other engine designs. In AB3D and TKG, zones are manually defined with a bunch of rules.

And you can always only be in one zone at a time?

[Karlos]

Originally Posted by grond

And you can always only be in one zone at a time?

There's only one pointer, so yes, although you can basically be stood on the boundary of adjoining zones (how complex rooms work is by adjacent convex zones sharing an edge). Unless it's maintained somewhere else that I haven't found.

I don't know that it's saving a ton of time by trying to skip it, but it may help on real hardware.

[Karlos]

I might be thinking about this the wrong way. Instead of earlying out the ordering of zones every frame because I appear to have not changed zone pointer, what if instead, I ran the zone order code when I detect the zone pointer has changed?

This is trivial for a C code refactor but in assembler I can't make too many assumptions on how decoupled the code is from where it is currently called.

[Karlos]

Originally Posted by abu_the_monkey

yes it is, almost.

build from the current main.

edit: I have included a 'readme' for the new key definitions

can someone do a quick comparison with an older build on real hardware please

Top banana.

edit: We should start stripping the release binary, it'll be half the size.




Mmmmm banana. Almost time.

[Karlos]

Experimental changes pushed to the performance/renderer branch for this idea of lazy zone order evaluation. It works (updates when player location moves) but I don't think it will make much difference. It may help on real silicon by saving some code and cache trashing due to list manipulation.

[abu_the_monkey]

@Karlos

are Plr1_RoomPtr_l and Plr1_ZonePtr_l the same thing? I get an undefined reference error with your push to the performance/renderer branch

I may have done something wrong

[abu_the_monkey]

ignore me, my bad

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

are Plr1_RoomPtr_l and Plr1_ZonePtr_l the same thing? I get an undefined reference error with your push to the performance/renderer branch

I may have done something wrong

It got renamed because the thing it points to is really a zone. A "room" can be made of multiple connected zones but doesn't appear to be a distinct thing in its own right. That is to say, there doesn't appear to be anything akin to a Sector in Doom.

[pipper]

I’m surprised it’s not using some form of portal rendering, starting from the player zone branching out into all connected zones all the while shrinking the “clip rectangle” for drawing.

The symbols were included into the executable so that I could use the WinUAE debugger with a little bit of source level debugging. WinUAE will load the symbols and allows you to refer to them when setting breakpoints or inspecting memory.
Removing the debugging symbols is definitely something that should be done for a release version.

[Karlos]

Originally Posted by pipper

I’m surprised it’s not using some form of portal rendering, starting from the player zone branching out into all connected zones all the while shrinking the “clip rectangle” for drawing.

The man is back!

The whole PVS has some issues, as the Dev build can show. Bits of the map being drawn behind solid walls and so on. I just picked this part up to ease myself into the murky world of it. I am pretty sure it is a portal style renderer. When wall drawing is turned off, usually the stuff that would be partially obstructed by them is clipped against where the walls would be.

The symbols were included into the executable so that I could use the WinUAE debugger with a little bit of source level debugging. WinUAE will load the symbols and allows you to refer to them when setting breakpoints or inspecting memory.
Removing the debugging symbols is definitely something that should be done for a release version.

Definitely. We have two separate builds now. The release one and the developer one. The latter has conditionally complied stuff in it that's excluded from the release.

[pipper]

Oh, also, wrt to the “doublewidth” test branch: what I tried there was to ignore the dedicated double width rendering routines and then modify the regular rendering routines to achieve doublewidth rendering. The idea being: what are the relevant parts? Can the necessary changes maybe rolled into the outer math and make it “just work”?
I think I made all the necessary changes, but didn’t pursue a “productization” enough. I wanted to make the regular rendering routines switchable, but that’s not as easy to do as I wished for and then I lost a bit of interest.

What could be done with the current code, though, is to modify the doublewidth rendering paths in the master branch to use the code used in the doublewidth test branch.

[Karlos]

I'm taking a bit of a break from the lower level optimisations after eliminating a further 1500-3000 long divisions per frame (up to 8000 in one scene in my mod) arising from the polygon rendering. That's why I decided to take a quick look at the higher up stuff.

[Karlos]

@pipper

I think the double height mode offers better bang for buck because you can transfer half as much data over the slow chip ram bus as well as saving on calculation time. With the double width mode, you only get calculation time saving, right?

[abu_the_monkey]

@Karlos

for the fps counter in the release version you mentioned using the border text/char, I think the border, weapon indicator, ammo and health are on a planar screen which the chunky buffer draws over but I could be wrong. would you just be looking to reuse the 'font' and redirect it to the top left corner of the chunky buffer?

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

for the fps counter in the release version you mentioned using the border text/char, I think the border, weapon indicator, ammo and health are on a planar screen which the chunky buffer draws over but I could be wrong. would you just be looking to reuse the 'font' and redirect it to the top left corner of the chunky buffer?

Yes, just the font data. Plotting into the chunky buffer, we only need 3 digits and a dot. I could even just embed my own glyphs easily enough.

I am probably going to factor out some of the timing code from the dev_inst.s into a common timer file so that there's a single point of definition. I'll also use the same last 8 frames average as it seems to give a pretty reliable measure. But not tonight. I'm beat, lol.

[abu_the_monkey]

that's cool

I am not surprised, only 4 hours sleep a night catches up with you at the best of times. how was the banana by the way

[Karlos]

Originally Posted by abu_the_monkey

that's cool

I am not surprised, only 4 hours sleep a night catches up with you at the best of times. how was the banana by the way

Yellow and potassiummy

[abu_the_monkey]

sorry, had to comment at this

Mmmmm banana. Almost time.

made me chuckle, had an image of Homer Simpson in my head.