VIDEO Patch for pixel-perfect scaling (SDL1)

Here you can discuss the development of patches.

Re: Patch for pixel-perfect scaling

Postby Solanacean » 2017-8-25 @ 13:06

Ant_222 wrote: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!
Solanacean
Newbie
 
Posts: 22
Joined: 2017-4-03 @ 00:00
Location: Russia

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-25 @ 19:47

lukeman3000 wrote: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.
You do not have the required permissions to view the files attached to this post.
Last edited by Ant_222 on 2017-8-25 @ 19:56, edited 3 times in total.
Ant_222
Member
 
Posts: 357
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-25 @ 19:50

Solanacean wrote: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
Member
 
Posts: 357
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-25 @ 20:25

And in the meantime, alpha 13 is out...
Ant_222
Member
 
Posts: 357
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby lukeman3000 » 2017-8-28 @ 04:22

Ant_222 wrote: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?
You do not have the required permissions to view the files attached to this post.
lukeman3000
Member
 
Posts: 191
Joined: 2009-3-17 @ 00:59

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-28 @ 08:30

lukeman3000 wrote: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 :-)
Ant_222
Member
 
Posts: 357
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Giuliano » 2017-8-31 @ 03:11

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!
Giuliano
Newbie
 
Posts: 14
Joined: 2017-8-26 @ 16:24

Re: Patch for pixel-perfect scaling

Postby lukeman3000 » 2017-8-31 @ 03:28

Ant_222 wrote:
lukeman3000 wrote: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.
lukeman3000
Member
 
Posts: 191
Joined: 2009-3-17 @ 00:59

Re: Patch for pixel-perfect scaling

Postby KainXVIII » 2017-8-31 @ 08:58

Giuliano, you aslo better post dosbox console log to make things easier for ant_222 :cool:
User avatar
KainXVIII
Member
 
Posts: 275
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-31 @ 09:13

Giuliano wrote: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.
lukeman3000 wrote: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.
Ant_222
Member
 
Posts: 357
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby lukeman3000 » 2017-8-31 @ 14:04

lukeman3000 wrote: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
lukeman3000
Member
 
Posts: 191
Joined: 2009-3-17 @ 00:59

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-31 @ 14:15

lukeman3000 wrote:
Ant_222 wrote: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.
Ant_222
Member
 
Posts: 357
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Giuliano » 2017-8-31 @ 20:02

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.
Giuliano
Newbie
 
Posts: 14
Joined: 2017-8-26 @ 16:24

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-31 @ 21:47

lukeman3000 wrote: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.
Ant_222
Member
 
Posts: 357
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Giuliano » 2017-8-31 @ 23:03

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!
Giuliano
Newbie
 
Posts: 14
Joined: 2017-8-26 @ 16:24

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-9-01 @ 08:47

Giuliano wrote: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.
Ant_222
Member
 
Posts: 357
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby unther » 2017-9-05 @ 23:22

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
Newbie
 
Posts: 5
Joined: 2017-9-05 @ 15:59

Re: Patch for pixel-perfect scaling

Postby unther » 2017-9-05 @ 23:37

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)
unther
Newbie
 
Posts: 5
Joined: 2017-9-05 @ 15:59

Re: Patch for pixel-perfect scaling

Postby krcroft » 2017-9-05 @ 23:55

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!
krcroft
Newbie
 
Posts: 43
Joined: 2017-4-29 @ 15:07

Re: Patch for pixel-perfect scaling

Postby lukeman3000 » 2017-9-06 @ 04:59

Ant_222 wrote:
Giuliano wrote: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?
lukeman3000
Member
 
Posts: 191
Joined: 2009-3-17 @ 00:59

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 2 guests