Basic Savestate

[Piiman]

4

Added a Savestates button in the main menu and its corresponding screen (images attached)

Main menu

Savestates menu

The arrows cycle throgh the save slots, the load button executes the emulation_lstate function, save button the emulation_sstate function

The savestate file is created inside the directory vb_savestates/{rom name}/ it generates the directory in the same address where the rom is

As of now for each rom you'll have access to a whopping 10 savestates

This was tested with Jack Bros and Mario's tennis

[skyfloogle]

This is a good start! There's a few things that currently aren't recorded in the savestates such as the sound state and some static variables in the interrupt checkers, and I don't want to put this out to the world before that's sorted out, but the UI side looks good.

[Piiman]

Thanks for checking the PR!

Yes, I noticed that when you load a savestate the sound gets lost until another track gets loaded, and for the ui I also wanted it to display the time and date of the save below the text State X, but I haven't had much free time this couple of days, might look into it on the week end

Also, regarding the directory in which the savestates are stored, I was wondering if it would be better to save them inside a folder at the root of the sd instead of where the rom is located, this because the function get_savestate_path turned out more complicated than I thought it would be, what do you think?

[skyfloogle]

I'd generally go with the precedent set by other emulators. That said, there's a bunch of things it would need to save, considering other frequently requested features. Global settings, per-game settings, savestates, output from the 3dslink clone, potentially debug dumps. Maybe it's best to make a directory for Red Viper to put its stuff in, like sdmc:/red-viper?

[Piiman]

sounds good, I understand that there would be a subdirectory or file for these features (sdmc:/red-viper/savestates/, sdmc:/red-viper/settings.ini, sdmc:/red-viper/debug/, etc), I'll implement it just for savestates for now, this would adding the path to the current settings file, creating the base directory on startup and creating the savestates directory (don't know the timing yet tho), but overall I think this would be a more standard practice and would make implementing new features easier in the future.

[eku]

Please check for return codes of library calls and act on errors instead of crashing the emulator.

[skyfloogle]

I think this is in a mergeable state now. Thank you for the contributions!

[eku]

Too bad that return values are not checked and the emulator crashes. There was no lack of hints for improving the code.

[skyfloogle]

I did make some improvements. I checked the longest possible file path and allocated with that in mind, and I changed the savestate format so that it's checked continuously for validity while loading and not applied until it's confirmed to be valid. Any failure during savestate code will simply show an error screen, and return to the emulator cleanly. Everything specific that you pointed out has been addressed, except for malloc calls. As far as malloc goes, the emulator is pretty careful about allocation. Most allocation happens at boot time. The only allocations after that are in menu-related code, and they're small allocations that are freed as necessary. If malloc fails, I honestly want the emulator to crash, as that indicates a programming error. Of course, ideally everything would be statically allocated, but I haven't investigated the implications of that. If you feel that I missed something important, you're welcome to send in a pull request.