VIDEO Patch for pixel-perfect scaling (SDL1)

[Solanacean]

But there is no such problem with the Official SVN DosBOX?

It didn't occur to me to check - turns out the vanilla dosbox is guilty of it as well!

[Ant_222]

Noticed an interesting issue with the patch. When playing King's Quest 1, whose native resolution is 320x200, if I want to scale it up to 960x800 then I have to set the window resolution in dosbox to 960x801

Please, try again with the attached patch. Edit: If you cannot build DOSBox, wait a bit for the release of version 13.

[Ant_222]

Fantastic work, Ant_222. Both modes are now completely glitch free! One thing though, is 320x200 game supposed to scale like this with output=surfacenp?

Code: Select all

CONFIG:Loading primary settings from config file dsun.conf
MIDI: Opened device:coreaudio
Available area: 1440x900
Color data offset: 1
Scaling: 640x400 (1.00) --[2.2 x 2.2]--> 1440x900  (1.00)
Available area: 1440x900
Color data offset: 1
Scaling: 320x200 (1.00) --[4.5 x 4.5]--> 1440x900  (1.00)
Available area: 1424x858
Color data offset: 1
Scaling: 320x200 (1.00) --[4.3 x 4.3]--> 1373x858  (1.00)

If you had

Code: Select all

aspect=false

then it is the expected result. If not, let me know the game.

[Ant_222]

And in the meantime, alpha 13 is out...

[lukeman3000]

And in the meantime, alpha 13 is out...

Awesome! I always look forward to new releases of your patch.

First, I immediately noticed a significant improvement in speed. Big difference.

Second, I assume that this:

The secondary scaling mode and the exact criterium for the fallback may be specified in the config file

Refers to the dosbox.conf file? I am using the 4035 build of ECE and don't see any such options; maybe I'm overlooking it?

[Ant_222]

First, I immediately noticed a significant improvement in speed. Big difference.

Good! It should not be more than 100% (two times), though.

Second, I assume that this:

The secondary scaling mode and the exact criterium for the fallback may be specified in the config file

Refers to the dosbox.conf file? I am using the 4035 build of ECE and don't see any such options; maybe I'm overlooking it?

This is only a "projected feature". I have not implemented it yet :-)

[Giuliano]

Hi Ant,

I've tested surfacepp with three games so far. I'm using the following options with all of them:

Code: Select all

[sdl]
fullscreen=true
fullresolution=desktop
output=surfacepp

[render]
aspect=true
scaler=none

Two of the games, X-Com: UFO Defense and Star Wars: Rebel Assault, display the image correctly. By correctly I mean with a 4:3 aspect ratio.

These two games come with 320x200 graphics (8:5 aspect ratio), and that's why I use the aspect=true option. Otherwise the Death Star would appear as an egg instead of a sphere.

On the other hand, when I test surfacepp with Star Wars: Rebel Assault II, the aspect=true option does nothing. This game's graphics are 640x400, also 8:5 aspect ratio, and with the aspect=true option they should be transformed to 4:3 as well.

Am I doing anything wrong?

Thank you!

[lukeman3000]

Noticed an interesting issue with the patch. When playing King's Quest 1, whose native resolution is 320x200, if I want to scale it up to 960x800 then I have to set the window resolution in dosbox to 960x801

Please, try again with the attached patch. Edit: If you cannot build DOSBox, wait a bit for the release of version 13.

Ant -

I seem to be encountering this same issue with 1600x1200 resolution when Playing KQ1 (AGI version) whose native res is 320x200. If I sent the window resolution to 1600x1201 then it scales properly.

[KainXVIII]

Giuliano, you aslo better post dosbox console log to make things easier for ant_222

[Ant_222]

On the other hand, when I test surfacepp with Star Wars: Rebel Assault II, the aspect=true option does nothing. This game's graphics are 640x400, also 8:5 aspect ratio, and with the aspect=true option they should be transformed to 4:3 as well.

Indeed, post a screenshot of the DOSBox console window.

I seem to be encountering this same issue with 1600x1200 resolution when Playing KQ1 (AGI version) whose native res is 320x200. If I sent the window resolution to 1600x1201 then it scales properly.

Do you observe it with the latest version of the patch—alpha 13? It has been included into DOSBox EXE.

[lukeman3000]

