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!

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 …

@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 ( …

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 …

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 …

It is only a configuration issue, but this lets me continue to use the suggested setting pinhackexpandwidth=0. --- a/src/dosbox.cpp +++ b/src/dosbox.cpp @@ -403,7 +403,7 @@ void DOSBOX_Init(void) { Pstring->Set_help("The Y resolution (height) the pinball hack should trigger at. Default is 350 (good …

The pinhack patch breaks with (exactly) svn rev 3996 (1 pixel wide screen in Pinball Fantasies). I'll see if I can fix it.

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 …

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 …

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 …

Can't you just dump the memory at the address that the idt points at?

Can you please post the source code for this build?

Because with KVM, it’s the hardware doing its job at full speed. DOSBox does not use hardware virtualization for many (good) reasons. - It can run in a virtualized guest OS - It can run on non-Intel systems - It can probably provide a better debugging environment (?)

In my experience, it does nearest neighbour for graphics modes as well, unless I use output=opengl, so there is no difference between text and graphics modes. But I have not investigated this heavily.

I think it does what you want with output=opengl.

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 …

Because of http://www.vogons.org/viewtopic.php?f=41&t=12424 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 …