mirror of https://github.com/bsnes-emu/bsnes.git
cbbf5ec114
byuu says: Changelog: - tomoko: video scaling options are now resolutions in the configuration file, eg "640x480", "960x720", "1280x960" - tomoko: main window is now always resizable instead of fixed width (also supports maximizing) - tomoko: added support for non-integral scaling in windowed mode - tomoko: made the quick/managed state messaging more consistent - tomoko: hide "Find Codes ..." button from the cheat editor window if the cheat database is not present - tomoko: per-game cheats.bml file now goes into the higan/ subfolder instead of the root folder So the way the new video system works is you have the following options on the video settings panel: Windowed mode: { Aspect correction, Integral scaling, Adaptive } Fullscreen mode: { Aspect correction, Integral scaling } (and one day, hopefully Exclusive will be added here) Whenever you adjust the overscan masking, or you change any of the windowed or fullscreen mode settings, or you choose a different video scale from the main menu, or you load a new game, or you unload a game, or you rotate the display of an emulated system, the resizeViewport logic will be invoked. This logic will remember the last option you chose for video scale, and base the new window size on that value as an upper limit of the new window size. If you are in windowed mode and have adaptive enabled, it will shrink the window to fit the contents of the emulated system's video output. Otherwise, if you are not in integral scaling mode, it will scale the video as large as possible to fit into the video scaled size you have selected. Otherwise, it will perform an integral scale and center the video inside of the viewport. If you are in fullscreen mode, it's much the same, only there is no adaptive mode. A major problem with Xorg is that it's basically impossible to change the resizability attribute of a window post-creation. You can do it, but all kinds of crazy issues start popping up. Like if you toggle fullscreen, then you'll find that the window won't grow past a certain fairly small size that it's already at, and cannot be shrunk. And the multipliers will stop expanding the window as large as they should. And sometimes the UI elements won't be placed in the correct position, or the video will draw over them. It's a big mess. So I have to keep the main window always resizable. Also, note that this is not a limitation of hiro. It's just totally broken in Xorg itself. No amount of fiddling has ever allowed this to work reliably for me on either GTK+ 2 or Qt 4. So what this means is ... the adaptive mode window is also resizable. What happens here is, whenever you drag the corners of the main window to resize it, or toggle the maximize window button, higan will bypass the video scale resizing code and instead act as though the adaptive scaling mode were disabled. So if integral scaling is checked, it'll begin scaling in integral mode. Otherwise, it'll begin scaling in non-integral mode. And because of this flexibility, it no longer made sense for the video scale menu to be a radio box. I know, it sucks to not see what the active selection is anymore, but ... say you set the scale to small, then you accidentally resized the window a little, but want it snapped back to the proper small resolution dimensions. If it were a radio item, you couldn't reselect the same option again, because it's already active and events don't propagate in said case. By turning them into regular menu options, the video scale menu can be used to restore window sizing. Errata: On Windows, the main window blinks a few times on first load. The fix for that is a safeguard in the video settings code, roughly like so ... but note you'd need to make a few other changes for this to work against v103r10: auto VideoSettings::updateViewport(bool firstRun) -> void { settings["Video/Overscan/Horizontal"].setValue(horizontalMaskSlider.position()); settings["Video/Overscan/Vertical"].setValue(verticalMaskSlider.position()); settings["Video/Windowed/AspectCorrection"].setValue(windowedModeAspectCorrection.checked()); settings["Video/Windowed/IntegralScaling"].setValue(windowedModeIntegralScaling.checked()); settings["Video/Windowed/AdaptiveSizing"].setValue(windowedModeAdaptiveSizing.checked()); settings["Video/Fullscreen/AspectCorrection"].setValue(fullscreenModeAspectCorrection.checked()); settings["Video/Fullscreen/IntegralScaling"].setValue(fullscreenModeIntegralScaling.checked()); horizontalMaskValue.setText({horizontalMaskSlider.position()}); verticalMaskValue.setText({verticalMaskSlider.position()}); if(!firstRun) presentation->resizeViewport(); } That'll get it down to one blink, as with v103 official. Not sure I can eliminate that one extra blink. I forgot to remove the setResizable toggle on fullscreen mode exit. On Windows, the main window will end up unresizable after toggling fullscreen. I missed that one because like I said, toggling resizability is totally broken on Xorg. You can fix that with the below change: auto Presentation::toggleFullScreen() -> void { if(!fullScreen()) { menuBar.setVisible(false); statusBar.setVisible(false); //setResizable(true); setFullScreen(true); if(!input->acquired()) input->acquire(); } else { if(input->acquired()) input->release(); setFullScreen(false); //setResizable(false); menuBar.setVisible(true); statusBar.setVisible(settings["UserInterface/ShowStatusBar"].boolean()); } resizeViewport(); } Windows is stealing focus on calls to resizeViewport(), so we need to deal with that somehow ... I'm not really concerned about the behavior of shrinking the viewport below the smallest multiplier for a given system. It might make sense to snap it to the window size and forego all other scaling, but honestly ... meh. I don't really care. Nobody sane is going to play like that. |
||
---|---|---|
.. | ||
memory.cpp | ||
serialization.cpp | ||
smp.cpp | ||
smp.hpp | ||
timing.cpp |