Tuesday, December 23, 2014

Condensing my room definitions

I recently realized that I was doing it wrong in my room definitions. Previously, I was storing the addresses of each section of background wall data, like:

    .byte #<TestRoomLineDefsA   ;background definition.
    .byte #>TestRoomLineDefsA   ; The < and > signify low and high bytes of 
    .byte #<TestRoomLineDefsB   ; the pointer address.
    .byte #>TestRoomLineDefsB
    .byte #<TestRoomLineDefsC   ; Atari backgrounds are made up of 3 chunks
    .byte #>TestRoomLineDefsC   ; of data which is why there are 3 pointers.
    .byte #ROOM_COLOR_BROWN     ;room colors
    .byte #ROOM_COLOR_GRAY
    .byte #TOP_CLOSED           ;door flags 
    .byte #<EnemyDefSlime       ;what enemies are in this room
    .byte #>EnemyDefSlime
    .byte #3                    ;number of enemies
    .byte #NO_ITEM              ;any special items in the room

That's 6 bytes for each room that are used to point to the background data. Realistically, there's no way I'm going to have more than 255 different room backgrounds. (There's just not enough ROM space for it), so an int Id seems to make a lot more sense, with the assumption that all 3 sections are always going to be used together:

    .byte #ROOM_STARTING
    .byte #ROOM_COLOR_GRAY
    .byte #TOP_CLOSED 
    .byte #<EnemyDefSlime
    .byte #>EnemyDefSlime
    .byte #3
    .byte #NO_ITEM

Doing so, I've cut the space required for a room definition in half. That means I can have twice as many rooms in my game before I run out of space. I think that's worth it! If I get around to it, I could cut out another byte per room by changing the Enemy Definition pointer to an ID instead of a pointer, but I'm not sure it's worth the effort just to save a byte per room. We'll see how desperate I get for space by the end, though.....

No comments:

NNNNNN in 12 hours

I recently announced my NESdev competition entry for this year: NNNNNN , a multiplayer NES port of the Gravitron from VVVVVV .  Now that it&...