VOGONS

Common searches


First post, by truth_deleted

User metadata

There are two options for fullresolution while output=openglnb: desktop or original. Original is typically the low resolution source, while fullresolution=desktop scales a high quality image to full screen. This is an ideal configuration for DOS/VGA games and especially for Win95 games. However, the image was not scaling while running a 95 guest nor games inside the guest; instead the image appeared as a small window on a black background.

Attached is a patch against DOSBox 0.74/SVN to fix this issue. I can now run Win9x games inside DOSBox and have a high quality fullscreen image (fullresolution=desktop). This patch should also work for DOS games which do not scale to fullscreen while fullresolution=desktop. It's a minor edit to code, but consider it a test patch until its compatibility is verified.

Attachments

  • Filename
    Opengl_Fullscreen_95.diff
    File size
    1.06 KiB
    Downloads
    128 downloads
    File comment
    OpenGL Fullscreen/Win95 patch
    File license
    Fair use/fair dealing exception

Reply 1 of 9, by robertmo

User metadata
Rank l33t++
Rank
l33t++

the patch simply allows opengl stretching images using color higher than 8-bit
fixed after so many years 😉

fullresolution has more options - you can set here any resolution you want same as with windowresolution
you can use it with vgaonly and hqnx and windowresolution too

One bug i found is hqnx has problems with aspect true - makes image twice taller.

Reply 2 of 9, by NY00123

User metadata
Rank Member
Rank
Member

Some scalers, and possibly emulated high-res graphic modes as well (say 15-bpp or more), are designed with the RGBA color format (on the host side) in mind, while DOSBox' OpenGL output currently uses BGRA. Furthermore, although less relevant to this specific patch, the Overlay output has its own unique color format (a variant of YUV). This is one reason for forcing Surface output on some occassions.

So, while the patch may seem to work now, there may still be cases where you get the wrong colors. (And then there may be more problems I haven't thought about, like the one described by robertmo in the last reply.)

Reply 4 of 9, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Moved to patches forum

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 5 of 9, by truth_deleted

User metadata

Thank you both for testing the code change and for documenting the nature of the original issue. It is a good insight that this is color depth specific. It should be possible to enable the code change only when running at high color depths, given the minor patch causes any significant issues in DOS games, whether related to aspect mode or color space. In the case this is necessary, one simple and coarse fix would be to try a conditional statement detecting color depth.

I did verify that I am unable to reproduce the bug while setting hqnx/aspect=true. I suspect this is related to detection of the screen size, but we can continue to test.

Reply 6 of 9, by robertmo

User metadata
Rank l33t++
Rank
l33t++
truth5678 wrote:

I did verify that I am unable to reproduce the bug while setting hqnx/aspect=true. I suspect this is related to detection of the screen size, but we can continue to test.

aspect=true has to work (so original has to be in 320x200 (most dos games) or 640x400 or some other more rare resolution (Quake allows choosing from many)

Reply 7 of 9, by truth_deleted

User metadata

I reproduced the bug. It occurs when fullresolution=original, aspect=true, while full screen. Can you verify that aspect=false isn't preserving the true aspect ratio? It does for me.

Also, this bug existed before my code change. I have the same bug in an unmodified copy of dosbox.

Reply 8 of 9, by NY00123

User metadata
Rank Member
Rank
Member

For some emulated video modes, it seems like the aspect setting is ignored (i.e. aspect=false is practically forced). For textual modes this is done by design. For any graphical modes where this is reproduced it is probably a bug. An example of a game for which the bug is reproduced is Rayman (along with a few variants of that game).