This uses the existing `Limiter` class (stolen from Metaforce) in `JFWDisplay::waitForTick`.
The limiter also now uses `SDL_DelayPrecise` internally on non-Windows platforms.
On Windows, the existing `NanoSleep` logic is untouched, as it appears to provide a
more stable framerate for the folks testing it on Windows than `SDL_DelayPrecise` does.
On Linux, however, `SDL_DelayPrecise` is plenty accurate.
* Disable waitForTick and waitBlanking
* Initial frame interpolation implementation
* Initial batch of speed fixes
* Fix Iron Boots
* Strip dead code once used for debugging
* Interpolate shadows
* Revert overzealous/redundant lookups
* Fix JUTFader
* Fix field map cursor
* Fix various particle effects
* Fix Midna when riding Wolf Link
* Fix title logo
* Title Logo 2: Electric Boogaloo
* Fixed grass and flowers
* "Unlock Framerate" config option (WIP)
* Wrap more things in TARGET_PC
* Finish wrapping things in TARGET_PC
* Missed one
* Disable dComIfGd_drawXluListInvisible when interpolating
---------
Co-authored-by: Luke Street <luke@street.dev>
* CI attempt
* syntax
* fix cmake for linux
* fix include directories and merge main
* fix PDB fighting
* fix gcc compiling
* fix SSCACHE for windows
* try and fix gcc
* more CI presets
* remove the android target for now
* bump cmake minimum to fix debug information format
* yet another attempt at fixing gcc
* yet another attempt at fixing gcc
* better CI matrixing
* yet another attempt at fixing GCC
* fix arm
* fix CI
* placeholder icons
* compile dawn from source for windows arm64
* fix icons and linker warnings
* fix cmake
* fetch libjpegturbo
---------
Co-authored-by: Luke Street <luke@street.dev>
Caused by a size that should've been sizeof(CMemBlock).
Simple way to repro was to open and close the full map on dpad, afterwards heap check would fail.
From my reading of the code this assert is likely incorrect. This throws on cases where usize has a sane-looking value (the length of the pContent null-terminated string), and from my understanding of how the data is parsed, this length is needed to figure out the location of the next "paragraph".
Happens for me when loading a save in Death Mountain Twilight. Confirmed in Dolphin with the same save file.
PowerPC does not raise an exception on division by zero, so I assume this is an original game "bug"