VOGONS


DOSBOX on a GSYNC display - it's pretty great!

Topic actions

First post, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

I spent a lot of time getting DOSBOX to work with old CRT monitors in this thread.

The Quest for Pixel Perfect DOS Emulation

The tl;dr there is that modern LCD monitors struggle with DOS games because of the weird frame rates and resolutions that they used. So much so that "the real thing" (well a CRT monitor in particular) can be a significantly better experience than emulation in some respects.

I recently splurged on a fancy new gaming monitor, and so naturally one of the first things I did was use it to play DOS games 😁.

https://www.dell.com/en-us/shop/alienware-34- … tor-accessories

(this particular model is also an OLED, which is nice for other reasons).

I speculated in that thread that a modern monitor with gsync could do even better though. Basically gsync (and the similar tech free sync) will adjust the framerate of the display to match a the content. A gsync or free sync display with a wide sync window can handle all kinds of oddball framerates perfectly smoothly - even better than real hardware even, as even a CRT monitor will have judder if the frame rate of the game is not well in sync with the refresh rate of the game.

A good example is something like prehistorik 2, which runs at 15 fps for some reason but has a display mode with a 70hz refresh rate, and so even on real hardware there is some judder and it looks choppy as hell. My gsync monitor handles the loading screen and map preview well, which run at 70ish fps, and the main game which runs at 15 fps, even better than my real DOS machine which has some judder and some skipping here and there when the game does whatever it does that makes it drop frames (it drops frame in DOSBOX too, it's just that gsync doesn't used a fixed refresh rate so it's mostly fine).

Gsync also has basically no latency penalty compared vsync or double buffering. So compared to emulating with a CRT like in my other thread, it feels like the latency is actually a bit better.

Another cool feature on modern Nvidia/AMD graphics is that they support driver level integer scaling, which has the potential to be faster and reduce latency compared to software scaling and especially compared to hardware scaling on your display.

So I fired up DOSBOX, and using the settings below I got basically perfect emulation. Smooth frame rate, latency felt low, and crispy unfiltered pixels. No screen tearing, no judder, all DOS gaming goodness.

In my nvidia control panel I enabled gsync for windows and full screen applications, enabled integer scaling, ultra low latency mode, and set a frame limit of 3pfs below my monitors max refresh rate (in my case 172fps). You want to set the vysnc in the driver to global "on" and you went to disable buffering and vsync in your applications (like dosbox).

Dosbox settings -

# This is the configuration file for DOSBox 0.74-3. (Please use the latest version of DOSBox)
# Lines starting with a # are comment lines and are ignored by DOSBox.
# They are used to (briefly) document the effect of each option.

[sdl]
# fullscreen: Start dosbox directly in fullscreen. (Press ALT-Enter to go back)
# fulldouble: Use double buffering in fullscreen. It can reduce screen flickering, but it can also result in a slow DOSBox.
# fullresolution: What resolution to use for fullscreen: original, desktop or fixed size (e.g. 1024x768).
# Using your monitor's native resolution (desktop) with aspect=true might give the best results.
# If you end up with small window on a large screen, try an output different from surface.
# On Windows 10 with display scaling (Scale and layout) set to a value above 100%, it is recommended
# to use a lower full/windowresolution, in order to avoid window size problems.
# windowresolution: Scale the window to this size IF the output device supports hardware scaling.
# (output=surface does not!)
# output: What video system to use for output.
# Possible values: surface, overlay, opengl, openglnb, ddraw.
# autolock: Mouse will automatically lock, if you click on the screen. (Press CTRL-F10 to unlock)
# sensitivity: Mouse sensitivity.
# waitonerror: Wait before closing the console if dosbox has an error.
# priority: Priority levels for dosbox. Second entry behind the comma is for when dosbox is not focused/minimized.
# pause is only valid for the second entry.
# Possible values: lowest, lower, normal, higher, highest, pause.
# mapperfile: File used to load/save the key/event mappings from. Resetmapper only works with the defaul value.
# usescancodes: Avoid usage of symkeys, might not work on all operating systems.

fullscreen=true
fulldouble=false
fullresolution=original
windowresolution=original
output=surface
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-0.74-3.map
usescancodes=true

[dosbox]
# language: Select another language file.
# machine: The type of machine DOSBox tries to emulate.
# Possible values: hercules, cga, tandy, pcjr, ega, vgaonly, svga_s3, svga_et3000, svga_et4000, svga_paradise, vesa_nolfb, vesa_oldvbe.
# captures: Directory where things like wave, midi, screenshot get captured.
# memsize: Amount of memory DOSBox has in megabytes.
# This value is best left at its default to avoid problems with some games,
# though few games might require a higher value.
# There is generally no speed advantage when raising this value.

language=
machine=svga_s3
captures=capture
memsize=16

[render]
# frameskip: How many frames DOSBox skips before drawing one.
# aspect: Do aspect correction, if your output method doesn't support scaling this can slow things down!
# scaler: Scaler used to enlarge/enhance low resolution modes. If 'forced' is appended,
# then the scaler will be used even if the result might not be desired.
# To fit a scaler in the resolution used at full screen may require a border or side bars,
# to fill the screen entirely, depending on your hardware, a different scaler/fullresolution might work.
# Possible values: none, normal2x, normal3x, advmame2x, advmame3x, advinterp2x, advinterp3x, hq2x, hq3x, 2xsai, super2xsai, supereagle, tv2x, tv3x, rgb2x, rgb3x, scan2x, scan3x.
Show last 189 lines

frameskip=0
aspect=true
scaler=normal2x

[cpu]
# core: CPU Core used in emulation. auto will switch to dynamic if available and
# appropriate.
# Possible values: auto, dynamic, normal, simple.
# cputype: CPU Type used in emulation. auto is the fastest choice.
# Possible values: auto, 386, 386_slow, 486_slow, pentium_slow, 386_prefetch.
# cycles: Amount of instructions DOSBox tries to emulate each millisecond.
# Setting this value too high results in sound dropouts and lags.
# Cycles can be set in 3 ways:
# 'auto' tries to guess what a game needs.
# It usually works, but can fail for certain games.
# 'fixed #number' will set a fixed amount of cycles. This is what you usually
# need if 'auto' fails. (Example: fixed 4000).
# 'max' will allocate as much cycles as your computer is able to
# handle.
# Possible values: auto, fixed, max.
# cycleup: Amount of cycles to decrease/increase with keycombos.(CTRL-F11/CTRL-F12)
# cycledown: Setting it lower than 100 will be a percentage.

core=auto
cputype=auto
cycles=max
cycleup=10
cycledown=20

[mixer]
# nosound: Enable silent mode, sound is still emulated though.
# rate: Mixer sample rate, setting any device's rate higher than this will probably lower their sound quality.
# Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
# blocksize: Mixer block size, larger blocks might help sound stuttering but sound will also be more lagged.
# Possible values: 1024, 2048, 4096, 8192, 512, 256.
# prebuffer: How many milliseconds of data to keep on top of the blocksize.

nosound=false
rate=44100
blocksize=1024
prebuffer=75

[midi]
# mpu401: Type of MPU-401 to emulate.
# Possible values: intelligent, uart, none.
# mididevice: Device that will receive the MIDI data from MPU-401.
# Possible values: default, win32, alsa, oss, coreaudio, coremidi, none.
# midiconfig: Special configuration options for the device driver. This is usually the id of the device you want to use
# (find the id with mixer/listmidi).
# Or in the case of coreaudio, you can specify a soundfont here.
# See the README/Manual for more details.

mpu401=intelligent
mididevice=default
midiconfig=

[sblaster]
# sbtype: Type of Soundblaster to emulate. gb is Gameblaster.
# Possible values: sb1, sb2, sbpro1, sbpro2, sb16, gb, none.
# sbbase: The IO address of the soundblaster.
# Possible values: 220, 240, 260, 280, 2a0, 2c0, 2e0, 300.
# irq: The IRQ number of the soundblaster.
# Possible values: 7, 5, 3, 9, 10, 11, 12.
# dma: The DMA number of the soundblaster.
# Possible values: 1, 5, 0, 3, 6, 7.
# hdma: The High DMA number of the soundblaster.
# Possible values: 1, 5, 0, 3, 6, 7.
# sbmixer: Allow the soundblaster mixer to modify the DOSBox mixer.
# oplmode: Type of OPL emulation. On 'auto' the mode is determined by sblaster type. All OPL modes are Adlib-compatible, except for 'cms'.
# Possible values: auto, cms, opl2, dualopl2, opl3, none.
# oplemu: Provider for the OPL emulation. compat might provide better quality (see oplrate as well).
# Possible values: default, compat, fast.
# oplrate: Sample rate of OPL music emulation. Use 49716 for highest quality (set the mixer rate accordingly).
# Possible values: 44100, 49716, 48000, 32000, 22050, 16000, 11025, 8000.

sbtype=sb16
sbbase=220
irq=7
dma=1
hdma=5
sbmixer=true
oplmode=auto
oplemu=compat
oplrate=44100

[gus]
# gus: Enable the Gravis Ultrasound emulation.
# gusrate: Sample rate of Ultrasound emulation.
# Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
# gusbase: The IO base address of the Gravis Ultrasound.
# Possible values: 240, 220, 260, 280, 2a0, 2c0, 2e0, 300.
# gusirq: The IRQ number of the Gravis Ultrasound.
# Possible values: 5, 3, 7, 9, 10, 11, 12.
# gusdma: The DMA channel of the Gravis Ultrasound.
# Possible values: 3, 0, 1, 5, 6, 7.
# ultradir: Path to Ultrasound directory. In this directory
# there should be a MIDI directory that contains
# the patch files for GUS playback. Patch sets used
# with Timidity should work fine.

gus=false
gusrate=44100
gusbase=240
gusirq=5
gusdma=3
ultradir=C:\ULTRASND

[speaker]
# pcspeaker: Enable PC-Speaker emulation.
# pcrate: Sample rate of the PC-Speaker sound generation.
# Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
# tandy: Enable Tandy Sound System emulation. For 'auto', emulation is present only if machine is set to 'tandy'.
# Possible values: auto, on, off.
# tandyrate: Sample rate of the Tandy 3-Voice generation.
# Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
# disney: Enable Disney Sound Source emulation. (Covox Voice Master and Speech Thing compatible).

pcspeaker=true
pcrate=44100
tandy=auto
tandyrate=44100
disney=true

[joystick]
# joysticktype: Type of joystick to emulate: auto (default), none,
# 2axis (supports two joysticks),
# 4axis (supports one joystick, first joystick used),
# 4axis_2 (supports one joystick, second joystick used),
# fcs (Thrustmaster), ch (CH Flightstick).
# none disables joystick emulation.
# auto chooses emulation depending on real joystick(s).
# (Remember to reset dosbox's mapperfile if you saved it earlier)
# Possible values: auto, 2axis, 4axis, 4axis_2, fcs, ch, none.
# timed: enable timed intervals for axis. Experiment with this option, if your joystick drifts (away).
# autofire: continuously fires as long as you keep the button pressed.
# swap34: swap the 3rd and the 4th axis. Can be useful for certain joysticks.
# buttonwrap: enable button wrapping at the number of emulated buttons.

joysticktype=auto
timed=true
autofire=false
swap34=false
buttonwrap=false

[serial]
# serial1: set type of device connected to com port.
# Can be disabled, dummy, modem, nullmodem, directserial.
# Additional parameters must be in the same line in the form of
# parameter:value. Parameter for all types is irq (optional).
# for directserial: realport (required), rxdelay (optional).
# (realport:COM1 realport:ttyS0).
# for modem: listenport (optional).
# for nullmodem: server, rxdelay, txdelay, telnet, usedtr,
# transparent, port, inhsocket (all optional).
# Example: serial1=modem listenport:5000
# Possible values: dummy, disabled, modem, nullmodem, directserial.
# serial2: see serial1
# Possible values: dummy, disabled, modem, nullmodem, directserial.
# serial3: see serial1
# Possible values: dummy, disabled, modem, nullmodem, directserial.
# serial4: see serial1
# Possible values: dummy, disabled, modem, nullmodem, directserial.

serial1=dummy
serial2=dummy
serial3=disabled
serial4=disabled

[dos]
# xms: Enable XMS support.
# ems: Enable EMS support.
# umb: Enable UMB support.
# keyboardlayout: Language code of the keyboard layout (or none).

xms=true
ems=true
umb=true
keyboardlayout=auto

[ipx]
# ipx: Enable ipx over UDP/IP emulation.

ipx=false

[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.

tl;dr

Using gsync/freesync and driver level integer scaling can make DOS emulation even better than the real thing when it comes to smoothness/ frame pacing while keeping latency low and pixels crispy.

Last edited by mothergoose729 on 2022-05-30, 15:11. Edited 1 time in total.

Reply 1 of 20, by Pierre32

User metadata
Rank Oldbie
Rank
Oldbie

I like this information.

Reply 2 of 20, by OldCat

User metadata
Rank Member
Rank
Member

This sounds brilliant!

I probably would like to add some CRT shader on top of it (something like this: https://mattiasgustavsson.itch.io/dosbox-crt ), but that is only my personal preference. Otherwise, excellent use of new technology. It wouldn't even occur to me that this could be done. Appreciate you sharing the details a lot!

Reply 3 of 20, by Spikey

User metadata
Rank Oldbie
Rank
Oldbie

Thanks a lot for this post! As someone who plays on a laptop with GSync capabilities, I'm excited to give this a go.

You want to set the vysnc in the driver to global "on" and you went to disable buffering and vsync in your applications (like dosbox).

I'm slightly confused here. You mean VSync on in the Nvidia settings? I thought enabling VSync would prevent GSync from working? Or am I confusing myself?

Also, why disable buffering in DOSBox? And, do you mean in DOSBox.exe in the Nvidia CP Program Settings (versus in DOSBox.conf)?

Sorry for the questions, audio is my forte, NOT graphics. 😀 Thanks again for your post, for sharing the wealth of knowledge.

Reply 5 of 20, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie
Spikey wrote on 2022-05-30, 20:24:
Thanks a lot for this post! As someone who plays on a laptop with GSync capabilities, I'm excited to give this a go. […]
Show full quote

Thanks a lot for this post! As someone who plays on a laptop with GSync capabilities, I'm excited to give this a go.

You want to set the vysnc in the driver to global "on" and you went to disable buffering and vsync in your applications (like dosbox).

I'm slightly confused here. You mean VSync on in the Nvidia settings? I thought enabling VSync would prevent GSync from working? Or am I confusing myself?

Also, why disable buffering in DOSBox? And, do you mean in DOSBox.exe in the Nvidia CP Program Settings (versus in DOSBox.conf)?

Sorry for the questions, audio is my forte, NOT graphics. 😀 Thanks again for your post, for sharing the wealth of knowledge.

Everything I read said to force vsync in the driver and to disable vsync in the game or application itself.

Reply 6 of 20, by Kahenraz

User metadata
Rank l33t
Rank
l33t

I have had very mixed results getting my Radeon 6900XT to work with Adaptive Sync, which I attribute to my monitors having a very early implementation. It doesn't work on all outputs and there are some caveats that require the burning of incense, jiggling of cables, and frequent excursions beneath my desk with a flashlight. But when it does work, the results are glorious.

ASUS (who made the monitors) says it's AMD's fault. AMD (who made the Radeon) says it's ASUS's fault. I don't have any other Adaptive Sync monitors to test with and this is my only card to support it, so I can't swap that out either. I'm pretty sure that it's the monitors, but I have no other option for testing.

When I found the right kind of monitor some years ago, I bought 6 of them. I only use three now, so I have several spares. I don't know when I will buy any more, but it won't be for some time.

When/if some form of OLED or similar technology in monitors that are not the size of TVs becomes available and affordable, this will be my next upgrade.

Reply 7 of 20, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie
Kahenraz wrote on 2022-05-31, 09:03:
I have had very mixed results getting my Radeon 6900XT to work with Adaptive Sync, which I attribute to my monitors having a ver […]
Show full quote

I have had very mixed results getting my Radeon 6900XT to work with Adaptive Sync, which I attribute to my monitors having a very early implementation. It doesn't work on all outputs and there are some caveats that require the burning of incense, jiggling of cables, and frequent excursions beneath my desk with a flashlight. But when it does work, the results are glorious.

ASUS (who made the monitors) says it's AMD's fault. AMD (who made the Radeon) says it's ASUS's fault. I don't have any other Adaptive Sync monitors to test with and this is my only card to support it, so I can't swap that out either. I'm pretty sure that it's the monitors, but I have no other option for testing.

When I found the right kind of monitor some years ago, I bought 6 of them. I only use three now, so I have several spares. I don't know when I will buy any more, but it won't be for some time.

When/if some form of OLED or similar technology in monitors that are not the size of TVs becomes available and affordable, this will be my next upgrade.

You're in luck, the alienware I bought is such an OLED. I don't know if it supports vsync though.

Reply 8 of 20, by ZellSF

User metadata
Rank l33t
Rank
l33t

Should be noted that G-Sync != G-Sync compatible. G-Sync compatible displays may not display low refresh rates as well as G-Sync displays. They're obviously still an improvement over non-variable refresh rate displays.

For that reason I really wish DOSBox had some more settings for dealing with refresh rate problems.

mothergoose729 wrote on 2022-05-30, 01:48:

Another cool feature on modern Nvidia/AMD graphics is that they support driver level integer scaling, which has the potential to be faster and reduce latency compared to software scaling and especially compared to hardware scaling on your display.

I don't think either AMD or NVidia supports proper integer scaling for non-1:1 PAR resolutions. So using driver level integer scaling should be avoided. There are DOSBox builds that include the pixel perfect patch that are better, as they will correct aspect ratio as much as possible.

Reply 9 of 20, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie
ZellSF wrote on 2022-06-02, 09:16:
Should be noted that G-Sync != G-Sync compatible. G-Sync compatible displays may not display low refresh rates as well as G-Sync […]
Show full quote

Should be noted that G-Sync != G-Sync compatible. G-Sync compatible displays may not display low refresh rates as well as G-Sync displays. They're obviously still an improvement over non-variable refresh rate displays.

For that reason I really wish DOSBox had some more settings for dealing with refresh rate problems.

mothergoose729 wrote on 2022-05-30, 01:48:

Another cool feature on modern Nvidia/AMD graphics is that they support driver level integer scaling, which has the potential to be faster and reduce latency compared to software scaling and especially compared to hardware scaling on your display.

I don't think either AMD or NVidia supports proper integer scaling for non-1:1 PAR resolutions. So using driver level integer scaling should be avoided. There are DOSBox builds that include the pixel perfect patch that are better, as they will correct aspect ratio as much as possible.

It's the refresh rate window that matters most. Below or above a certain threshold it just becomes regular vsync which doesn't do you much good if your content or games are outside that window.

If DOSBox could automatically frame double or triple to target a certain framerate that would be pretty great and help a lot.

Regarding resolution, you definitely want to turn aspect ratio correction on. The driver can scale it the rest of the way, which is convenient but not necessary.

Reply 10 of 20, by ZellSF

User metadata
Rank l33t
Rank
l33t

I was just saying driver level integer scaling is pointless. If you let DOSBox handle the integer scaling which is required for aspect ratio correction, then you should use the highest possible integer scale. Then driver level integer scale and driver level center screen will give identical results.

mothergoose729 wrote on 2022-06-02, 23:02:

It's the refresh rate window that matters most. Below or above a certain threshold it just becomes regular vsync which doesn't do you much good if your content or games are outside that window.

Above, yes (if set in driver settings), below it's left to the display to do frame duplication to get to the minimum refresh rate the display runs at.

mothergoose729 wrote on 2022-06-02, 23:02:

If DOSBox could automatically frame double or triple to target a certain framerate that would be pretty great and help a lot.

Yes, but I would also like to see an option to just output 60 FPS for 60hz and 70 FPS for 70hz. I would also like to see resolution and refresh rate settings separated, so you can set DOSBox to run at 3840x2160@native refresh rate. Not sure if refresh rate changing is even possible with SDL though.

The latter would help with high refresh rate displays that aren't G-Sync too. Both would also help with accuracy; displaying mismatched framerates (15 in 70hz for example) smoothly is an improvement, but not accurate.

It looks like the next release of DOSbox Staging (DOSbox fork / unofficial build) actually will have one of the things I want:
https://github.com/dosbox-staging/dosbox-staging/pull/1596
I'm guessing RetroArch also can do it, but eww RetroArch.

Reply 11 of 20, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
ZellSF wrote on 2022-06-03, 07:15:

Yes, but I would also like to see an option to just output 60 FPS for 60hz and 70 FPS for 70hz.

SVN will already do this when using OpenGL output and a shader, if the shader makes use of a uniform named "rubyFrameCount".

Reply 12 of 20, by Mr_Blastman

User metadata
Rank Member
Rank
Member

Interesting, but... DOS games were never designed for "crispy perfect pixels" as the monitors of the era had flaws that these games exploited. The only way to take advantage of this is to either get a real era-specific CRT for that title or proper CRT emulation.

They definitely weren't crispy, nor perfect.

Reply 13 of 20, by Navjack27

User metadata
Rank Newbie
Rank
Newbie

They were and are pretty perfect. They just don't scale the same as modern displays and aren't confined to the fixed pixel grid issue. What we have now is flawed by the square fixed pixel grid issue. DOS games took advantage of the fact that you have analog range in the shape of the display... Not flaws. Remember turning a dial and getting analog movement of the screen shape with no discreet snapping of the pixels? That is something we cannot do today no matter what. At some point in our modern display of dos games you need at apply some level of resampling to the signal or you get shimmering or uneven pixel representation. Not even getting to frame rate which this thread is mainly about...

NavJackKnows 😏

Reply 14 of 20, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie
Mr_Blastman wrote on 2022-09-02, 01:18:

Interesting, but... DOS games were never designed for "crispy perfect pixels" as the monitors of the era had flaws that these games exploited. The only way to take advantage of this is to either get a real era-specific CRT for that title or proper CRT emulation.

They definitely weren't crispy, nor perfect.

I have a real CRT monitor. Do what you like.

Navjack27 wrote on 2022-09-03, 00:17:

They were and are pretty perfect. They just don't scale the same as modern displays and aren't confined to the fixed pixel grid issue. What we have now is flawed by the square fixed pixel grid issue. DOS games took advantage of the fact that you have analog range in the shape of the display... Not flaws. Remember turning a dial and getting analog movement of the screen shape with no discreet snapping of the pixels? That is something we cannot do today no matter what. At some point in our modern display of dos games you need at apply some level of resampling to the signal or you get shimmering or uneven pixel representation. Not even getting to frame rate which this thread is mainly about...

DOSbox figured out aspect correction ages ago, there is no shimmering. As to what games are "supposed" to look like, that's a whole can of worms.

Reply 15 of 20, by leileilol

User metadata
Rank l33t++
Rank
l33t++
Mr_Blastman wrote on 2022-09-02, 01:18:

They definitely weren't crispy, nor perfect.

Correct. Not everyone had a killer Matrox. Not everyone had a killer Trinitron either. Halation smoothening the dithering contrast out and the non-overdriven scrolling of dithering, RGB misalignment, etc. are other factors lost.

There's also cases of some 'correction' of aspects in certain letterboxed 60hz VGA modes that shouldn't happen (i.e. TIM, Jazz)

apsosig.png
long live PCem

Reply 16 of 20, by ZellSF

User metadata
Rank l33t
Rank
l33t

A lot of DOS games probably didn't that much advantage of flaws of the displays of the era nor the display signal. Partially because they're not at all consistent since people used different monitors and video cards.

There's also a whole argument about making games look like they did to back in the day, how they were designed to look or what looks good. I'm siding with the people who just want the games to look good. If a game runs at a stuttering framerate and I can smooth that out with G-Sync, I'm taking it.

Navjack27 wrote on 2022-09-03, 00:17:

At some point in our modern display of dos games you need at apply some level of resampling to the signal or you get shimmering or uneven pixel representation. Not even getting to frame rate which this thread is mainly about...

The better displays get, the less relevant this is. 1080p display? Scaling DOS games looks pretty bad. 4K display? Pretty much perfect.

Same with framerate, better monitor tech means you can buy monitors that will display it correctly. Low end 60hz only LCDs however aren't going to handle all DOS games well.

Reply 17 of 20, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

When talking about what games are "supposed" to look like you are often just talking about what games looked like when you were a kid as you remembered them. This is a problem with all games but particularly for DOS - what display is "true", did the artists of the game care at all about that stuff, and does it even matter? It doesn't have to be a purity test. Just play games the way you like them.

The biggest reason I prefer emulation is for audio reasons. Mixing SB with midi or redbook audio on real hardware is very difficult to get right and you lose a lot of fidelity in the process. Some people like that nosier, rougher sound. Not me. With DOSBOX it's all digital and mixed in software. Perfection.

Reply 18 of 20, by Navjack27

User metadata
Rank Newbie
Rank
Newbie

No one brought up "supposed to look" until mothergoose729. Don't pull me into any discussions about artists intent or nostalgia. I'm just talking technical.

I'm only clarifying this because my post keeps getting quoted and then "supposed" is used in related replies...

ZellSF wrote on 2022-09-03, 12:40:

A lot of DOS games probably didn't that much advantage of flaws of the displays of the era nor the display signal. Partially because they're not at all consistent since people used different monitors and video cards.

There's also a whole argument about making games look like they did to back in the day, how they were designed to look or what looks good. I'm siding with the people who just want the games to look good. If a game runs at a stuttering framerate and I can smooth that out with G-Sync, I'm taking it.

I'm in full agreement. I wish I had gsync and I wish I had a higher pixel density monitor. Those two things would fix issues I've had related to playing older games. Well, gsync would fix. Pixel density would mask. Getting an old 14" Compaq monitor from like 1994 or something like I had for one of my old computers would solve though.

mothergoose729 wrote on 2022-09-03, 01:59:

DOSbox figured out aspect correction ages ago, there is no shimmering. As to what games are "supposed" to look like, that's a whole can of worms.

I wouldn't call forcing things to square pixel aspect ratio "figured out". Some resolutions just aren't square pixel no matter how you want them to be. Except to display them on our modern displays, they have to be... Or they have to be resampled at some point in the chain of render to present to minimize shimmering. But it can't be and won't be completely removed. We have square pixels. We have alignment of the raster of the pixels (which aren't square by definition and are just points, units, samples of color in a space, usually temporal in nature due to scan (crt) OR sample and hold (all flat panels)) of the graphics we want to display on our monitors...
I'm not one of those crazy every circle must be a circle people with this stuff. I was maybe a bit different? When I played these games as a kid I always turned the H and V knobs until the whole visible area was filled on the 4:3 display. I didn't care what was what, I just knew I had to fill the whole screen like my TV did with console games.
Anyway... How bout that gsync?

NavJackKnows 😏

Reply 19 of 20, by ZellSF

User metadata
Rank l33t
Rank
l33t
Navjack27 wrote on 2022-09-04, 09:17:

I wouldn't call forcing things to square pixel aspect ratio "figured out". Some resolutions just aren't square pixel no matter how you want them to be. Except to display them on our modern displays, they have to be... Or they have to be resampled at some point in the chain of render to present to minimize shimmering. But it can't be and won't be completely removed.

Not to derail another of mothergoose729 threads too badly, but you can get so close you can't see any shimmering. I mean it's still there, but it won't be noticeable to humans... at that point why does it being there matter?

And for low resolutions (320x200 for example), 4K displays can already scale them entirely artifact free, assuming a human is looking at them from a normal viewing distance for playing games and not looking at the screen with a microscope.

Also DOSBox has aspect ratio correction that doesn't force games to square pixels, so I'm not even sure what you're going on about there.