I seem to be encountering this same issue with 1600x1200 resolution when Playing KQ1 (AGI version) whose native res is 320x200. If I sent the window resolution to 1600x1201 then it scales properly.

Do you observe it with the latest version of the patch—alpha 13? It has been included into DOSBox EXE.[/quote]
Yes

[Ant_222]

Do you observe it with the latest version of the patch—alpha 13? It has been included into DOSBox EXE.

Yes

OK, I will check my patch with these settings.

[Giuliano]

Giuliano, you aslo better post dosbox console log to make things easier for ant_222

Good idea! I confess I'd never paid attention to these logs. Here they are:

Console window for Star Wars: Rebel Assault:

Code: Select all

DOSBox version ECE
Copyright 2002-2017 DOSBox Team, published under GNU GPL.
---
CONFIG:Loading primary settings from config file DOSBox-ECE.conf
One joystick reported, initializing with 4axis
Using joystick CH Control Manager Device 1 with 3 axes, 16 buttons and 1 hat(s)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)
Available area: 1920x1080
Color data offset: 0
Scaling: 320x200 (1.20) --[4.0 x 5.0]--> 1280x1000 (1.25)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)
Available area: 640x480
Color data offset: 0
Scaling: 640x400 (1.20) --[1.0 x 1.0]-->  640x400  (1.00)


For X-Com: UFO Defense:

Code: Select all

DOSBox version ECE
Copyright 2002-2017 DOSBox Team, published under GNU GPL.
---
CONFIG:Loading primary settings from config file DOSBox-ECE.conf
Available area: 1920x1080
Color data offset: 0
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)
Available area: 1920x1080
Color data offset: 0
Scaling: 320x200 (1.20) --[4.0 x 5.0]--> 1280x1000 (1.25)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)
Available area: 1920x1080
Color data offset: 0
Scaling: 320x200 (1.20) --[4.0 x 5.0]--> 1280x1000 (1.25)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)
Available area: 640x480
Color data offset: 0
Scaling: 640x400 (1.20) --[1.0 x 1.0]-->  640x400  (1.00)


And for Star Wars: Rebel Assault II:

Code: Select all

DOSBox version ECE
Copyright 2002-2017 DOSBox Team, published under GNU GPL.
---
CONFIG:Loading primary settings from config file DOSBox-ECE.conf
One joystick reported, initializing with 4axis
Using joystick CH Control Manager Device 1 with 3 axes, 16 buttons and 1 hat(s)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x480 (1.00) --[2.0 x 2.0]--> 1280x960  (1.00)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x480 (1.00) --[2.0 x 2.0]--> 1280x960  (1.00)
Available area: 1920x1080
Color data offset: 0
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)
Available area: 640x480
Color data offset: 0
Scaling: 640x400 (1.20) --[1.0 x 1.0]-->  640x400  (1.00)


Seeing these logs, I realize that the first two games, which I thought were displaying at 4:3 (1.33333...), are apparently displaying at 1.28 (= 1280/1000).

I ran all of them with aspect=true.

[Ant_222]

I seem to be encountering this same issue with 1600x1200 resolution when Playing KQ1 (AGI version) whose native res is 320x200. If I sent the window resolution to 1600x1201 then it scales properly.

I have reproduced and fixed this error in alpha 14.

Thank you for the textshots, Giuliano. They seem absolutely correct to me. What do you think is wrong? Bear in mind that pixel-perfect scaling requires integer scaling factors and cannot always reproduce the exact aspect ratio of the emulated game. My patch tries, however, to end up with as close an approximation as possible. With aspect = true it uses the pixel aspect ratio (PAR) supplied by DOSBox and otherwise assumes it to be unity.

Edit: also see this explanation.

[Giuliano]

Hi Ant,

Edit: also see this explanation.

After reading your explanation, I do understand now how surfacepp works!

What I thought was wrong was the resulting aspect ratio of the games with 640x400 graphics. But now I see that, for surfacepp to bring those graphics closer to 4:3, it would require a 3200x2400 full screen area.

Thank you!

[Ant_222]

What I thought was wrong was the resulting aspect ratio of the games with 640x400 graphics. But now I see that, for surfacepp to bring those graphics closer to 4:3, it would require a 3200x2400 full screen area.

