Use fullresolution=original instead of setting your native resolution. If you still get a tiny area in the middle of your screen simply change the GPU scaling setting in your graphics card's control panel (or in the display's on-screen settings if if has this feature). DOSBox's output will then be scaled appropriately to fit the screen.

This will also fix scaling behaviour for native Windows games that only support low resolutions.

I've tried "stretching" the image as well. To be honest, when you stretch an image that small up to the edges of a 4k monitor, it's so horrible and blurry that you actually have to be sitting back on the couch just to endure the "vaseline effect".

I can't believe that an emulator that has been around since 2002 still hasn't been able to achieve native scaling beyond 3x the normal resolution of DOS.

Are you sure those are the only options? Crisp and tiny, or huge and blurry? Why can't I just enable some sort of hardware scaling so I can enjoy something that's both large and crisp? Are there any DOSBox builds that will support the hwscale variable?

Plenty of people have been talking about this magical hwscale variable. Why isn't there any official references to it or instructions as to how to make it work?

http://www.abandonia.com/vbullet/showthread.php?t=8664

https://zxtech.wordpress.com/2010/09/05/dosbo … dow-resolution/

Would anyone be able to provide any information on hwscale?

What renderers (output) does it work with? Why is it not in the Wiki? Does it take an int or a float?

Give me a 4k monitor and I'll tell you the settings 😊

I did have it running at 4K with Nvidia's Dynamic Super Resolution. It renders it at 4k, then scales it down for a somewhat nicer image.

Are there ways to get DOSBox itself to scale this way, though? Manufacturer driver hacks don't help me as much as native support would, because some of my machines I would like to get scaling on don't even use x86

😜

DOSBox SVN Daum can fully scale to the current native resolution. The default mode has the pixels scaled up without any filtering applied or you can use one of several filters (as with normal DOSBox).

SpectreVR wrote:

I've tried "stretching" the image as well. To be honest, when you stretch an image that small up to the edges of a 4k monitor, i […]
Show full quote

I've tried "stretching" the image as well. To be honest, when you stretch an image that small up to the edges of a 4k monitor, it's so horrible and blurry that you actually have to be sitting back on the couch just to endure the "vaseline effect".

I can't believe that an emulator that has been around since 2002 still hasn't been able to achieve native scaling beyond 3x the normal resolution of DOS.

Are you sure those are the only options? Crisp and tiny, or huge and blurry? Why can't I just enable some sort of hardware scaling so I can enjoy something that's both large and crisp? Are there any DOSBox builds that will support the hwscale variable?

Plenty of people have been talking about this magical hwscale variable. Why isn't there any official references to it or instructions as to how to make it work?

http://www.abandonia.com/vbullet/showthread.php?t=8664

https://zxtech.wordpress.com/2010/09/05/dosbo … dow-resolution/

You seem so sure all the devs have 4k monitors to made it possible.

Does this work?

output= opengl
windowresolution= 1600x1200

Or whatever window size you want?

SpectreVR: Do you want to play in an window or fullscreen? For fullscreen you could try

1output= openglnb
2fullresolution=desktop

Else, you could try my enhanced DOSBox build (see signature), which offers at least 6x normal scaling, thanks to VileRancour.

SpectreVR wrote:

Yes, I know how to use the .conf file to set scaling higher. I've been trying to use the "normal3x" scaler and it just doesn't c […]
Show full quote

Yes, I know how to use the .conf file to set scaling higher. I've been trying to use the "normal3x" scaler and it just doesn't cut it.

It's setting me to a little 960x600 window in the middle of the screen. On a 4K monitor, this is barely even legible. I've been hurting my eyes and getting headaches trying to play Might and Magic, Albion, Oregon Trail Deluxe, etc on it. It's just so small I almost have to give up on DOSBox.

I looked in the .conf Wiki page, and apparently the highest I can go is 3x scaling with any scaler. HWSCALE has been purged from this page and there's no support for it apparently. It doesn't work on any renderer. How is this possible for a program that's been in development for so long to still only have support for a resolution that's 3x the size of 320x200? I'm pretty sure that there were resolutions larger than that when DOSBox development STARTED.

Has anyone else out there had ANY success getting the resolution to be, say, 4x or 5x even? That would help. I'm needing 12x 320x200 scaling just to fill up/fit a dimension of my monitor, just for perspective.

(please ignore, for Google crawlers) DOSBox hardware scaling 4k 1440p 1080p small

Use a SDL2 build and set the full-screen resolution to 0x0 (or desktop), and aspect correction on. See here: Re: DOSBox Feature Request Thread

You need a hardware accelerated surface/texture for this to work, thus you need to use a SDL2 build or OpenGL in the stock builds with bilinear filtering turned off if you want it to not look fuzzy.

The software scaler is likely unusable with a 4K monitor because it's not parallel (eg not using OpenCL or OpenMP or similar.) We can get away with it at HD and below resolutions because the multiplier is only 2 or 3 typically, but at 4K it would need a 9x multiplier, and a UHD monitor would need an 18x multiplier.

It should be possible to set the output to 1280x1024 or something like this (1280x720) (1600x900) and use 2x or 3x scaler.

Then let the monitor upscaling from 1280x1024 to native Resolution.

Yesterplay80 wrote:

Else, you could try my enhanced DOSBox build (see signature), which offers at least 6x normal scaling, thanks to VileRancour.

Whereas your build includes my pixel-perfect patch, why not let SpectreVR try it? The following settings should automatically produce a razor-sharp image with maximum possible scale regardless of the actual resolution and the hard-coded normalnx scalers:

