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.

   

This is usually an issue with your monitor or graphics driver not scaling up lower resolutions than its native resolution. My monitor and drivers are set to blow them up without altering the aspect ratio. Every monitor or at least driver should have similar options for this.

   

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.

   

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

   

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.

   

In my opinion, the artist's intention takes precedence. But to each their own.

quote:

---

Originally posted by GAG
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

code:

---

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

   

A hybrid x5/x6 scaler (which scales 320x200 up to 1600x1200) would be ideal ...

   

quote:

---

Originally posted by sev
(...)
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

---