-
Notifications
You must be signed in to change notification settings - Fork 20
Add boot-to-menu functionality #201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
on non-Windows platforms, this isn't caught by tools/*.exe
Add an option to boot directly to the InfoHUD menu instead of the Nintendo splash. The sound engine is also loaded asynchronously in the menu, elimiating the delay for it to initialize. This reduces the time from power-on to practice menu to about half a second. The option is under the Cutscenes menu.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Transferring SPC in the background, fancy!
I'm mostly trusting you that this works. I like that it's off by default; it's easy enough to turn it on if you want to. I also like defaulting to controller bindings from first save file if available.
...to prevent conflicting SPC register writes. I don't think this could cause any problems, but it's best to be safe.
I was thinking, perhaps the development build could default to skip nintendo splash screen and go straight to menu. I think the regular releases should stay as they are, but making the development build default to the faster boot up makes sense. |
Great thinking! I've implemented that. I didn't make a new SRAM version for it, so it will only apply when booting from fresh SRAM. This solve what seems (to me) to be the most common use case for that feature: booting a dev build in an emulator environment that doesn't preserve SRAM (anyone else can just enable it manually.) I also pushed a commit that removes the old fast splash option, as this seems to take care of most of the reason you'd want that. This lets us reuse the SRAM bit for that option, which means that people upgrading from older versions will automatically have quickboot enabled if they had the fast splash option before. If this is undesirable it can easily be reverted. |
this is what i get for committing at 1am
It gets stuck in a loop if you soft-reset and then try to exit the menu. Never makes it past the first branch in
|
Great catch. I've pushed a fix to only initialize the SPC after a hard reset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've got some + branches in menu.asm that idle has been trying to get rid of, but looks good to me.
Ah, I didn't realize we were trying to clean those up. I normally avoid them, but I used them here since I thought they made the common idiom of "increment + check for overflow" easier to read than with an explicit label. I can replace them with explicit labels (or perhaps a macro) if desired. |
Not really a blocker imo, but the menu is triggered when pressing B at the file select menu. |
Ha, apparently pressing B on the file select menu triggers a soft reset: https://patrickjohnston.org/bank/81#f94D5 I'm inclined to leave it as-is, because it's simpler than changing the code to do something other than a soft reset (though changing the game state to zero would probably do the job.) |
lol I'd say keep it then |
Merged with #202 |
Add an option to boot directly to the InfoHUD menu instead of the normal title sequence. This reduces the time from power-on to practice menu to about half a second:
quickboot.mp4
A large portion of the boot time is spent uploading the sound engine to the SPC. To eliminate this delay, we load the SPC engine asynchronously in the background while the user is browsing the menu. (Don't worry, if the user exits the menu before the SPC finishes loading, we wait for it to finish first.)
The functionality is currently disabled by default, but can be enabled in the cutscenes menu. (Although enabling it by default might be something to consider as it would be convenient for TASing.)
Since this increases the likelihood of users selecting presets before selecting a save file, I've also made a tweak to @InsaneFirebat's work in 983e808. Instead of detecting blank controller bindings and setting default bindings, we load the last used saved file after booting, or a default save file if none exists. That way we'll use the user's saved controller bindings and settings instead of the default. This applies both to boot-to-menu and the standard boot sequence.