internally, wipe is rendered within a single "frame" so no input is processed. but we can't know from the movie which frame is wipe, so we can't insert empty frames to make imported movies work with our wipe - which has to happen across frames so we could capture every interim state of it. when exporting movies, wipe frames can be dropped based on lag info which we're currently setting for wipe only.
the way the initial lists are populated is kinda hacky because we need some separators and split the results using them. it's impossible to make sure they won't use that separator in a name in the future. maybe there's a better way than listing every available name in entire mame and finding which symbols never appear there and using them as separators (tho I admit for views I didn't even do that and relied on users running the thing).
only doom1 uses episode number in -warp, all the rest ignore it and use the first digit to set map (episode is forced to 1 for them). to detect this we now ask the core which gamemode it is (which determines it internally too).
rename complevel setting
see also #2090. This can reasonably catch and handle simple load failures like all waterbox loads and some others.
Not calling the issue fixed because there is more that can be done to prevent cores from trying to load invalid savestates.
various toolbars may exist near screen edges, we don't want them to be triggered when hawk has "captured" the mouse, especially in fullscreen. I considered taking into account when hawk window is partly offscreen but it's hard to expect anyone would play that way - normal scenario is fullscreen, so screen edges are automatically pushed away from. dialogs covering hawk are even less likely to remain during mouse capture, so we don't care about mouse appearing on them.
The core as it is is a very poor choice for Genesis. Much worse compatibility, very noticeably worse audio, and it's not like GPGX is hurting badly in the performance department. It's also very outdated compared to upstream (making these problems much worse than if it was updated). It was only in BizHawk to handle 32X games to begin with (as there aren't many options for 32X to begin with), with Genesis fallback support (without user selectability!) just tacked on "because we can."
Perhaps with a core update it could be more reasonable to allow users to select this, but for now, nope.
Closes#4251, #4250, #4235
demos still sync btw
horizontal mouse was calibrated for my machine, dunno about others. for me 1-pixel relative movement results in 272-pixel deltas, so I divide it inside the core for now
when the global sensitivity option is there, I'll drop sensitivity syncsettings and rely on client ones that I'll configure to match default dsda sensitivity.
upstream uses a hotkey toggle instead but vanilla didn't have it. even "always run" itself was just a vanilla bug. I don't want to have a special on-the-fly input for autorun toggle, hopefully user either wants to always run + occasional mouse movement, or only run using the proper button
this allows to properly set available range which makes demos sync again (aside from weapon switching that I broke)
when importing demos we now force shorttics (even tho some source ports can record demos with longtics depending on compatibility level but importing those is for the later time)
There's 3 approaches here, of which only 1 appears to work more or less correctly
1. Use XFixes "pointer barriers." Introduced in XFixes version 5.0 (end of 2010), these effectively allow 1:1 mapping with Windows ClipCursor, giving behavior BizHawk wants.
2. Use XGrabPointer, with the confine_to argument set to the presentation panel. This mostly works, however, it changes how some events operate and for whatever reason prevents Mono from responding to mouse buttons. This approach can be used with 1. too for a simple warp of the mouse cursor over to wherever the window is.
3. Use Mono's internal CaptureWithConfine function. This is just internally using XGrabPointer with the confine_to argument. Somehow it makes mouse buttons work, but it ends up working too well as it can respond to the menu bar somehow, and interacting with such or the right click menu cancels the grab (seems to be internal Mono code doing such in this case here?).
Note a lot of weirdness with previous code came down to testing being in a VM and mouse integration being enabled. That apparently just prevents any kind of mouse warping from happening so nothing appeared to work correctly. Disabling such allows these approaches to work as above, also makes relative mouse values sane (previous values with mouse integration were completely bonkers).
TODO: Need to check if this works on XWayland (maybe it does?). Also need to refresh mouse capture on window resize and move (needed in general for both Windows and Linux)
currently requires manually binding RMouse X/Y in config.ini (and zero deadzone I guess)
empirically match dsda default settings with sensitivity syncsettings (defctrl.json wasn't touched yet)
TODO: look at mouse calc inside the core
that way we don't have to rebuild the core for every commandline option that it already supports and we decide to use, also more meaningful presentation of those options on the managed side
native api side done. trying to map it probably interferes with absolute inputs, needs some global relative mouse sensitivity setting for input translation purposes. hopefully everything else doesnt break
attempts to resolve#3053 by shuffling some bools around.
Specifically, `_runloopFrameProgress` is now set when either (continuously) frame advancing or rewinding.
removed the NETCOREAPP3_0 code because it didn't even compile; lots of internals missing and we probably wouldn't need the 1% speedup anyway (the function using it is unused currently too)
by immediately throwing out the current movie. This should prevent this message box from coming up repeatedly, not providing any additional useful information and just blocking all other windows.
should resolve#2332
fixes 18078c876
and some others, maybe as far back as the commits introducing the lists,
I haven't checked
also I left a marker so it's easier to find these later
fixes#4204
RANT TIME
visible area is largely nonsense when it comes to CRT TVs, because they may cover different amounts of the screen based on model, and you can adjust some of them also based on model to show more or less of it.
4:3 aspect ratio is also somewhat nonsense because TVs don't automatically rescale your video input to the entire screen like modern computers do. they just stretch or shrink it based on pixel frequency of the input and how it relates to whatever the given TV is configured to.
Rec601 was created in order to somewhat standardize this but it only contained RECOMMENDATIONS (hence the name) on how to digitize analog video, not how analog devices should be configured. so a lot of TVs looked different from what it would be digitized to based on this spec.
in gaming it's a common misconception that console output is meant to be resized to 4:3 DAR of the TV. in reality it's stretched according to PAR - pixel shape which comes from differences between color frequency of the input and standard NTSC or PAL color frequency.
if the console updates color more often than the standard, analog signal with higher pixel density will be put on the screen as is, and pixel will look "squished", sometimes up to 2x for 512px resolution modes (PS1). if the console updates color rarer, pixels will look stretched (A2600).
Amiga PAL mode has 1:1 PAR, no stretching is needed, so whatever aspect we're outputting will just go to encodes as is. NTSC Amiga PAR is 6:7, so we're shrinking a bit in encodes and when hawk is configured to device aspect.
this all means that it doesn't matter how many pixels we take of the rendered image, all we care about is stretching it to proper PAR. whether it contains overscan only affects fullscreen because extra blank area means less of useful data. and since some exceptional games decide to render AT THE VERY BOTTOM there's little to no harm in showing all 574 rendered scanlines. who hates it and wants 568 can crop it, but I don't expect anyone to care (or even notice).
so while nominal internal res for Amiga is 576 and canonical UAE default is 568 (tho it lets you adjust visible area and we don't), I think we can safely output our heretical number at all times.
Semicolons are perfectly valid for path names, but windows disallows dll paths to contain such (presumingly internally using them as path separators like with PATH env var)
A workaround for this is to simply use the "short name path" instead, which does not have a semicolon (but these names aren't guaranteed to exist, and in certain cases if they don't,GetShortPathNameW will just return the long name back, so semicolon still needs to be rechecked)
[C64] Disk: Use raw track capacity values per the G64 file format specification, should fix some disk loaders that are expecting data not to be so sparse (Spindle demos in D64 format particularly)
[C64] Disk: fix 1541 drive address decodes
[C64] VIA: 6522 core facelift, shift register and use of low-order timer latches implemented, should fix some disk loaders ("Sprite B*****e 2" demo plays, yes they called it that, and it's not what it sounds like)
[C64] CIA: fix PB6/PB7 outputs when enabled on CRA/CRB
* [6502] Pass Lorenz C64 tests
* [C64] make sure the 1541 drive uses the same 6502 undocumented behavior as the main CPU
* [6502] Use field instead of delegate for ANE/LXA system constants
doesn't matter for ASCII-only strings, and `InvariantCultureIgnoreCase`
is arguably correct in some circumstances, but IMO it's more foolproof
to simply ban it
This reverts commit b2f3bb3cba.
Revert "fix removing everything"
This reverts commit a0da874431.
YEP. this "feature" is COMPLETELY, ABSOLUTELY, UNIVERSALLY fucked. sure #4184 can be "fixed" by flipping some bools, like setting MainForm.HoldFrameAdvance back to false in TasView_MouseWheel. but then there's still the problem of removing actual input if farther lag picture changed after initial removal, and I'm not going to debug that. taseditor's ONLY bug was related to erroneous detection of lag change that we were never able to consistently reproduce or figure out, and it's completely impossible to replicate identical behavior in tastudio due to crazy overhead. but even SIMULATING that behavior would involve touching that minefield of bools that control everything in insane ways. given zero requests for this feature during tastudio's decade of existence, I'm considering it too useless for all the chaos it introduces.
so instead I'm closing #4184 by disabling the "feature" that caused it
* BizHawk#4187 Add a method to the comm LUA library to allow setting ExpectContinue
* Instead of exposing ExpectContinue set it automatically based on a threshold
YoshiRulz