glider pro on the snes.
it started in 2016 when i emailed john calhoun, author of a series of macintosh games being released from 1988 to 1994. i asked him to post the source code online, and i had no idea why.
the original glider (1.0?) i have never seen, it may just be a myth. glider 2.02 has pascal source code somewhere. i might be able to find it on a hard drive. glider 3.14 too. all these early versions are 15-screen long arcade style games. single screen, no scrolling.
glider 4.0 was also written in pascal, in 1990-91 but this time had 16 colors and a level editor.
glider pro was written in C in 1994. even larger worlds, a much better editor (bettitor?), 256 colors, and was one of the first video games i played. i posted some houses online in the summer of 2003 or 2004 to a yahoo group. this was basically the end of online glider community, as far as i'm aware.
a few days ago i started looking at the C source of PRO with the intent of... well, something, i guess. snes homebrew is something i had been thinking about for a few months, after getting deeper into snes architecture and programming after romhacking super metroid for about 3 years.
so, here are some highlights of failed attempts to display a static background on the screen, which took about 2 or 3 days (yes, seriously, like 8 hours a day). i am not sure i really need toe C source at this point (or ever) but maybe once i get to the point of making an actual engine it will be useful.
and finally it came together today. this is actual snes emulator output, and finally, on a real console. here's the github repo https://github.com/n-neen/glider , you can open it in a snes emu and be amazed at the nonmoving background. you'll probably see some garbage sprites if your emulator is accurate enough.
next up is to learn how to apply the skills we have with doing DMA to load sprites into OAM. well, first clear OAM to initialize it, because we have not yet done that.
aw yeah this looks nice
the only real progress has been structural. i have implemented a state machine. after boot and some init, we drop into a state handler loop.
state 0 is the splash screen. we load graphics, tilemap, and palettes, then wait $80 frames. increase state to 1.
state 1 is the newgame preparation. right now this just loads a static background and some sprite graphics get uploaded to vram. also load new palettes. this is where the level data will be loaded and anything else for preparing to play the game. then increase game state to 2
state 2 is where gameplay will occur. currently this is a loop where we wait for nmi over and over.
oh yeah, non-maskable interrupt handler has been implemented. this is where sprites will be updated when that occurs. also we will read the controller port here. anything else that needs to happen while the electron gun is not drawing to the screen will happen now, too. set up dma, whatever.
main: {
.stateinit: {
lda #$0000
sta !gamestate
}
.statehandle: {
inc !maincounter ;main switch case jump table loop
lda !gamestate ;usually, state handler will
asl ;return after running once, like newgame
tax ;or itself has a loop, like playgame
jsr (statetable,x)
jmp .statehandle
}
}
statetable: ;program modes, game states, etc
dw #splash ;0
dw #newgame ;1
dw #playgame ;2
dw #gameover ;3
this is the core of the state machine. the rest is in https://github.com/n-neen/glider/blob/main/bank80.asm
this is the splash screen, with a palette i was playing around with. currently we just proceed from this to the static room background test from earlier. i need to figure out how to read the controller next (happens during nmi).
ooh that's a very nice title screen
made a debug state handler and enabled debug mode. you can use the dpad to scroll the tilemap around, and you can press y, b, and x to change the background. i hope someday to display a sprite on the screen, but that day is not today
the first iteration of the controller response code is pretty naively written as a gigantic switch case with cmp instructions. yuriks gave me a tip on how to rewrite it so we will have the ability to press multiple buttons at once! more details to follow
controller reading is fine now, gotta use the bit instruction, not cmp, and check each button in some order.
initially, backgrounds were on layer 1. today, i moved them to layer 2. the idea is to use layer 1 for a mostly transparent tilemap where objects like furniture exist. this means we want to define a type of object for modifying part of the layer 1 tilemap to place objects around the room.
i worked some on glider movement at some point, but got kind of fed up with trying to understand metasprites and how to program a system to interpret them. i might look at if any open-source libraries exist so that i can avoid having to write this myself.
but that will be whenever i work on this next, which will not be for a bit, as i swung back to sm hacking for the moment.
i find this pretty rewarding to work on, but stuff has slowed down considerably since the first two weeks.
ended up picking this back up. i have defined a spritemap format (https://github.com/n-neen/glider/blob/main/data/sprites/spritemaps.asm). it's really not all that different from an oam entry, except the x and y coordinates are offsets from the center of the sprite object instead of relative to the screen
the current loading routine (https://github.com/n-neen/glider/blob/main/bank82.asm#L198) is all hardcoded but at least the glider is whole, now
and am trying to rewrite the routine to load the spritemaps from spritemaps.asm, here (https://github.com/n-neen/glider/blob/main/bank82.asm#L272). but i was very tired last night and it's not done yet
watch this space for me to hopefully update later. i also have been thinking about streaming snesdev but it might be a pretty meandering stream
yay spritemaps.
(i haven't figured out spritemaps myself for the SMS)
much has been done, i will write a proper update when i am less tired. but:
glider can move, furniture and other objects exist, and the room format has been basically defined. i had been hardcoding some routines to load objects first but now we have a proper list of object instances and i can load an entire room from room data.
next is room transitions
oh yeah here is room transitions working. i also wrote the stairs part last night but i haven't uploaded a video to youtube yet
With vents, room transitions, and stairs working, you're literally 90% of the way to a minimum viable product code-wise. That's a very exciting milestone!
Hot dang that's really coming along!
What's left in terms of core game systems? Other sprites and music?
enemies, powerups (both going to use sprites), music, yeah. there are open source spc engines around, which is very good because i do not want to learn spc stuff at all.
there is also a basic hud system and points, like an arcade style game, but that's probably going to be on layer 3 on the top of the screen and not that interesting to write. the game uses clocks as a point-giving prize object. cuckoo clocks being worth the most :smug:
we now have our first object type that can be given a size parameter per instance: the mighty shelf.
eventually, tables will work the same way, but more complex: tabletop of variable length, and the pole part in the center of variable height. this will be somewhat more complex as i need to implement it as three separate objects: the base, which keeps the dimensions in its parameters, and spawns the top and stem objects in its setup routine.
spent most of the weekend implementing enemies. started collision this afternoon before work and just got it working tonight.
nice!
the collision is a little jank when going horizontally but it can be improved hopefully. but yeah otherwise I'm very happy with this
did a reasonably large file restructure, and renamed the project so the repo has moved to https://github.com/n-neen/super-glider
previously, modules were fixed in place in a known bank and code elsewhere had hardcoded pointer base addresses, but now all modules have bank defines at the top for easier long pointer reads.
e.g., bank80.asm is now main.asm. bank81.asm contained loading and dma routines, but is now loading.asm. the top level file includes both main.asm and loading.asm in bank $80.
this isn't all that important, but it feels cleaner to me now, anyway. the rename is because i caught wind that the original author does not like people using simply "glider" as a title for the project, so i renamed mine "super glider"
hey
@veni-vidi-ascii check out the ascii logo for this project
https://github.com/n-neen/super-glider/blob/main/super_glider.asm
oh, hehe i have been meaning to finish that. i guess the word "GLIDER" also gets some fancification but idk how to do an uppercase 'r'
did a basic bg3 implementation for a hud, although no logic to actually make the numbers to anything
i can imagine that font fitting right in between the lines on some notebook paper. very nice
hud works now
wrote light switches tonight. also at some point i made the balloons shootable (ballootable?) and with the proper balloovement
two main things implemented since last i posted are:
-enemies can now pass data between rooms. main use is for switches to be able to turn things off or on from across the house. there is a table in ram that contains a record of: room number, enemy number, and enemy property. when loading a room, if an entry in this table exists for any of the enemies in the room, we swap out the default value for the new one. it remains to be seen how good of an implementation this is.
-prize objects (extra lives, powerups) now record a bit in a bit array when collected and do not reappear when the room reloads later
we are now capable of Drip https://www.youtube.com/watch?v=AlXWiFhQOUY
it has come up more than once that animating a spritemap with the global timer and simple bitwise math on the pointers is not adequate but i keep doing it anyway.
i need to reorganize the enemy code so that:
/src/enemies.asm
/src/enemies/nameofenemy.asm
and enemies.asm has the main implementation of the system and incsrc individual enemies in order at the bottom. but it will take some work to shuffle these routines around and change all the references to them. so in the meantime, i added headings for the different sections in enemies.asm.
also wrote the initial foil implementation. it only works on enemies, and i might keep it that way.
i have decided that i want to write The Cat from classic glider. overall, the project feels more like glider 4 than pro, so i am once again tempted to switch the art over.
attached: comparison betwixt the "simple room" and stairs from glider 4 and pro
started the graphics for the cat today. this is art by john for the shareware game, originally 1-bit, colorized by me for snes. it's all in snes format now ready to go but the image of cat in place is a mockup because i am too tired to write the spritemaps and stuff
cat needed a rewrite/restructure because the existing enemy stuff only works for really simple enemies (so, most of them work fine)
so, took a break from cat to invent fire
implemented a couple enemies and a new background type. it's looking like the end is actually in sight, which i could not have really imagined a few months ago.
i need to rework the room object that deals with walls. the current system is thus:
the background tilemap consists only of the base room, with both walls. in order to open the walls, two things happen: the "openwall" object is put in the object list, and the bound bit for that wall is removed. the openwall object has a single tilemap that uses teh same tile index numbers for every tileset. the problem is that not all room graphics align to 8x8 pixel tiles in the same way. so i have been thinking about making a new system for this: make a list of openwall tilemaps that gets picked based on background index. it'll take up more room and it'll be more work for every new tileset (backgroudn type) added, but it's the only way to make sure it works for all of them...
surely it'll work for left and right in the wame way, too, right? :smug:
also, i used a tool (superfamiconv) to lay out the gaphics for this tiled room background (either a bathroom or a kitchen) but i forgot that i had laid out the others by hand so that the openwall object could make sense for all of them. the superfamiconv output definitely takes up less space but it's not exactly sanely laid out for a human to work on. might have to redo that by hand
i think a better way of describing the openwall object problem is this: some graphics align to 8 pixels horizontally but some only align to 16. so the width of the tilemap that needs to be updated could be off by 1 tile, which is also a problem. so, if i make new tilemaps for every background type, some will need to be 5 tiles wide, and some 6
ah screw it, it's not going to be that much work. let's dew it
that was ez :smug:
https://github.com/n-neen/super-glider/blob/main/src/openwall.asm
now time to make new tilemaps for each backgroudn type. then the walls will all work properly
............................
unless i need to rework this again for left/right wall types. lookin at you, wood-panneled room
pictured: wall problems that i aim to solve with this
notice the brick patterns are wrong; it would be hard or impossible to make this one tile pattern work for all background types. so this will be fixed as soon as i can make a new tilemap for the basement background type. the wood-panneled room problem is still not solved yet, because left and right are not the same as it is now.
so this is the basic description of what i need to now do
once this is all done i can make a handler that checks the room bounds bits and spawns these objects automatically, so they can be removed from the object list.
this is all basically done btw. every background type (tileset) now has its own openwall object tilemap and tilemap width. hopefully this covers all cases for rooms with more complex tile patterns. compare wood panneling here to the above
did 2 backgrounds tonight. a third, the library, was too large to fit into the normal area for background tiles. need to figure out how to cram it into 240 8x8 pixel tiles.
the process for backgrounds ends up like this:
copy the original background PICT from ResEdit, and get it into Paint dot net. reduce the image from 512x322 pixels to 256x224, with careful pixel editing, no scaling. (see the stairs comparison for an example of the scale change needed.) quantize colors down to 15 at most (don't like using the backdrop color)
the 256x224 pixel bitmap is fed into superfamiconv, which spits out: 4bpp graphics, palette, and tilemap.
put the graphics, tilemap, and palette into the rom. make loadingtable entries for the dma routines. create an openwall object tilemap for the tileset and put that into the rom (this kinda sucks, and the swinger's room doesn't align to any multiple of 8 pixels from what i could see, so there's a slight error on one side, but it's not too bad)
implemented a new system for a room loading a special tilemap, so we can load different tilemaps from the same set of graphics. used this to implement the ending scene of the game. but it isn't quite finished or put into place yet
trying to make variable sized furniture. almost there. the four parts (main object, top, pole, base) all mostly work but they don't locate the pieces correctly yet
o yeah, it works now. just imagine a table that works, and you will have imagined what it looks like now. (similar to the above images, but without the parts that made it not work)
functional furniture is always good
finally, a place to put my brain garbage.
this was a manual recolor to fit inside the existing palette so i didn't have to use new colors. went ok, the rim is a little weird, might try to fix that
some things done since last post:
-walls can be placed in the middle of the room like shown, allowing for Room Variety
-a couple of invisible objects that exist only to provide collision types, like: act solid, kill, provide lift
-new object types like fireplace, and manholes for the sewer tileset (do not currently work)
one thing i decided to deviate from on glider pro's design is that: in glider pro, you an go outside and explore a ton of different environments. in fields, on roofs, multiple houses, etc. and so the goal of the game changed from 4.0 to pro, from "leaving the house" to "collect this mcguffin". i decided to stay indoors, partly because it reduces the number of backgrounds i need, but also it seems like an easier goal to believably satisfy. you leave the house at the very end and go into the sky.
i did want to at least taunt the player with the idea of outside a little bit, so i made this scene. maybe could fit in some special graphics like a clothesline, clouds, a bird, who knows.
looked back at the first post just to feel accomplished at how much i have done :smug: