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
Morilli