Yes, except that 3200 x 2400 will give you precisely a 4:3 aspect ratio, whereas 2560 x 2000 will be nearly perfect.

[unther]

Hi Ant,

I just tried this patch out today and it looks great - thanks for making this.

After testing on my desktop, I wanted to get it running on my Raspberry Pi 3 (RPI3). However, I ran into compiling problems related to OpenGL calls. From what I understand, the RPI3 GPU driver doesn't support standard OpenGL, so SDL functions related to OpenGL aren't available.

Normally, when compiling dosbox for use on an RPI3, the lack of Open is worked around by passing "--disable-opengl" to the dosbox configure script, which uses the C_OPENGL preprocessor directive to disable OpenGL calls. Unfortunately, your new code for handling opengl surfaces is not wrapped in C_OPENGL #ifdefs, so it's not being disabled with "--disable-opengl", hence causes compile time errors.

As a quick hack, I worked around this problem modifying src/gui/sdlmain.cpp by deleting all lines within the ogSetSize(), ogStartUpdate(), and ogEndUpdates functons, and just have these functions return 0 instead. (This breaks opengl surfaces, but I can't use them anyway on a RPI3).

After make the above changes, I was able to compile successfully, and it runs and looks great with the RPI3 connected to a 1080p HDTV. I'm also running munt on the RPI https://retropie.org.uk/forum/topic/12549/tutorial-installing-munt-mt-32-emulation-on-rpi-3, so it sounds great too.

Thanks again.

[unther]

Note: if anyone else wants to try this on a Raspberry Pi 3 using the RetroPie image, I compiled as follows:

1. install the necessary libraries and development tools:

Code: Select all

sudo apt-get install libsdl1.2-dev libsdl-net1.2-dev libsdl-sound1.2-dev libasound2-dev libpng12-dev automake autoconf zlib1g-dev subversion

2. download Ant's pixel perfect patch (first post of this thread) to some directory and unzip it.

3. download the dosbox source code and apply Ant's patch:

Code: Select all

svn checkout svn://svn.code.sf.net/p/dosbox/code-0/dosbox/trunk dosbox -r 4025 &&
cd dosbox &&
patch -p0 < ../pixel-perfect-alpha14.patch

4. If you're using the alpha14 patch, you'll need to modify src/gui/sdlmain.cpp as per my previous post to work around the opengl compile errors (hopefully not necessary for later versions).

5. configure and compile dosbox

Code: Select all

./autogen.sh &&
CFLAGS="-Ofast -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" \
CXXFLAGS="-Ofast -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" \
./configure --disable-opengl &&
make

6. Make sure the standard RetroPie dosbox package is installed, then overwrite the its binary with the one you just compiled:

Code: Select all

sudo cp -i src/dosbox /opt/retropie/emulators/dosbox/bin/dosbox

7. adjust the dosbox config file as desired (located at ~/.dosbox/dosbox-SVN.conf)

[krcroft]

Unther,

Does your build solve the issue mentioned here?

viewtopic.php?f=41&t=49160&start=320#p592089

My build was based on r2025 and the current pixel perfect patch at the time, and I haven't checked to see if performance has improved since then (I'm running profile-feedback built with gcc 7.x)

Thanks in advanced for checking!

[lukeman3000]

What I thought was wrong was the resulting aspect ratio of the games with 640x400 graphics. But now I see that, for surfacepp to bring those graphics closer to 4:3, it would require a 3200x2400 full screen area.

Yes, except that 3200 x 2400 will give you precisely a 4:3 aspect ratio, whereas 2560 x 2000 will be nearly perfect.

Wouldn't 1600x1200 give him a unity PAR as well as a 4:3 aspect ratio?

I was under the impression that 1600x1200 is the lowest resolution for which you will have a truly perfect PAR and aspect ratio for games with native resolution of 320x200 and 1.20 PAR. To my understand, it is as follows:

For games with native resolution of 320x200 and 1.20 PAR
960x800 = 89% perfect PAR; 92% perfect aspect ratio
1280x1000 = 96% perfect PAR; 99% perfect aspect ratio
1600x1200 = 100% perfect PAR; 100% perfect aspect ratio

Assuming I'm understanding all this correctly so far, I am still confused by something. Why is 4:3 the correct aspect ratio when the native resolution's aspect ratio (320x200) is 1.6?