Conversation
Still need music and theme IDs
This file contains hidden or 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
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.
Proposal/prototype for a new combined JSON config for wsmod. All per-stage configuration (ID, name, theme/music ID, time limit, warp goal jump distance, etc.) is grouped by stage and organized in story/challenge layout sections. See
default-config.jsonfor a mostly complete configuration of vanilla SMB2.Config parsing is working at both the JSON and config format level, but implementing the story/challenge configs in-game is still TODO.
I'm using ArduinoJson to parse the config which is meant to be a small code/memory size and ergonomic JSON parser. One issue is that if there's a JSON parse error you can't retrieve a error location/message, but the library's simple enough it looks eas y to add at least a parse error location if needed. I have an error suggesting people use an editor like VSCode to look for JSON parse errors as well, since it's a standard language and all. On the contrary, errors parsing the config format itself are much better IMO.
Also, the plan for memory management is to do all parse-related allocations in a separate heap allocated in a block at the end of the main heap which is freed after all
init_main_loop()functions are called. The idea is patches read from config and do their thing, copying from the parse heap and/or writing to the game's memory under the assumption the parse heap will be freed. A separate heap prevents heap fragmentation.