VOGONS


DOSBox OS X 64bit

Topic actions

Reply 20 of 58, by almeath

User metadata
Rank Member
Rank
Member

No problem. I am glad to help.

I think I further narrowed down this issue. I have found that when switching to windowed mode and moving the Mac mouse cursor rapidly, there is no slow down in the audio. However, clicking back into the DOSBOx window and repeating this with the DOS cursor does cause the slow down.

So some games are exhibiting slow down in the audio when the DOS mouse cursor is moving across the screen, usually when it is done very fast but sometimes when it is scrolled more slowly across the screen. The same thing happens in either full screen or windowed mode. I suspect this could happen with any fast moving graphic and maybe not just the mouse cursor, but I have not found an example yet, and that would not explain why the issue is tending to happen in the opening menus of games and not in the games themselves where there is plenty of graphic movement going on.

I have tested very small and very large resolutions, opengl vs. overlay, and different sound sources from soundblaster to MT-32 and General MIDI. None of these vary the results. The issue can be tested in the following games, all on the main menus.

- Warcraft 1
- Warcraft 2
- Hoyle Classic Card Games
- Space Quest 6

What puzzles me is, why it apparently only affects a small number of games. Some games that use the same engine (i.e. the Sierra SCI games) are not equally affected.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 21 of 58, by Ringding

User metadata
Rank Member
Rank
Member

Regarding the CPU simulation cores:

I would expect heavy FPU users to be affected the most. At least my limited testing with DOS Quake seems to support this. The difference between the 32 bit build and the 64 bit build is dramatic (on Linux, on the same machine).

Not that it would make sense to run a DOS version of Quake 😉.

Reply 22 of 58, by Ringding

User metadata
Rank Member
Rank
Member

Regarding the slow downs:

Unfortunately, you cannot expect one version of macOS to behave like any other. Each release needs to be tested individually 😉. 10.11 is especially bad. I'm having the same problems, which have nothing to do with bitness, but with macOS restricting frame refresh. 10.12 allegedly works much better in this regard.
I had/have the same puzzling problems on 10.11 with Pinball Fantasies.

Related post: OS X: Toolchain & frame rate

Executive summary: It can be nudged into working well on macOS 10.11 by using opengl surface and applying a miniscule patch (really just removing an #ifdef).

Would be interesting to investigate if this fixes your slowdown problems as well.

Reply 23 of 58, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Allegedly is not a good measure 😉
I did not encounter anything like that in 10.11. Anyway, if one wants to compare it better, use the same Dos benchmark on the same machine with the different OS X versions. At least for 32bit I did not see any differences over the last three years.
When you test 32 and 64 bit always remember to use the same optimizations.

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 24 of 58, by almeath

User metadata
Rank Member
Rank
Member

This got me thinking, so I re-installed 10.11 on my iMac and tested both the 32 bit 0.74 DOSBox and the 64 bit SVN by Dominus in each of 10.13 and 10.11. The results were rather confusing.

In macOS 10.13: the audio slows downs occur in the 64 bit SVN but *also* under the 32 bit 0.74 release of DOSBox (that was rather surprising)

In macOS 10.11: the audio slow downs occur in 64 bit SVN but *not* under the 32 bit 0.74 release of DOSBox (which explains why it was good on my Macbook as well)

What I could not test is the SVN by Dominus in 32 bit because there is currently no way to force it to use 32 bit on 10.11 and above. If I could do that, perhaps I could establish whether the problem is the way the SVN code itself interacts with macOS, or whether it is related to the 32/64 bit issue.

Last edited by almeath on 2018-04-19, 11:46. Edited 1 time in total.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 25 of 58, by almeath

User metadata
Rank Member
Rank
Member
Ringding wrote:
Regarding the slow downs: […]
Show full quote

Regarding the slow downs:

Unfortunately, you cannot expect one version of macOS to behave like any other. Each release needs to be tested individually 😉. 10.11 is especially bad. I'm having the same problems, which have nothing to do with bitness, but with macOS restricting frame refresh. 10.12 allegedly works much better in this regard.
I had/have the same puzzling problems on 10.11 with Pinball Fantasies.

Related post: OS X: Toolchain & frame rate

Executive summary: It can be nudged into working well on macOS 10.11 by using opengl surface and applying a miniscule patch (really just removing an #ifdef).

Would be interesting to investigate if this fixes your slowdown problems as well.

Thanks for this suggestion, but I am not technically proficient enough to work out what "removing an #ifdef" involves. I can follow instructions and have manually compiled apps in the terminal, but I would need more guidance on how to achieve this. Also, when you say to use "opengl surface" I thought those are mutually exclusive settings. I thought you can only use either opengl or surface, and surface performs so badly on the macOS it is not worth it.

Is there any chance you could send me a patched build with the change you mentioned? I would be happy to test it thoroughly on my system in both 10.11 and 10.13. 😀

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 26 of 58, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The SVN snapshot in my sig is now *not* forcing 64bit but to use 32bit you need to right click the app in Finder and select "Open in 32-bit mode" (this will stay, so if you want to get back to 64bit you have to uncheck that again).

The mentioned vsync patch is added to this built https://www.dropbox.com/s/p51kh6ino7fk3h2/DOS … .vsync.zip?dl=0 , but it may be that this build is not working correctly at all.

Thanks again for your thorough testing.

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 27 of 58, by Ringding

User metadata
Rank Member
Rank
Member

@almeath: Sorry, I meant output=opengl 😉

A few words:

The patch that I had in mind, which I hope Dominus picked up as I intended it:

--- a/src/gui/sdlmain.cpp
+++ b/src/gui/sdlmain.cpp
@@ -683,9 +683,7 @@ dosurface:
goto dosurface;
}
SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 1 );
-#if defined (WIN32) && SDL_VERSION_ATLEAST(1, 2, 11)
SDL_GL_SetAttribute( SDL_GL_SWAP_CONTROL, 0 );
-#endif
GFX_SetupSurfaceScaled(SDL_OPENGL,0);
if (!sdl.surface || sdl.surface->format->BitsPerPixel<15) {
LOG_MSG("SDL:OPENGL: Can't open drawing surface, are you running in 16bpp (or higher) mode?");

It affects only opengl.

That the official 0.74 binary does not experience the slow down in 10.11 (with output=opengl) matches my experience. But this is not because of 32 vs 64 bits, but because of the older toolchain used for creating it back in the day. As crazy as that sounds, that is my conclusion from long late-night experimentation sessions last year 😉.

Reply 28 of 58, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Crazyness, but points at some changes in the SDL 1.2x sources rather than the old toochain (because I'm almost sure I used the same toolchain for 32bit back then but am using a newer SDL 1.2x source)

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 29 of 58, by Ringding

User metadata
Rank Member
Rank
Member

I thought so too, but I built SDL myself from the same source with both toolchains with no effect. I also built DOSBox against those SDL sources and even swapped one dylib for the other at run time using DYLD_LIBRARY_PATH, again with no effect whatsoever. Nothing would change the basic fact: DOSBox built with old toolchain -> faster refresh rate / no sound stuttering. DOSBox built with new toolchain -> slower refresh rate / sound stuttering. CPU usage was rather low in all cases – after all it was a game that ran well on a 286! As I also wrote in the other thread, I found out later that only the default for OpenGL vsync was different between those two binaries. So good behavior could be restored in a new build by setting SDL_GL_SWAP_CONTROL to 0.

Reply 30 of 58, by Ringding

User metadata
Rank Member
Rank
Member

And now back to the topic of 64bit and performance:

DOS Quake 1 (1.08), 800x600, timedemo demo2
Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz (Haswell)
Fedora 26 x86_64
i386 dynamic-x86: 54.0fps
i386 dynrec: 17.0fps
x86-64 dynrec: 16.0fps

That's a dramatic gap!

Reply 31 of 58, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I got to try that.

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 32 of 58, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There are many topic being discussed at once in this topic, which makes it a bit hard to follow.
1) There is a stuttering possibly based on the toolchain, or on some opengl flag.
2) there is a speed difference between cores.
3) There is a graphics issue with mouse

