Shin_Gouki
New member
well i'm not expecting a "working" version, i want to test or look what error it spits out.
Who wants to help with a osx port?
- Thread starter Danny
- Start date
thatmariolover
New member
It's a great start though, Auria. Nobody expects you to put out a working version tomorrow (or ever, even if we'd like it). Any progress that brings us closer is appreciated.
Just don't let yourself get burned out on it.
It's a great start though, Auria. Nobody expects you to put out a working version tomorrow (or ever, even if we'd like it). Any progress that brings us closer is appreciated.
Just don't let yourself get burned out on it.
buying me an intel mac might considerably speed it up :bouncy:
(just joking of course)
I'm not sure I can complete a port but I can at least submit patches taking us closer to it
I looked through your issues. I don't have a Mac to test on, but I can help make things more portable none the less. While I agree with some things, others I don't follow. For example, I see volume.c is using linux-only headers. It's using OSS-specific stuff which is technically wrong (we're using SDL for portability and should use SDL volume controls) so I agree it needs to be fixed. Same thing with the OpenGL types, I saw a lot of float foo[3]; ... vertex3fv(foo); which is really wrong. Mupen64_audio also writes to ALSA directly. Its buggy and never seemed to work, so has been pulled from 1.4. (not by me)
However, you claim jttl_audio and blight_input also use linux-specific headers. I checked the source and they seem to be using SDL correctly. Could you be more specific as what linux-specific stuff is there? Since a portability effort will be a big part of 1.5, I'd like to know so I can help fix it.
However, you claim jttl_audio and blight_input also use linux-specific headers. I checked the source and they seem to be using SDL correctly. Could you be more specific as what linux-specific stuff is there? Since a portability effort will be a big part of 1.5, I'd like to know so I can help fix it.
Last edited:
Nick_kidid0
Member since 2001
Hi, just letting you guys know that the PPC dynarec over at http://code.google.com/p/mupen64gc/ isn't completed (yet). We are currently working on it though
1.5's portability efforts are about getting support on more than just linux. One big issue is that right now a lot of people can't use mupen, so they can't help contribute. Considering how many people are on this OSX thread, it seems important to add support . Granted, a good part of our porting effort is aimed at getting mupen to compile with MSVC so there can be a real shared-codebase Windows port. Not being tied to x86 / x86_EMT is also a good thing since it helps keep code quality high.
One other reason I'm so inclined to fix the OpenGL bugs is because chances are in fixing the sloppyness with type we'll find other bugs which will help increase compatibility or at the very least visual quality in supported games.
. Granted, a good part of our porting effort is aimed at getting mupen to compile with MSVC so there can be a real shared-codebase Windows port. Not being tied to x86 / x86_EMT is also a good thing since it helps keep code quality high.One other reason I'm so inclined to fix the OpenGL bugs is because chances are in fixing the sloppyness with type we'll find other bugs which will help increase compatibility or at the very least visual quality in supported games.
However, you claim jttl_audio and blight_input also use linux-specific headers. I checked the source and they seem to be using SDL correctly. Could you be more specific as what linux-specific stuff is there? Since a portability effort will be a big part of 1.5, I'd like to know so I can help fix it.
blight_input/plugin.c :
Code:
#include <linux/input.h>About jttl_audio... sorry I meant "mupen64_audio", it includes "#include <linux/soundcard.h>".
The Mupen64Plus project is far from dead. But I haven't seen any progress with an OSX port.
The issue is that only one of the core devs has a Mac and he's currently working on netplay which, IMHO is a higher priority not only since its a killer feature, but because to get it we'll fix a lot of core and input bugs along the way. It also will lead to TAS support, our most requested feature. Of course, since this is open source, we'd love for more people to attempt to get it working on their Macs and submit patches.
Overall development slowed down, primarily due to a few of the main coders having other responsibilities get in the way.
Overall development slowed down, primarily due to a few of the main coders having other responsibilities get in the way.
Shin_Gouki
New member
i have no problem when they finish their regular release and then try to port this to mac.
DarkJezter
New member
You've posted patches where? You can either post a patch file here on the page, or better yet... you can request SVN access from Richard either here or in the irc channel.
I'm looking forward to seeing these patches there IS a wip ppc recompiler being bade by a seperate team for the gamecube if I'm not mistaken
I'm looking forward to seeing these patches
there IS a wip ppc recompiler being bade by a seperate team for the gamecube if I'm not mistakenthatmariolover
New member
Bleck. I know PPC support would be nice for Macs, but 10.6 won't even support PPC. Seems like a lot of work for a soon-to-be unsupported architecture. Not to step on any toes, I know some of you guys didn't buy your PPC Macs that long ago. But you have to be practical.
But yes, there's a lot of progress being made on the PPC front with Mupen64GC.
But yes, there's a lot of progress being made on the PPC front with Mupen64GC.
You've posted patches where? You can either post a patch file here on the page, or better yet... you can request SVN access from Richard either here or in the irc channel.
I'm looking forward to seeing these patches
In this thread (page 4 i think) and also in the bug tracker
I think the goal is to support intel macs, not PPC macs