this was causing a warning to appear, see microsoft/vstest#3475
don't entirely remember why it was necessary to pass
this, originally `-a`, at all; it's in the first commit d91c477e5
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).
YoshiRulz