DOSBox Feature Request Thread

General information and assistance with DOSBox.

Re: DOSBox Feature Request Thread

Postby franck » 2016-9-02 @ 13:58

Hi,
Could I get a feedback on this Feature Request ?
User avatar
franck
Newbie
 
Posts: 8
Joined: 2016-8-11 @ 06:24

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2016-9-02 @ 14:38

Let me hereby notify everyone intereseted that pixel-perfect scaling with aspect-ratio approximation has been implemented. See also the discussions on Reddit in dosbox and dosgaming
Ant_222
Member
 
Posts: 324
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2016-9-04 @ 09:49

jfrisby wrote:Someone was working on a 'pixel-perfect scaler' for SCUMMVM (x5x6 Nearest Neighbor): https://github.com/hooby3dfx/scummvm/tree/perfect-scaler-wip

Since there's monitors that can run 1600x1200 these days it'd be a great way to implement better 4:3 aspect correction. Is this already possible in DOSBox and I've missed it? :P

If you are on Windows, take a look at this patch. It implements pixel-perfect and near-perfect scaling in a way independent of the hard-coded normalnx scalers. One of these modes might be what you need.
Ant_222
Member
 
Posts: 324
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby KainXVIII » 2016-9-10 @ 09:46

My biggest gripe is screen tearing :neutral:
User avatar
KainXVIII
Member
 
Posts: 214
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: DOSBox Feature Request Thread

Postby James-F » 2016-9-10 @ 10:02

Enabling vsync with 70Hz games on a 60Hz monitor is much worse than tearing, the game will stutter so badly it will be unplayable.
Edit: Even without vsync the game stutters badly and has tearing, this is how a mismatch of fps and refresh rate looks, nothing can be done about it with a 60Hz monitor.
Enabling vsync with dosbox will be smooth only on G-sync or CRT monitors with custom resolutions.
Last edited by James-F on 2016-9-10 @ 10:19, edited 2 times in total.
User avatar
James-F
Oldbie
 
Posts: 1397
Joined: 2015-11-30 @ 04:10

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2016-9-10 @ 10:03

KainXVIII wrote:My biggest gripe is screen tearing :neutral:
SDL offers no explicit control over VSync and should do it internally. Maybe there is a problem with your video card or its driver? I can't look into it now, because I am busy with interpolative scaling.
Ant_222
Member
 
Posts: 324
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby KainXVIII » 2016-9-10 @ 10:13

James-F wrote:Enabling vsync with 70Hz games on a 60Hz monitor is much worse than tearing, the game will stutter so badly it will be unplayable.
Enabling vsync with dosbox will be smooth only on G-sync or CRT monitors.

I'm lcd monitor peasant without G-sync.

Ant_222 wrote:
KainXVIII wrote:My biggest gripe is screen tearing :neutral:
SDL offers no explicit control over VSync and should do it internally. Maybe there is a problem with your video card or its driver? I can't look into it now, because I am busy with interpolative scaling.

I don't know, even ykhwong dosbox build with built-in vsync option don't help me much.
User avatar
KainXVIII
Member
 
Posts: 214
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: DOSBox Feature Request Thread

Postby Kisai » 2016-9-27 @ 02:04

PhilsComputerLab wrote:Seeing all the screenshots and videos of DOS games in the wrong aspect ratio online, maybe:

- resize screenshots to 640 x 480
- resize captures to 640 x 480
- Have aspect=true as default?


This isn't wise, because 320x200 requires at least an 8x stretch to not lose data, which puts it over the size of current 1080p HD monitors, and requires a significant amount of processing power (and disk i/o.) What you want is to keep SAR at 8:5 but set the DAR to 4:3 and hope whatever software ingress understands it. You never want to apply post-processing to your "master" video/image source.

What I do with DOSBOX video captures is upscale to 1440x1080. This has so far worked well enough with VirtualDub and straight-up FFMPEG. If you're aiming for the most accuracy you need to scale up to 2560x1920 and then scale back down to 1280x960. I actually play the games at 1280x960.

The 2016 version of the Steam Sierra collections for example use 2X Normal, Overlay as default without aspect ratio correction. A better suggestion is implementing a way for DOSBOX to ID the game engine (Eg sha1 of the EXE) and load/download the optimal base configuration instead of this goofy "one dosbox.exe per game" strategy that GOG uses that is the minimal required to work.

As it is people tend to use OBS or similar "post-process" capture tools lately which doesn't use RGB color space, so the end result is that the video looks worse than up-scaling the dosbox capture.
Kisai
Newbie
 
Posts: 96
Joined: 2010-5-05 @ 08:04

Re: DOSBox Feature Request Thread

Postby KainXVIII » 2016-9-27 @ 08:30

I use Nvidia's Shadowplay to capture dosbox videos lately, looks alright (and pretty smooth with 60 fps), but don't know about color space.. :confused:
https://youtu.be/6z7v48TGIfw
User avatar
KainXVIII
Member
 
Posts: 214
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: DOSBox Feature Request Thread

Postby PhilsComputerLab » 2016-9-27 @ 09:07

Kisai wrote:This isn't wise, because 320x200 requires at least an 8x stretch to not lose data, which puts it over the size of current 1080p HD monitors, and requires a significant amount of processing power (and disk i/o.) What you want is to keep SAR at 8:5 but set the DAR to 4:3 and hope whatever software ingress understands it. You never want to apply post-processing to your "master" video/image source.


Wise? :blush:

Like 90% of online images and videos are in the wrong aspect ratio. It's a battle you're not going to win. Having DOSBox resize to 4:3, sure call it unwise, but it will address the issue.

The "pros" can just override this setting and do whatever fancy up-scaling they want to do.

Currently it's set, assuming the user knows about aspect ratio, which 90% of people don't. So this doesn't make sense to me. Don't leave it in the hand of the users :)
User avatar
PhilsComputerLab
Hardware Mod
 
Posts: 6180
Joined: 2014-9-28 @ 03:33
Location: Western Australia

Re: DOSBox Feature Request Thread

Postby collector » 2016-9-27 @ 15:21

This ^. And the processing power required is not much of an issue with most of today's processors.
User avatar
collector
l33t
 
Posts: 3968
Joined: 2003-1-15 @ 10:39

Re: DOSBox Feature Request Thread

Postby Kisai » 2016-9-28 @ 19:47

PhilsComputerLab wrote:
Kisai wrote:This isn't wise, because 320x200 requires at least an 8x stretch to not lose data, which puts it over the size of current 1080p HD monitors, and requires a significant amount of processing power (and disk i/o.) What you want is to keep SAR at 8:5 but set the DAR to 4:3 and hope whatever software ingress understands it. You never want to apply post-processing to your "master" video/image source.


Wise? :blush:

Like 90% of online images and videos are in the wrong aspect ratio. It's a battle you're not going to win. Having DOSBox resize to 4:3, sure call it unwise, but it will address the issue.

The "pros" can just override this setting and do whatever fancy up-scaling they want to do.

Currently it's set, assuming the user knows about aspect ratio, which 90% of people don't. So this doesn't make sense to me. Don't leave it in the hand of the users :)


No what I meant was that when people play with Steam they use the steam screenshot feature which takes a screenshot of the window. My suggestion in this regard is not to aspect-ratio correct the screenshot files generated by dosbox.

If you are proposing an oversampled pixel-perfect Aspect Ratio correct screenshot alternative (eg "screen size to capture",) that I can get behind. Otherwise it just gives the impression that dosbox produces incorrect emulation. If the dosbox developers want to consider changing the default so aspect-ratio is correct by default, it needs to default to a hardware accelerated surface that will do the stretch in hardware regardless of window/monitor size. Otherwise correct aspect ratio effect is typically worse. This also creates another unintended consequence where playing on a 16:9 monitor or 8:5 monitor, the monitor or GPU may not stretch it in the intended direction because 320x200 is also 8:5 in square pixels.

