FitzRoy wrote:lidnariq wrote:But more seriously, the more I think about this, the more I think this is something that should be decided on a hack-by-hack basis. It'd be a shame to discover that some games just can't get the desired "full" width, whatever that is.
That sounds terrible, we need to push for a standard as these patches are hard to make. The option should lead to consistent results and be as simple as checking a box. We should push for 480 or even 640 and then give zoomcrop options to effectively achieve narrower outputs. If you undercut yourself, you eliminate the possibility of running in 480, which has major benefits that I am trying to point out.
No, I don't think there's a need for a standard dimension at all. I don't think there's really much need to argue about pixel aspect ratios, or what the target resolution should be, TBQH. Whether or not game art was circular to begin width hardly matters, these hacks aren't going to be changing PAR, they're adding
pixels. Besides, what's possible/practical will be very much decided on a per-game basis anyway.
For a game where this can work, you already have a map/background that can be extended to some arbitrary size. The point is to
fill the screen. You extend as far as you
can and then crop there. This concept easily adapts to different PAR options and different screen geometries.
It might matter a little bit if you wanted to move UI elements from their original location to the sides or coners of the HD screen, but wanting to do something like that in a game that you could do that to... there are so many constraints here, there's no way some standard could apply. Every game has different UI needs. In this respect, you have a "safe" region in the original screen area that everybody is guaranteed to have, and all visual content outside this region should be seen as optional. The whole problem becomes a really big "overscan".
As a suggestion though, perhaps the emulator should implement some new registers that return the host emulated screen dimensions in pixels? That would allow hacks to dynamically place UI elements or stuff like that (if this is really needed at all), and maybe also let those same hacks determine when widescreen emulation isn't available too, so they can fall back in some way. This might also provide a mechanism for the hack to tell the emulator "the screen can go as wide as XXX pixels", so that it does not try to over-extend the view if a game could only go so far.
E.g. You write "496, 240" to the widescreen control registers indicating your maximum pixel dimension, and then read back "398, 224" which lets you know what the emulator was able to provide. You otherwise do all the same things in the hack, but might use this information to relocate UI or something, if you need to.
BTW, I think it seems just as natural to want to extend the vertical pixel range as well. (Could be quite wonderful for assisting "atlas" style videos:
example 1,
example 2.)
Otherwise, good luck with the hacking I guess. For anyone wanting to do this, there's clearly a mountain of problems for you to solve. Easy to cherry-pick a screenshot that looks clean, but of course
a video demonstration makes it really easy to spot the things that will need a lot of attention. In the long run you'll probably need quite a bit of extended register / interface support, and
that would need a standard.