useful when some obscure window can overlay bizhawk while in mouse capture mode if the hidden mouse pointer is too close to it (pop-up panel on the edge of the screen in my case). topmost+fullscreen makes those unreachable, but automatic topmost is set to false since normally it's potentially bad
Previous implementation was broken and differed between the two in practice in the case of archives. Standard single file just passed archive loaded, without archive binding info. Xml case was even more nonsense, giving a completely nonexistent path using the internal archived file name. RomPath now will properly report the binding info in the case of archives. Cores should be very careful with using RomPath with file apis, as the | used for binding info is not a valid file char and will throw most file apis (some cores were already doing this, I've fixed most of the cores not doing so save for UAE and DSDA).
TODO: Need to fix the edge case of the file being in the same archive as the xml (represented specially in xml and that code path seems to already been broken)
"@" was used as part of a description string, breaking the parsing. Surely no description includes a newline... (is there a better way to do this?)
- closes#4288
There was no eviction logic so the reserved frames would accumulate and never be cleaned, leading to continuously increasing memory usage.
Additionally I don't know why they would need to be reserved in the first place
the core uses 2 bytes, but if we use that range then raw mouse input is automatically recalibrated somehow and sends values multiplied by 272. that way maximum actual value is 120 (after dividing the range cap by 272), which is even more limiting than shorttics. and min value is 272 itself, which is not very useful if we have to divide it, because we need it to be 1!
the range of [-180, 180] is somehow the highest range that still gives minimal movement of 1, while providing maximum room for bigger movement.
in vanilla doom, turn key + strafe key = strafe in the direction of the turning key. but if directional strafe key is added to the mix, both strafe speeds are ADDED TOGETHER. on top of that, max strafe speed is max vertical movement speed (50), NOT the speed you get if you strafe while holding the run key (40). all of this makes strafe50 possible in vanilla, and turning is impossible at that time (because strafe key turns turning into strafing).
* fix on_bus_read issue for genplus-gx core
- related to issue #3813
- update signatures, create new value variable in each of the memory read core functions, pass it to the callback and return it instead of the inline calculations. Also, pass val to write and exec callbacks in IDebuggable since they all use the same mem_cb signature and it would break otherwise. I want to update write and exec callbacks in next commit though to ensure nothing unexpected happens.
* update write callbacks for genplus-gx
- related to issue #3813
* update exec callbacks for genplus-gx
- closes#3813
* twice memory peek for deep freeze via on_bus_read bizhawk
Read a first time to pass the read value to the callback, read a second time to read the updated value in case it was updated by the callback and effectively deep freeze the value, no matter if 8, 16 or 32 width
* remove lines from unknown source
I have no idea where those lines came from. But I never meant to add them. This should look like it currently looks in master
* reinsert const, use implicit delegate constructors
* update submodule commit to before override memory values
* rename a to addr, unsigned int to just unsigned
funny story, the `--gdi` handler didn't remove it from the `args` array,
so it's always been parsed as a rom filename and obviously failing, but
before bd58bde07 it was failing silently
- closes#2622
not sure if this should always apply or only in playback mode but probably doesn't matter too much.
Also changed the default to false because that's what it's effectively been for many years
this now also prevents _runloopFrameProgress from potentially getting stuck after rewinding and fixes some other obscure interactions with frame advance and rewind.
- added 2 bugs
* getmarkers
Lua method to get a table with all markers for the current TasMovie, with Frame and Text as fields
* getmarkerabove
Returns a table of the marker at or above the given frame
* getbranchmarkerabove
same as getbranchmarker, but for getting the marker from a branch
* getbranchmarkers
returns a list of all markers for the given branchId, with fields Frame and Text