VOGONS

Common searches


maximizing dosbox performance in 2019, getting full fps

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by igermi

User metadata
Rank Newbie
Rank
Newbie

I have been using dosbox for about 2 years now to play some of my old racing games. Indycar Racing 2, and Grand Prix 2. The games run pretty good on my computer, which I built myself in 2013. Back when I built it, I had no idea that I'd be using it for dosbox (I didn't even know it existed). The computer has an I7 processor (I think it is 8 core) and it has a 3.5ghz clock speed. It has 32 gigs of ram and 3 solid state drives. I use Linux as an operating system.

The games run pretty good on dosbox. I've spent a lot of time modifying and testing different settings in the config file. Dynamic core, auto core. I think everything is optimized but honestly I don't really see a difference by changing these settings.

There are a couple racetracks in these games that have areas with high detail. The game slows down and I lose some frame-rate here. If I turn off some of the graphics my performance goes back to optimal frame rate.

I even went into my bios settings and played with the CPU options as far as clock frequency. I don't know precisely what I'm doing here but it didn't seem to make a difference in performance anyways.

I am thinking that there is nothing else I can do to modify settings on my existing machine to make this run at a flawless frame rate. I hope I missed something but I don't think so because I have studied dosbox settings and researched this for hours and hours.

I think I might get what I want by building a faster machine specifically to work as best as possible for this. Cost isn't so important. Is there anyone who has built a performance specific machine for dosbox lately?

Reply 4 of 16, by igermi

User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:
you might need to add the architecture dpkg --add-architecture i386 apt-get update […]
Show full quote

you might need to add the architecture
dpkg --add-architecture i386
apt-get update

It's considerably faster.