I can't comment on most things, but for number 2, I do miss the results of core normal for that machine on i386, x64. Another things that I miss is the compiler used on the fedora system.

Water flows down the stream
How to ask questions the smart way!

Reply 33 of 58, by almeath

User metadata
Rank Member
Rank
Member

I am sorry, I probably contributed to the confusion because I wrongly assumed that the sound stuttering problem I was experiencing was related to the 32/64 bit issue.

Although it is now probably 'off topic' I just want to add for the record that the vsync patch definitely resolves the issue in both 32 and 64 bit on macOS 10.11. Unfortunately it seems to have no effect in 10.13, so Apple must have gone and changed something again which broke the patch. 🙁

What I thought was a graphics problem with the mouse cursor seems to be the same underlying issue that affected the sound, and hence the patch resolves it in 10.11.

I do hope someone will be able to figure out another work-around or patch to resolve the issue in macOS 10.13, but I will not hijack this thread any further now that I know this is not an issue with the 64 bit build.

My thanks to @Dominus and @Ringding for pointing me in the right direction. 😀

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 34 of 58, by Ringding

User metadata
Rank Member
Rank
Member

@Qbix:
Number 2)
Results for core=normal (cycles=max):
i386: 5.4 fps
x86-64: 6.0 fps

Compiler:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180130 (Red Hat 7.3.1-2) (GCC)

Reply 35 of 58, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

The dynamic x86 core is just being crazy fast! 😉
At least we have some numbers now. Still 3 times the normal speed isn't too bad, but it is a big difference to the 9/10 times of the dynamic core

edit: what about a slightly lower resolution ? I expect some base speed to be needed and then the extra speed is spend on fps.

Almeath, Oh no, I didn't intend to keep you from posting. I was merely trying to make a summary for myself. The mouse problem I am talking about is the yellow background around it.
For your mouse problem, is that with a real mouse or a mousepad ? I have had unexplainable slowdowns with using the mousepad, It just seemed like the OS was slowing down dosbox.

Water flows down the stream
How to ask questions the smart way!

Reply 36 of 58, by almeath

User metadata
Rank Member
Rank
Member
Qbix wrote:

Almeath, Oh no, I didn't intend to keep you from posting. I was merely trying to make a summary for myself. The mouse problem I am talking about is the yellow background around it.
For your mouse problem, is that with a real mouse or a mousepad ? I have had unexplainable slowdowns with using the mousepad, It just seemed like the OS was slowing down dosbox.

Thanks, I forgot about that one - yes, I get the box too but it is more white in color. I am using a real mouse. It only shows up in 10.13. In 10.11 the cursor is normal in the SVN build.

I should add, I did not seem to get any slowdown related to the mousepad when testing in 10.11 on my MacBook. Unfortunately I do not have a trackpad to use with my iMac to test it there as well.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 38 of 58, by phanboy_iv

User metadata
Rank Newbie
Rank
Newbie

Can confirm a similar diff between the x86 and x86-64 builds using Blood.

Using the in-game FPS counter I get about 30-50FPS in 1024x768 VESA mode with the x86 version, and about 5-7FPS with the same settings, on the same machine (2017 Kaby Lake i7 MBP), with the x86-64 build.

Last edited by phanboy_iv on 2018-05-18, 17:28. Edited 1 time in total.

Reply 39 of 58, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Yeah, Blood is probably one of the hardest cases ;(

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