finally trying to use some of the art i justified making because it was concept art, by using it to do some mockups
sisters7.png
sisters6.png
light_mockup.png
pyramid_mockup.png
sisters_meet_mockup.png
moon_mockup.png
sauna_mockup.png
kaleido_mockup.png
I absolutely love these ♥
thank you :smug:
i want to start developing these ideas more. i've never really written narrative fiction before, but i have some seed ideas now from these mockups that should get me started
i guess this is kind of something like "speculative storyboarding"
scream2.png
tapestry.png
started writing some structural stuff on this, nothing really to show yet. trying to just get something on the screen first, but there's a lot of pointers, pointers to pointers, pointers to lists, and lists of pointers
gonna see about doing some more mockups since i have my fill of programmering atm
probably gonna take another stab at this later but this is an idea. i also tried to imagine how to abstractly draw some dresses for them but nothing really came together
sisters_scene_dev.png
worked on the program part today, lots of boring structural stuff that took forever cuz i made fun mistakes but, celebratory image on crt now
PXL_20260316_022952701.jpg
i can now take any of my mockups or any static image and get it onscreen. next up, messageboxes. i have a system for this from another project i could adapt for this.
i am going to want to make or find an actually good 8px font...
in_emu_sisters.png
robot past is in our future!! :catgirl:
there's still a lot to do, but it feels good to have "a program that does something"
it won't be that much work now to transition between scenes and put text on the screen
conceptually, after that, i need some kind of game to stitch them together. i am thinking top-down rpg thing so i don't have to program physics (or at least not really)
i was working on mockups for what that kind of isometric rpg could be but didn't get far last time i tried.
i should get the dialog scene and messagebox system working and then do some more thinking about the story
it's gonna end up like disillusion isn't it
it better
made a scene of this one
image-15.png
and also some variations.
could make a palette glow for this
it occurred to me that i'm once again starting to do something by focusing on details rather than larger more important elements first...
maybe something important happens there
Untitled.png
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
i had done mockups like this at some point last year
trying to imagine what this is
current state of the program
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
object system works! with collision. we have two object types now. one starts a room transition, one triggers some dialog
lot of debugging today just to draw these placeholder tiles that indicate locations of room transitions and text triggers
was happy with the player animation so i made a gif for showing it off
0.gif
also made a room out of the ice cave tiles
ice_cave.png
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.