- Fixed some typing or naming errors resulting in compilation warnings
- No longer show errors for ENOENT
- Adjusted some things regularly causing merge conflicts
All those things are fixed in dev branch but people tend to use master as a basis for their fork (which is usually a good idea!), and those specific items have come up in the issues.
So I'm exceptionally committing those fixes to master between releases.
I refactored spc700.c:
- Replaced jump table by a switch. I'm aware that they're essentially the same thing (given our range), but the generated code is ~9KB less, so...
- Removed unnecessary inlining
Doesn't seem to have any performance impact, if anything it is marginally faster...
Possible improvements:
- Grouping identical instructions will reduce size further, but it might break the switch optimizations
- Finalizing the loop inside the function will certainly improve performance
When loading a ROM, retro-go calcs the crc32 of the rom and searches for it in the database. If the CRC32 is 0, the last entry in the database will be selected, which is invalid.
This patch just confirms that the selected entry is valid.
A proper patch might be to not search the database at all if we don't have a crc function. But that would change multiple lines versus just this one!
It's unfortunate but 0 causes audio glitches in some GBC games.
I will have to evaluate the best value for every console and not use a global default...
The advantage is that the menu entries are generated on demand, so they'll always be up to date irt language.
I think it would be better if the options_handler was in charge of showing the dialog too.
It would allow in-app menus and it will also avoid the careless unbounded copying.
But this first step preserves the previous behavior.
retro-go now always maintains the expected time a frame should take (time between ticks).
I've added `rg_system_set_tick_rate` to replace `app->tickrate = N` to ensure frameTime is recalculated when tickrate changes.
* Innitial commit
Localization for retro-go using a simple 0(n) lookup function called rg_gettext()
* adding language settings in options menu
* adding more gettext()
* new lookup function
* adding "For these changes to take effect you must restart your device." gui alert + fixing gettext() function
* modifying the gui dialog
* updating struct syntax
* update struct syntax (again)
* creating the python tool for localization
* updating tool + adding missing translations
* moving stuff to libs + starting writing readme
* adding missing "libs/localization" folder import in cmakelist + added the "fixme for rg_system"
* synthax adjust + moving back stuff from libs to retro-go
* removing trailing spaces
* adding the enum for language ids
* updating documentation according to the latest changes
* small tweaks
* Moved LOCALIZATION.md to the root folder
Whilst it is mostly relevant to libretro-go, it really is project-wide documentation.
* rg_localization: Got rid of the switch, made GUI dynamic
This makes adding a language more straightforward.
I kept the *msg *fr *en for now to avoid updating translations.h, but it could be replaced by the GCC extension as such:
[RG_LANG_EN] = "...",
[RG_LANG_FR] = "...",
So that adding a language is really just updating the enum...
* rg_localization: translations is const, we can use RG_COUNT
* rg_gui: Fixed language selection
* rg_localization: No need to validate rg_language in rg_gettext
It should always be valid, there's no need to validate it.
* rg_gui: Show language name in the log
* rg_localization: Got rid of the Translation struct
I am not 100% positive this is a good move...
Benefits:
- One less thing to change when adding a language
- Less code is always better
Cons:
- It doesn't make it clear what the "key" is (the english text)
- If in the future we need to add things like flags it will have to be returned to a struct
* updated python tool + updating translations
* added missing translations
* audio filter wrong translation
* fix : "a propose de retro-go"
---------
Co-authored-by: Alex Duchesne <ducalex007@gmail.com>
More apps might want to use wifi.
The file server remains in the launcher for now. But it could make sense to move it to retro-go at some point.
Big part of the new code in rg_gui is copy pasted from the launcher and needs some cleanup...
This reverts the previous commit. Applications don't have to care about the presence of zip support, just that unzipping failed for any reason.
If an application really needs to know if ZIP support is present, it can of course still `#if RG_ZIP_SUPPORT`.
This adds zip support to GB, GBC, NES, SNES, SMS, GG, COL, PCE, LYNX, MD/GEN
The first file in the ZIP is loaded.
Still to fix:
- Be smarter about picking a file in the zip
- Reduce unzip memory usage to allow loading larger ROMs
- Maybe use miniz' ZIP implementation instead of my own
