Those tutorials got me started, but a lot of what I understand is thanks to Tokumaru, Quietust, and anyone else who took the time to answer my questions. I've been busy at work over the last two months, coming home mentally exhausted, but now am trying to pick this project back up.
- Used sprite 0 hit for a 2 name-table title screen.
- Stars (sprites) on title screen sparkle, because of a clock, which is a counter based on NMI hits.
- Music plays on the screens.
- When A is pressed a second "game screen" is loaded.
- CHR Bank switching; A new .chr file is loaded.
- A woman walks with some animation based on the clock.
It uses the entrances and exits to the sound engine - I don't understand the engine entirely. It is using the NN sample songs. My next goal is to write my own song. Also to make a text box appear when you press A over a certain area of the screen. Then get into multiple screens, NPCs, choices. I have a synopsis written for the game too. It's about personal stories of a few characters and some super natural topics like vampires, I think it'll be more like a story based game with some puzzle elements. Any tips or coding or suggestions would be appreciated. I'll update this as I hit more milestones.
Not much to say otherwise - you've got a tree growing in the middle of the street, and the lady can walk on the moon, which feels like it should be kept in the final game as an Easter egg. But it's definitely an accomplishment!
FYI, your reset routine has something wrong with it - if you reset (not full power cycle) after starting the game, the title screen is garbled, and if you enter the game again, it sometimes works and sometimes crashes.
- I have to figure out how to get rid of those blue dashes flickering on the title screen. When I move sprite zero even 1 pixel in either direction, it screws up the "full screen" image.
- I'll still have to set all the limits so the character can't go into the sky. There is only one right now stopping her from going up in the buildings.
Right now I'm trying to come up with a way to condense BG data, because I'm realizing that I can really only fit 7 full backgrounds from $E000 to $FFFF. My sound engine is at $A000 to $C000, and my game code is at $C0000 to $E00. It looks like I have $8000 to $A000 empty, so maybe I can fit another 8 backgrounds there. I'm wondering how games seem to fit A LOT more than that though.
your sprite zero hit polling loop is way too slow. try this:
Code: Select all
@wait_sprite0_hit_clr: bit PPU_STATUS bvs @wait_sprite0_hit_clr @wait_sprite0_hit_set: bit PPU_STATUS bvc @wait_sprite0_hit_set
remove duplicate tiles, compress the rest. i'm using donut compression, it reduces tile data by about 40%NeverCameBack wrote: ↑Sat Aug 01, 2020 2:14 pmRight now I'm trying to come up with a way to condense BG data, because I'm realizing that I can really only fit 7 full backgrounds from $E000 to $FFFF. My sound engine is at $A000 to $C000, and my game code is at $C0000 to $E00. It looks like I have $8000 to $A000 empty, so maybe I can fit another 8 backgrounds there. I'm wondering how games seem to fit A LOT more than that though.
Most games don't store raw name/attribute table data in the ROM. For static screens they'll often use some generic compression technique, such as RLE or LZSS. As for level maps, games usually take advantage of the fact that certain structures appear many times in different places, so they store these structures separately and reference those in the map, instead of raw tiles, making it possible to "invoke" larger blocks/structures using only 1 or 2 bytes.
In SMB for example, each screen starts out "blank" and the level map specifies where to draw everything (holes on the ground, pipes, bricks, etc.) in a very compact format. Mega Man on the other hand defines a set of 32x32-pixel blocks (commonly called metatiles) that it uses to build the levels, bringing the total size of a screen down to 64 bytes. There's of course the overhead of the metatiles themselves, but the overall savings are still huge.