It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
What the title says - when choosing a scaler like normal3x the game window stays the same size. I CAN seem to change it by setting a custom resolution, but if I leave resolution at "original", there is no difference in window size between "none" scaler and "normal3x" scaler. I have tried different outputs as well (surface, openglnb, etc.).
No posts in this topic were marked as the solution yet. If you can help, add your reply
Remember that "Surface" output doesn't support scaling.
Please, post the DOSBox config file you can find in the game's folder.

Anyway you may want to run the game using ScummVM.
avatar
lukeman3000: What the title says - when choosing a scaler like normal3x the game window stays the same size. I CAN seem to change it by setting a custom resolution, but if I leave resolution at "original", there is no difference in window size between "none" scaler and "normal3x" scaler. I have tried different outputs as well (surface, openglnb, etc.).
You have to add "force" to the end of the scaler name (e.g.g normal3xforce) if the game resolution doesn't "require" scaling according to dosbox's rules. Also, on my dosbox/system I have to explicitly change the window resolution as well. Scaling with a scaler in this way works with any video output, including surface. With 3d and resolution switching currently broken on my system, it's the only way I can scale the output.
avatar
lukeman3000: What the title says - when choosing a scaler like normal3x the game window stays the same size. I CAN seem to change it by setting a custom resolution, but if I leave resolution at "original", there is no difference in window size between "none" scaler and "normal3x" scaler. I have tried different outputs as well (surface, openglnb, etc.).
avatar
darktjm: You have to add "force" to the end of the scaler name (e.g.g normal3xforce) if the game resolution doesn't "require" scaling according to dosbox's rules. Also, on my dosbox/system I have to explicitly change the window resolution as well. Scaling with a scaler in this way works with any video output, including surface. With 3d and resolution switching currently broken on my system, it's the only way I can scale the output.
I was under the impression that using the original resolution and a scaler was the preferred method to increase the game's resolution in the interest of keeping all of the pixels from not being stretched or something along those lines..

Or, is the same thing accomplished when setting a custom resolution? In other words does DOSBox automatically correct for this if the new resolution isn't an even multiple of the original resolution?
avatar
lukeman3000: I was under the impression that using the original resolution and a scaler was the preferred method to increase the game's resolution in the interest of keeping all of the pixels from not being stretched or something along those lines..

Or, is the same thing accomplished when setting a custom resolution? In other words does DOSBox automatically correct for this if the new resolution isn't an even multiple of the original resolution?
I don't know what's "preferred"; I used to always just use no scaling in windowed mode, and full screen resolution switching if I wanted it bigger (but now I can't do that due to 3d card issues). Yes, setting a custom resolution with a scalable display method (such as opengl or ddraw) does the same thing, and usually better. Or you can use scummvm (see the separate thread on that), which seems better at scaling. You should probably set aspect=true and/or the correct aspect mode in your monitor to avoid stretching.

As I see it, the only reason you'd use the scalers is if you have to (like I do) or if you prefer the way they look over what the 3D scaling or resolution switching output looks like. Non-integral resolution changes may look funny to you, or they may not. Just try it.
avatar
lukeman3000: I was under the impression that using the original resolution and a scaler was the preferred method to increase the game's resolution in the interest of keeping all of the pixels from not being stretched or something along those lines..

Or, is the same thing accomplished when setting a custom resolution? In other words does DOSBox automatically correct for this if the new resolution isn't an even multiple of the original resolution?
avatar
darktjm: I don't know what's "preferred"; I used to always just use no scaling in windowed mode, and full screen resolution switching if I wanted it bigger (but now I can't do that due to 3d card issues). Yes, setting a custom resolution with a scalable display method (such as opengl or ddraw) does the same thing, and usually better. Or you can use scummvm (see the separate thread on that), which seems better at scaling. You should probably set aspect=true and/or the correct aspect mode in your monitor to avoid stretching.

As I see it, the only reason you'd use the scalers is if you have to (like I do) or if you prefer the way they look over what the 3D scaling or resolution switching output looks like. Non-integral resolution changes may look funny to you, or they may not. Just try it.
Solution is fairly simple...need to use direct3d as your output, and this opens up not just scalers but other shader effects that can be applied to good effect to many DOSbox games. Here is *some* of my config file for the game: (Note that I am using DOSbox SVN-Daum in place of the GOG DOSbox files--SVN allows the use of more options and 64-bit DOSbox.exe support as well.)

# This is the configuration file for DOSBox SVN-Daum. (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 or fixed size (e.g. 1024x768).
# Using your monitor's native resolution 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.
# 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, openglhq, ddraw, direct3d.
# 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.
# pixelshader: Pixelshader program (effect file must be in Shaders subdirectory).
# usescancodes: Avoid usage of symkeys, might not work on all operating systems.
# overscan: Width of overscan border (0 to 10). (works only if output=surface)

fullscreen=True
fulldouble=False
fullresolution=1920x1200
windowresolution=original
output=direct3d
autolock=True
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-SVN-Daum.map
pixelshader=HQ2x.fx
usescancodes=True
overscan=0

[dosbox]
# language: Select another language file.
# machine: The type of machine DOSBox tries to emulate.
# Possible values: hercules, cga, cga_mono, tandy, pcjr, ega, vgaonly, svga_s3, svga_et3000, svga_et4000, svga_paradise, vesa_nolfb, vesa_oldvbe, amstrad.
# vmemsize: Amount of video memory in megabytes.
# The maximum resolution and color depth the svga_s3 will be able to display
# is determined by this value.
# 0: 512k (800x600 at 256 colors)
# 1: 1024x768 at 256 colors or 800x600 at 64k colors
# 2: 1600x1200 at 256 colors or 1024x768 at 64k colors or 640x480 at 16M colors
# 4: 1600x1200 at 64k colors or 1024x768 at 16M colors
# 8: up to 1600x1200 at 16M colors
# For build engine games, use more memory than in the list above so it can
# use triple buffering and thus won't flicker.
#
# 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.
# memsizekb: Amount of memory DOSBox has in kilobytes.
# This value should normally be set to 0.
# If nonzero, overrides the memsize parameter.
# Finer grained control of total memory may be useful in
# emulating ancient DOS machines with less than 640KB of
# RAM or early 386 systems with odd extended memory sizes.
#
# memalias: Memory aliasing emulation, in number of valid address bits.
# . Many 386/486 class motherboards and processors prior to 1995
# suffered from memory aliasing for various technical reasons. If the software you are
# trying to run assumes aliasing, or otherwise plays cheap tricks with paging,
# enabling this option can help. Note that enabling this option can cause slight performance degredation. Set to 0 to disable.
# Recommended values when enabled:
# 24: 16MB aliasing. Common on 386SX systems (CPU had 24 external address bits)
# or 386DX and 486 systems where the CPU communicated directly with the ISA bus (A24-A31 tied off)
# 26: 64MB aliasing. Some 486s had only 26 external address bits, some motherboards tied off A26-A31
#

language=
machine=svga_s3
vmemsize=8
captures=capture
memsize=16
memsizekb=0
memalias=0

[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!.
# linewise: Draw the display line by line. Needed for certain special graphics effects in games and demos. Can be changed at runtime but will be put in effect at the next mode switch.
# char9: Allow 9-pixel wide text mode fonts.
# multiscan: Set this value to true to allow zooming gfx effects used in demos. It will disable several options such as scalers though.
# 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.
# Possible values: none, normal2x, normal3x, advmame2x, advmame3x, advinterp2x, advinterp3x, hq2x,
# hq3x, 2xsai, super2xsai, supereagle, tv2x, tv3x, rgb2x, rgb3x, scan2x, scan3x, hardware2x, hardware3x.

frameskip=0
aspect=false
linewise=false
char9=false
multiscan=false
scaler=hq3x

------

This will give you some idea, at least, of the possibilities.

I might add that on 98% of my DOSbox games I find DOSbox SVN-Daum to be superior to the GOG implementation--I don't know whether the GOG implementation allows direct3d and shader outputs yet, although it might. I have maybe 2-3 very, very old games that *require* the GOG DOSbox config to display properly--that won't allow for a direct3d output--but like I say, SVN works wonderfully well on 98% of my DOSbox games--and I have dozens.

Good luck...!
Post edited March 18, 2017 by waltc