[4.5.9] More Compact / Efficient Collision Table Loads

[CutterCross]

Sort of an extension to what I was doing with attribute table loads. Experimenting with collision table compression, saw the collision table loads were inefficient for full-screen loads, made a more efficient version. Again, instead of the original's row-column system, this streams each collision nibble one by one.

This loads the same set of collision bytes to BOTH collision tables, so this is really only applicable as-is to non-scrolling games. If you're so inclined, you can modify it so that it only loads to one collision table based on what PPU nametable you're on. And of course this is mostly just for full-screen collision table loads, so arg3 should be set to #240.

New doLoadCollisionTable.asm:

;;;; CC Collision Table Load ;;;;

doLoadCollisionTable:
    ;;; currently, arg0_hold has the bank data
    ;;; arg1_hold has the screen index, if it is needed.
    ;;; arg2_hold has screen bits.
        ;;; bit 0 = overworld (0) underworld (1)
        ;;; bit 1 = metaTable (0) 8x8 table (1)
        ;arg0 = screen bank
    ;arg3_hold = number of collisions to load
    ;arg4_hold = collision table offset



    SwitchBank arg0_hold
    LDA arg4_hold
    TAX
    LSR
    TAY
    LDA arg4_hold
    AND #$01
    BNE +
    LDA #%11110000
    JMP ++
    +
    LDA #%00001111
    ++
    STA arg4_hold    ;; Now used to determine if collision is on even or odd column
       
        loop_LoadCollisionTable:
            LDA (temp16),y
            AND arg4_hold
            STA arg5_hold
            LDA arg4_hold
            CMP #%11110000
            BNE +
                LDA arg5_hold
                LSR
                LSR
                LSR
                LSR
                STA arg5_hold
            +
            ;;;; loading to 1st collision table
                LDA arg5_hold
                STA collisionTable,x
            ;;;; loading to 2nd collision table
                STA collisionTable2,x
               
        doneLoadingThisCollision:
            LDA arg4_hold
            EOR #$FF
            STA arg4_hold
            CMP #%11110000
            BNE +
            INY
            +
            INX
            DEC arg3_hold
            BNE loop_LoadCollisionTable
           
        doneWithLoadingCollisions:
   
    ReturnBank
    RTS

New LoadCollisionData macro:

MACRO LoadCollisionData  arg0, arg1, arg2, arg3, arg4
    ;arg0 = screen bank
    ;arg1 = screen index
    ;arg2 = load screen bits
        ;;; bit 0 = overworld (0) underworld (1)
        ;;; bit 1 = metaTable (0) 8x8 table (1)
    ;arg3 = number of collisions to load
    ;arg4 = collision table offset
   
    LDA arg0
    STA arg0_hold
    LDA arg1
    STA arg1_hold
    LDA arg2
    STA arg2_hold
    LDA arg3
    STA arg3_hold
    LDA arg4
    STA arg4_hold


   
    SwitchBank #$16
   
        LDY arg1
   
        LDA arg2
        AND #%00000001
        BEQ loadFromMap1table
            ;;;load from map 2 table
            LDA CollisionTables_Map2_Lo,y
            STA temp16
            LDA CollisionTables_Map2_Hi,y
            STA temp16+1
                LDA arg0_hold
                CLC
                ADC #$08
                STA arg0_hold
            JMP GotColTablePointer
        loadFromMap1table:
            LDA CollisionTables_Map1_Lo,y
            STA temp16
            LDA CollisionTables_Map1_Hi,y
            STA temp16+1
           
        GotColTablePointer:
            ;;now (temp16) holds the address of the nametable to be loaded.
    ReturnBank
   
   
    JSR doLoadCollisionTable
   

    ENDM

 

[Jonny]

If this way is more efficient maybe there will be less anomalies like when walkable tiles randomly act as solids when using scrolling? Although, since last update I haven't noticed it happen yet (touch wood) and I also don't know if it's caused when the collision data loads or something quirky in the physics script or somewhere else.

 

[CutterCross]

If this way is more efficient maybe there will be less anomalies like when walkable tiles randomly act as solids when using scrolling? Although, since last update I haven't noticed it happen yet (touch wood) and I also don't know if it's caused when the collision data loads or something quirky in the physics script or somewhere else.

Like with attribute table loads, I'm unsure if the original LoadCollisionData macro is used in the scrolling routines for the scrolling modules. If they are then this would absolutely destroy scroll updates because it needs to specifically load columns while this routine is optimized to only stream each collision nibble one by one. Also like I said, this current setup loads the same screen collision data to both PPU nametables, so as-is it's not meant for scrolling games. Feel free to experiment with it though, just make sure you got backups ready beforehand.

 

[Jonny]

Ah ok, I understand now. Cheers. I'm actually planning a single screen game too so I can still try this.