Who wants to help with a osx port?

[Richard42]

Somebody needs to move the plugin thread into the main thread, so that there's only one thread. And then keyboard inputs may work in blight_input. We did that with mupen64 0.5 a year ago, and we did have functional keyboard input, but we had a hard drive crash and lost the patch before we could post it here.

dtm, I've already mentioned it: Mupen64plus has no plugin thread or input thread. The only threads are for the GUI, the emulator, and an audio callback thread which is created and managed by SDL. In fact, you can run in single threaded mode by using the "--nogui --audio ./plugins/dummyaudio.so" switches.

And there are 2 dynarecs in Mupen64Plus - the original Hacktarux code for 32-bit x86 machines with a few bug fixes, and my 64-bit x86-64 dynarec which was based on his code but mostly re-written. It's not correct to say that the dynarec needs to be ported to OSX. It doesn't interface with the operating system at all; only the CPU itself through the machine code that is generated, and the function call ABI, which is probably the same under OSX.

I seem to remember hearing that the Interpreter doesn't run under OSX, correct? The dynarec actually sits on top of and uses the interpreter, so if the Interpreter won't run the dynarec won't either. It's possible that if we find and fix the incompatibility bug in the Interpreter, the dynarec will work as well.

 

[Auria]

I seem to remember hearing that the Interpreter doesn't run under OSX, correct?

Correct, for my PPC mac at least. I cannot test on intel macs atm. So it may be an endianness issue (or maybe not). I just doubt i have the necessary knowledge to find where the problem is.

It also seems to differ depending on the plug-in used. Rice crashes, glide shows colourful triangles, gln64 complains about unknown opcodes.

 

[Auria]

I would also like to add that mupen neither works on PPC Linux, therefore i am probably meeting a combination of mac support and PPC support issues there. For pure mac support, testing on an intel mac would be better. For PPC/big endian support, testing on PPC/Linux would make more sense.

 

[dtm]

Ha ha ha ha ha. As of a couple minutes ago, we now have a working dynarec on MacOS. With Richard's diligent collaboration, I submitted a patch and it appears to function on Linux as well. So we'll see when it ends up in svn.

To summarize, we have dynarec and choppy audio and no input. The Pilotwings intro runs at 30-40% cpu usage on one core of my 2GHz c2d. It runs at full speed now, and the in-game timer runs in realtime.

I've messed with adjusting the jttl_audio buffers against choppiness but that has no effect.

 

[CrispyXUK]

Excellent news, well done guys!

From what I'm reading, the developement of Mupen64+ OSX is also helping the other builds?

 

[Slougi]

Generally making code more portable improves the code base in any project.

 

[Auria]

About choppy audio, when building i get warning messages we're not using the resampling library and thus may get crappy output. It may be related?

 

[Richard42]

About choppy audio, when building i get warning messages we're not using the resampling library and thus may get crappy output. It may be related?

The lack of the SRC resampling library should not result in choppy audio. The built-in linear resampler should be okay for all but the most sensitive listeners. The choppiness is due to some other problem.

 

[CrispyXUK]

The chopiness is in the old mupen64, unless its a rosetta thing?

 

[dtm]

Tillin9 just told me that the sound can be choppy on some Linux systems as well! I didn't know that. Don't know why. I thought everything was perfect on Linux The grass is always greener on the other side!

 

[okaygo]

I think we just fixed the blight issues, occording to tmator

 

[thatmariolover]

Good God you guys are making a lot of progress quickly. I eagerly await a binary to test (though I could buck up and get the environment set up for compiling it myself I suppose).

 

[dtm]

Read my previous post about that. You'll not be downloading a binary to test anytime soon!

 

[dtm]

Keyboard and dynarec both now work

Whoops, sorry! It does work. I started up the configuration GUI, configured the keyboard, quit mupen64plus, and ran it using the non-gui mode. Keyboard input works!

./mupen64plus --nogui --gfx plugins/glN64.so --audio plugins/jttl_audio.so --input plugins/blight_input.so --rsp plugins/mupen64_hle_rsp_azimer.so --emumode 1 ./pilotwings.z64

So games are now playable! Now we just need non-choppy audio, and we'll have full basic functionality.

 

[Slougi]

Here's a little bit of progress on the UI side of things, the Qt4 interface works on OS X as well, pretty much straight out of the box

 

[CrispyXUK]

Is the choppy audio anything to do with games running at 59.94hz and being displayed at 60hz?

 

[Richard42]

Is the choppy audio anything to do with games running at 59.94hz and being displayed at 60hz?

Not likely. Most monitors are set to 70-100Hz, not 60, but at any rate a discrepancy between the vertical retrace and the emulator playback should not even potentially cause choppy sound unless the monitor refresh is _below_ the 59.94 native frequency of the TV.

 

[dtm]

It's not unlikely; it's totally physically impossible. A monitor is output hardware, not a software API.

 

[Richard42]

It's not unlikely; it's totally physically impossible. A monitor is output hardware, not a software API.

O RLY? I can imagine some (rather contrived but still possible) scenarios where mismatched emulation/playback frequencies could cause gaps in the audio. The monitor is driven by hardware on the PC (graphics card) and that hardware is driven by software video drivers, which interact with OpenGL, which interacts with the application. There does exist a dependency chain.

 

[CrispyXUK]

Yup, vsync'd to a monitor at 60hz, game running at 59.94hz, bad-sync ammundo!