Playing fullscreen in 4:3 on a 16:10 or 16:9 screen
Moderator: ScummVM Team
Playing fullscreen in 4:3 on a 16:10 or 16:9 screen
Hello, long-time user of ScummVM but first-time poster here.
Being aware of the "aspect ratio correction" option in ScummVM, I'm led to understand that such option serves the purpose of playing in proper QVGA 320x240 resolution rather the the native 320x200 with rectangular pixels, typical of certain SCUMM games. That said, I was wondering if it were possibile to have something else too. I would like to play fullscreen, but in "pillarboxed" mode, as to preserve the (post-"aspect ratio correction") aspect ratio of 4:3 (320:240), even on wide screens. Let me offer an example.
I own a 16:10 monitor, with a native resolution of 1680x1050. Enabling the aspect ratio correction, the game would be rendered at 320x240. Would it be possible to scale the game to not fill the whole screen, but an equivalent pillarboxed area of 1400 by 1050 pixels? With pillars 140 pixels wide on either side? This would imply equally scaling height and width by the same factor of h/240, where h is the native vertical resolution of the display in question (in my case, a factor 1050/240, ie. 4.375).
Condisidering that most (all?) games ScummVM supports were developed with 4:3 displays in mind, without this option any game played fullscreen will inevitably appear vertically squashed (or horizontally expanded, depending on the point of view). For now my solution was to play in windowed mode, but this little workaround of mine seems and feels very silly, even to myself.
Thank you, and I apologize if any of my assumptions are incorrect
Being aware of the "aspect ratio correction" option in ScummVM, I'm led to understand that such option serves the purpose of playing in proper QVGA 320x240 resolution rather the the native 320x200 with rectangular pixels, typical of certain SCUMM games. That said, I was wondering if it were possibile to have something else too. I would like to play fullscreen, but in "pillarboxed" mode, as to preserve the (post-"aspect ratio correction") aspect ratio of 4:3 (320:240), even on wide screens. Let me offer an example.
I own a 16:10 monitor, with a native resolution of 1680x1050. Enabling the aspect ratio correction, the game would be rendered at 320x240. Would it be possible to scale the game to not fill the whole screen, but an equivalent pillarboxed area of 1400 by 1050 pixels? With pillars 140 pixels wide on either side? This would imply equally scaling height and width by the same factor of h/240, where h is the native vertical resolution of the display in question (in my case, a factor 1050/240, ie. 4.375).
Condisidering that most (all?) games ScummVM supports were developed with 4:3 displays in mind, without this option any game played fullscreen will inevitably appear vertically squashed (or horizontally expanded, depending on the point of view). For now my solution was to play in windowed mode, but this little workaround of mine seems and feels very silly, even to myself.
Thank you, and I apologize if any of my assumptions are incorrect
If your Monitor is connected via a digital link (not VGA) to your graphics card, you may enable aspect-correct scaling in your graphics drivers. At least ati and nvidia offer this setting, i don't know if it's available for crappy intel graphics.
Another option is to check your monitor for a builtin 4:3-Mode.
Another option is to check your monitor for a builtin 4:3-Mode.
I understand, but what if none of those options are viable? I mean, I understand that we are in the new millennium and that HDMI is the next best thing, but I'm pretty sure that VGA is still pretty common (especially among old school gaming aficionados)... and many monitors don't have low-level aspect ratio correction!whatever wrote:If your Monitor is connected via a digital link (not VGA) to your graphics card, you may enable aspect-correct scaling in your graphics drivers. At least ati and nvidia offer this setting, i don't know if it's available for crappy intel graphics.
Another option is to check your monitor for a builtin 4:3-Mode.
Would it be really impossible to implement this on a software level via ScummVM?
Of course it is possible to solve this in software.
In fact, in principle, this is already solved, so for reasons of weirdness in the OS / graphic card drivers / monitors, this does not always work for everybody (though it worked fine for me for many years on various systems including some with a monitor connected using an old-style VGA cable.)
ScummVM is built on the SDL library. When ScummVM starts a game in fullscreen mode, it asks the SDL library for a screen of a certain resolution, say 640x480 (that's what it asks if you start a 320x200 game and chose a 2x scaler and aspect ratio correction).
Now, SDL, will then in turn ask the OS (which will ask the graphics card driver, which may ask the graphics card and the screen...) to switch to a resolution; or at least a resolution close to that.
If the final resolution does *not* match exactly what ScummVM is using, then SDL will try to automatically do what you call "pillarbox mode": Namely, it centers the actual graphics drawn by ScummVM on the screen, and adds black borders around that as necessary.
Thus, if all went right, then ScummVM should still display with correct aspect ratio and maybe black borders! Perfect.
Sadly, this breaks down on various systems for various reasons. Namely, sometimes the OS (I'll from now on just refer to the "OS" when I mean "OS, driver, card or screen") will tell us that video modes are available that we really do not want to use. Say, a mode which is not aspect ratio correct. You screen might be 16:10, but the OS might end up telling us that, sure, we can get 640x480 out of it. And it then proceeds to somehow map that resolution to the screen surface. Somtimes by stretching/squeezing it (bad :/) sometimes by adding black borders / pillarboxes of its own to it (not as bad but still usually not perfect), etc.
On some systems, you can avoid that by either editing the list of resolutions the OS will accept as valid; or by changing a setting that forces it to never stretch screen data (e.g. I think the NVidia drivers on Windows allow both; and some better LCDs have settings for that, too). But sometimes none of this is possible, and we end up in a crap situation. .
None of these problems would exist if the OS would not try to cheat by telling us about resolutions that are not really supported, or about resolutions that lead to stretching. So, in general, this is something that deserves bug reports to be sent to the responsible parties.
However, it is clear that this does not help you, unless you are willing to buy a new screen/graphics card/switch th OS ...
So, we could try to work around this mess in ScummVM, but none of it is pretty. We currently have some code which tries to partially workaround this all by inspecting the list of resolutions the OS tell us are really, *really* supported, and only using one of those. But as I explained, even that heuristic can fail badly because too many involved parties may hand out "incorrect" (or at least: misleading) information.
Another approach, used by DOSBox (AFAIK) is to let the user specify which resolution to use. I.e. offer key/value pairs for this in the config, maybe also show a popup in our GUI option dialog with a list of all available resolutions, and use that.
This is certainly doable, but poses some issues of its own to us (none are unresolvable, mind you). For example, we only should show that popup on systems were it makes sense. We'd also have to create an API internally to our "backends" (the code which interfaces with your PC/game console/smartphone) which makes such information available to the options dialog. Then, we'd have to make sure that people who switch between using multiple screens (they the one built into your laptop, and a big external one you use at home) are not suddenly made unhappy.
All this is solvable, but adds quite some complexity, not just for us the developers, but also to users. While it would help some people, like you, it would also bear the risk of creating a new inconvenience for other people, were things used to work but due to the change may work less, if we are not very careful.
All in all, definitely something we should consider looking into, as it has become clear that certain OS & graphic cards & screen vendors will not do anything to improve the messy situation. However, not everybody is so interested in working on this. Me, for example: I have no interest in working on this since it always worked perfectly on *my* Mac OS X computers, and also on the external (non-Apple screens I used over the years.
In fact, in principle, this is already solved, so for reasons of weirdness in the OS / graphic card drivers / monitors, this does not always work for everybody (though it worked fine for me for many years on various systems including some with a monitor connected using an old-style VGA cable.)
ScummVM is built on the SDL library. When ScummVM starts a game in fullscreen mode, it asks the SDL library for a screen of a certain resolution, say 640x480 (that's what it asks if you start a 320x200 game and chose a 2x scaler and aspect ratio correction).
Now, SDL, will then in turn ask the OS (which will ask the graphics card driver, which may ask the graphics card and the screen...) to switch to a resolution; or at least a resolution close to that.
If the final resolution does *not* match exactly what ScummVM is using, then SDL will try to automatically do what you call "pillarbox mode": Namely, it centers the actual graphics drawn by ScummVM on the screen, and adds black borders around that as necessary.
Thus, if all went right, then ScummVM should still display with correct aspect ratio and maybe black borders! Perfect.
Sadly, this breaks down on various systems for various reasons. Namely, sometimes the OS (I'll from now on just refer to the "OS" when I mean "OS, driver, card or screen") will tell us that video modes are available that we really do not want to use. Say, a mode which is not aspect ratio correct. You screen might be 16:10, but the OS might end up telling us that, sure, we can get 640x480 out of it. And it then proceeds to somehow map that resolution to the screen surface. Somtimes by stretching/squeezing it (bad :/) sometimes by adding black borders / pillarboxes of its own to it (not as bad but still usually not perfect), etc.
On some systems, you can avoid that by either editing the list of resolutions the OS will accept as valid; or by changing a setting that forces it to never stretch screen data (e.g. I think the NVidia drivers on Windows allow both; and some better LCDs have settings for that, too). But sometimes none of this is possible, and we end up in a crap situation. .
None of these problems would exist if the OS would not try to cheat by telling us about resolutions that are not really supported, or about resolutions that lead to stretching. So, in general, this is something that deserves bug reports to be sent to the responsible parties.
However, it is clear that this does not help you, unless you are willing to buy a new screen/graphics card/switch th OS ...
So, we could try to work around this mess in ScummVM, but none of it is pretty. We currently have some code which tries to partially workaround this all by inspecting the list of resolutions the OS tell us are really, *really* supported, and only using one of those. But as I explained, even that heuristic can fail badly because too many involved parties may hand out "incorrect" (or at least: misleading) information.
Another approach, used by DOSBox (AFAIK) is to let the user specify which resolution to use. I.e. offer key/value pairs for this in the config, maybe also show a popup in our GUI option dialog with a list of all available resolutions, and use that.
This is certainly doable, but poses some issues of its own to us (none are unresolvable, mind you). For example, we only should show that popup on systems were it makes sense. We'd also have to create an API internally to our "backends" (the code which interfaces with your PC/game console/smartphone) which makes such information available to the options dialog. Then, we'd have to make sure that people who switch between using multiple screens (they the one built into your laptop, and a big external one you use at home) are not suddenly made unhappy.
All this is solvable, but adds quite some complexity, not just for us the developers, but also to users. While it would help some people, like you, it would also bear the risk of creating a new inconvenience for other people, were things used to work but due to the change may work less, if we are not very careful.
All in all, definitely something we should consider looking into, as it has become clear that certain OS & graphic cards & screen vendors will not do anything to improve the messy situation. However, not everybody is so interested in working on this. Me, for example: I have no interest in working on this since it always worked perfectly on *my* Mac OS X computers, and also on the external (non-Apple screens I used over the years.
Thanks for taking the time to write such a detailed and englightening explanation.
It's obvious things are much more complicated than I thought (when are things ever easy, eh?).
Considering how messy the automatic resolution detection appears to be, right now I'm rooting for an implementation of a GUI popup (or, if it's easier, a field like the ones in the "Graphics" and "Sound" portions of the ScummVM GUI, so that the option could be enabled only by the "experienced" user) that will allow the user to specify the resolution.
Goes without saying, nothing of what I say is meant to pressure the development team in any way. I, like all ScummVM users, am thoroughly grateful to the whole project for bringing us a powerful tool like ScummVM.
In the meantime, I would be grateful if you could tell me where Windows keeps the list of resolutions it will accept as valid, maybe I'll be able to pull something off by editing that. All this will be done at my own risk, of course (ie. if I screw it up, I'll be wall-banging my head and mine alone). Besides, I think I'll do this on a virtual windows machine... A VM in a VM... sounds a bit like Matrix.
If understand it correctly, I should remove from the list any and all resolutions with ARs that are different from the screen's native AR, am I right?
Thanks again!
It's obvious things are much more complicated than I thought (when are things ever easy, eh?).
Considering how messy the automatic resolution detection appears to be, right now I'm rooting for an implementation of a GUI popup (or, if it's easier, a field like the ones in the "Graphics" and "Sound" portions of the ScummVM GUI, so that the option could be enabled only by the "experienced" user) that will allow the user to specify the resolution.
Goes without saying, nothing of what I say is meant to pressure the development team in any way. I, like all ScummVM users, am thoroughly grateful to the whole project for bringing us a powerful tool like ScummVM.
In the meantime, I would be grateful if you could tell me where Windows keeps the list of resolutions it will accept as valid, maybe I'll be able to pull something off by editing that. All this will be done at my own risk, of course (ie. if I screw it up, I'll be wall-banging my head and mine alone). Besides, I think I'll do this on a virtual windows machine... A VM in a VM... sounds a bit like Matrix.
If understand it correctly, I should remove from the list any and all resolutions with ARs that are different from the screen's native AR, am I right?
Thanks again!
I wasn't talking about HDMI in particular,but about digital display connections in general, this includes DVI and DisplayPort.ZCo wrote:I understand that we are in the new millennium and that HDMI is the next best thing, but I'm pretty sure that VGA is still pretty common
DVI should be quite common these days. Even my old graphics-card from 2003 has a DVI connector and (apart from some extremely cheap models) most LCDs support DVI.
The approach taken by Dosbox is the best. Much, much better than what ScummVM does currently.
With dosbox I can simply edit the conf file and set the resolution to 1680x1050.
Dosbox will automatically scale the image to 1400x1050 and fill the rest of the screen with black pixels to get the exact resolution I want (1680x1050).
The default "normal2x" scaler of dosbox works very well, and even setting the aspect correction to "true" keeps the text and graphics crisp and beautiful.
However, with ScummVM I cannot get crisp graphics and text, no matter what I do. I've tweaked my monitor's settings, all of the NVIDIA scaling settings, tried different resolutions and combinations...
The best I can manage with correct aspect ratio is blurry text and crappy graphics :(
I really wish I could simply tell ScummVM to use 1680x1050, adding black pixels to the image until it fills the entire screen.
I hope some day ScummVM will do the same as dosbox does now!
With dosbox I can simply edit the conf file and set the resolution to 1680x1050.
Dosbox will automatically scale the image to 1400x1050 and fill the rest of the screen with black pixels to get the exact resolution I want (1680x1050).
The default "normal2x" scaler of dosbox works very well, and even setting the aspect correction to "true" keeps the text and graphics crisp and beautiful.
However, with ScummVM I cannot get crisp graphics and text, no matter what I do. I've tweaked my monitor's settings, all of the NVIDIA scaling settings, tried different resolutions and combinations...
The best I can manage with correct aspect ratio is blurry text and crappy graphics :(
I really wish I could simply tell ScummVM to use 1680x1050, adding black pixels to the image until it fills the entire screen.
I hope some day ScummVM will do the same as dosbox does now!
We will, this has been worked on as part of GSoC and will be likely included in the next stable version (1.3.0)Leolo wrote:The approach taken by Dosbox is the best. Much, much better than what ScummVM does currently.
With dosbox I can simply edit the conf file and set the resolution to 1680x1050.
Dosbox will automatically scale the image to 1400x1050 and fill the rest of the screen with black pixels to get the exact resolution I want (1680x1050).
The default "normal2x" scaler of dosbox works very well, and even setting the aspect correction to "true" keeps the text and graphics crisp and beautiful.
However, with ScummVM I cannot get crisp graphics and text, no matter what I do. I've tweaked my monitor's settings, all of the NVIDIA scaling settings, tried different resolutions and combinations...
The best I can manage with correct aspect ratio is blurry text and crappy graphics
I really wish I could simply tell ScummVM to use 1680x1050, adding black pixels to the image until it fills the entire screen.
I hope some day ScummVM will do the same as dosbox does now!
-
- Posts: 85
- Joined: Sun Sep 17, 2006 2:26 am
- Location: Perth, WA, Australia
That's good to hear!
Can't wait for the new version.
A tip for Nvidia users though.
You need to create a custom resolution of 1040 x 1050 in the Nvidia control panel AND enable aspect ratio scaling.
When you set this resolution you should have a perfect 4:3 image with black bars on the sides.
I used this for a lot of 4:3 games back in the days.
Can't wait for the new version.
A tip for Nvidia users though.
You need to create a custom resolution of 1040 x 1050 in the Nvidia control panel AND enable aspect ratio scaling.
When you set this resolution you should have a perfect 4:3 image with black bars on the sides.
I used this for a lot of 4:3 games back in the days.
Has this feature been included yet? I am asking because last night i was playing MI2 SE for the first time, and when i switched to classic mode, it was perfect 4:3 aspect ratio on my 1280x800 resolution. In ScummVM i just get fullscreen 1280x800 16:10 when playing MI2, and i have aspect ratio correction enabled. Using latest nightly dev build on Win XP SP3.md5 wrote:We will, this has been worked on as part of GSoC and will be likely included in the next stable version (1.3.0)
I have installed the latest daily build for win32 and I must say I love it!
The text is now really crisp and gorgeous when using OpenGL and the nearest neighbor filtering. Pressing CTRL-ALT-F toggles between filtering modes and the difference in sharpness is absolutely incredible!!
I just have one question, because I don't fully understand the OpenGL "conserve" mode:
What's the purpose of OpenGL "conserve" mode? I've tried it on Monkey Island 1 and it didn't preserve the aspect ratio when I pressed ALT-ENTER to go full screen (unless I set aspect_ratio=true in scummvm.ini)
I suppose that games using 320x200 resolution don't need OpenGL "conserve" mode at all, am I correct?
Kind regards.
The text is now really crisp and gorgeous when using OpenGL and the nearest neighbor filtering. Pressing CTRL-ALT-F toggles between filtering modes and the difference in sharpness is absolutely incredible!!
I just have one question, because I don't fully understand the OpenGL "conserve" mode:
What's the purpose of OpenGL "conserve" mode? I've tried it on Monkey Island 1 and it didn't preserve the aspect ratio when I pressed ALT-ENTER to go full screen (unless I set aspect_ratio=true in scummvm.ini)
I suppose that games using 320x200 resolution don't need OpenGL "conserve" mode at all, am I correct?
Kind regards.
- MusicallyInspired
- Posts: 1138
- Joined: Fri Mar 02, 2007 8:03 am
- Location: Manitoba, Canada
- Contact:
It did preserve the aspect ratio but ScummVM automatically assumes that the aspect ratio for all resolutions are based on square pixels. Many 320x200 games by design were not intended to have square pixels, however, but rectangular. But 320x200 is inherently a widescreen resolution if the pixels are square. Thus ScummVM has the option aspect_ratio=true to stretch the image vertically somewhat to create rectangular pixels and change what would normally be a 16:10 320x200 image into a 4:3 320x200 image, for those games that were designed that way. Since there's no way for ScummVM to know which games were and which weren't you have to do it manually. However, you can set it specifically for each game in the GUI or the ini file.
That's how aspect_ratio=true works.
That's how aspect_ratio=true works.