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

[abu_the_monkey]

I get sound breakup no matter what due to the age of the PC I am running.

the difference could be due to forcing RTG to run a 50hz (fake VBL) to keep timing simple regardless of actual refresh rate?

[abu_the_monkey]

Originally Posted by Karlos

If anyone wants to verify there's no oddities in the positioning of objects https://github.com/mheyer32/alienbreed3d2/pull/150

I've been through several levels in my mod that are very object heavy and I can see no meaningful differences in placement over the visible depth

I will try and test this later, no promises

[Karlos]

Originally Posted by abu_the_monkey

I get sound breakup no matter what due to the age of the PC I am running.

the difference could be due to forcing RTG to run a 50hz (fake VBL) to keep timing simple regardless of actual refresh rate?

Not sure. It's definitely not just audio, I get jittery screen updates. It's much more fluid in AGA

[Karlos]

Originally Posted by abu_the_monkey

I will try and test this later, no promises

I'm pretty sure it hasn't broken anything. Worst case I can improve the approximation precision, but it seems fine here as an 8 bit fixed point reciprocal.

[abu_the_monkey]

Originally Posted by Karlos

I'm pretty sure it hasn't broken anything. Worst case I can improve the approximation precision, but it seems fine here as an 8 bit fixed point reciprocal.

in that case merge away

[Karlos]

Originally Posted by abu_the_monkey

in that case merge away

Done

[paraj]

Originally Posted by Karlos

For the 060 experts, I could do with some reordering advice (this is in a loop over every object point):

.objpointrotlop:
    cmp.b    #OBJ_TYPE_AUX,ObjT_TypeID_b(a4)
    beq.s    .itaux

    move.w    (a0),d0
    sub.w    xoff,d0
    move.w    4(a0),d1
    addq    #8,a0

    tst.w    ObjT_ZoneID_w(a4)
    blt        .noworkout

    sub.w    zoff,d1
    move.w    d0,d2
    muls    d6,d2
    move.w    d1,d3
    muls    d5,d3
    sub.l    d3,d2

    add.l    d2,d2
    swap    d2
    move.w    d2,(a1)+

    muls    d5,d0
    muls    d6,d1

    add.l    d0,d1
    asl.l    #2,d1
    swap    d1
    ext.l    d1

    ;divs    #3,d1 ; kill this
    muls    #85,d1

    moveq    #0,d3

    asr.l   #8,d1


    move.w    d1,(a1)+
    ext.l    d2
    asl.l    #7,d2
    add.l    xwobble,d2
    move.l    d2,(a1)+
    sub.l    xwobble,d2
    NEXT_OBJ    a4
    dbra    d7,.objpointrotlop

I feel like this is quite badly arranged for superscalar execution. I can see some opportunitues to reorder this code. I can improve my tiny modification by just shoving the register clear of d3 between the muls and shift, but overall there's a lot of other stuff going on here that I think is primary execution unit only.#

Found a no-brainer - replace the clearing of d3 with a move.l xwobble,d3 and then use d3 in the two later places.

I don't think I'd bother trying to reschedule the instructions in a loop like this, better to just do general optimizations like the one you mentioned.
It's only like 100-ish cycles per iteration (ignoring cache effects etc.) and is probably not really a hot-hot spot. Many of the instructions a pOEP-only (muls/swap) so they can't pair anyway. Much too great a risk of breaking the code for extremely marginal gains.


Running my simple, automated cycle counter on the loop I'd say that it's probably not as bad as you think, and there are already quite a bit of instructions that will end up in the sOEP.

[Karlos]

I did reorder a tiny bit, there shouldn't be (m)any successive pOEP instructions, but removing register dependencies wasn't really possible.

Out of interest, what does your counter say when we replace the muls #85 and slightly later asr.l #8 with divs #3 ?

[paraj]

Originally Posted by Karlos

I did reorder a tiny bit, there shouldn't be (m)any successive pOEP instructions, but removing register dependencies wasn't really possible.

Out of interest, what does your counter say when we replace the muls #85 and slightly later asr.l #8 with divs #3 ?

