VOGONS


dosbox-staging (DOSBox Git repo)

Topic actions

Reply 160 of 212, by krcroft

User metadata
Rank Member
Rank
Member

Let's talk more nuked!

1. Performance: Let's restate our OPL differences as a rule-of-thumb. All we need to remember is "2 and 3". 'fast' is twice as fast as 'compat', which is three times faster than 'nuked'.

2. SIMD: great point dreamer. Doing it ourselves adds maintenance and complexity but probably worth it if the hot spots are concentrated like you said. We can come at it from the compiler side- have it flag problematic loops and blocks that need some adjustment or hinting before it can effectively SIMD them (nuked is simple and elegant enough that this approach will probably work).

Combined with profile-feedback, this lazy-approach can offer most of the benefits with little added maintenance burden. We'd decide on a handful of CPU models for each architecture and generate optimized release binaries for them (march=..., mtune=..., etc).

3. Quality! I am absolutely amazed that nuked is essentially a cycle-accurate emulator of the OPL processor based on inspecting the hardware die. I mean.. most huge companies and governments don't even go through this level of effort (nor have the talent) to retain or extend compatibility with their own hardware or custom ICs.. they just move on or give up.

Could we be any more lucky to have such a thing? wow. That's like little Johnny losing his favorite pet Fido and his parents just happen to be in charge of the government's clandestine bio-cloning laboratory. "Johnny, we got you another puppy.. remember how you lost Fido last year? Well.."

There's an impressive discussion here involving James-F and others, The way to detect OPL3 clone regarding testing actual OPL hardware. Maybe he and other hardcore OPL folks can comment on distinguishable differences between fast, compat, and nuked? help wanted!

2. Threading: right now almost everything in DOSBox blocks and operates serially.

How true is this on actual hardware though? For example: Game generates FM notes which it sends to the OPL driver, which "sends" them across bus to the card, which generates samples fed to its DAC and then to line-out and the speakers. How soon in this chain does the game's function call to the driver return, allowing the game to carry on running the game?

MSCDEX is asynchronous: the game simply says "play cdrom at sector X for N frames", and is handed back control the moment the cdrom starts playing.. the game code carries on without having to make even a single function call to babysit the cdrom; so audio plays for "free" and asynchronously.

This same MSCDEX flow in DOSBox is synchronous though: the CPU emulation core waits on the Ogg decoder to decode each Vorbis packet before the CPU emulator resumes, and in turn the game waits before its instructions resume executing. Fortunately it all happens fast enough that it all fits within the framerate!

It would be interesting if people with this deeper knowledge could comment on all the hardware flows, and which are mostly async vs mostly sync.

Reply 161 of 212, by DosFreak

User metadata
Rank l33t++
Rank
l33t++
dreamer_ wrote on 2020-01-10, 20:18:
DosFreak wrote on 2020-01-10, 19:25:

I am well aware that games that use DOSBox do not require Steam (Unless a pub/dev implements that requirement I think Ubisoft or Origin did that for some games).

DRMed DOS games from Ubi or Origin would be a news to me. My community manages Powered by DOSBox curator page and I think collectively we own all of the games from that list. If you know about any DOS titles with injected DRM, then let me know, please (so we could warn the users). I know about few cases when publisher resigned from DOSBox and replaced it with custom ScummVM build, but that's it.

Off Topic:

Went back and checked and it's Origin that requires the Origin client for their games that use DOSBox:

Syndicate
Uses Launcher.exe that requires the client but there is an untouched DOSBox.exe in the game directory

The following include a DOSBox.exe that requires the Origin client:
Crusader No Remorse
Dungeon Keeper
Simcity 2000 SE
Ultima 8
Wing Commander III

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 162 of 212, by Akuma

User metadata
Rank Newbie
Rank
Newbie

Great, I like a git-repo 😁 , but I have some trouble:

Configure failed as libsdl2 was not found
-Solved it by installing libsdl2-dev (libsdl2-2.0 libsdl2-net-2.0 was not enough)

But then I get an error:

.....
checking whether struct tm is in sys/time.h or time.h... time.h
checking size of unsigned char... 1
checking size of unsigned short... 2
checking size of unsigned int... 4
checking size of unsigned long... 8
checking size of unsigned long long... 8
checking size of int *... 8
./configure: line 5879: syntax error near unexpected token `noext,'
./configure: line 5879: `AX_CXX_COMPILE_STDCXX_11(noext, mandatory)'

Attachments

  • Filename
    log.txt
    File size
    2.35 KiB
    Downloads
    1 download
    File license
    Public domain

Reply 166 of 212, by dreamer_

User metadata
Rank Member
Rank
Member
Akuma wrote on 2020-01-13, 13:46:

Thanks, this worked for me :)
sudo apt install autoconf-archive libopusfile-dev libpng16-16 libsdl2-dev

Just yesterday we merged-in two necessary macros from autoconf-archive, so this dependency won't be required going forward :). I also recommend installing an optional build dependency libsdl2-net-dev.

Some new commits landed in SVN yesterday (r4308) and we have them merged-in already, so I recommend pulling the master branch.

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

Reply 168 of 212, by dreamer_

User metadata
Rank Member
Rank
Member
Akuma wrote on 2020-01-13, 17:15:

Aw-shucks, you shouldn't have :D , updating the dependencies under Linux Builds would have been enough.

Pulled and compiled, happy camper!

Dependencies listed under Linux Builds section are for testers, who want to run the snapshot builds from CI; build dependencies are listed in the INSTALL file. Perhaps I need to re-structure README.md file to make it clearer… or maybe just list build deps list straight above build instructions?

