* 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
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
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
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.
while libretro initially ported original puae (which is long dead), they switched to just pulling updates from winuae every once in a while (and renamed to libretro-uae), because it's still active and is kinda considered golden standard these days
what the fuck
if I send my ports to puae's 0 and 1, both go to port 0
if I send my ports to puae's 1 and 2, they go to ports 1 and 2
if I send both of my ports to puae's 0, they go to ports 0 and 1
what the fuck
feos