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
* Adding initial version of the core
* Adding base files
* Trying to load waterbox now
* Adding stella
* Adding bk class
* Compiling bk interface to stella core
* Now compiling against Stella + SDL2-based BK backend
* Progress
* More progress
* Frame advancing (no render)
* Calling video update but crashing on zero div
* Now rendering to screen with correct palette
* Now rendering appropriately and with correct palette based on region
* Now reading controls
* Trying to capture audio
* Now adding audio
* Now polling inputs
* Now polling inputs
* Now reporting memory regions
* Added memory regions
* Removing debug prints
* Fixing indent
* Adding stella core
* Updating readme and make all cores
* Recovering ending comma
* Using heap alloc for sound buffer
* Removing unnecessary files
* Update src/BizHawk.Emulation.Cores/Consoles/Atari/Stella/Stella.IMemoryDomains.cs
Co-authored-by: James Groom <OSSYoshiRulz+GitHub@gmail.com>
* Update src/BizHawk.Emulation.Cores/Consoles/Atari/Stella/Stella.IMemoryDomains.cs
Co-authored-by: James Groom <OSSYoshiRulz+GitHub@gmail.com>
* Fix
* Restoring vscode
* Removing warning
* Update waterbox readme
* Fix Stella's `[Core]` attr
* Increased sound buffer size to 1Mb, as some games need more than 4K
---------
Co-authored-by: James Groom <OSSYoshiRulz+GitHub@gmail.com>
Co-authored-by: Morilli <35152647+Morilli@users.noreply.github.com>
Co-authored-by: YoshiRulz <OSSYoshiRulz+git@gmail.com>
These numbers are derived from the 2010 whitepaper:
NTSC's 4*(315/88 MHz) is doubled to give the master clock rate, which is
then divided by 1820 cycles per line and 262 lines per (progressive)
frame.
---------
Co-authored-by: Morilli <35152647+Morilli@users.noreply.github.com>
feos