VOGONS


First post, by Ringding

User metadata
Rank Member
Rank
Member

Because of Pinball Fantasies no-scroll patch for dosbox 0.65 I started playing around with Pinball Fantasies and noticed that it was quite unplayable on OS X (10.11) because of unpredictable slowdowns and sound stuttering. After a while I noticed that the official 0.74 release build does not exhibit this problem. Further experimentation revealed the following:

- The problem is caused by the frame rate being restricted to 60fps. Since GFX_EndUpdate is blocked by this, the VGA refresh rate of 70fps cannot be attained.
- Current source compiled with current Xcode -> 60fps.
- 0.74 source compiled with current Xcode -> 60fps.
- 0.74 source compiled on an old 10.6 installation -> 70fps.
- Switching between the old and new SDL builds (via DYLD_LIBRARY_PATH) does not make a difference.
- Behavior is the same for surface and opengl.

All builds were done with -arch i386.

Clearly something with binary produced by old tools causes OS X to deactivate v-synch, while it is forced for the build from today's toolchain. I have not yet found out if something is being compiled differently because of divergent preprocessor conditionals or other slight API differences, or if it is merely the version stamped onto the final binary that causes this behavior change. Using the newer tools to build for older versions is not exactly made easy by Apple – in fact I have not found out a way to do this –, but I'm not really so much into the developer stuff in Apple land. I have also tried using CGLSetParameter(kCGLCPSwapInterval) to switch off v-synch to no avail.

I wanted to share my preliminary observations. I have no solution to this apart from building on Snow Leopard.

Reply 1 of 7, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Are you just building unmodified code or are you patching it as well.
I'm quite good at using the old toolchain on current OS X or using the current one to build for old OS X. I'm providing a snapshot if SVN. If you need an unaltered built, give mine a try.

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 2 of 7, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Also, which 0.74 release did you try? The original one or the 0.74.1 one? The .1 was done by me because OS X changes made it necessary to use the latest source of SDL 1.2x.
And there were three patches that needed to be applied to the Dosbox 0.74 source (backported from Dosbox SVN). I can look this up later if you need it.
All was likely done with apple gcc 4.2.1 from the Xcode 3.x toolchain. Your problems might be due to current toolchain using clang.

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

User metadata
Rank Member
Rank
Member

Well I was not aware that there were several "0.74" releases 😉. I took r3609 from the svn repository.

I built both unmodified and with the pinhack patch from the referenced thread. The patch itself does not make a difference regarding the frame rate difference. The clang build of 0.74 required two or three minor assembly tweaks (filds instead of fild, IIRC).

Actually I don’t care much for 0.74. It was just something that I have an official binary of, so I started from there for reasons of comparability. I have not tried if the current head is buildable with gcc 4.2.1; when built with current clang, it exhibits the same frame rate limited behavior.

Reply 4 of 7, by Ringding

User metadata
Rank Member
Rank
Member

An update after a long time: It seems that I have mixed up my observed results, and the reality is that the rate limiting behavior exists for both builds with "surface". Only "opengl" is affected by the build toolchain. And as I've just verified, only the default setting seems to be affected. The Snow Leopard build seems to default to SDL_GL_SWAP_CONTROL=0, while the El Capitan one defaults to 1. I don't know why setting it to 0 is only done on WIN32 (in src/gui/sdlmain.cpp), but removing the ifdef makes for sane behavior on El Capitan again.

This also means that I don't have to juggle compilers and different builds anymore and can instead try to find a way to disable the rate limiting with "surface" using El Capitan alone.

Reply 6 of 7, by Ringding

User metadata
Rank Member
Rank
Member

Jeez, how often do they change this? I have no experience with post-El-Capitan yet, but given this constant change without anything really working for more than a year or two makes it not surprising that macOS absolutely sucks as a gaming platform. It seems as if they have given up on it entirely and are even trying to actively dissuade anyone from trying to bring games to it.

Reply 7 of 7, by Ringding

User metadata
Rank Member
Rank
Member

That being said, I'm trying to find a workaround, and I am making another attempt at trying to learn some Cocoa programming, which appears to me as the most unapproachable framework ever created, and the constant documentation reorganization, dropping of old introductory material, as if how to use Interface Builder was somehow self-evident, does not help in this regard 😉.