1fullresolution=desktop
2output=surfacepp

Everyone seems to assume that he wants to use full screen. On such a big monitor he very well want to run it in a window. Forcing a 320x200 game to full screen will create some gigantic pixel blocks or the blurriness from the various filters. A decent sized window may be the best solution.

collector wrote:

Everyone seems to assume that he wants to use full screen. On such a big monitor he very well want to run it in a window. Forcing a 320x200 game to full screen will create some gigantic pixel blocks or the blurriness from the various filters. A decent sized window may be the best solution.

As I understand, SpectreVR wants a crisp image in the first place.

Kisai wrote:

The software scaler is likely unusable with a 4K monitor because it's not parallel (eg not using OpenCL or OpenMP or similar.) We can get away with it at HD and below resolutions because the multiplier is only 2 or 3 typically, but at 4K it would need a 9x multiplier, and a UHD monitor would need an 18x multiplier.

Have you tested the performance of SDL 2.0 with integer scaling via SDL_RenderSetScale()?

Ant_222 wrote:

Kisai wrote:

The software scaler is likely unusable with a 4K monitor because it's not parallel (eg not using OpenCL or OpenMP or similar.) We can get away with it at HD and below resolutions because the multiplier is only 2 or 3 typically, but at 4K it would need a 9x multiplier, and a UHD monitor would need an 18x multiplier.

Have you tested the performance of SDL 2.0 with integer scaling via SDL_RenderSetScale()?

No I haven't, I'm not sure if that's what you'd want to do since you're operating on a line-by line basis. The purpose of that feature is to create a game with a resolution at a different display scale, and then draw everything with multiple SDL textures where you need the coordinates to be consistent, where as how DOSBOX works is just one texture, therefor it would add an additional complication into the SDL backend that is unnecessary.

I bought a 4K monitor, it arrived today.

So I re-tested all the same things I did in the "feature request thread", pretty much everything but the full screen switch and the dosbox debugger work. There are some unintended side-effects however.

This is a ASUS MG24UQ, it has a feature in the monitor to switch the aspect ratio, so it IS possible to tell it to force the aspect ratio to 4:3 without screwing around with the GPU controls. That said, the defaults are not great. The fullscreen performance at 640x480 (SDL1 stock dosbox overlay, 10% window/fullscreen idle) vs 3840x2160 (SDL2.0 texturenb) is negligible on my system (0.2% with SDL2, full screen or windowed idle)

The dosbox debugger doesn't like the display scaling. it just blanks out and you see things when the scroll. I'm not sure why that is yet, but I think it may be an unintended side effect of windows 10's display scaling itself. Point of interest, When dosbox is not compiled with HiDPI awareness in, your 4K monitor at 200% has the same screen real estate as a 1920x1080. So DOSBOX's game window get scaled too when it's windowed. Since there are no menus or GUI objects, DOSBOX can be compiled with HiDPI enabled and you can actually specific a 4K windowed resolution. a 2560x1920 window is still only 9% CPU. (so roughly 72% of one core)

Also when DOSBOX switches in/out of full screen, it messes up the display scaling of other windows, that I'm not sure if it's DOSBOX or SDL because I can't seem to replicate it consistently.

Things to consider:
- Compile non-debug DOSBOX's windows manifest to be DPI aware.
- SDL2 does not require a scaler with texture/texturenb and performance does not appear impacted regardless of resolution or full screen
- 4K monitor might have an aspect ratio over-ride allowing 'original' resolution at 640x480 to be used. This monitor's smallest resolution is 640x350. This is moot with SDL2 since it can be set to desktop (even when HiDPI aware) and use the hardware scaling.

That said, not everyone is going to have a high end system, and what I have is a Geforce GTX760 which is actually good enough for 2D 4K stuff.

Edit: I forgot to turn off heavy_debug, the CPU is actually 0.37% windowed (2560x2000)

I'm surprised no one has pointed out an obvious quick fix, use Windows magnifier. Wouldn't hurt to mention this in the readme or elsewhere, along with mac and linux equivalent magnifying tools. mac and linux should have them built into the OS, accessibility options, and there are alternatives: http://magnifier.sourceforge.net/

Kisai wrote:

Ant_222 wrote:

Have you tested the performance of SDL 2.0 with integer scaling via SDL_RenderSetScale()?

No I haven't, I'm not sure if that's what you'd want to do since you're operating on a line-by line basis. The purpose of that feature is to create a game with a resolution at a different display scale, and then draw everything with multiple SDL textures where you need the coordinates to be consistent, where as how DOSBOX works is just one texture, therefor it would add an additional complication into the SDL backend that is unnecessary.

It shall work with a single texture as well, as described in the migration guide. Just calculate the vertical and horizontal scales using, for example, my algorithm, and then set them in the renderer. This will give you pixel-perfect and hardware-accelerated scaling, if your renderer is hardware-accelerated, which I should think it is. That will be what you want—hardware scaling independent on the display dimensions and other hardware-specific factors.

awgamer wrote:

I'm surprised no one has pointed out an obvious quick fix, use Windows magnifier. Wouldn't hurt to mention this in the readme or elsewhere, along with mac and linux equivalent magnifying tools. mac and linux should have them built into the OS, accessibility options, and there are alternatives: http://magnifier.sourceforge.net/

This is crutches, and it won't work in fullscreen. I myself was considering this quick fix before I wrote the pixel-perfect patch.