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
menuhax-v2 branch: Menu memory and usability improvements. #249
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…the title DB. If a title was loaded by titles.c, we can simply take a pointer to it instead of strdup()'ing it. This should save a good amount of memory. GameInfo has two new fields, which take up space that was previously used by padding: - NameAlloc: If non-zero, the Name field was strdup()'d and should be free()'d later. Otherwise, it should NOT be free()'d. - DiscNumber: Disc number. Used for printing the disc number in the menu. Previously, this would be part of the strdup()'d game name. SelectGame(): - Reduce gamename[] to 65, since the maximum size of a game name is 64 characters. - Set NameAlloc and DiscNumber where appropriate. - Use DiscNumber when printing the game title. - When free()'ing gi[], only free() gi[i].Name if gi[i].NameAlloc is set. titles.c: - Increase LINE_LENGTH to 64 for performance reasons. - SearchTitles(): Return a const char* to the title if found instead of copying the string. This can improve performance a bit. NULL is returned if the title ID was not found. - FIXME: This is a linear search, which can be slow...
…ng SD or USB. This allows the user to switch between SD and USB without having to reload the entire application. TODO: If SD or USB is missing and/or doesn't have a games directory, the program will exit. ShowLoadingScreen(): New function that consolidates all of the "Loading" screen invocations and makes it easier to update.
- Show a message immediately on startup saying it's checking storage devices so the user doesn't think it's hung. This is especially true if no USB device is connected, since it takes a while for USB detection to time out. - Always show Nintendont version and HW information on message screens. - Use a common function to exit to the loader and display messages. If the 'ret' value is non-zero, the message will be printed in maroon, similar to how it was done before. The version information will remain visible.
…lectGame(). This function can return one of three values: - DEV_OK: Device is opened and has a "games/" directory. - DEV_NO_GAMES: Device is opened, but doesn't have a "games/" directory. - DEV_NO_OPEN: Device could not be opened. DEV_NO_OPEN is currently fatal, since the device needs to be open in order to handle memory card emulation and other functions. DEV_NO_GAMES will still allow for booting from game discs on Wii. (TODO: Make sure the "DISC01" entry is always added.)
If /games/ is missing, booting from disc is still allowed on Wii. If the device is missing, the menu still allows the user to go back. This should help for those times when you accidentally select the wrong device, resulting in Nintendont exiting to the loader instead of letting you go back and select the correct device.
It'll take a while to load 1024 games, but it's doable. Reference: FIX94#212
…pty. Similar logic in update.c. This fixes titles.txt loading when using wiiload to load Nintendont over the network.
I performed some benchmarks for loading the game list: - master (v399, gpt-support-v3): 0.964s - menuhax before switching to fgets(): 1.296s - menuhax after switching to fgets(): 1.298s - menuhax after binary search: 1.295s The menuhax branch seems to have added 0.3s of extra loading time, which isn't too significant. I'll try to cut it down with some more optimizations.
Use one snprintf() to create the base path, then memcpy() the actual filename after it. When clearing the filename for FST, just set the last character to 0. Benchmarks occasionally showed some improvement, but the difference was too minimal to be measured accurately.
(NOTE: v3.399 was skipped; that should have been the merge for gpt-support-v3.rebase-for-merge.)
Tagging issue #212, since this also extends the game list to 1,024 entries. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here's a rebased version of my menuhax branch, without the later debugging information commits. (Those will need to be redone once we switch to FatFs.)
I'm sending this PR now because some of it conflicts with the preliminary FatFs port, so I want to get it out of the way before rebasing.
Major changes:
I'll be rebasing the preliminary FatFs port on top of this. I have some ideas for optimizing the FatFs game list read code to make it not take 20s to load the list, and I'll commit those to another branch once they're done.