As for feature requests. I don't think there is any demand for this, but it might solve one problem with GOG/STEAM bundles. Turn all the music cards, including the MPU-401 OFF by default and enable only soundblaster (not pro, not 16) as default. GOG should be configuring the games correctly, but it seems lately they aren't (or some game developers aren't.) Thus you get situations where the sound card detection routine uses the wrong device (eg the MPU-401) over the OPL-2, even when the MPU-401 is connected to nothing.

I had several games refuse to run in a version of ykhwong's build because all sound devices including the disney and tandy sound devices were enabled, which might have more to do with all the other hardware enabled by default in that build, but I narrowed it down by turning off everything but the sound blaster at that time.
Kisai
Newbie
 
Posts: 96
Joined: 2010-5-05 @ 08:04

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2016-10-15 @ 17:31

Kisai wrote:320x200 requires at least an 8x stretch to not lose data
How is that? Assuming a 4x3 image, the pixel aspect ratio (PAR) of this graphical mode is:
Code: Select all
3/4 * 320/200 = 1.2 ,
which requires at least 5x6 magnification and consequently a 1600x1200 display. The pixel-perfect patch will do that. Notice also that some 320x200 games, such as Lure of the Temptress, are designed for unity PAR and should be played with
Code: Select all
aspect=false
Ant_222
Member
 
Posts: 324
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2016-10-15 @ 17:44

PhilsComputerLab wrote:Like 90% of online images and videos are in the wrong aspect ratio. It's a battle you're not going to win. Having DOSBox resize to 4:3, sure call it unwise, but it will address the issue.
Considering that 80% of those screenshots and videos are made with DOSBox, we can win. DOSBox may resize its screenshots intelligently, i.e. by finding the minimal integral horizontal and vertical scales that yield the desired aspect ratio.
Ant_222
Member
 
Posts: 324
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby Kisai » 2016-10-23 @ 00:09

Ant_222 wrote:
PhilsComputerLab wrote:Like 90% of online images and videos are in the wrong aspect ratio. It's a battle you're not going to win. Having DOSBox resize to 4:3, sure call it unwise, but it will address the issue.
Considering that 80% of those screenshots and videos are made with DOSBox, we can win. DOSBox may resize its screenshots intelligently, i.e. by finding the minimal integral horizontal and vertical scales that yield the desired aspect ratio.


You're trying to solve the wrong problem here.

Assuming that the video card has enough memory (pretty much all do. even a 4K monitor only needs about a 36MB framebuffer) when someone takes a screenshot in an external utility, unless the window or full screen is at exactly the right size (eg 1600x1200), it will not generate the intended screenshot. When you generate it from inside dosbox, it's creating exactly the screenshot desired, one that is square-pixel sized, because pre-scaling up and back down alters the pixel data, and that might not be what the user intended. Where you want to fix things are when people are streaming (eg TwitchTV), the aspect-correction can't be done easily when the capture software only operates on square pixels. So it needs to output an aspect-correct resolution and down-scale it if it's in a window. Now consider that the vast majority of monitors are 1080p, not 1200p, so that means the correct 4:3 dimensions is 1440x1080 on those. But that also leaves another problem, what if the monitor is set to "fill screen" and can't easily be adjusted, or the GPU's "scaler" is set incorrectly (believe me this happens all the time on ATI cards after driver updates) then the game isn't even being played at the right aspect ratio because the GPU or Monitor disagree.

So the right problem to solve is "force aspect ratio correct during full screen" which means you calculate how tall the screen is, divide by 3, multiply by 4, make the render aperture that wide, and then fill fill the pillars on the left and right with a solid color, or alternatively a "wallpaper" or manual page with controls listed in that space. Things like Voodoo or MPEG boards would not permit for a solid background fill.

A game shipped from GOG, is rarely setup as anything other than 0x0 full screen (Scale2X.) So that means that could be anything from 720p to 2160p, and on a 5K mac this goes goes up to 2880p, and some production 8K monitors are 4320p. Take an external screenshot, get exactly what is on screen. Take an internal screenshot, get the original resolution.

Perhaps at that point one could consider saving "playback" screenshots in parallel, pulled from the render surface and the emulated video adapter.
Kisai
Newbie
 
Posts: 96
Joined: 2010-5-05 @ 08:04

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2016-10-23 @ 14:56

Kisai wrote:You're trying to solve the wrong problem here.
I am solving the problem of obtaining from DOSBox pixel-perfect screenshots with the correct aspect ratio independently of the hardware used. If it is be not the right problem, what is (see below)?
Assuming that the video card has enough memory (pretty much all do. even a 4K monitor only needs about a 36MB framebuffer) when someone takes a screenshot in an external utility, unless the window or full screen is at exactly the right size (eg 1600x1200), it will not generate the intended screenshot.
What do you assume is intended? With my pixel-perfect patch DOSBox will produce a perfect image provided the display resolution is high enough. The same algorithm sans the limitation of display size can be applied make perfect screenshots.
When you generate it from inside dosbox, it's creating exactly the screenshot desired, one that is square-pixel sized,
Does that mean this screenshot will not faithfully reproduce the original pixel aspect ratio (PAR)?
because pre-scaling up and back down alters the pixel data, and that might not be what the user intended. Where you want to fix things are when people are streaming (eg TwitchTV), the aspect-correction can't be done easily when the capture software only operates on square pixels. So it needs to output an aspect-correct resolution and down-scale it if it's in a window.
That will introduce a lot of interpolation or quantization distortion. Why not use the correct source so as to avoid lossy re-scaling later?
Now consider that the vast majority of monitors are 1080p, not 1200p, so that means the correct 4:3 dimensions is 1440x1080 on those. But that also leaves another problem, what if the monitor is set to "fill screen" and can't easily be adjusted,
If an LCD monitor is operating at its native resolution and the unused area is filled with black or some other color, this will never happen.
or the GPU's "scaler" is set incorrectly (believe me this happens all the time on ATI cards after driver updates) then the game isn't even being played at the right aspect ratio because the GPU or Monitor disagree.
DOSBox need not rely on hardware acceleration for simple pixel-perfect scaling. It can be done by software.
So the right problem to solve is "force aspect ratio correct during full screen" which means you calculate how tall the screen is, divide by 3, multiply by 4, make the render aperture that wide, and then fill fill the pillars on the left and right with a solid color, or alternatively a "wallpaper" or manual page with controls listed in that space.
Good, but not always possible without interpolation or quantization artefacts, and I do not want the quality of my screenshots to depend upon the size and dimensions of my display. Therefore, the screenshot generation algorithm should be separate from the rendering one.
A game shipped from GOG, is rarely setup as anything other than 0x0 full screen (Scale2X.)
What is 0x0? I don't think our discussion has anything to do with the way DOSBox is (mis)configured in GOG releases, not to mention that the official stable DOSBox cannot reliably display games at pixel-perfect scale with aspect-ratio correction.
So that means that could be anything from 720p to 2160p, and on a 5K mac this goes goes up to 2880p, and some production 8K monitors are 4320p. Take an external screenshot, get exactly what is on screen. Take an internal screenshot, get the original resolution.
Neither shall be satisfactory. If the internal screenshot is pixel-perfect, it is likely to have the wrong PAR. If it is aspect-corrected by the DOSBox's nearest-neighbor algorithm, it has quantization distortion. The external screenshot has either quantization or interpolation distortion and can never be guaranteed to be simultaneously a) pixel-perfect, b) reasonably magnified and c) corrected for a possible (and probable) non-unity PAR.
Perhaps at that point one could consider saving "playback" screenshots in parallel, pulled from the render surface and the emulated video adapter.
Of course! That is what I suggest, and optionally processed to have the correct aspect ratio and no distortion, e.g. a 320 x 200 image with a PAR of 1.2 may be upscaled to
Code: Select all
320 x 200 --[5 x 6]--> 1600 x 1200
.
Ant_222
Member
 
Posts: 324
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby Kisai » 2016-10-23 @ 22:09

Ant_222 wrote:
Perhaps at that point one could consider saving "playback" screenshots in parallel, pulled from the render surface and the emulated video adapter.
Of course! That is what I suggest, and optionally processed to have the correct aspect ratio and no distortion, e.g. a 320 x 200 image with a PAR of 1.2 may be upscaled to
Code: Select all
320 x 200 --[5 x 6]--> 1600 x 1200
.


So to summarize:
- The screenshot should have the square pixel resolution and the correct aspect ratio, even if that screenshot ends up larger than the rendered output.

Back to the point about game-streaming and full-screen driver issues. When you download a GOG or Steam game, they are typically configured for 0x0 (current desktop resolution), depending on what the native desktop is set to, this may have the GPU and Monitor disagree on what the display aspect ratio is.

For example, this is the configuration of Space Quest collection on Steam 2016
Code: Select all
fullscreen=true
fulldouble=false
fullresolution=original
windowresolution=original
output=overlay
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper.txt
usescancodes=true

frameskip=0
aspect=false
scaler=normal2x


While this is the configuration for the Quest For Glory collection on Steam
Code: Select all
fullscreen=true
fulldouble=false
fullresolution=0x0
windowresolution=original
output=overlay
autolock=false
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper.txt
usescancodes=true

frameskip=0
aspect=false
scaler=normal2x



On my system, if I run the SQ game this is what it looks like, and is also identical to the GOG configuration:
Image

Now if I run QFG1(EGA):
Image

Neither of these are correct. Yet this is how they are shipped. One might be persuaded that the SCI game running full screen on a 1920x1200 monitor is correct, but it isn't.

So here's the problem, "original" at full screen is telling the GPU to put the game window at 0x0, and stretch it until it fits the width of the screen. When you alt-tab out of it, and hover the icon in the taskbar, you see that the game is in the upper-left corner. According to the monitor, it's at 640x480. So the monitor or the GPU is stretching it to the full width.

With the QFG default configuration, it's using the desktop resolution of 1920x1200. If I switch aspect=true, I get the pillar-bars on the left and right. The Monitor is still running at 1920x1200.

With the SQ1 default configuration, it's using 640x480, if I switch aspect=true, it instead fills more of the vertical space (eg the SQ logo at the beginning shows the version at the bottom of the screen) but it instead fills the entire width of the screen as well making it look like the QFG1 without aspect=true.

So fullresolution=original does not have the desired effect with or without aspect=true. fullresolution=0x0 does have the desired effect.

But, guess what, that doesn't work on SDL2, notice that both configurations use overlay. Overlay doesn't exist in SDL2. If I drop-in my SDL2 version into the SQ, configuration unchanged, the monitor makes a terrible noise and then drops back to a window. If I drop in the SDL2 version for the QFG1-EGA configuration it fails to start in full screen, but can still be switched to full screen with alt-enter and has the same effect as SDL1.2, except now there is a bilinear filter (because the default is auto, which puts the texture preference over texturenb)

What this means is that the intended behavior isn't default. Someone who isn't particularly proficient with editing configuration files will not know what to change, and even if the changes are made, it may not work on their hardware.

So what is the default nVidia settings?
Image

If I change this to "Aspect Ratio" and "Perform scaling on GPU", it blinks and then goes back to Perform scaling on Monitor. So it refuses to use the GPU scaler, thus forcing the monitor to try changing the resolution. A similar problem exists with the ATI cards. Unless you are already running at the resolution you want to scale, it doesn't let you change these settings. You can't select 640x480 in Windows 10 (the "do you want to keep these settings" box appears outside the window.) So I tried 800x600, turned the scale mode on, and yes, 800x600 and are scaled to native 1920x1200 with pillar-bars. But again I try dosbox and nope, it won't have it. That must be what the "override" box is for. Yet selecting it also proves futile.

So fullresolution=original does not work correctly under any scenario. The only working fullscreen configuration under Windows 10 (and presumably everything after XP) is 0x0.

But we're not done yet. What happens if we turn the scaler off? It looks worse when windowed. Looks the same when full screen.
Windowed (aspect=false, scaler=normal2x), as shipped
Image

Windowed 320x240 (aspect=true)
Image
Versus Normal2X (aspect=true)
Image
Versus Full screen (aspect=true)
This will break the forum 1920x1200, download it

Versus Full screen (aspect=false), as shipped
This will break the forum 1920x1200, download it

Which comes back to the entire issue with defaults. By default, the game doesn't look the way it should due to the aspect ratio, and doesn't look "right" because of bilinear filtering or other features that make sense with 3D but makes your eyes strain when trying to read text.

There is one more thing, which you might have noticed from the screenshots. As shipped, the color looks a little different. The Cyan is #55FFFF in all the SDL2 screenshots, but in the SDL1, overlay screenshot (as shipped) it's #49EEFF. According to SCI Companion the color is likely 80,255,255 (#50FFFF)

I suspect the Overlay mode is going through a color-space conversion. A screenshot generated by DOSBOX shows #55FFFF, which would be the correct EGA palette color.

Anyway, as far as features are concerned, the defaults should do as little as possible, and assume the user knows what they are doing, but since most DOS games are supposed to have a 4:3 aspect ratio, and DOSBOX can't predict what the user's monitor/GPU will do, it's difficult to predict any behavior other than fullresolution=0x0, since it will use the desktop resolution. This is why I suggest having some kind of database of optimal settings.

Like, sha1 hash the exe/com file, look it up in a editable database containing things that should override, or be preferred.
Like for all the SIERRA games, they have an EXE of SCIV, SCIDHUV, SIERRA or sometimes just the game's name.
For the SCI games, the forced default would be AR correct, Adlib/Sound Blaster OPL mode,Sound Blaster DAC, MPU-401 disabled. The resource.cfg file would be intercepted to make sure those settings are used unless auto-configuration is disabled.
Then for Optimal settings, The music card would be set to MT-32, Fluidsynth, or MPU-401, depending on what is compiled in and what is preferred. A game could have multiple optimal profiles if the game has more than one optimal configuration.

Right now GOG/Steam does this lazy thing where they ship a complete copy of DOSBOX with every game, even games in the same bundle. This creates poor user experiences as every game is configured differently. If it were easy to just drop the game exe onto dosbox's shortcut, auto-configure, all of this mess could go away.
Kisai
Newbie
 
Posts: 96
Joined: 2010-5-05 @ 08:04

Re: DOSBox Feature Request Thread

Postby dnewhous » 2016-10-23 @ 23:53

Could you add a Adlib mode for the games supporting sound effects through Adlib like F-15 Strike Eagle II?

Or how about emulation of the Yamaha YM2164 a.k.a.OPP (FM Operator Type P), is an FM synthesis sound chip developed by Yamaha, functionally identical to their YM2151 a.k.a. OPM. The OPP was used in various MIDI-based synthesizers by Yamaha - DX21, DX27, DX100, SFG-05, FB-01 (= a standalone SFG-05) - plus several licensed products: the IBM Music Feature Card (effectively an FB-01 on an ISA card) and Korg's DS-8 and Korg 707.

This synth was used on King's Quest IV.
dnewhous
Member
 
Posts: 221
Joined: 2002-7-22 @ 02:53
Location: Gainesville, FL

Re: DOSBox Feature Request Thread

Postby Jorpho » 2016-10-24 @ 01:08

Kisai wrote:Anyway, as far as features are concerned, the defaults should do as little as possible, and assume the user knows what they are doing, but since most DOS games are supposed to have a 4:3 aspect ratio, and DOSBOX can't predict what the user's monitor/GPU will do, it's difficult to predict any behavior other than fullresolution=0x0, since it will use the desktop resolution. This is why I suggest having some kind of database of optimal settings.

Like, sha1 hash the exe/com file, look it up in a editable database containing things that should override, or be preferred.
Like for all the SIERRA games, they have an EXE of SCIV, SCIDHUV, SIERRA or sometimes just the game's name.
For the SCI games, the forced default would be AR correct, Adlib/Sound Blaster OPL mode,Sound Blaster DAC, MPU-401 disabled. The resource.cfg file would be intercepted to make sure those settings are used unless auto-configuration is disabled.
Then for Optimal settings, The music card would be set to MT-32, Fluidsynth, or MPU-401, depending on what is compiled in and what is preferred. A game could have multiple optimal profiles if the game has more than one optimal configuration.
A nice idea, but who do you think is going to maintain this database? It is not a trivial undertaking. Have you seen https://www.scummvm.org/old/documentation.php?view=md5 ?

Right now GOG/Steam does this lazy thing where they ship a complete copy of DOSBOX with every game, even games in the same bundle. This creates poor user experiences as every game is configured differently. If it were easy to just drop the game exe onto dosbox's shortcut, auto-configure, all of this mess could go away.
If GOG/Steam – or rather the actual publisher - wanted to improve "poor user experiences", they would be entirely capable of modifying the DOSBox sources themselves. (Consider Wasteland, as well as Blizzard's freeware offerings.)

In the meantime, I think the vast majority of users do not even appreciate how "poor" their experience is.
User avatar
Jorpho
l33t++
 
Posts: 7043
Joined: 2003-2-14 @ 19:50
Location: Canada

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2016-10-24 @ 20:13

Kisai wrote:So to summarize:
- The screenshot should have the square pixel resolution and the correct aspect ratio, even if that screenshot ends up larger than the rendered output.
Yes, that should be an option in addition to a pixel-for-pixel representation of the source image regardless of the its pixel aspect ratio so that the former will render 320x200 as 1600x1200 and the latter as 320x200.
Back to the point about game-streaming and full-screen driver issues. When you download a GOG or Steam game, they are typically configured for 0x0 (current desktop resolution), depending on what the native desktop is set to, this may have the GPU and Monitor disagree on what the display aspect ratio is.
If you mean
Code: Select all
fullresolution=desktop
in the config file then it is the only meaninful choice for LCD displays, and the overwhelming majority of displays are LCD these days.
For example, this is the configuration of Space Quest collection on Steam 2016
Code: Select all
fullresolution=original
aspect=false
scaler=normal2x
While this is the configuration for the Quest For Glory collection on Steam
Code: Select all
fullresolution=0x0
aspect=false
scaler=normal2x

...
Neither of these are correct. Yet this is how they are shipped. One might be persuaded that the SCI game running full screen on a 1920x1200 monitor is correct, but it isn't.
No, of course not. First, the pixels are blurry in both cases due to interpolation, and your photos are sharp enough show it! Second, the aspect ratio of SQ is forced to the 640x400 section of your 640x480 display and the aspect ratio of QFG1 is left uncorrected for the non-unity par.
So here's the problem, "original" at full screen is telling the GPU to put the game window at 0x0, and stretch it until it fits the width of the screen.
Not quite so. original is telling DOSBox to force the display into the resolution of the source pixel array, which in your case is twice the game's true resolutuion because of the normal2x scaler and without aspect-ratio correction because it is turned off. But DOSBox failed to activate that exact resoltuion and chose the closest one, 640x480 to wit and displayed the game inside it. The aspect ratio with this configuration depends on the display dimentions. This, and the fact that LCDs are useless at non-native resolutions, makes the setting
Code: Select all
fullresolution=original
meaningless unless one has a CRT monitor, in which case—and if the desired grahical mode can be activated—it is the best choice.
When you alt-tab out of it, and hover the icon in the taskbar, you see that the game is in the upper-left corner. According to the monitor, it's at 640x480. So the monitor or the GPU is stretching it to the full width.
When you alt-tab you change everything. You should be able to check the current working resolution via the monitor's built-in menu while in fullscreen DOSBox. 0x0 is not a location on the screen—it is an alias for the desktop resolution.
With the QFG default configuration, it's using the desktop resolution of 1920x1200. If I switch aspect=true, I get the pillar-bars on the left and right. The Monitor is still running at 1920x1200.
That's right. If 1920x1200 is the native resolution of your monitor, then its pixels are square and aspect correction resizes the image so that it shall assume the desired aspect ratio, probably 4/3. That is why the vertical bars appear. The image is still distorted by interpolation.
With the SQ1 default configuration, it's using 640x480, if I switch aspect=true, it instead fills more of the vertical space (eg the SQ logo at the beginning shows the version at the bottom of the screen) but it instead fills the entire width of the screen as well making it look like the QFG1 without aspect=true.
Correct. The orignal PAR is likely 1.2:
Code: Select all
(320/200) / (4/3) = 1.2
, so the verical dimention should be stretched by 20% which results in 320x240, which the normal2x stretches to the whole screen. This configuration is meaningless because for aspect ratio correction DOSBox assumes the target display has square pixels.
So fullresolution=original does not have the desired effect with or without aspect=true. fullresolution=0x0 does have the desired effect.
If you mean aspect ratio alone, then yes, but the pixels are blurry in both cases.
But, guess what, that doesn't work on SDL2, notice that both configurations use overlay. Overlay doesn't exist in SDL2. If I drop-in my SDL2 version into the SQ, configuration unchanged, the monitor makes a terrible noise and then drops back to a window. If I drop in the SDL2 version for the QFG1-EGA configuration it fails to start in full screen, but can still be switched to full screen with alt-enter and has the same effect as SDL1.2, except now there is a bilinear filter (because the default is auto, which puts the texture preference over texturenb)
Yes, the behavior of overlay is hardware-dependent. But I see no reason why DOSBox should suffer from the perks of hardware acceleration, especially because SDL (both 1.2 and 2.0) does provide immediate pixel-by-pixel access to video memory, so the solution is simple:
  • always use the native resolution in fullscreen, and
  • do not rely on hardware scalers, but employ direct pixel-level output routines or gain manual control over horizontal and vertical scaling factors. I think SDL 2.0 has it.
But we're not done yet. What happens if we turn the scaler off? It looks worse when windowed. Looks the same when full screen.
That is because DOSBox's aspect-ratio correction is based on nearest-neightbor interpolation which terrible at small output resolutions but somewhat better at higher ones.
Which comes back to the entire issue with defaults. By default, the game doesn't look the way it should due to the aspect ratio, and doesn't look "right" because of bilinear filtering or other features that make sense with 3D but makes your eyes strain when trying to read text.
I agree.
I suspect the Overlay mode is going through a color-space conversion.
Yes. The first versions of my pixel-perfect patch were based on the overlay mode, which uses a YUV color space ecoded in the UYVY sequence so that the overlay layer has to be twice as wide as the underlying surface to keep the color information!
Anyway, as far as features are concerned, the defaults should do as little as possible, and assume the user knows what they are doing, but since most DOS games are supposed to have a 4:3 aspect ratio, and DOSBOX can't predict what the user's monitor/GPU will do, it's difficult to predict any behavior other than fullresolution=0x0, since it will use the desktop resolution. This is why I suggest having some kind of database of optimal settings.
Well, my solution is simpler—make DOSBox independent of the dimensions and resolution of the target display.

P.S.:I should like to help you with SDL 2.0 either by advice or by actual coding. May I PM you to exchange e-mails?
Ant_222
Member
 
Posts: 324
Joined: 2010-7-24 @ 21:29

PreviousNext

Return to DOSBox General

Who is online

Users browsing this forum: No registered users and 3 guests