divs is 20 cycles slower (and actually I meant loop was more like 60 cycles before not 100), but it's very basic and only really made for "texture mapping" inner loops and the like (all branches are assumed to be free b/c they can "only" appear at the end).


You can try it yourself: https://github.com/mras0/acycles


It works OK for simple innerloops (like a texture mapping one or your sound mixing stuff) and straight-line instruction sequences, but everything else is likely wildly incorrect. I use it to flesh out ideas for instruction scheduling, and then verify on real HW. #include <stddisclaimer.h>

[Karlos]

I had to get rid of it though. At one point, I here were scenes switch literally thousands of divisions (and long divisions) per frame

[Karlos]

In a rare moment of free time, I want to work on the engine.

I have an outstanding optimisation task to do with overdraw (in this case, drawing the sky where it is potentially needed but in practise is not, based on level errata data). This needs a buffer that I prefer to be an allocate once affair, rather than every time a level is loaded as it has a dependency on the zone count.

Now, it turns out that the zone count isn't really strongly limited anywhere in the engine (there may be some assumptions of 256 in places) and I know that @abu_the_monkey has experimented with a level editor supporting more than that many zones. For my use case, the data is a bitmap and it doesn't make sense to dynamically allocate it every time.

So what I want to do is to define a hard upper limit on the zone count. Somethinhg that goes into defs.i and defs.h and can be revised by software updates only.

The question is what is a good hard upper limit? I was thinking maybe 512 for now?

[Karlos]

I have the sky backdrop errata mechanism working.

In devmode, you can use X to toggle the sky visibility for the current zone (note, you can only disable it if the zone has sky according to the level data, otherwise it does nothing). Pressing Z clears all the override data and pressing V causes it to be dumped to the RAM disk (this happens at the point where the developer overlay information is drawn, doing it immediately is not possible as we are in an interrupt).

For now, copying the dumped file to Game/Levels/LEVEL_X/properties.dat causes the game to treat it as the per-level properties file (it will form the first section of it anyway) and reloads the data and uses it.

I've tested with Arena level of my mod which has a significant amount of sky overdraw in the beginning area and it works. There is still the odd 1-frame glitch passing between zones that are overridden to not show it.

Unsurprisingly, this saves a lot of cycles in areas where the sky is improperly tagged for rendering by the level data.

[abu_the_monkey]

Originally Posted by Karlos

In a rare moment of free time, I want to work on the engine.

I have an outstanding optimisation task to do with overdraw (in this case, drawing the sky where it is potentially needed but in practise is not, based on level errata data). This needs a buffer that I prefer to be an allocate once affair, rather than every time a level is loaded as it has a dependency on the zone count.

Now, it turns out that the zone count isn't really strongly limited anywhere in the engine (there may be some assumptions of 256 in places) and I know that @abu_the_monkey has experimented with a level editor supporting more than that many zones. For my use case, the data is a bitmap and it doesn't make sense to dynamically allocate it every time.

So what I want to do is to define a hard upper limit on the zone count. Somethinhg that goes into defs.i and defs.h and can be revised by software updates only.

The question is what is a good hard upper limit? I was thinking maybe 512 for now?

512 seems reasonable as there may be ways to extend it in the engine and editor. I ran out of time to investigate it further unfortunately.

Originally Posted by Karlos

I have the sky backdrop errata mechanism working.

In devmode, you can use X to toggle the sky visibility for the current zone (note, you can only disable it if the zone has sky according to the level data, otherwise it does nothing). Pressing Z clears all the override data and pressing V causes it to be dumped to the RAM disk (this happens at the point where the developer overlay information is drawn, doing it immediately is not possible as we are in an interrupt).

For now, copying the dumped file to Game/Levels/LEVEL_X/properties.dat causes the game to treat it as the per-level properties file (it will form the first section of it anyway) and reloads the data and uses it.

I've tested with Arena level of my mod which has a significant amount of sky overdraw in the beginning area and it works. There is still the odd 1-frame glitch passing between zones that are overridden to not show it.

