VOGONS


dosbox-staging (DOSBox Git repo)

Topic actions

Reply 200 of 212, by dreamer_

User metadata
Rank Member
Rank
Member
ripa wrote on 2020-02-12, 00:26:

"either rewrite DOSBox buildsystem in cmake"
I have been working on porting dosbox build system to cmake in a private repo with both Linux and Windows compatibility, but progress is slow due to work and other stuff.

Do share 😀 Upload your branch somewhere, it might prevent duplication of efforts. Ping me via email (you'll find it attached to my commits in the repo), or GitHub issue.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 201 of 212, by Serious Callers Only

User metadata
Rank Member
Rank
Member

I actually build munt libmt32 with automake for my ppa, but that's linux only... and i suspect i'm building a defective library too.

I don't know the process to become a debian maintainer and i suspect wouldn't like it either so basically did a lot of the work (without following standards), and dumped everything on a ppa. Only works because munt upstream made the Makefile ofc, much like the patch only works because sergm keeps it updated on his repo and launchpad can automatically import it into a build recipe. What a hero.

Reply 202 of 212, by dreamer_

User metadata
Rank Member
Rank
Member

I think it's time for a progress update 😀

There was lots of activity recently - both in SVN and Git. We're keeping up-to-date with the latest SVN developments (r4328 for build below), so I will include them in the changelog.

Overall over last month, 20 commits landed in SVN trunk, additional 115 commits landed in dosbox-staging master branch. The summary of bigger changes:

Due to changes to defaults, I recommend testers to re-create their .conf files.

Changes originating from SVN (up to r4328):
- Fix a number of PPC/Big Endian - related fixes
- Fix a number of bugs (SF #285, #469, and some others)
- Add OpenGL shader support
- Fix Q-Channel track number reporting - fixes CD player feature in DOS Navigator
- A number of code cleanups and general improvements

Changes from dosbox-staging (up to v0.75.0-pre-526-g6e69228c):
- Some alternative fixes for PPC/Big Endian issues
- Allow Opus support for CD-DA emulation to be optionally disabled during compilation
- Add CGA/mono support
- Update codec libraries: dr_flac to 0.12.4, dr_mp3 to 0.5.5, dr_wav to 0.11.4
- Add support for keymapper reloading in runtime (Z:\> config -set sdl mapperfile=<path>)
- Expand mouse countrol methods: replace the autolock = true/false configuration setting with capture_mouse = ... with a two-value setting.
- Add a makefile for generating .ico and .icns files to contrib
- Fix a dosbox-staging issue with filename shortening on platforms, that have problem with PRIuPTR
- Fix a dosbox-staging regression in CD-DA emulation code (MK3)
- Fix a number of CD-DA emulation related corner cases
- Add a script for performing automatic diffs between CI logs
- Fix a crash in config -get "foo bar"
- Change default: sdl.output: "texture" → "opengl"
- Change default: sdl.capture_mouse "onclick middlegame" → "seamless middlerelease"
- Change default: sdl.fullresolution: "0x0" → "desktop"
- Change default: render.glshader: "none" → "sharp"
- Change default: sblaster.oplemu: default selects "nuked"
- Fix handling of escape characters in softmodem
- Fix a number of static analysis issues
- A number of code cleanups, general code and documentation improvements

Changes removed from dosbox-staging, available in SVN only:
- Rewritten video capture code

macOS test snapshots
This is the first time we offer macOS snapshots; these are very much Work In Progress app bundles, but hopefully should work ok. Unfortunately, we can build snapshots only for the latest macOS version at the moment (10.15 Catalina). App bundle is unsigned - click on app with right mouse button, select "Open" and the dialog window will show a button to run it. Please report issues in #148.

Attachments

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 204 of 212, by dreamer_

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2020-02-16, 17:48:

Having both glshader=sharp and scaler=normal2x as default settings seems a bit counterproductive.

Right, but scaler still affects the default window size. We'll probably get rid of it and use scaler=none once window resizing feature will be finished: https://lbry.tv/dosbox-staging-windows-test-1:3 (right now it works correctly only on Linux).

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 205 of 212, by jmarsh

User metadata
Rank Member
Rank
Member

You may as well just set the default window resolution to 640x480 instead. Otherwise the shader is causing more distortion than ordinary bilinear filtering.
200 vertical pixels -> scaler2x = 400 pixels.
Output size will be set to 480 vertical pixels due to aspect=true.
sharp shader does ceil(480/400) (=2) to get the integer prescale factor, so overall that's a 4x integer upscale to 800 pixels then a bilinear filter back down to 480.

Reply 206 of 212, by dreamer_

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2020-02-16, 21:33:

You may as well just set the default window resolution to 640x480 instead. (…)

No, I can't - it will downscale perfectly fine 800x600 and 1024x768 windows. New defaults were selected to minimize the chance of users needing to go in and override them. They are not set in stone - we'll likely change them again, but there might be a better way of dealing with the problem of scaler and glshader being enabled at the same time.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 207 of 212, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

if output == opengl && glshader != none -> glshader?
That might be something for upstream

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 208 of 212, by jmarsh

User metadata
Rank Member
Rank
Member
dreamer_ wrote on 2020-02-17, 07:37:

No, I can't - it will downscale perfectly fine 800x600 and 1024x768 windows.

For all the DOS games that use those resolutions, vs. all the ones that use 320x200?
If you're going to use that as justification you shouldn't have any scaler set at all, since it won't activate for all resolutions >= 640x480. And the sharp shader will just be wasting power if input size = output size...

New defaults were selected to minimize the chance of users needing to go in and override them. They are not set in stone - we'll likely change them again, but there might be a better way of dealing with the problem of scaler and glshader being enabled at the same time.

It's only a "problem" if you choose conflicting options. Advanced scalers like supersai and hqx have no shader equivalent (they use fixed-size kernels) so having those scalers active with a shader is perfectly sensible.

Reply 209 of 212, by dreamer_

User metadata
Rank Member
Rank
Member
Dominus wrote on 2020-02-17, 07:40:

if output == opengl && glshader != none -> glshader?
That might be something for upstream

I think you mean disabling scaler when glshader is working - and I agree. Plus a little bit of code to change the default window resolution based on selected scaler option (while not applying the scaler itself), or maybe a new option for windowresolution (windowresolution = adapt ?). To be investigated.

The default behaviour that I want is:
1) in window, when program starts in resolution lower than 640x480 - upscale default window size to 640x480, otherwise keep the original resolution. This avoids the problem of having a tiny game window on FHD screens.
2) in fullscreen, the same as glshader=sharp now
3) allow user to resize the window just by resizing the window, without needing to change .conf file.

