2.5 rollup

[NobodyNada]

(At least I'm assuming we're gonna bump the minor version. It's a big release; surely we've earned it!)

This PR is a rollup of all the stuff we've done so far for the next release. We've made a lot of sweeping changes to a lot of things -- and we've got 8 branches currently. Unsurprisingly, there's merge conflicts and bank conflicts that prevent us from doing a straightforward git merge.

I wanted to test all the changes together; both for the sake of ensuring everything is bug-free when combined, and just so I have a usable practice setup on my MiSTer (tinystates and fast-doors make a huge difference for me). So I merged all our PRs into one, and resolved all the conflicts. I'm opening this PR so that 1) testing is easier, and 2) we don't have to deal with the conflicts again as we continue to develop more features and get closer to release.

PRs included in this rollup:

• 92

• 94

  • NOTE: includes my patch to fix BG2 corruption in large rooms, as opposed to IFB's proposal. We can easily swap them out if needed.

• 97

• 99

• 100

• 102

• 103

• 101

---

Note that we are NOT ready for a release yet, and I'm not trying to push for one soon -- there's still plenty of work to be done. This PR is just to roll up our work so far so that we don't have to do an 8-way merge every time we want to test something.

As we continue development on our active branches, I think the best way to manage things in Git is if, before adding commits to another branch, we make sure to first merge this branch into that other branch. That way further development happens on top of all our changes here & we don't end up with more conflicts.

[NobodyNada]

As a nice bonus: we now have prerelease .ips patches autogenerated for this branch by GitHub Actions: https://github.com/tewtal/sm_practice_hack/actions/runs/2909544435

[InsaneFirebat]

Thanks. I tried to do this last week and GitHub's desktop app couldn't find the pull branches. One of these days I'll learn how to command line.

I pushed a couple cleanup things and a fix for controller shortcuts that idlechild mentioned. PR #101 is ready to merge as well. All of the Terminator presets have been fixed to remove bomb blocks, and those last few blue suits were just missed in the cleanup.

[InsaneFirebat]

Do we have any blocking issues remaining? I've put in a good amount of testing on this build and haven't found anything worth noting (aside from TinyStates issues now addressed in that pull thread).

[NobodyNada]

I still have a few minor things that I’d like to wrap up. I’ll try to get them done this weekend.

• 104 (should be really easy)

• 100 needs docs, and a couple addresses need to be changed for PAL

• One of the menu options on the Preset Option page is garbled

[InsaneFirebat]

My recent commits to this pull added docs for your new features and fixed that menu macro. I forgot about the PAL addresses. I might go ahead and find those for you if I have time today.

[InsaneFirebat]

Looks like you already covered the things that needed PAL attention. The rest (three addresses marked TODO PAL) are identical between PAL and NTSC. The build script for PAL tinystates was setting SD2SNES as well, so the build was failing. I fixed that and cleaned up the TODO comments.

[NobodyNada]

Sweet, thanks! I’m gonna eat some lunch then I’ll see about the loudpants change, should only take me a few minutes.

[NobodyNada]

Okay, the loudpants change is pushed. I also pushed a convenience change that I found helpful but that we might want to back out and save for a later update. Before a2ae88d, we didn't restore the infohud WRAM upon loading a tinystate. This meant segment timers got messed up, but it was actually really convenient to be able to go in the menu and change settings (e.g. RNG control or magicpants) and have those changes persist across savestates. So, I changed that commit to only save the first $1C bytes of infohud WRAM, so that the timers are restored but settings persist.

To maintain feature parity, I also modified the SD2SNES version to skip saving/loading the non-timer portion of infoud RAM.

This could probably do with a little playtesting before being released as I could have messed up some of the pointer math, or forgotten to save/load something important.

As long as we don't find any bugs in that though, I'm good to release if everyone else is.

[InsaneFirebat]

I think the persistence change could give bad data in whatever HUD mode or other features are active. I made a list of the addresses I think you're interested in keeping. It's just the flags that enable/disable features. https://pastebin.com/NGC2ESs9 It's a lot of addresses to deal with, but we could move all of them into their own block of $40-50 bytes from $7EFDB0-7F for flags that should persist through loadstates. That would let them easily be excluded from the loadstate DMA.

[NobodyNada]

@InsaneFirebat Awesome, thanks for doing that! Since the savestates decide which addresses to save based on the WRAM_PERSIST_START macro, it's easy to categorize RAM based on persistence, and to update the categorizations later.

I added a couple addresses to the persistence list that looked like they should be there: ram_suits_enemy_damage_check, ram_suits_periodic_damage_check, ram_freeze_on_load and ram_game_mode_extras. Most of these are things that are dynamically calculated when menu items change, so they need to be kept in sync with the other menu RAM, not with the game state.

[NobodyNada]

I also cherrypicked your tinystates graphics corruption fixes: 5c1a575

[InsaneFirebat]

ram_suits_enemy_damage_check, ram_suits_periodic_damage_check, and ram_game_mode_extras are updated in init_sram_from_wram which runs from post_load_state. All looks good. I'll try to find some time to play with the build tomorrow.

[InsaneFirebat]

I've added a couple fixes for builds with !RAW_TILE_GRAPHICS disabled. This will be needed for hacks, or if we ever run out of space in ROM and need to cut some of that data. TinyStates uses two routines that load from pre-decompressed graphics. These are easily replaced with vanilla calls. Fast doors/elevators uses optimized_decompression, which was living in tilegraphics.asm. Moving that routine to misc.asm includes it in all builds.

I'm pretty happy with the build we have now. I'm not aware of any outstanding bugs.

[InsaneFirebat]

Anyone opposed to pushing it out this weekend?