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
feos