New defaults fulfil (1) and (2).
(3) will be fixed when new window resizing code feature lands, as showcased in [link] (although in the first iteration it might land as an experimental feature enabled only on Linux - we'll see).

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 211 of 212, by Kisai

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2020-02-17, 10:08:

Sounds like a more sensible choice would be to set windowresolution to somewhere around 75% so you get a decent sized window regardless of the resolution/desktop.

IMO, the sensible choice is 4:3 = 1:1 DAR, and the default be texturenb. Which means that 640x480 (640 x 1), 1280x960 (640 x2), or 1920x1440 (640 x 3) as the default window size. Since the latter will only make sense on a 4K/5K screen and compiled in HiDPI-aware mode, the happy middle there is 1280x960, since it fits within the screen size of expected 1920x1080 monitors. Any other step in between will not produce a pixel-perfect integer scale.

But going one further (that would probably require some re-engineering) would be to go back to the lowest resolutions supported like 160x120 /100 and 320x200, and remove the pixel-doubling/aspect ratio correction from that stage in the display output to the scaler stage (let's call this "Software Scale" and "Hardware Scale")

So if a game actually uses 160x100 160x120, 160x200, 320x200, or 640x200, 640x350, where the DAR is intended to be 4:3, it should be sent to the hardware scaler as that if present, otherwise use the software scaler. That would lower the CPU requirements at the expense of GPU requirements. However this runs into the power-of-two texture limitations (128, 256, 512, 1024 or 2048), so if you upload a 160x100 surface, it's really a 256x128 texture, and 320x200 is 512x256, so there may be additional processing done in SDL to make it a power of 2 internally.

The only reason NOT to use texturenb as default is to explicitly use OpenGL. My preference would be for "no bilinear filtering" done if no shaders or scalers are selected.

Reply 212 of 212, by jmarsh

User metadata
Rank Member
Rank
Member

Most of that is already done as you suggest, i.e. if the output mode supports hardware scaling no aspect correction is done in the software scaler, power-of-two textures are already handled...
No bilinear filtering is not a sensible choice with aspect=true.

When I suggested "75%" I meant it as an explicit setting, it makes DOSBox calculate the output size based on a percentage of the available desktop resolution (and as a bonus centres the DOSBox window on the desktop).