"Touch input interpolation" here is rather simple: it does a simple linear interpolation against the touch values between the last frame's touch position and the current frame's touch position, using the current frame cycle count. In case the last frame wasn't touching anything, it just touches immediately.
The API presented here was originally intended as a way to try to avoid merge conflicts. It is intended that before RunFrame(), the user would call MoveTouch(), then call TouchScreen() once RunFrame() returns.
Alternatively, TouchScreen() could be solely called before RunFrame() (this would probably be what the libretro port does, maybe some other ports). This however will run into issues for some games which do not like immediate changes to touch input every frame, rather needing touch input to go slowly across the frame, as touch input gets polled multiple times in a frame (see https://github.com/TASEmulators/BizHawk/issues/3397).
melonDS Qt doesn't do this however, instead just calling TouchScreen() within mouse event handlers, i.e. within the UI thread, not the emulator thread. This does end up making it (at least seemingly) avoid issues with games not liking exactly per frame touch changes, but it is just a giant race condition and probably should be changed.
This pr allows for configuring the framerate target and adds support for two other framerate targets, a "fastforward" and "slowmo" target which can be enabled via either a toggle or holding a button.
this allows for supporting a more accurate framerate target and allows for users to slow down the speed of gameplay if they so desire
* maintain precision until all lights are calculated
fixes lugia on the soul silver title screen
* small optimization
* small note
* small cleanup/notes
shouldn't need to check that every time, since the variable shouldn't be able to overflow
* hw doesn't cap difflevel at 255
Should it cap at all?
Can vtx colors overflow...?
* diffuse level appears to be shifted right by 9
fixes some minor inaccuracies
* improve specular lighting a little
* small improvement to diffuse lighting
fixes a few off by ones
- finding by azusa
* small tweaks
* handle overflows of diffuse lighting properly
-credits to azusa once more
* attempt at improving specular lighting calcs
still far from correct, but its a start.
fixes: https://github.com/melonDS-emu/melonDS/issues/1545
* meh
* improve specular lighting further
* add notes
* theory: add half vec instead of subt 1
* implement azusa's specular lighting algorithm
* fix minor edge case with spec lighting
* give proper credit in comments
* fix some bugs/misc tweaks
* more quirky overflow/underflow handling
* fix a spec lighting edgecase
remove some redundant parentheses
* fix an edge case with light vector calcs
* spec recip uses a different calc for light dir?
also remove a check that shouldn't be mathematically possible to trigger
* nvm that thing i thought couldn't trigger was required
also move reciprocal calc into the light vector calc function since i might as well now ig
* replace a bunch of stuff with much *much* simpler algorithms
* misc cleanup
PARENTHESES WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
* leave a note abt shininess table's default value being incorrect
* Resolve symlinks to avoid including the same thing twice (like
version-numered dylib symlinks)
* Look in all Qt prefix paths for plugins - the package may not
necessarily have the same path
* reduce install_name_tool invocations to make it a bit faster
* change dylib IDs to remove original source path
Adds a Nix flake, allowing easy building and running of melonDS using the Nix package manager, as well as potentially very stable and reproducible CI in the future.
* 0 dot disp defaults to the 24 bit integer limit
* useless correction
it goes through the reset function to set the variable on boot anyway but why not have the initialized state be correct too
* Make `EmuInstance::cheatFile` use a `unique_ptr`
- Fixes a memory leak, as the cheat file wasn't cleaned up in the destructor
* Split `AREngine` and `ARCodeFile` apart
- Suitable for frontends that have their own way of storing cheats
- Store the cheats in `AREngine` in a `std::vector`
- Apparently cheats are _supposed_ to be executed each frame; I didn't understand this until recently
CasualPokePlayer