robot past

[RT-55J]

it better

[neen]

made a scene of this one

[neen]

and also some variations.

could make a palette glow for this

[neen]

it occurred to me that i'm once again starting to do something by focusing on details rather than larger more important elements first...

[neen]

maybe something important happens there

[neen]

i think i've decided i also want top down isometric rpg gameplay. maybe need to start working on that part of the program soon

[neen]

i had done mockups like this at some point last year

[neen]

trying to imagine what this is

[neen]

current state of the program

[neen]

got some basic text string stuff done today. not super exciting but it works.

i think some kind of interactible object should be started relatively soon, and with that comes collision. one such object could initiate room transitions.

the player sprite stuff is a mess right now, but still, it exists so it can be improved

feels good to make progress

[neen]

object system works! with collision. we have two object types now. one starts a room transition, one triggers some dialog

[neen]

lot of debugging today just to draw these placeholder tiles that indicate locations of room transitions and text triggers

[neen]

was happy with the player animation so i made a gif for showing it off

[neen]

also made a room out of the ice cave tiles

[neen]

started working on this again and did the following:

player character is drawn with spritemaps now. it looks exactly the same but it's not all hardcoded anymore

wrote spritemap offscreen handling and then a system for entities/actors using sprites. in glider the whole system was called "enemies" but now they are all "fae". the offscreen handling for sprites was one of the more difficult routines to write in awhile but it was nice to get it working.

the area of memory (OAM, object allocation memory) that stores hardware sprites on the snes is mostly straightforward, four bytes per sprite: x position, y position, properties like h/v flip and palette, and the graphics tile to use. OAM is split into two different tables though, and the high table uses two bits per sprite (four sprites per byte). so there's some bitwise math to figure out how to address these bits. in glider i did not bother with this at all and so the two bits in the upper table are fixed in place for all sprites. those two bits toggle the sprites size (small or large, which is selectable) and the 9th bit of x position that is necessary to have sprites be partially offscreen on the left side of the screen. this is all implemented now.

i'll probably think of a demo to write to show off the fact that we have proper offscreen handling for sprites other than the player.

the spritemap routine is at the top of the file here and it was a doozy. https://github.com/n-neen/robot-past/blob/main/src/fae/fae.asm

this system is barebones right now but i can start adding features as individual fae need to be added.

phew.