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