Unsurprisingly, this saves a lot of cycles in areas where the sky is improperly tagged for rendering by the level data.

Top stuff

[Karlos]

Just added another test with level G which had the same basic issue in a couple of places.

This is just the start - I intend to add per zone "force cull" to work around cases where the editor is too conservative with zone visibility data. Who cares if a pixel of one zone are visible from a very specific location in another that you can't stand still on for more than a frame? Better to cull it and risk a single pixel / single frame disturbance and avoid rendering an entire zone to overdraw all but that pixel.

It's all pushed to the misc/redesign branch of my mod. The files are just 64 bytes at the moment because the data is a bit per zone (up to 512 of them). When zone culling lists get added, they will be varying length and will need a header.

[abu_the_monkey]

@Karlos

I am away on holiday at the mo, but will be sure to check it out when I return.

[grond]

Originally Posted by Karlos

I intend to add per zone "force cull" to work around cases where the editor is too conservative with zone visibility data. Who cares if a pixel of one zone are visible from a very specific location in another that you can't stand still on for more than a frame? Better to cull it and risk a single pixel / single frame disturbance and avoid rendering an entire zone to overdraw all but that pixel.

I assume that is easier than having the editor emit some warning and change the level layout just so slightly that the one pixel problem can't happen?

Similarly it is probably too complicated to turn the sky into a special type of ceilings that are texture-mapped without any perspective correction but straight from the sky-graphics.

[Karlos]

Originally Posted by grond

I assume that is easier than having the editor emit some warning and change the level layout just so slightly that the one pixel problem can't happen?

Similarly it is probably too complicated to turn the sky into a special type of ceilings that are texture-mapped without any perspective correction but straight from the sky-graphics.

Almost nothing is ever made easier by "changing the level layout" in this engine because your manual level is literally the BSP that other game engines use software to create

I think the editor just has limitations on its abilities. For one, I don't think it takes vertical separation into consideration at all. A scenario:

Imagine two connected zones, A and B. A is a deep pit with an open sky, B is a cave at the bottom. A is tagged as having visible sky and if you have a jetpack you can fly to a vantage where it will be rendered.

Zone B will be tagged as having "potentially visible sky" since it has an open connection to A, and therefore the sky of zone A is potentially visible. However, the sky can literally never be seen from B in practise. because A's ceiling is never visible from B It gets worse when you add zone C to B and there's a line of sight from C to A through B. C will now also be tagged as having potentially visible sky.

So you are 100% correct that a special ceiling renderer that puts the sky texture in at the right offset a better way. However, the data layout and render just aren't quite ready for it.

For now, this is a "better than nothing" solution but it's not pointless - it introduces the mechanism for loading a bunch of level specific ad-hoc data that I want to add.

Even with a "sky ceiling" solution, there are still problems since we get overdraw between zones sometimes that a mechanism like this can be used to limit, e.g. "due to differences in verticality, exclude zones A, B and C from the PVS of Zone X".

[Karlos]

Below is a good example of how bad it gets sometimes. This is the beginning of Level H.



The darker blue areas are the zones in which the sky is directly visible, either because the zone is open sky or directly shares an edge with an open sky zone at a similar height (I may have missed a couple but you get the idea).

The lighter blue areas are the zones in which the sky is legitimately potentially visible. The large octagonal region is a bit of a shame and should be restructured since the sky is only actually visible from the right hand end of it. However, bisecting that zone accordingly has created more PVS pain than I care to revisit.

The pinkish red areas are all the zones the editor has decided the sky can potentially be visible from when in practise there are no viable line of sight paths. I can now tag these in game and dump the data when I am happy, from the dev build.

[Karlos]

I managed to remove the last of the old messages code (the bottom of screen stuff) that was referenced from a few places.

This was just a lucky find as I was wanting to work out what happens when the game is paused, so that we can display some stuff. It turns out the pause is a pretty brutal hard polling loop in the main render path. This is a bit annoying. It would be a lot better if it let the system breathe a bit.