Hi. I have used ScummVM for quite some time now; I even registered in this forum almost 8 years ago. There is one thing that bugs me with even the newest releases of ScummVM, and that is that the maximum scaling method (without any fancy graphic-improvements) is only 3x.
Many of the older games in ScummVM runs in the ancient MS-DOS resolution of 320x200, and by scaling that image up three times the picture only gets enlarged to 960x600. The image would still be small in size after that if a 1080p monitor is used.
As of today 1440p monitors are beginning to be the new standard when it comes to PC gaming, and 4K/UHD is at our doorsteps with the massive resolution of 3840x2160. Imagine ScummVM with 3x scaling on a 4K monitor, the image would be like a tiny little poster in the middle of the screen.
I have myself used a workaround by using OpenGL no-filtering renderer and change the screen-resolution by pressing Ctrl-Alt and + - to adjust to the pixel perfect resolution that is exactly 5x the size of 320x200. That solution is a bit clunky if you ask me, and when I'm about to change to a different game I may have to change the resolution and so on again.
If you look at RetroArch, the use some kind of integer scaler that automatically blows the image up to the Desktop resolution without requiring you to choose how much (2x, 3x, 4x etc) you would like to resize the image. It fills the empty space with black borders.
Scaling above 3x for a authentic, fullscreen experience
Moderator: ScummVM Team
-
MusicallyInspired
- Posts: 1138
- Joined: Fri Mar 02, 2007 8:03 am
- Location: Manitoba, Canada
- Contact:
Let's say I would like to play the DOS version of Goblins 3 in ScummVM. Goblins 3 runs at 320x200, and by selecting 3x as rendering method each pixel is magnified 3 times, making a sharp image at 960x600.
960x600 means that there's going to be a lot of black borders surrounding the screen while maintaining a pixel perfect image on a 1920x1080 screen. I would prefer the maximum number of pixels my screen can handle without stretching some of the pixels in either width or height. Thereby scaling the image by 5x (1600x1000), I can maintain correct, non-stretched but square pixels with a minimum of black borders around the screen.
3x scaling is however the maximum scaling integer in ScummVM as of now. Why not have 4x, 5x, 6x and even higher as an alternative, as both 1440p and 2160p (4K) monitors are ready and available?
I can manage by selecting OpenGL no-filtering and the Ctrl-Alt + - combo to blow the game image up to the calculated max resolution while retaining square pixels, but it would be much easier if a high numbered scaling option was available.
I tried using the Nvidia Control Panel and scale via Aspect Ratio, but by using that method not all the pixels became square ones; a good portion was stretched.
960x600 means that there's going to be a lot of black borders surrounding the screen while maintaining a pixel perfect image on a 1920x1080 screen. I would prefer the maximum number of pixels my screen can handle without stretching some of the pixels in either width or height. Thereby scaling the image by 5x (1600x1000), I can maintain correct, non-stretched but square pixels with a minimum of black borders around the screen.
3x scaling is however the maximum scaling integer in ScummVM as of now. Why not have 4x, 5x, 6x and even higher as an alternative, as both 1440p and 2160p (4K) monitors are ready and available?
I can manage by selecting OpenGL no-filtering and the Ctrl-Alt + - combo to blow the game image up to the calculated max resolution while retaining square pixels, but it would be much easier if a high numbered scaling option was available.
I tried using the Nvidia Control Panel and scale via Aspect Ratio, but by using that method not all the pixels became square ones; a good portion was stretched.
We have for a long time this unfinished GSoC task: https://github.com/scummvm/scummvm/pull/271 which is aimed to make scaler plugins pluggable. This would let us add 4x or more scaler.
Also there is a plan to eventually add shader support to OpenGL port which will let different cool shaders which RetroArch uses to be used with ScummVM.
We always welcome any helping hands, including the tasks above.
Eugene
Also there is a plan to eventually add shader support to OpenGL port which will let different cool shaders which RetroArch uses to be used with ScummVM.
We always welcome any helping hands, including the tasks above.
Eugene
-
MusicallyInspired
- Posts: 1138
- Joined: Fri Mar 02, 2007 8:03 am
- Location: Manitoba, Canada
- Contact:
You do realize that for most older games 320x200 is a rectangular pixel 4:3 aspect ratio resolution, right? So you're going to be stretching them anyway if you want it to look the way it was meant to (ie- stretching 320x200 to about 320x240 physical resolution). The only way you'll get pixel perfection is with a CRT monitor until we can come up with something better.
This may still be preferable. I know I personally prefer sacrificing overall image aspect ratio of a low resolution video game for pixel fidelity. One thing I've experimented with image editors and would like to see in emulators and reimplementations is independent integer multipliers for the horizontal and vertical, padded/boxed to screen resolution. For example: 320x200 scaled 4x horizontally and 5x vertically gives 1280x1000 which a) uses the vertical resolution on a 1080p screen pretty efficiently, b) has uniform pixels, c) is closer to the original 4:3 of rectangular 320x200 than square pixels. A nice compromise, I feel.
Last edited by raina on Tue Apr 12, 2016 7:07 am, edited 1 time in total.
It may be true that the older DOS games in 320x200 was stretched to 320x240 on the older CRT monitors. To be honest, I don't remember. It's a long time ago.
It is the same with the Super Nintendo, the image was quite short, but was stretched to fill the whole width on the CRT screen.
As I grew older, I have become a pixel-nazi. The pixels must be square, and even emulated SNES games can not be stretched like they used to on TVs in my personal preferences. If the image gets too small, I prefer to magnify each and every pixel just the same, to maintain the squareness of the pixels.
It is the same with the Super Nintendo, the image was quite short, but was stretched to fill the whole width on the CRT screen.
As I grew older, I have become a pixel-nazi. The pixels must be square, and even emulated SNES games can not be stretched like they used to on TVs in my personal preferences. If the image gets too small, I prefer to magnify each and every pixel just the same, to maintain the squareness of the pixels.
-
MusicallyInspired
- Posts: 1138
- Joined: Fri Mar 02, 2007 8:03 am
- Location: Manitoba, Canada
- Contact:
In my opinion, the artist's intention takes precedence. But to each their own. 
It is absolutely true (with the exception of possibly DOTT and a couple other later LA adventures). Though, not actually stretched to a 320x240 pixel resolution, but the image was stretched to something that would reach the effect of a 320x240 square-pixel image. Look for formations of objects in images that should be perfect circles in the games, they'll be squished.GAG wrote:It may be true that the older DOS games in 320x200 was stretched to 320x240 on the older CRT monitors. To be honest, I don't remember. It's a long time ago.
I had same problem, and finally i decide was easy to moddify the source code. I change the normal3x filter, for a normal6x, and works great, 1920x1200
I did for different reason, because i want nice EGA style scanlines in my CRT, and in low resolutions looks horrible
I did for different reason, because i want nice EGA style scanlines in my CRT, and in low resolutions looks horrible
Code: Select all
void Normal3x(const uint8 *srcPtr, uint32 srcPitch, uint8 *dstPtr, uint32 dstPitch,
int width, int height) {
uint8 *r;
const uint32 dstPitch2 = dstPitch * 2;
const uint32 dstPitch3 = dstPitch * 3;
const uint32 dstPitch4 = dstPitch * 4;
const uint32 dstPitch5 = dstPitch * 5;
const uint32 dstPitch6 = dstPitch * 6;
assert(((long)dstPtr & 1) == 0);
while (height--) {
r = dstPtr;
for (int i = 0; i < width; ++i, r += 12) {
uint16 color = *(((const uint16 *)srcPtr) + i);
*(uint16 *)(r + 0) = color;
*(uint16 *)(r + 2) = color;
*(uint16 *)(r + 4) = color;
*(uint16 *)(r + 6) = color;
*(uint16 *)(r + 8) = color;
*(uint16 *)(r + 10) = color;
*(uint16 *)(r + 0 + dstPitch) = color;
*(uint16 *)(r + 2 + dstPitch) = color;
*(uint16 *)(r + 4 + dstPitch) = color;
*(uint16 *)(r + 6 + dstPitch) = color;
*(uint16 *)(r + 8 + dstPitch) = color;
*(uint16 *)(r + 10 + dstPitch) = color;
*(uint16 *)(r + 0 + dstPitch2) = color;
*(uint16 *)(r + 2 + dstPitch2) = color;
*(uint16 *)(r + 4 + dstPitch2) = color;
*(uint16 *)(r + 6 + dstPitch2) = color;
*(uint16 *)(r + 8 + dstPitch2) = color;
*(uint16 *)(r + 10 + dstPitch2) = color;
*(uint16 *)(r + 0 + dstPitch3) = 0;
*(uint16 *)(r + 2 + dstPitch3) = 0;
*(uint16 *)(r + 4 + dstPitch3) = 0;
*(uint16 *)(r + 6 + dstPitch3) = 0;
*(uint16 *)(r + 8 + dstPitch3) = 0;
*(uint16 *)(r + 10 + dstPitch3) = 0;
*(uint16 *)(r + 0 + dstPitch4) = 0;
*(uint16 *)(r + 2 + dstPitch4) = 0;
*(uint16 *)(r + 4 + dstPitch4) = 0;
*(uint16 *)(r + 6 + dstPitch4) = 0;
*(uint16 *)(r + 8 + dstPitch4) = 0;
*(uint16 *)(r + 10 + dstPitch4) = 0;
*(uint16 *)(r + 0 + dstPitch5) = 0;
*(uint16 *)(r + 2 + dstPitch5) = 0;
*(uint16 *)(r + 4 + dstPitch5) = 0;
*(uint16 *)(r + 6 + dstPitch5) = 0;
*(uint16 *)(r + 8 + dstPitch5) = 0;
*(uint16 *)(r + 10 + dstPitch5) = 0;
}
srcPtr += srcPitch;
dstPtr += dstPitch6;
}
}
Dosbox now has patch for pixel perfect (or near perfect, without black bars) support in fullscreen mode, maybe ScummVM someday will too! 
https://www.vogons.org/viewtopic.php?f=32&t=49160
https://www.vogons.org/viewtopic.php?f=32&t=49160
There is some shader support in backends/opengl/shader.cpp . Can the default shader be changed to something useful like sharp-bilinear (integer prescale followed by bilinear scaling of remainder?)sev wrote:(...)
Also there is a plan to eventually add shader support to OpenGL port which will let different cool shaders which RetroArch uses to be used with ScummVM.
We always welcome any helping hands, including the tasks above.
Eugene
Noticed something new in daily build (pixel-perfect scaling), only one caveat - it does not work (yet?)
https://www.old-games.ru/forum/attachme ... jpg.154474
https://www.old-games.ru/forum/attachme ... jpg.154474
Can you be a bit more precise here? It seems to work properly for me. But it might not do what you expect (writing the documentation on the wiki for the new stretch modes is on my list of things to do).KainXVIII wrote:one caveat - it does not work (yet?)
Reading this thread now I see that in the first post GAG wrote:
This is pretty much what the pixel-perfect mode does in ScummVM. It does not change the screen resolution, but it will scale the display to a multiple of the original game resolution as much as possible and fill the remaining empty space with black borders.GAG wrote:If you look at RetroArch, the use some kind of integer scaler that automatically blows the image up to the Desktop resolution without requiring you to choose how much (2x, 3x, 4x etc) you would like to resize the image. It fills the empty space with black borders.
There is a caveat when aspect ratio is enabled. For example for games that have an original resolution of 320x200, with aspect ratio correction this is stretched to 320x240 before the pixel-perfect scaling kicks in. And this means that vertically you will not get perfect pixels, unless you use the OpenGL graphics mode and can set your window size (or screen resolution for fullscreen mode) to something that is at least 1600x1200 (a x5 scaling) but less than 1920x1440 (a x6 scaling). A size of at least 3200x2400 and less than 3520x2640 would also work (to get a x10 scaling). The OpenGL graphics mode indeed does all the stretching and scaling (aspect ratio and stretch mode) in one pass, which means the original 320x200 scaled to 1600x1200 should provide perfect pixels (with a 5x scaling horizontally and 6x scaling vertically). All the other graphics modes do the stretch mode as an additional pass after the aspect ratio correction and graphics mode scaling have been applied, which mean you will already have non-perfect pixels even before the stretch mode is applied.
You probably also want to turn off filtering (bi-linear interpolation) if you care about getting crisp big pixels.
And as a final note, the new "Stretch to window" mode would also allow doing what raina wrote above:
But to do so you would need to set your window/screen size to exactly 1280x1000 pixels, which might not be easy to do. But if you can do it, this should give you perfect pixels in either Normal or OpenGL mode and aspect ratio correction turned off.raina wrote:For example: 320x200 scaled 4x horizontally and 5x vertically gives 1280x1000 which a) uses the vertical resolution on a 1080p screen pretty efficiently, b) has uniform pixels, c) is closer to the original 4:3 of rectangular 320x200 than square pixels.
I mean that final image not changed no matter which option i select (even if choose stretched, which should fill whole widescreen did nothing for me..) That's with OpenGL renderer.criezy wrote:Can you be a bit more precise here? It seems to work properly for me. But it might not do what you expect (writing the documentation on the wiki for the new stretch modes is on my list of things to do).KainXVIII wrote:one caveat - it does not work (yet?)