Who wants to help with a osx port?

[Tillin9]

Sorry for the confusion. The NO_GUI only really applies to the core, but as I said we're working on removing the Gtk dependence in the plugins. The README says GUI=NONE is "build without GUI support" but should really say something more like, build without GUI support where possible.

Thanks, I'll test the patches and try to get them included soon.

I actually have a question about Blight. You said you got it working. Does this mean you can play ROMs with it or it just compiles? If you can play, does the SDL GUI work for you? I only ask since dtm can play ROMs but seems to get a blank white window and crashing. On the todo list is porting the GUI to Gtk and removing the dependence in NO_GUI.

 

[Auria]

Well all i'm doing now is getting it to build. Mupen is totally unusable on my computer since i'm on PPC (i dual-boot linux and it doesn't work there either). What i mean by unusable depends on the video driver. glide actually starts but there's only very distorted color triangles on-screen so the coords must be messed up somehow. Rice remains black for a few seconds then hangs and crashes. glN64 complains about opcodes it can't reckognise or something like that.

So from this point, when my compile patches/change suggestions are in we'll really need an intel mac user to look into this on his computer (well i should get one in some time, not exactly sure when though)

 

[Tillin9]

Sorry, thought we had made a bit more progress. That behavior has to be some memory alignment or other endianess issue in the core. Sorry to ask, but are you using a 64-bit or 32-bit build? I believe the previous OSX port (on PPC) actually addressed this. We might not have that patch in the mupen64plus codebase, but I'll need to double check. If you have the time, you might want to check the 0.5.1 OSX source for hints. I'll also ask dtm as he was responsible for organizing that.

Any news on the Blight SDL GUI? You might run into PPC issues there too, but emulation doesn't need to be started to check. Dtm has emulation running on an Intel Mac with only glN64 baring Blight, sound (due to OSS includes), and dynarec issues.

 

[Auria]

The fix may very well be in 0.5.1 OS X version. I tried making a diff between that code and the current one, but my current skills did not allow me to identify the meaningful change. (mainly, i don't know assembly code)

Is there a way to check the blight GUI without running the full GTK gui? the mac version of GTK is still incomplete, and it does not successfully run the mupen GUI (i think it's a thread issue)

EDIT: forgot to mention, it's 32-bit.

 

[Tillin9]

Ah. Besides writing a simple app which loads the plugin, and calls the configure function, no method I know of. Thanks for letting me know you're 32-bit.

Dtm showed me the code. Its assembly, so I need to run by someone whose assembly skills are better than mine. Its not in mupen64plus.

http://www.emutalk.net/showthread.php?p=382653 (see Hacktarux's 2nd post)

 

[thatmariolover]

I'm sure there are many people that would be willing to test any build you can provide, myself included.

 

[Auria]

thatmariolover and others who would like a test build : The main problem is that mupen currently installs itself in Unix directories (/usr/local/, etc.) and probably expects to find its plugins there too. I'm sure there will be a way to package it in the mac way (i did it many times before with other linux projects i helped bring to the mac) but to make it, it is required that i can also test right away my changes. Making the change, cross-compiling to intel, uploading the build, waiting for someone to try, explaining that person how to debug, starting again, etc... does not appeal much to me.

 

[thatmariolover]

Yeah, I figured there was probably a reason if you weren't already doing it that way. The offer still stands if you get to the point where you do want help.

 

[CrispyXUK]

yup, same here.

 

[krimb1]

Hey guys, sorry I'm jumping on the boat a little later than everyone else but I just wanted to say I'd be happy to test as well. I've running OS X 10.5.4 on a MacBook Pro and am fairly comfortable compiling source.

I tried looking through the earlier pages, but couldn't find a download link to the latest source? Does such a thing exist?

Thanks for all your help!

EDIT
Oops, sorry! Is this it? Even though it says only Mupen64 and not Mupen64Plus?

http://www.emutalk.net/showthread.php?p=382653 (see Hacktarux's 2nd post)

Sorry for the newb questions guys.

 

[Tillin9]

Try our svn (at the bottom of the page here: http://code.google.com/p/mupen64plus/).

Right now, glide, rice, and jttl audio may not compile from svn. You'll need to comment out part of the makefile to not build those plugins. Also, pass NO_ASM=1 as the dynarec doesn't compile right now.

One of the biggest issues now is that while blight (our input plugin) compiles, it doesn't really work. So you get to see the intros of games, and that's it. I'm not really sure what is wrong, so if OSX developers could look at that, it would be a big help.

Edit: P.S. Sorry for the lack of porting updates, I'm busy wrestling with the new (gettext based) translation system.

 

[Auria]

glide and rice do compile on my mac - just not sure which parts of my fixes are committed and which arent though and NO_ASM=1 is only relevant on PPC, on intel macs the asm code might just work

Tillin9: Where did you get that Blight doesn't work? Did someone on an intel mac actually test and report it, and i missed it?

 

[Tillin9]

dtm on his Intel Mac can get ROMs to run in glN64, but without input he can't get past the intro, so its a fancy animation. I'm not sure whether its a full input issue or just that the SDL GUI won't open (so he can't configure the plugin).

 

[CrispyXUK]

oooh, progress, awesome.

What sort of speeds should we be expecting? I'm assuming full speed on a 2ghz intel?

 

[Auria]

Did you get that from the one-year-old thread mentionned above? If so it may changed since then

 

[dtm]

Auria, did who get what from the one-year-old thread? The status at the very moment with mupen64plus now is the same as with mupen64 0.5 back then.

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.

tmator suggested this threading thread: http://listas.apesol.org/pipermail/sdl-libsdl.org/2006-May/056142.html

Some people are asking about speed. I'm watching mupen64plus on my 2GHz c2d imac, with pure interpreter mode and the dummy audio plugin (no audio) right now. I'm watching the Pilotwings 64 intro, which has an on-screen timer which is moving at somewhere between 1/3 and 1/2 of wall-clock speed while using 100% of one core. Mario64 would probably be barely playable, with a lot of frame dropping, if you're good at the game, assuming that you had input. If you try the mupen64 0.5 ports (either ours, or lamer0's), which do have a dynarec, it is way above realtime speed on this host hardware.

I don't know why Auria was mentioning the installation paths of mupen64plus, because there is no reason to have to install it anywhere, so maybe I missed something.

 

[dtm]

How to build and contribute to Mupen64plus on MacOS

You may want to read this post a few times, because it's got everything in it and your experience may vary. Please give feedback!

People have asked for a binary to test. We will do that in the future, but right now it wouldn't work because stock MacOS doesn't have the dependencies. If you were able to run mupen64plus right now, then you'd have everything needed in order to have compiled it in the first place. So just do that! If you can't, or don't know how, then you don't need it. If you just wanna play, you can use the binary of Mupen64 0.5 which is available on the main download page. Don't kid yourself though, because we've had at least 3 total newbies build it and give very valuable feedback.

http://mupen64.emulation64.com/files/0.5/mupen64-PR1.dmg.sitx

If you have a Mac, then you have XCode or you can redownload it from a free account on http://connect.apple.com/ . Then you install macports or fink. Almost everyone involved uses macports because it tends to be more updated. It is possible to build it with an Aqua GUI via a Qt dmg from trolltech or via non-x11 gtk from macports, and it's possible to activate/deactivate multiple, installed, versions of these macports packages:

Get the appropriate dmg for your system at the top of this page:

http://www.macports.org/install.php

For the X11 version:

Get the latest MacOS update. Get the latest X server from XQuartz, if you have MacOS 10.5.

http://xquartz.macosforge.org/trac/wiki

sudo port install libsdl libsdl_ttf libpng gtk2

For the Aqua GTK (no X11) version:

sudo port install pango +no_x11 cairo +quartz+pdf+no_x11 gtk2 +quartz libsdl_ttf

Get the mupen64plus svn:

svn co svn://fascination.homelinux.net:7684/mupen64plus/trunk --username mupen64 --password Dyson5632-kart

cd trunk

make clean ; make all

Please let me know if that works or doesn't work! You can help by helping to maintain current instructions. We have at least 3 newbies following the above instructions from scratch and having a working application.

Run './mupen64plus'. Enable the proper plugins in the GUI. Enable dynarec. Then configure the Blight input gui. Some joysticks work, such as a Wii remote with wiiji, but not my adaptoid. If your input doesn't work, quit mupen64plus and do this:

./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 [rom file]

If you don't want the choppy audio, then either fix the source code or use the dummyaudio plugin.

If you want more details, read the heck out of this thread you're in now, and every thread that it links to, do everything they say, do everything you can to get a functional build environment, and THEN proceed to #mupen64plus on irc.freenode.net. That's more or less a good way to see the bar for participation. If you don't do at least that, then you're probably just wishing that you could help and you're not actually going to help and aren't going to find out what it'd take in order to be able to help and nobody can telepathically extract help from your helpless spinal fluids

I'm not a programmer but I've documented as much as I can and I try to help coordinate some dialog and status for the devs, and recruiting more devs. I often am not able to help, but sometimes I get lucky, such as by having recruited and managed Feanor to do the 0.5 port (he says I "made" him do it but I dunno ) or by motivating a helpful and productive and intelligent discussion. There are no small roles; there are just those who act loudly helpless and those who know that they are not helpless. I honestly hope that helps to put things into perspective, so you don't burn out, or don't keep annoying or begging here due to not knowing what's going on. Annoying, begging, and wishing, don't help (to put it mildly). Nobody's helpless.

The more people who can actually reproduce these steps from various pristine MacOS installations, the more proof and motivation there is. So there is no need to announce what you can't do, what you won't do, or what you wish you could do

Once you do that, remember, irc is where it's at.

 

[Auria]

I don't know why Auria was mentioning the installation paths of mupen64plus, because there is no reason to have to install it anywhere, so maybe I missed something.

Well you're right, mupen does run in-place, contrarly to other projects (i do so many projects, i'm getting confused ). Though as you said in your post, it's a matter of dependencies, and for me it's also about cross-compiling, so providing binary was still a no-go.

dtm, are you on PPC or intel? People always say to build with NO_ASM=1, but IMO that's not relevant on intel macs. I think the asm version will work better than the NO_ASM version there - cause the NO_ASM version is slow as hell and very seldom tested

 

[dtm]

Nope. The dynarec for mupen64plus does not work on intel MacOS, only on Linux and maybe Windows. It requires porting, but has received effectively zero attention. That'd be one HUGE heck of an oversight to just forget that we had this whole working dynarec to make it playable instead of unplayable, dontcha think?

The old dynarec from Mupen64 0.5 was ported to intel MacOS and was implemented by lamer0 in his Cocoa port and by Feanor and I in our BSD-style port. Mupen64plus's dynarec is all new, written for x86_64 by Richard.

Simulating a discussion on a bulletin board is hilarious, but come to irc!

 

[dtm]

Also, in case it hasn't been perfectly clear, Mupen64Plus will build on PPC MacOS 10.4 and probably on 10.5, the GUI will run, but emulation is useless. It's filled with artifacts and no recognizable game-related presentation. We don't know why, coz nobody's stepped through it with gdb or in the source code.

Mupen64Plus svn does build and run on Intel MacOS 10.5 with no input, and it probably will do so on Intel MacOS 10.4.

Update: As of about 5 minutes ago, we have jittery audio support now via a manual hack that I just applied. It's probably jittery due to the fact that the pure interpreter is too slow! Otherwise it sounds perfect.