Anyways, have fun - and if you'll have some interesting fixes or features developed mind - send us a PR :)

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

Reply 170 of 212, by Akuma

User metadata
Rank Newbie
Rank
Newbie

Did I miss that ? Recompiling..

I have a question I did not want to bother the dosbox guys with as I don't know if its dosbox or linux. But since you seem to have skills in both 😁. The debug window background is grey. My terminals are configured for black, once I invoke debug it goes grey.

How can I get the terminal window to stay black ? (screenshot attached)

Attachments

Reply 171 of 212, by dreamer_

User metadata
Rank Member
Rank
Member

@aaronp Thanks! 😀

@Akuma you might've missed it - rebase your branch on top of newest master; motivation for retouched splash is explained in the commit message (1f1e83).

TL;DR; New splash was needed for users of GUI frontends - it was in preparation for today's release of Boxtron 0.5.4.

Akuma wrote on 2020-01-17, 18:09:

My terminals are configured for black, once I invoke debug it goes grey.

How can I get the terminal window to stay black ? (screenshot attached)

I guess that's because of curses library you use; look in file src/debug/debug_gui.cpp, you can change the colour set in function DrawBars() (line 150). If you're using ncurses, then you can change colour definitions and create the foreground/background pair that matches your defaults better (but you'll need to do this in source code; ncurses docs). As far as I can tell there's no option to change internal debugger colour scheme at runtime.

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

Reply 174 of 212, by dreamer_

User metadata
Rank Member
Rank
Member

Boxtron is an unofficial Steam Play Compatibility Tool (Steam Play compat. tools are Linux-exclusive Steam feature; official tool is called Proton and allows running many Windows-only games on Linux).

Some game publishers sell old DOS games on Steam, usually bundled with DOSBox in some ancient version (but sometimes with ScummVM), very often without support for Linux. Using Boxtron, user can instruct Steam to run DOS game using Linux-native, up-to-date DOSBox (even if the game is not published for Linux on Steam).

As a bonus, Boxtron does autodetection of MIDI hardware (or runs software synthesiser as a fallback), preconfigures some games to play MIDI out of the box, makes some small tweaks (like deploying a patch when the publisher did not include one with Steam release), etc. When using it, all normal Steam features work correctly (GUI for controller mapping / community input schemes / cloud saves / uploading screenshots, etc, etc).

I strongly suggest using Boxtron+dosbox-staging, but any DOSBox version will do - I am testing also with 0.74-3 and DOSBox-X.

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

Reply 175 of 212, by krcroft

User metadata
Rank Member
Rank
Member

For those with a Mac OS X machine who have some cycles to try/test new mouse-capture behavior:

Read about it here so you know what to expect and change in your conf file: https://github.com/dreamer/dosbox-staging/pull/146

To build on your Mac OSX machine using brew:

git clone --depth 1 --single-branch --branch kc/simplify-capture-1 https://github.com/dreamer/dosbox-staging.git
cd dosbox-staging
brew install $(./scripts/list-build-dependencies.sh -m brew -c clang)
./scripts/build.sh --build-type debug -c clang

If all went well, your DOSBox (staging) binary will be here ./src/dosbox.

Feedback welcome here, PM, or via GitHub PR discussion above -- thank you!

Reply 176 of 212, by citrixscu

User metadata
Rank Newbie
Rank
Newbie
krcroft wrote on 2020-01-27, 00:37:
For those with a Mac OS X machine who have some cycles to try/test new mouse-capture behavior: […]
Show full quote

For those with a Mac OS X machine who have some cycles to try/test new mouse-capture behavior:

Read about it here so you know what to expect and change in your conf file: https://github.com/dreamer/dosbox-staging/pull/146

To build on your Mac OSX machine using brew:

git clone --depth 1 --single-branch --branch kc/simplify-capture-1 https://github.com/dreamer/dosbox-staging.git
cd dosbox-staging
brew install $(./scripts/list-build-dependencies.sh -m brew -c clang)
./scripts/build.sh --build-type debug -c clang

If all went well, your DOSBox (staging) binary will be here ./src/dosbox.

Feedback welcome here, PM, or via GitHub PR discussion above -- thank you!

Seems to work ok on my Catalina laptop.

Unrelated, but the DOSBox content within the window disappears if output=texture[nb] and renderer=auto or metal. This is consistent with any SDL2 build I run on this machine, but I can't find much info on what's going on behind the scenes.

Reply 177 of 212, by krcroft

User metadata
Rank Member
Rank
Member

> Seems to work ok on my Catalina laptop.

citrixscu, thanks for the quick test and feedback.
Does middle-click-to-release work? I've read that you can middle-click with a three-finger tap, however I've also read that 3rd party software is needed (I don't have an OS X machine, so unsure of how this is done).

Regarding the SDL2 content issue, I've opened https://github.com/dreamer/dosbox-staging/issues/149.
If you have a GitHub account, let me know and I can update your user-reference.

Reply 178 of 212, by citrixscu

User metadata
Rank Newbie
Rank
Newbie

citrixscu, thanks for the quick test and feedback.
Does middle-click-to-release work? I've read that you can middle-click with a three-finger tap, however I've also read that 3rd party software is needed (I don't have an OS X machine, so unsure of how this is done).

Middle-click required a 3rd party app / hack on Mojave and I think the devs have disabled it in Catalina, so I cannot test this. That said, however, the following is true:

  • capturemouse=onstart --> works as intended
  • capturemouse=onclick --> works as intended
  • capturemouse=never --> works as intended

Edit: autocorrect