I could swear at one time (can't remember if it was debian 7 or 8 ) that I enabled the ability to do both 32 and 64 bit stuff..... I have installed debian on probably a half dozen machines at my house in the last few years...

Reply 7 of 16, by junglemontana

User metadata
Rank Newbie
Rank
Newbie

On average, how much faster is the x86 dynamic core compared to the recompiling core? Are we talking about percents or orders of magnitude?

I've thought about compiling a 32-bit version on my main desktop system but it got annoying as some 32--bit SDL-related libraries are missing from Arch Linux repositories...

How does the x86 dynamic core exactly work? Does it let most of the code run natively? (I think Virtualbox works like this when VT-x/AMD-V is not available.)

Reply 8 of 16, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Roughly 200-300% faster? Depends on the game...
It still interprets/recompiles every instruction but takes advantage of the fact that the new code will implicitly produce the same flag results as the original code. So unlike the generic dynamic core there's no need to manually calculate the flags every time they're accessed.

Reply 9 of 16, by junglemontana

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote:

Roughly 200-300% faster? Depends on the game...
It still interprets/recompiles every instruction but takes advantage of the fact that the new code will implicitly produce the same flag results as the original code. So unlike the generic dynamic core there's no need to manually calculate the flags every time they're accessed.

Ok, thanks for the information.

I tried to compile Dosbox (SVN) on Debian, but looks like I can't compile a 32-bit version.

If I do ./configure --build=i386-pc-linux-gnu configuration works but compiling does not - it complains about loss of precision. As far as I can tell this is because it's still compiling a 64-bit version and the error is about conversion of pointers to 32-bit integers.

If I do CC="cc -m32" CXX="c++ -m32" ./configure --build=i386-pc-linux-gnu as instructed elsewhere, it fails during configuration as it can't find some 32-bit SDL files. And installing libsdl1.2-dev:i386 is not OK because installing some of its dependencies would require deleting a huge bunch of packages.

I've tried using --host instead of --build but it doesn't apparently help.

Installing dosbox:i386 from repositories is possible but it can't be installed side by side with the default 64-bit version. This isn't a big problem, but it's just annoying that the 32-bit SVN version can't be compiled.

Reply 10 of 16, by igermi

User metadata
Rank Newbie
Rank
Newbie
junglemontana wrote:

Installing dosbox:i386 from repositories is possible but it can't be installed side by side with the default 64-bit version. This isn't a big problem, but it's just annoying that the 32-bit SVN version can't be compiled.

I did 'sudo apt-get remove dosbox' before hand, it still kept my directory and config file. This way, when the 32 version was installed the old config was already there and it worked pretty much seamless for me.

This is on debian 8 with the standard gnome 3 gui

Reply 11 of 16, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

For Ubuntu/Debian, I think it is easier to use a 32-bit Ubuntu/Debian guest on Virtual Machine to compile the 32-bit version of DOSBox and then run it on the 64-bit host by resolving the i386 libraries dependency. This worked very well for me with Ubuntu/Debian as both distro have good i386 multilib packages ecosystem. Compiling for 32-bit using "gcc -m32" did not work for me, which I believe the linking of 32-bit libraries had issues.

I have recently transitioned from Ubuntu to ArchLinux in favor of its pacman rolling update and x86_64 optimization. Unfortunately for ArchLinux, the i386 multilib is considered unsupported, so I haven't tried the same trick I used for Ubuntu/Debian.

Reply 12 of 16, by junglemontana

User metadata
Rank Newbie
Rank
Newbie
kjliew wrote:

For Ubuntu/Debian, I think it is easier to use a 32-bit Ubuntu/Debian guest on Virtual Machine to compile the 32-bit version of DOSBox and then run it on the 64-bit host by resolving the i386 libraries dependency. This worked very well for me with Ubuntu/Debian as both distro have good i386 multilib packages ecosystem. Compiling for 32-bit using "gcc -m32" did not work for me, which I believe the linking of 32-bit libraries had issues.

I have recently transitioned from Ubuntu to ArchLinux in favor of its pacman rolling update and x86_64 optimization. Unfortunately for ArchLinux, the i386 multilib is considered unsupported, so I haven't tried the same trick I used for Ubuntu/Debian.

Using a virtual machine is a possible solution as well. It just takes some effort.

Debian does have a multiarch ecosystem for x86-64/i386 but there are still packages that are not multiarch-compatible. And if such packages end up into the stable branch, it may take years before they are fixed.

I think the offending package in my case is libglib2.0-dev:i386 which is in the dependency chain of libsdl1.2-dev:i386. It seems that it has been fixed but Stretch repositories still have an older version after two years.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683593

Oh, and Dosbox in Stretch repositories is still version 0.74. Version 0.74-2 is not available in stretch-backports either. PFFT.

Arch Linux no longer maintains a 32-bit distribution but many 32-bit libraries are available in the repositories. However, two such libraries needed by Dosbox (SDL_Net and SDL_Sound) are not so they must be installed manually if one wants to compile a 32-bit Dosbox.

Reply 13 of 16, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
junglemontana wrote:

Oh, and Dosbox in Stretch repositories is still version 0.74. Version 0.74-2 is not available in stretch-backports either. PFFT.

I thought this was the case and was wondering why OP was not experiencing segfaults using the distro package (since the old x64 dynarec doesn't align the stack correctly = FPU instructions trigger alignment faults).

Reply 14 of 16, by igermi

User metadata
Rank Newbie
Rank
Newbie

I never really had issues with running either the 64 or 32 versions as far as crashes are concerned.

This is possibly getting off topic, but Is there a better Linux distribution you would suggest as far as "built in support" would be considered? Back in the day when I installed Debian on this machine I wanted something that wouldn't need to be upgraded all the time. On my other machine I had Debian as well, but I switched to Mint because Debian gave me frustrations not having some later software in the repositories (mostly browser version stuff) I know there are options to compile things manually but I am not the most advanced user. I would be in over my head using Archlinux.

Reply 16 of 16, by junglemontana

User metadata
Rank Newbie
Rank
Newbie

Just a note about Arch Linux: it seems that SDL_sound is only needed for compressed disc audio (rarely needed I guess?) and SDL_net is only needed for networking features. I just ignored these libraries and managed to compile a 32-bit Dosbox on Arch.

If those features are needed, one can install SDL_sound and SDL_net from AUR or manually from their sources.

I'll check if 32-bit Dosbox can be compiled in a 64-bit environment on the newly released Debian 10 "Buster".