VOGONS

Common searches


Reply 420 of 727, by Solanacean

User metadata
Rank Newbie
Rank
Newbie
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!

Reply 421 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Attachments

  • Filename
    roundingfix.patch
    File size
    84.42 KiB
    Downloads
    6 downloads
    File license
    Fair use/fair dealing exception
Last edited by Ant_222 on 2017-08-25, 19:56. Edited 3 times in total.

Reply 422 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Solanacean wrote:
Fantastic work, Ant_222. Both modes are now completely glitch free! One thing though, is 320x200 game supposed to scale like thi […]
Show full quote

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?

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

aspect=false

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

Reply 424 of 727, by lukeman3000

User metadata
Rank Member
Rank
Member
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?

Attachments

  • Filename
    dosbox-ECE.conf
    File size
    20.46 KiB
    Downloads
    10 downloads
    File license
    Fair use/fair dealing exception

Reply 425 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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 :-)

Reply 426 of 727, by Giuliano

User metadata
Rank Newbie
Rank
Newbie

Hi Ant,

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

[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!

Reply 427 of 727, by lukeman3000

User metadata
Rank Member
Rank
Member
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.

Reply 429 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 430 of 727, by lukeman3000

User metadata
Rank Member
Rank
Member
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

Reply 431 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 432 of 727, by Giuliano

User metadata
Rank Newbie
Rank
Newbie

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:

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:

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:

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.

Reply 433 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 434 of 727, by Giuliano

User metadata
Rank Newbie
Rank
Newbie

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!

Reply 435 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 436 of 727, by unther

User metadata
Rank Newbie
Rank
Newbie

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/tut … lation-on-rpi-3, so it sounds great too.

Thanks again.

Reply 437 of 727, by unther

User metadata
Rank Newbie
Rank
Newbie

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:

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:

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

./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:

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)

Reply 438 of 727, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Unther,

Does your build solve the issue mentioned here?

VIDEO Patch for pixel-perfect scaling (SDL1)

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!

Reply 439 of 727, by lukeman3000

User metadata
Rank Member
Rank
Member
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?