snes homebrew: super glider

[neen]

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

[neen]

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

[neen]

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

[neen]

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?

[neen]

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

[neen]

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

[neen]

that was ez   
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

[neen]

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.

[neen]

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

[neen]

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)

[neen]

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

[neen]