Hi,
With integer scaling on, bsnes uses a lower resolution than it could. Fullscreen resolution is set to 1920x1200. The output video has a resolution of 1280x960 (x4). It has room to go up to 5x. Aspect ratio is set to core provided.
I previously used bsnes-mercury-performance and bsnes-performance which didn’t have this problem.
Please help, thanks! 
bsnes reports a vertical height of 448 pixels. I think that’s what RA uses to calculate integer scaling. You can see it if you enable the “Settings/Onscreen Display/Onscreen Notifications/Display Statistics” option.
So it seems you only get a height of 896 pixels.
You can use Mesen-S or Snes9x instead to get proper scaling. Those report the correct resolution to RA.
Thanks for your reply RealNC.
Devs, would it be possible to fix the reported resolution please ?
It’s not a bug per se. It uses the high resolution all the time because the SNES needs to be able to change resolution mid-frame, so it needs the max size to expand into. It’s an accuracy thing.
What is the higher resolution used for? Is there a way around it? Were previous versions of bsnes less accurate or did they just do things differently?
Higan core has an internal resolution setting, which lets users drop the res down at the expense of the mid-frame resolution changes. bsnes-mercury accuracy profile looks like it does it on-demand but can’t do it mid-scanline.
Thanks hunterk. Does any of these cores implement HD mode 7 ?
no, HD mode 7 is dependent on the new bsnes core’s multithreaded renderer.
Ah, too bad that some of us have to choose between HD mode 7 and fullscreen video.
Any chance bsnes would allow for the high resolution switching to be optionally turned off or not reported as such ? I suspect it’s only useful for the few games using 512x448 like Secret of Mana?
You could put in a feature request here:
Will do, thank you!
Squaresoft games used 512x224 in the menus (like Secret of mana). Vanishingly few games use a vertical resolution of 448.
Just to add to this thread, the reported resolution also seems to negatively affect some shaders. Here’s a comparison of the snes9x and bsnes cores running with crt-geom. As you can hopefully see, on bsnes there are two scanlines per line of pixels, instead of one.
snes9x:
bsnes:
EDIT: From reading through the thread @Cutter created on github it seems that the core correctly renders at 256x224 when the Fast PPU option is enabled. However, it incorrectly reports as still rendering at 512x448. At least as far as I am able to understand. Am I misunderstanding or should I go ahead and raise that as an issue on github?
AFAIK, the current bsnes and bsnes-hd-beta cores do not have any way to natively downsample and will always have double vertical and horizontal res to accommodate mid-scanline res changes. This is functioning as expected and as intended.
Oh that’s good to know, thank you. A shame about the shader, though. Do you know if there is a shader that can downsample the resolution before applying crt-geom? Or is there another way to use crt-geom on the bsnes core, with correct scanlines?
crt-hyllian-3d and crt-guest-advanced-highres can both handle downsampling, AFAIK
I’ve had quite good results with crt-hylian-3d. Thank you for that recommendation. I’ve just been trying out the bsnes-mercury (accuracy) core, because it has the option to toggle gamma ramp, and I discovered that it appears to render at a lower resolution like snes9x. However, shader behaviour is still a little odd. To my eyes it appears something is different about horizontal resolution? Do you know anything about this? Thank you very much. 
The following examples are using the same combination of shaders with the same settings.
snes9x:
bsnes-mercury (accuracy):
I tested the latest bsnes core the other day with crt-guest-advanced and it looked like any other 240p core when using the Fast PPU. The scanlines looked fine and nothing looked off like it would if it were running at 2x res. With Fast PPU disabled, it triggered that shader’s de-interlacing effect.
