[$threadinfo[title]]

[_Zack_]

I just got myself a mac mini ::)

There is a slight problem though...................Unless your willing to pay 10 euros to make sixtyforce usable (ie savestates etc) then your pretty much out of luck if you want to emulate the n64 on a new mac mini.

So who else wants to help me port mupen64 plus to osx?

I don't have time to do it all myself but if a few of us got together it would be possible.

[nmn]

Mupen64Plus will probably not make it to the PPC platform, but I don't know exactly. More luck with Intel Macs.

[CrispyXUK]

I'm running an Intel Mini with Leopard so am willing to help, but I've no experience in programing so would only really be able to help in the testing of it.

Although I can do you some nice graphics for it if that helps.

[_Zack_]

Forgot to clarify.

I am only planning on a port to macs that are using intel processors.

[Nevexst]

Is there any chance of a Universal build?

I'm in a similar predicament with Zion. 'cept I have a Powerbook G4 with plenty of life left in it. So any love thrown our way would be overwhelmingly appreciated.

[nmn]

Very unlikely due to large amounts of byteswapping and assembly code issues we'll run into. You'll need a powerful CPU to run the emulation without a native recompiler, also.

[DarkJezter]

Funny story on this, I just got my hands on an old G4 (it's slow but functional) that is PPC based. I've put OSX on it for the sole purpose of trying to set up a native osx port, I haven't yet got ANY experience with Xcode, so I'll be learning as I go along.

Hopefully the differences between intel and ppc shouldn't prevent us from collaborating on this :)

[Nevexst]

DarkJetzer:

Maybe these will be of some interest to you:

http://letsgetdugg.com/page/Emulation
There is a SVN repository on there that I think could be used as a springboard of sorts.

And... some other people were working on a OSX version, but I imagine they must have got busy or something

http://emutalk.net/showthread.php?t=39340
http://www.emutalk.net/showthread.php?p=382606#post382606

Hope it helps :)

[okaygo]

It would be a good idea if you all got onto IRC, irc.freenode.net #mupen64plus

Lots of people there to collaborate with.

[DarkJezter]

http://letsgetdugg.com/page/Emulation
There is a SVN repository on there that I think could be used as a springboard of sorts.


:o

Actually, that's awesome! I HAVE the binary of that version and didn't know there was a separate repository online for it. I don't know if it will help when I finally do start working on the osx stuff (trust me, it won't be tomorrow) but it's great to know that's out there

[lifning]

There exists a project to port Mupen64 to the Nintendo Gamecube/Wii (similar platforms, both use PowerPC). Perhaps you could borrow their dynarec (if they have one yet) =)

[Surkow]

There exists a project to port Mupen64 to the Nintendo Gamecube/Wii (similar platforms, both use PowerPC). Perhaps you could borrow their dynarec (if they have one yet) =)

This (http://code.google.com/p/mupen64gc/wiki/Screenshots) project?

[_Zack_]

Just to anyone that wants in on this, progress will more than likley be slow. Due to a few things :

1) I work 5 days a week.
2) I am just getting used to osx, been a windows user my whole life.

I believe I have the programming skills needed, i don't claim to be a whizz mind :P Just the few things above that are going to make this take a while, that is unless a few people team up with me (which i hope will be the case)

[lifning]

This (http://code.google.com/p/mupen64gc/wiki/Screenshots) project?
Yeah, that's the one I'm thinking of.
You might be able to at least collaborate with them a bit...

[thatmariolover]

I'm not much of a coder myself. But I'm happy to do whatever you guys need. I've got a Quad core Intel Mac at my disposal.

[Auria]

Well I would be interested. Main problem is I currently don't have an intel mac :P though I guess the initial problem will be getting it to compile, most likely by fixing the makefile.

I gave it a try not so long ago. The issue I ran into is that it seemed to use quite a few uncommon linker commands (and while the OS X compiler is almost exactly the sam as on linux, the linker is not)
I was having trouble understanding what these link flags were doing (haven't searched much though) I generally suspect it could be something like weak linking - can a dev confirm?

But on a deeper issue : if mupen is going multi-platform, I have a general feeling a bare makefile is not a strong enough build system ( well I generally think it is not even for very small projects but that's another issue and i don't want to start a flamewar ;) )

[DarkJezter]

There exists a project to port Mupen64 to the Nintendo Gamecube/Wii (similar platforms, both use PowerPC). Perhaps you could borrow their dynarec (if they have one yet) =)



:o it appears they DO have a ppc recompiler written! Although, it looks like they took a very different approach from the ones used in x86 (both 32 and 64 bit) recompilers.

I can't wait to play around with this... possible feature add to the trunk? ;)

[CrispyXUK]

Adding PowerPC support is quite difficult isn't it? It's not something I'm interested in but I'm sure there are a few out there who are. Is there anything I can help with at all? I'm no programmer but there must be something I can do, maybe design the GUI? I can certainly make you some pretty icons.

/feel useless.

[Slougi]

Adding PowerPC support is quite difficult isn't it? It's not something I'm interested in but I'm sure there are a few out there who are. Is there anything I can help with at all? I'm no programmer but there must be something I can do, maybe design the GUI? I can certainly make you some pretty icons.

/feel useless.

One thing that is currently missing (on all platforms mind you) is a nice application icon. Also, the flags that we have for the different countries aren't as nice as they could be. Certainly not useless at all if you want to help with that.

On that note, i've been toying with the idea of an os x port myself. I can get a macbook from work to do the port. Unfortunately i'm pretty busy until the end of july. So it would be a while before i start on anything like that.

[CrispyXUK]

Ok, what sort of resolution do we need, I'm assuming a multiple of 32 pixels.

It would probably be easier to install osx86 if you want to play with osx, kalyway does a pretty good install for intel based PC systems, I'm sure you know where to look :D

[Shin_Gouki]

nice, i have anmac book i'd like to see mupen runnig here :D

[Slougi]

Ok, what sort of resolution do we need, I'm assuming a multiple of 32 pixels.

Yep. Different systems use different sizes by default so an icon that scales to different sizes would be cool.

It would probably be easier to install osx86 if you want to play with osx, kalyway does a pretty good install for intel based PC systems, I'm sure you know where to look :D

I do, but I think I prefer the macbook :)

[_Zack_]

I have tomorrow off work so I will make a start on the port.

That is if the 3 new Xbox 360 games I just got don't tear me away from it :P

I'll post tomorrow if I make any progress.

[thatmariolover]

Ok, what sort of resolution do we need, I'm assuming a multiple of 32 pixels.

It would probably be easier to install osx86 if you want to play with osx, kalyway does a pretty good install for intel based PC systems, I'm sure you know where to look :D

Yeah, when I say I have a Quad core Intel Mac at my disposal I mean I've got a Kalyway install on my PC. Almost as good as the real thing if you have compatible hardware.

[CrispyXUK]

Ok, I'll get some flags and a Icon/logo done hopefully some time today.

[CrispyXUK]

Well, I've ended up working late today, not gonna get much done unfortuantaley.

[_Zack_]

The same unfortunately. I got distracted with other work I had planned to do on my day off.

I have Thursday off, although I have a lot planned for that day. So again no promises but maybe I will get chance to work on it. :)

[Auria]

I've been trying to build mupen (svn) on my OS X computer.

Here's the changes I've had to do so far (build not yet done)
Some of it are hacky, others could go in though

(I'm on PPC though. so it may vary a little on intel macs)

EDIT: Removed, see next post for a more compelte one

[Auria]

Okay I fully got it to build on OS X! It doesn't run since I'm on PPC, but here's the changes

"safe" compatibility changes :

Index: glN64/DepthBuffer.cpp
======================================== ===========================
--- glN64/DepthBuffer.cpp (revision 497)
+++ glN64/DepthBuffer.cpp (working copy)
@@ -1,4 +1,4 @@
-#include <malloc.h>
+#include <stdlib.h>
#include "DepthBuffer.h"
#include "Types.h"
Index: glN64/OpenGL.cpp
======================================== ===========================
--- glN64/OpenGL.cpp (revision 497)
+++ glN64/OpenGL.cpp (working copy)
@@ -131,7 +131,7 @@
glGetFinalCombinerInputParameterfvNV = (PFNGLGETFINALCOMBINERINPUTPARAMETERFVNV PROC)wglGetProcAddress( "glGetFinalCombinerInputParameterfvNV" );
glGetFinalCombinerInputParameterivNV = (PFNGLGETFINALCOMBINERINPUTPARAMETERIVNV PROC)wglGetProcAddress( "glGetFinalCombinerInputParameterivNV" );
#endif // !__LINUX__
- glGetIntegerv( GL_MAX_GENERAL_COMBINERS_NV, &OGL.maxGeneralCombiners );
+ glGetIntegerv( GL_MAX_GENERAL_COMBINERS_NV, (GLint*) &OGL.maxGeneralCombiners );
}

if ((OGL.ARB_multitexture = isExtensionSupported( "GL_ARB_multitexture" )))
@@ -142,7 +142,7 @@
glMultiTexCoord2fARB = (PFNGLMULTITEXCOORD2FARBPROC)wglGetProcA ddress( "glMultiTexCoord2fARB" );
#endif // !__LINUX__

- glGetIntegerv( GL_MAX_TEXTURE_UNITS_ARB, &OGL.maxTextureUnits );
+ glGetIntegerv( GL_MAX_TEXTURE_UNITS_ARB, (GLint*) &OGL.maxTextureUnits );
OGL.maxTextureUnits = min( 8, OGL.maxTextureUnits ); // The plugin only supports 8, and 4 is really enough
}
Index: rice_video/Makefile
======================================== ===========================
--- rice_video/Makefile (revision 497)
+++ rice_video/Makefile (working copy)
@@ -5,7 +5,7 @@

# local CFLAGS, LIBS, and LDFLAGS
CFLAGS += -DUSE_GTK `sdl-config --cflags` $(GTK_FLAGS) -fpic -DPIC -Wall
-LDFLAGS += -L/usr/X11R6/lib `sdl-config --libs` -lGL -shared -Wl,-Bsymbolic
+LDFLAGS += `sdl-config --libs` $(LIBGL_LIBS) $(PLUGIN_LDFLAGS)

# set options

Index: rice_video/DeviceBuilder.cpp
======================================== ===========================
--- rice_video/DeviceBuilder.cpp (revision 497)
+++ rice_video/DeviceBuilder.cpp (working copy)
@@ -235,7 +235,7 @@
{
int maxUnit = 2;
COGLGraphicsContext *pcontext = (COGLGraphicsContext *)(CGraphicsContext::g_pGraphicsContext) ;
- glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB,&maxUnit);
+ glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, (GLint*)&maxUnit);

if( pcontext->IsExtensionSupported("GL_ARB_fragment_program") )
{
Index: rice_video/OGLFragmentShaders.cpp
======================================== ===========================
--- rice_video/OGLFragmentShaders.cpp (revision 497)
+++ rice_video/OGLFragmentShaders.cpp (working copy)
@@ -286,7 +286,7 @@
#ifdef _DEBUG
char *str = (char*)glGetString(GL_PROGRAM_ERROR_STRI NG_ARB);
#endif
- glGetIntegerv( GL_PROGRAM_ERROR_POSITION_ARB, &position);
+ glGetIntegerv( GL_PROGRAM_ERROR_POSITION_ARB, (GLint*)&position);
if( position >= 0 )
{
#ifdef _DEBUG
Index: rice_video/OGLExtCombiner.cpp
======================================== ===========================
--- rice_video/OGLExtCombiner.cpp (revision 497)
+++ rice_video/OGLExtCombiner.cpp (working copy)
@@ -67,7 +67,7 @@
if( pcontext->IsExtensionSupported("GL_EXT_texture_env_combine") || pcontext->IsExtensionSupported("GL_ARB_texture_env_combine") )
{
m_bOGLExtCombinerSupported = true;
- glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB,&m_maxTexUnits);
+ glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, (GLint*)&m_maxTexUnits);
if( m_maxTexUnits > 8 ) m_maxTexUnits = 8;

TRACE0("Starting Ogl 1.4 multitexture combiner" );
Index: rice_video/RenderExt.cpp
======================================== ===========================
--- rice_video/RenderExt.cpp (revision 497)
+++ rice_video/RenderExt.cpp (working copy)
@@ -781,8 +781,8 @@

// save the current clamp type
int iClampS, iClampT;
- glGetTexParameteriv(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, &iClampS);
- glGetTexParameteriv(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, &iClampT);
+ glGetTexParameteriv(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, (GLint*)&iClampS);
+ glGetTexParameteriv(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, (GLint*)&iClampT);
// force clamp type to CLAMP_EDGE (experiments show sometimes this is set to hex 0x2901 - invalid value)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
Index: rice_video/OGLExtRender.cpp
======================================== ===========================
--- rice_video/OGLExtRender.cpp (revision 497)
+++ rice_video/OGLExtRender.cpp (working copy)
@@ -26,7 +26,7 @@
OGLRender::Initialize();

// Initialize multitexture
- glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB,&m_maxTexUnits);
+ glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, (GLint*)&m_maxTexUnits);

for( int i=0; i<8; i++ )
m_textureUnitMap[i] = -1;
Index: rice_video/liblinux/BMGUtils.c
======================================== ===========================
--- rice_video/liblinux/BMGUtils.c (revision 497)
+++ rice_video/liblinux/BMGUtils.c (working copy)
@@ -25,7 +25,7 @@
// POSSESSION, USE OR PERFORMANCE OF THIS SOFTWARE.
*/

-#include <malloc.h>
+#include <stdlib.h>
#include "BMGUtils.h"

#ifndef _WIN32
Index: rice_video/liblinux/BMGImage.c
======================================== ===========================
--- rice_video/liblinux/BMGImage.c (revision 497)
+++ rice_video/liblinux/BMGImage.c (working copy)
@@ -3,7 +3,7 @@
//
// Copyright (C) 2001 Michael S. Heiman
*/
-#include <malloc.h>
+#include <stdlib.h>
#include <memory.h>
#include <setjmp.h>
#include "BMGUtils.h"
Index: memory/dma.c
======================================== ===========================
--- memory/dma.c (revision 497)
+++ memory/dma.c (working copy)
@@ -35,7 +35,7 @@
#include "../r4300/r4300.h"
#include "../r4300/interupt.h"
#include "../r4300/macros.h"
-#include <malloc.h>
+#include <stdlib.h>
#include "pif.h"
#include "flashram.h"
#include "../main/guifuncs.h"
Index: opengl/OGLFT.h
======================================== ===========================
--- opengl/OGLFT.h (revision 497)
+++ opengl/OGLFT.h (working copy)
@@ -57,7 +57,7 @@
R, G, B, A
};

- typedef void (*GLUTessCallback)();
+ typedef GLvoid (*GLUTessCallback)(...);

class Library
{
@@ -439,11 +439,11 @@
static int lineToCallback ( FT_Vector* to, Filled* filled );
static int conicToCallback ( FT_Vector* control, FT_Vector* to, Filled* filled);
static int cubicToCallback ( FT_Vector* control1, FT_Vector* control2,FT_Vector* to, Filled* filled );
- static void vertexCallback ( VertexInfo* vertex );
- static void beginCallback ( GLenum which );
- static void endCallback ( void );
- static void combineCallback ( GLdouble coords[3], void* vertex_data[4],GLfloat weight[4], void** out_data,Filled* filled );
- static void errorCallback ( GLenum error_code );
+ static GLvoid vertexCallback ( VertexInfo* vertex );
+ static GLvoid beginCallback ( GLenum which );
+ static GLvoid endCallback ( void );
+ static GLvoid combineCallback ( GLdouble coords[3], void* vertex_data[4],GLfloat weight[4], void** out_data,Filled* filled );
+ static GLvoid errorCallback ( GLenum error_code );
};

class Raster : public Face
Index: opengl/osd.cpp
======================================== ===========================
--- opengl/osd.cpp (revision 497)
+++ opengl/osd.cpp (working copy)
@@ -266,7 +266,7 @@
bool bSecColorArray = glIsEnabled(GL_SECONDARY_COLOR_ARRAY);

// deactivate all the texturing units
- int iActiveTex;
+ GLint iActiveTex;
bool bTexture2D[8];
glGetIntegerv(GL_ACTIVE_TEXTURE_ARB, &iActiveTex);
for (i = 0; i < 8; i++)
Index: opengl/OGLFT.cpp
======================================== ===========================
--- opengl/OGLFT.cpp (revision 497)
+++ opengl/OGLFT.cpp (working copy)
@@ -2354,7 +2354,7 @@
return 0;
}

- void Filled::vertexCallback (VertexInfo* vertex)
+ GLvoid Filled::vertexCallback (VertexInfo* vertex)
{
if(vertex->color_tess_ != 0) glColor4fv(vertex->color_tess_->color(vertex->v_));
if(vertex->texture_tess_ != 0) glTexCoord2fv(vertex->texture_tess_->texCoord(vertex->v_));
@@ -2362,17 +2362,17 @@
glVertex3dv(vertex->v_);
}

- void Filled::beginCallback (GLenum which)
+ GLvoid Filled::beginCallback (GLenum which)
{
glBegin(which);
}

- void Filled::endCallback (void)
+ GLvoid Filled::endCallback (void)
{
glEnd();
}

- void Filled::combineCallback (GLdouble coords[3], void* vertex_data[4], GLfloat weight[4], void** out_data, Filled* filled)
+ GLvoid Filled::combineCallback (GLdouble coords[3], void* vertex_data[4], GLfloat weight[4], void** out_data, Filled* filled)
{
(void)vertex_data;
(void)weight;
@@ -2381,7 +2381,7 @@
filled->extraVertices().push_back(vertex);
}

- void Filled::errorCallback (GLenum error_code)
+ GLvoid Filled::errorCallback (GLenum error_code)
{
std::cerr << "hmm. error during tessellation?:" << gluErrorString(error_code)<< std::endl;
}
Index: main/gui_gtk/main_gtk.c
======================================== ===========================
--- main/gui_gtk/main_gtk.c (revision 497)
+++ main/gui_gtk/main_gtk.c (working copy)
@@ -56,7 +56,7 @@
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
-#include <malloc.h>
+#include <stdlib.h>
#include <sys/types.h>
#include <sys/time.h>
#include <time.h>
Index: glide64/Makefile
======================================== ===========================
--- glide64/Makefile (revision 497)
+++ glide64/Makefile (working copy)
@@ -14,7 +14,7 @@

# local CFLAGS, LIBS, and LDFLAGS
CFLAGS = -O2 -Wall -g -DGCC -DUSE_GTK $(SDL_CFLAGS) $(GTK_FLAGS) -Iwrapper/ -ffast-math -funroll-loops
-LDFLAGS = -shared -Wl,-Bsymbolic -lGL -lGLU -L/usr/X11R6/lib $(SDL_LIBS)
+LDFLAGS = $(PLUGIN_LDFLAGS) $(LIBGL_LIBS) `sdl-config --libs`

# set special flags per-system
ifeq ($(CPU), X86)
Index: glide64/wrapper/combiner.cpp
======================================== ===========================
--- glide64/wrapper/combiner.cpp (revision 497)
+++ glide64/wrapper/combiner.cpp (working copy)
@@ -350,14 +350,14 @@
glLinkProgramARB(program_object);
glUseProgramObjectARB(program_object);

- glGetObjectParameterivARB(program_object , GL_OBJECT_LINK_STATUS_ARB , &log_length);
+ glGetObjectParameterivARB(program_object , GL_OBJECT_LINK_STATUS_ARB , (GLint*)&log_length);
if(!log_length)
{
- glGetInfoLogARB(fragment_shader_object, 2048, &log_length, shader_log);
+ glGetInfoLogARB(fragment_shader_object, 2048, (GLint*)&log_length, shader_log);
if(log_length) display_warning(shader_log);
- glGetInfoLogARB(vertex_shader_object, 2048, &log_length, shader_log);
+ glGetInfoLogARB(vertex_shader_object, 2048, (GLint*)&log_length, shader_log);
if(log_length) display_warning(shader_log);
- glGetInfoLogARB(program_object, 2048, &log_length, shader_log);
+ glGetInfoLogARB(program_object, 2048, (GLint*)&log_length, shader_log);
if(log_length) display_warning(shader_log);
}

@@ -400,14 +400,14 @@
glLinkProgramARB(program_object);
glUseProgramObjectARB(program_object);

- glGetObjectParameterivARB(program_object , GL_OBJECT_LINK_STATUS_ARB , &log_length);
+ glGetObjectParameterivARB(program_object , GL_OBJECT_LINK_STATUS_ARB , (GLint*)&log_length);
if(!log_length)
{
- glGetInfoLogARB(fragment_shader_object, 2048, &log_length, shader_log);
+ glGetInfoLogARB(fragment_shader_object, 2048, (GLint*)&log_length, shader_log);
if(log_length) display_warning(shader_log);
- glGetInfoLogARB(vertex_shader_object, 2048, &log_length, shader_log);
+ glGetInfoLogARB(vertex_shader_object, 2048, (GLint*)&log_length, shader_log);
if(log_length) display_warning(shader_log);
- glGetInfoLogARB(program_object, 2048, &log_length, shader_log);
+ glGetInfoLogARB(program_object, 2048,(GLint*) &log_length, shader_log);
if(log_length) display_warning(shader_log);
}

@@ -639,16 +639,16 @@
glLinkProgramARB(program_object);
glUseProgramObjectARB(program_object);

- glGetObjectParameterivARB(program_object , GL_OBJECT_LINK_STATUS_ARB , &log_length);
+ glGetObjectParameterivARB(program_object , GL_OBJECT_LINK_STATUS_ARB , (GLint*)&log_length);
if(!log_length)
{
glGetInfoLogARB(shader_programs[number_of_programs].fragment_shader_object,
- 2048, &log_length, shader_log);
+ 2048, (GLint*)&log_length, shader_log);
if(log_length) display_warning(shader_log);
- glGetInfoLogARB(vertex_shader_object, 2048, &log_length, shader_log);
+ glGetInfoLogARB(vertex_shader_object, 2048, (GLint*)&log_length, shader_log);
if(log_length) display_warning(shader_log);
glGetInfoLogARB(program_object,
- 2048, &log_length, shader_log);
+ 2048,(GLint*)&log_length, shader_log);
if(log_length) display_warning(shader_log);
}

Index: glide64/wrapper/textures.cpp
======================================== ===========================
--- glide64/wrapper/textures.cpp (revision 497)
+++ glide64/wrapper/textures.cpp (working copy)
@@ -72,7 +72,7 @@
}
aux = aux->next;
}
- glDeleteTextures(n, t);
+ glDeleteTextures(n, (const GLuint*)t);
free(t);
//printf("RMVTEX nbtex is now %d (%06x - %06x)\n", nbTex, idmin, idmax);
}
Index: glide64/wrapper/main.cpp
======================================== ===========================
--- glide64/wrapper/main.cpp (revision 497)
+++ glide64/wrapper/main.cpp (working copy)
@@ -695,13 +695,13 @@
show_warning = 0;

nbTextureUnits = 0;
- glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, &nbTextureUnits);
+ glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, (GLint*)&nbTextureUnits);
if (nbTextureUnits == 1) display_warning("You need a video card that has at least 2 texture units");

nbAuxBuffers = 0;
int getDisableAuxbuf();
if (!getDisableAuxbuf())
- glGetIntegerv(GL_MAX_DRAW_BUFFERS_ARB, &nbAuxBuffers);
+ glGetIntegerv(GL_MAX_DRAW_BUFFERS_ARB, (GLint*)&nbAuxBuffers);
if (nbAuxBuffers > 0)
printf("Congratulations, you have %d auxilliary buffers, we'll use them wisely !\n", nbAuxBuffers);

@@ -888,9 +888,9 @@
{
for (i=0; i<nb_fb; i++)
{
- glDeleteTextures( 1, &(fbs[i].texid) );
- glDeleteFramebuffersEXT( 1, &(fbs[i].fbid) );
- glDeleteRenderbuffersEXT( 1, &(fbs[i].zbid) );
+ glDeleteTextures( 1,(GLuint*) &(fbs[i].texid) );
+ glDeleteFramebuffersEXT( 1, (GLuint*)&(fbs[i].fbid) );
+ glDeleteRenderbuffersEXT( 1, (GLuint*)&(fbs[i].zbid) );
}
}
#endif
@@ -1130,8 +1130,8 @@
}
else //create new FBO at the same address, delete old one
{
- glDeleteFramebuffersEXT( 1, &(fbs[i].fbid) );
- glDeleteRenderbuffersEXT( 1, &(fbs[i].zbid) );
+ glDeleteFramebuffersEXT( 1, (GLuint*)&(fbs[i].fbid) );
+ glDeleteRenderbuffersEXT( 1, (GLuint*)&(fbs[i].zbid) );
if (nb_fb > 1)
memmove(&(fbs[i]), &(fbs[i+1]), sizeof(fb)*(nb_fb-i));
nb_fb--;
@@ -1142,8 +1142,8 @@

remove_tex(pBufferAddress, pBufferAddress + width*height*2/*grTexFormatSize(fmt)*/);
//create new FBO
- glGenFramebuffersEXT( 1, &(fbs[nb_fb].fbid) );
- glGenRenderbuffersEXT( 1, &(fbs[nb_fb].zbid) );
+ glGenFramebuffersEXT( 1, (GLuint*)&(fbs[nb_fb].fbid) );
+ glGenRenderbuffersEXT( 1, (GLuint*)&(fbs[nb_fb].zbid) );
glBindRenderbufferEXT( GL_RENDERBUFFER_EXT, fbs[nb_fb].zbid );
// VP ported from mudlord
glRenderbufferStorageEXT( GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT, width, height);
Index: glide64/wrapper/glidesys.h
======================================== ===========================
--- glide64/wrapper/glidesys.h (revision 497)
+++ glide64/wrapper/glidesys.h (working copy)
@@ -102,7 +102,7 @@
# define GLIDE_OS GLIDE_OS_DOS32
#elif defined(__WIN32__)
# define GLIDE_OS GLIDE_OS_WIN32
-#elif defined(macintosh)
+#elif defined(__APPLE__)
# define GLIDE_OS GLIDE_OS_MACOS
#else
#error "Unknown OS"
Index: r4300/r4300.c
======================================== ===========================
--- r4300/r4300.c (revision 497)
+++ r4300/r4300.c (working copy)
@@ -36,7 +36,7 @@
#include "macros.h"
#include "recomp.h"
#include "recomph.h"
-#include <malloc.h>
+#include <stdlib.h>

#ifdef DBG
extern int debugger_mode;
Index: r4300/recomp.c
======================================== ===========================
--- r4300/recomp.c (revision 497)
+++ r4300/recomp.c (working copy)
@@ -27,7 +27,7 @@
*
**/

-#include <malloc.h>
+#include <stdlib.h>

#include "recomp.h"
#include "macros.h"


hackish bits/needs proper implementation :

Index: install.sh
======================================== ===========================
--- install.sh (revision 497)
+++ install.sh (working copy)
@@ -38,7 +38,7 @@
INSTALLDIR=${PREFIX}/share/mupen64plus

echo "Installing Mupen64Plus to $PREFIX"
-$INSTALL -D -m 0755 mupen64plus "${BINDIR}/mupen64plus" || exit $?
+$INSTALL -c -m 0755 mupen64plus "${BINDIR}/mupen64plus" || exit $?
$INSTALL -d -v "${INSTALLDIR}" || exit $?
$INSTALL -d -v "${INSTALLDIR}/config" || exit $?
$INSTALL -m 0644 config/* "${INSTALLDIR}/config" || exit $?
Index: glN64/Textures.cpp
======================================== ===========================
--- glN64/Textures.cpp (revision 497)
+++ glN64/Textures.cpp (working copy)
@@ -11,6 +11,15 @@
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>

+#ifdef __APPLE__
+// FIXME... I have no clue why these are not picked up from the GL includes
+#define GL_UNSIGNED_BYTE_3_3_2_EXT 0x8032
+#define GL_UNSIGNED_SHORT_4_4_4_4_EXT 0x8033
+#define GL_UNSIGNED_SHORT_5_5_5_1_EXT 0x8034
+#define GL_UNSIGNED_INT_8_8_8_8_EXT 0x8035
+#define GL_UNSIGNED_INT_10_10_10_2_EXT 0x8036
+#endif
+
#include "OpenGL.h"
#include "Textures.h"
#include "GBI.h"
Index: glN64/Makefile
======================================== ===========================
--- glN64/Makefile (revision 497)
+++ glN64/Makefile (working copy)
@@ -15,6 +15,8 @@
OBJECTS = Config_gtk2.o
endif

+LDFLAGS += -lpng
+
# list of object files to generate
OBJECTS += glN64.o \
OpenGL.o \
Index: glN64/Config_gtk2.cpp
======================================== ===========================
--- glN64/Config_gtk2.cpp (revision 497)
+++ glN64/Config_gtk2.cpp (working copy)
@@ -1,4 +1,4 @@
-#include <features.h>
+//#include <features.h>
#include <dlfcn.h>
#include <unistd.h>
#include "../main/winlnxdefs.h"
Index: glN64/gDP.cpp
======================================== ===========================
--- glN64/gDP.cpp (revision 497)
+++ glN64/gDP.cpp (working copy)
@@ -23,6 +23,15 @@
#include <stdlib.h>
#endif

+#ifdef __APPLE__
+// FIXME... I have no clue why these are not picked up from the GL includes
+#define GL_UNSIGNED_BYTE_3_3_2_EXT 0x8032
+#define GL_UNSIGNED_SHORT_4_4_4_4_EXT 0x8033
+#define GL_UNSIGNED_SHORT_5_5_5_1_EXT 0x8034
+#define GL_UNSIGNED_INT_8_8_8_8_EXT 0x8035
+#define GL_UNSIGNED_INT_10_10_10_2_EXT 0x8036
+#endif
+
gDPInfo gDP;

void gDPSetOtherMode( u32 mode0, u32 mode1 )
Index: glN64/NV_register_combiners.h
======================================== ===========================
--- glN64/NV_register_combiners.h (revision 497)
+++ glN64/NV_register_combiners.h (working copy)
@@ -2,6 +2,10 @@
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>

+#ifdef __APPLE__
+#define APIENTRY
+#endif
+
/* NVidia extensions */
extern void APIENTRY glCombinerParameterfvNV (GLenum, const GLfloat *);
extern void APIENTRY glCombinerParameterfNV (GLenum, GLfloat);
Index: pre.mk
======================================== ===========================
--- pre.mk (revision 497)
+++ pre.mk (working copy)
@@ -35,10 +35,11 @@
# throw error
$(error pkg-config not installed!)
endif
-ifneq ("$(shell pkg-config gtk+-2.0 --modversion | head -c 2)", "2.")
- # throw error
- $(error No GTK 2.x development libraries found!)
-endif
+# head doesn't take a '-c' argument (?)
+#ifneq ("$(shell pkg-config gtk+-2.0 --modversion | head -c 2)", "2.")
+# # throw error
+# $(error No GTK 2.x development libraries found!)
+#endif

# set GTK flags and libraries
GTK_FLAGS = $(shell pkg-config gtk+-2.0 --cflags) -D_GTK2
@@ -77,7 +78,7 @@
CC = gcc
CXX = g++
LD = g++
-STRIP = strip --strip-all
+STRIP = strip -S
RM = rm
MV = mv
CP = cp
@@ -157,7 +158,7 @@
FREETYPE_LIBS = $(shell freetype-config --libs)
FREETYPE_FLAGS = $(shell freetype-config --cflags)

-PLUGIN_LDFLAGS = -Wl,-Bsymbolic -shared
+PLUGIN_LDFLAGS = -bundle

-LIBGL_LIBS = -L/usr/X11R6/lib -lGL -lGLU
+LIBGL_LIBS = -framework OpenGL

Index: jttl_audio/Makefile
======================================== ===========================
--- jttl_audio/Makefile (revision 497)
+++ jttl_audio/Makefile (working copy)
@@ -29,8 +29,11 @@
OBJECTS = main.o

# build targets
-all: jttl_audio.so
+#all: jttl_audio.so

+# seems unusable on non-linux systems
+all:
+
clean:
rm -f *.o *.so

Index: rice_video/OGLCombinerTNT2.cpp
======================================== ===========================
--- rice_video/OGLCombinerTNT2.cpp (revision 497)
+++ rice_video/OGLCombinerTNT2.cpp (working copy)
@@ -19,6 +19,19 @@
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>

+#ifdef __APPLE__
+// FIXME - no clue why it's not picked from header
+#define GL_COMBINE_EXT 0x8570
+#define GL_COMBINE_RGB_EXT 0x8571
+#define GL_COMBINE_ALPHA_EXT 0x8572
+#define GL_RGB_SCALE_EXT 0x8573
+#define GL_ADD_SIGNED_EXT 0x8574
+#define GL_INTERPOLATE_EXT 0x8575
+#define GL_CONSTANT_EXT 0x8576
+#define GL_PRIMARY_COLOR_EXT 0x8577
+#define GL_PREVIOUS_EXT 0x8578
+#endif
+
#include "stdafx.h"

//======================================== ================================
@@ -207,6 +220,10 @@

// Texture unit 0
glActiveTexture(GL_TEXTURE0_ARB);
+#ifndef GL_COMBINE4_NV
+ //FIXME hack to get it to build
+#define GL_COMBINE4_NV GL_COMBINE_ARB
+#endif
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE4_NV);
m_pOGLRender->EnableTexUnit(0,TRUE);
glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_RGB_ARB, res.unit1.rgbOp);
Index: rice_video/RenderBase.cpp
======================================== ===========================
--- rice_video/RenderBase.cpp (revision 497)
+++ rice_video/RenderBase.cpp (working copy)
@@ -1289,6 +1289,13 @@
// Assumes dwAddr has already been checked!
// Don't inline - it's too big with the transform macros

+#ifdef NO_ASM
+void ProcessVertexDataSSE(uint32 dwAddr, uint32 dwV0, uint32 dwNum)
+{
+ // FIXME - this function seems to have no NO_ASM equivalent
+}
+#endif
+
#if !defined(NO_ASM)
void ProcessVertexDataSSE(uint32 dwAddr, uint32 dwV0, uint32 dwNum)
{
Index: rice_video/Config.h
======================================== ===========================
--- rice_video/Config.h (revision 497)
+++ rice_video/Config.h (working copy)
@@ -359,7 +359,7 @@
s8 nCountryID;
uint8 nUnknown5;
};
-#pragma pack()
+//#pragma pack()

typedef struct
{
Index: rice_video/OGLRender.cpp
======================================== ===========================
--- rice_video/OGLRender.cpp (revision 497)
+++ rice_video/OGLRender.cpp (working copy)
@@ -20,6 +20,10 @@
#include <GL/gl.h>
#include "stdafx.h"

+#ifndef GL_MIRRORED_REPEAT_IBM
+#define GL_MIRRORED_REPEAT_IBM 0x8370
+#endif
+
// Fix me, use OGL internal L/T and matrix stack
// Fix me, use OGL lookupAt function
// Fix me, use OGL DisplayList
Index: Makefile
======================================== ===========================
--- Makefile (revision 497)
+++ Makefile (working copy)
@@ -1,7 +1,7 @@
# Makefile for Mupen64Plus

# include pre-make file with a bunch of definitions
-USES_KDE4 = true
+USES_KDE4 = false
include ./pre.mk

# local CFLAGS, LIBS, and LDFLAGS
@@ -229,13 +229,18 @@
endif
endif

+# even with GTK GUI, there seems to be C++ code
+# and I get errors if I try to link with gcc and not g++
+
# select proper compiler for final mupen64plus linking
-ifeq ($(GUI), KDE4)
- MUPENCC = $(CXX)
-else
- MUPENCC = $(CC)
-endif
+#ifeq ($(GUI), KDE4)
+# MUPENCC = $(CXX)
+#else
+# MUPENCC = $(CC)
+#endif

+MUPENCC = $(CXX)
+
# build targets
targets:
@echo "Mupen64Plus makefile. "
@@ -267,11 +272,11 @@
all: $(ALL)

mupen64plus: $(OBJECTS)
- $(MUPENCC) $^ $(LDFLAGS) $(LIBS) -Wl,-export-dynamic -lpthread -ldl -o $@
+ $(MUPENCC) $^ $(LDFLAGS) $(LIBS) -lpthread -ldl -o $@
$(STRIP) $@

mupen64plus_dbg: $(OBJECTS) main/main_gtk.o
- $(MUPENCC) $^ $(LDFLAGS) $(LIBS) -Wl,-export-dynamic -lpthread -ldl -o $@
+ $(MUPENCC) $^ $(LDFLAGS) $(LIBS) -lpthread -ldl -o $@

install:
./install.sh $(PREFIX)
Index: mupen64_audio/main.c
======================================== ===========================
--- mupen64_audio/main.c (revision 497)
+++ mupen64_audio/main.c (working copy)
@@ -6,7 +6,8 @@
#include <stdlib.h>
#include <fcntl.h>
#include <sys/ioctl.h>
-#include <linux/soundcard.h>
+// FIXME- quick hack to get it to build
+//#include <linux/soundcard.h>
#include <unistd.h>
#include <pthread.h>
#include <sys/time.h>
@@ -38,8 +39,8 @@
f = 48628316 / (*AudioInfo.AI_DACRATE_REG + 1);
break;
}
- if (ioctl(dsp, SNDCTL_DSP_SPEED, &f) == -1)
- printf("error initializing frequency:%x\n", f);
+ //if (ioctl(dsp, SNDCTL_DSP_SPEED, &f) == -1)
+ // printf("error initializing frequency:%x\n", f);
frequency = f;
}

@@ -330,21 +331,22 @@
}
dsp = open("/dev/dsp", O_WRONLY);
if (dsp == -1) printf("error opening /dev/dsp\n");
- if (ioctl(dsp, SNDCTL_DSP_RESET) == -1)
- printf("error resetting sound card\n");
+ //if (ioctl(dsp, SNDCTL_DSP_RESET) == -1)
+ // printf("error resetting sound card\n");
f = 0x20010;
- if (ioctl(dsp, SNDCTL_DSP_SETFRAGMENT, &val) == -1)
- printf("error setting fragment size\n");
- if (ioctl(dsp, SNDCTL_DSP_STEREO, &channel) == -1)
- printf("error setting stereo mode\n");
- if (!channel)
- printf("error setting stereo mode\n");
- format = AFMT_S16_LE;
- if (ioctl(dsp, SNDCTL_DSP_SAMPLESIZE, &format) == -1)
- printf("error initializing format\n");
+ //if (ioctl(dsp, SNDCTL_DSP_SETFRAGMENT, &val) == -1)
+ // printf("error setting fragment size\n");
+ //if (ioctl(dsp, SNDCTL_DSP_STEREO, &channel) == -1)
+ // printf("error setting stereo mode\n");
+ // if (!channel)
+ // printf("error setting stereo mode\n");
+ //format = AFMT_S16_LE;
+ format = 0;
+ //if (ioctl(dsp, SNDCTL_DSP_SAMPLESIZE, &format) == -1)
+ // printf("error initializing format\n");
f = 32000;
- if (ioctl(dsp, SNDCTL_DSP_SPEED, &f) == -1)
- printf("error initializing frequency:%d\n", f);
+ //if (ioctl(dsp, SNDCTL_DSP_SPEED, &f) == -1)
+ // printf("error initializing frequency:%d\n", f);
sem_init(&sem, 0, 0);
sem_init(&sem2,0, 1);
//sem_init(&semt,0, 0);
@@ -358,7 +360,7 @@
RomClosed( void )
{

- ioctl(dsp, SNDCTL_DSP_SYNC);
+ //ioctl(dsp, SNDCTL_DSP_SYNC);
closed = 1;
sem_post(&sem);
sem_post(&sem);
Index: main/volume.c
======================================== ===========================
--- main/volume.c (revision 497)
+++ main/volume.c (working copy)
@@ -30,6 +30,19 @@
/* Sound volume functions.
*/

+#ifdef __APPLE__
+
+// <sys/soundcard.h> doesn't seem to exist on OS X
+// FIXME
+
+void volSet(int percent){}
+int volGet(void){ return 75; }
+void volMute(void){}
+int volIsMuted(void){ return 0; }
+void volChange(int delta){}
+
+#else
+
#include <sys/soundcard.h>
#include <sys/types.h>
#include <sys/stat.h>
@@ -150,3 +163,4 @@
volSet(volGet() + delta);
}

+#endif
\ No newline at end of file
Index: blight_input/plugin.c
======================================== ===========================
--- blight_input/plugin.c (revision 497)
+++ blight_input/plugin.c (working copy)
@@ -20,7 +20,11 @@
#include <fcntl.h>
#include <unistd.h>
#include <dirent.h>
+
+// FIXME- totally broken on non-linux platforms
+#ifdef __LINUX__
#include <linux/input.h>
+#endif

#include "plugin.h"

@@ -453,9 +457,11 @@

BYTE lastCommand[6];

+#ifdef __LINUX__
struct ff_effect ffeffect[3];
struct ff_effect ffstrong[3];
struct ff_effect ffweak[3];
+#endif

BYTE DataCRC( BYTE *Data, int iLenght )
{
@@ -514,6 +520,7 @@
void
ControllerCommand(int Control, BYTE *Command)
{
+ #ifdef __LINUX__
BYTE *Data = &Command[5];
struct input_event play;

@@ -581,6 +588,7 @@
/*printf( "Write eeprom\n" );*/
break;
}
+#endif
}

/**************************************** **************************
@@ -860,6 +868,7 @@
void
GetKeys( int Control, BUTTONS *Keys )
{
+ #ifdef __LINUX__
struct input_event play;
int b, axis_val, axis_max_val, axis_val_tmp;
SDL_Event event;
@@ -1111,10 +1120,12 @@
perror("Error starting rumble effect");
}
}
+#endif
}

int InitiateRumble(int cntrl)
{
+ #ifdef __LINUX__
DIR *dp;
struct dirent *ep;
unsigned long features[4];
@@ -1208,6 +1219,7 @@
ioctl(controller[cntrl].event_joystick, EVIOCSFF, &ffweak[cntrl]);

printf("["PLUGIN_NAME"]: Rumble activated on N64 joystick #%i\n", cntrl + 1);
+#endif
}

/**************************************** **************************
Index: blight_input/Makefile
======================================== ===========================
--- blight_input/Makefile (revision 497)
+++ blight_input/Makefile (working copy)
@@ -15,8 +15,11 @@
pad.o

# build targets
-all: blight_input.so
+#all: blight_input.so

+# this plug-in is totally unusable on non-linux platforms
+all:
+
clean:
rm -f *.o *.so ttftoh arial.ttf.c

Index: glide64/Makefile
======================================== ===========================
--- glide64/Makefile (revision 497)
+++ glide64/Makefile (working copy)
@@ -125,7 +125,7 @@

$(TARGET): $(OBJECTS)
$(LD) $(OBJECTS) $(GTK_LIBS) $(LDFLAGS) -o $@
- $(STRIP) --strip-all $@
+ $(STRIP) $@

Main.o: font.h cursor.h
font.h: compiletex

[CrispyXUK]

Blimey, the ball is well and truely rolling.

Would this build work on an Intel machine as is?

[Auria]

It would most likely compile, though I doubt it would run, as I "butchered" away non-working pieces of code instead of fixing them.

Though that's a needed start, though before going further I guess we'd need the support of some core mupen dev to at least go on and apply the safer bits

[Tillin9]

You should PM Richard42 and ask for svn access and for an OSX branch since you're already submitting code. ;)

I know its been mentioned before in this thread, but I'll give a big thank you to anyone who merges in the working PPC dynarec from this project - http://code.google.com/p/mupen64gc/ Since you're on PPC OSX and want a full speed emu on your platform, that's what you'd need to do.

Something on the dev. team's todo list is to contact that project and ask for a more formal arrangement to work together. But as you can see from many of the posts in this forum, we need to try to keep our foucs narrow for things to actually get accomplished. If you're interested in pursuing a PPC OSX port, feel free to take up this task.

P.S. Sorry if I'm coming off a tad strong but we can always use a few more devs.

[Auria]

Hey Tillin9,

I understand what you mean, though SVN access for me is a little too much, I know very little about emulators, what I've done is merely fix the obvious errors and point out the other ones. I could consider PM'ing a dev though, or maybe opening a ticket on the bug tracker for some of the safest changes

[Slougi]

Hey Tillin9,

I understand what you mean, though SVN access for me is a little too much, I know very little about emulators, what I've done is merely fix the obvious errors and point out the other ones. I could consider PM'ing a dev though, or maybe opening a ticket on the bug tracker for some of the safest changes

Emulators aren't different from any other program really. Not knowing about them at least shouldn't keep you from contributing - i know next to nothing about dynarecs and things like that myself ;)

[CrispyXUK]

Bugger, I'm still working late, I know its only an icon but everything is the sum of its parts, hopefully I'll get a few done next week.

[Auria]

OK I contacted Richard.

First bug report : http://code.google.com/p/mupen64plus/issues/detail?id=105&colspec=ID%20Type%20Component%20Status%2 0Priority%20Stars%20Milestone%20Owner%20 Summary
(all people who would like to help with OS X look at this, it could save you a little searching)

[Auria]

... and now issue 106 too.
http://code.google.com/p/mupen64plus/issues/detail?id=106&colspec=ID%20Type%20Component%20Status%2 0Priority%20Stars%20Milestone%20Owner%20 Summary

the ball got rolling ;)

[Shin_Gouki]

hello there!
IS there already a "test" version for x86 MAC osx? Or do i have to build it myself? Which tools you use to test only gcc?

[DarkJezter]

Not having much experience here, do you know if there is much difference between binaries produced with xcode vs gcc running in the osx posix compatibility layer?

I know on win32 systems that having native tool support is ideal (MSVC support), I guess I'm wondering if this is equally as important on osx or not

[Auria]

Not having much experience here, do you know if there is much difference between binaries produced with xcode vs gcc running in the osx posix compatibility layer?


It is NOT a compatibility layer, OS X IS a Unix system (don't think about something like MSYS, on OS X there is no faking of POSIX, it's the actual system. OS X is a BSD derivate, remember). XCode just fires gcc/g++ commands. The binary produced by XCode and the one produced on the terminal are exactly the same.

IS there already a "test" version for x86 MAC osx? Or do i have to build it myself? Which tools you use to test only gcc?
There is no test version for OS X, many modules in mupen are closely tied with Linux

It can be built using the makefiles, provided you use the patches provided higher in this ost. Still, I wouldn't recommend trying this if you're not a programmer, and you should not expect it to work with the raw patches provided above. They do much more in the way of showing problems than in fixing thems

[Shin_Gouki]

well i'm not expecting a "working" version, i want to test or look what error it spits out.

[Auria]

Ok well you'd need to try it for yourself, I'm on PPC and have absolutely no clue what it would do on an intel mac :)

[thatmariolover]

:p

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.

[Auria]

:p

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

[Tillin9]

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. :)

[Nick_kidid0]

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 :)

[Tillin9]

Hey, if you're a mupen64gc dev, did Matt contact you? We're very interested in combining our efforts to improve the mupen codebase. Most of us are on the #mupen64plus IRC channel on freenode, so it would be nice to come on and discuss this. :)

[CrispyXUK]

Is PPC that high a priority? I'd image not many are about and who knows how long apple will support it.

[Tillin9]

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.

[Auria]

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 :
#include <linux/input.h>

About jttl_audio... sorry I meant "mupen64_audio", it includes "#include <linux/soundcard.h>".

[Richard42]

I removed mupen64_audio from the trunk a couple of days ago.

[CrispyXUK]

Is this dead?

[Surkow]

Is this dead?

The Mupen64Plus project is far from dead. But I haven't seen any progress with an OSX port.

[Tillin9]

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.

[Shin_Gouki]

i have no problem when they finish their regular release and then try to port this to mac.

[Auria]

Well I have already submitted many mac patches. A few of them could already go in but AFAIK no dev has applied them

[DarkJezter]

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

[thatmariolover]

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 (http://code.google.com/p/mupen64gc/).

[Auria]

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

In this thread (page 4 i think) and also in the bug tracker

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.
I think the goal is to support intel macs, not PPC macs

[Tillin9]

DarkJezter, the patches and issue discussion are mainly in Issue 105 and 106.

@thatmariolover - A lot of these are general non-Linux / endianness items which aren't just for PPC support.

[Tillin9]

CrispyXUK: You offered your services with a program icon? If you could make an SVG that looks roughly like this: http://upload.wikimedia.org/wikipedia/commons/c/cd/Mupen64_icon.png

Ideally with a greenish + in addition (though I probably have enough inkscape skills to add that :))

I believe the original icon is Creative Commons licensed (Hacktarux never got back to us but I found the icon in Wikicommons), however, the transparency around the edges is not very nice. A new SVG model would be better.

[CrispyXUK]

Yeah, I'm on it, what's SVG?

[CrispyXUK]

Ok, its mostly done, needs quite a bit of cleaning up so I'll post it some time today.

What's happening with the build BTW?

[Tillin9]

Thanks for the icon work.

SVG stands for scalable vector graphics. Its just the file format I want the new icon in since it avoids resolution issues, is easy to modify, etc. I'm fairly sure you figured this out yourself.

As far as the build, one / maybe two people have mupen64plus running under OSX (one working graphics plugin glN64 and non-dynarec core). Support isn't in trunk, but basically I think I know what's necessary to get it there. The biggest issue is I have no time this week, so be patient.

[CrispyXUK]

Oh, ok, nothing available to try then?

Not doing the icon in a vector format, but so far its been done @ 512x512 res, so we won't have any scaling issues anyway.

[thatmariolover]

Oh, ok, nothing available to try then?

Not doing the icon in a vector format, but so far its been done @ 512x512 res, so we won't have any scaling issues anyway.

Except that 10.6 won't support anything but vector graphics for icons. /shrug

[Tillin9]

I know beggars can't be choosers, but please do the icon as SVG. Most vector work is done in Illustrator or Inkscape. Does inkscape has an angle / length tool? I like to specify my vectors mathematically and that's currently giving me an issue. Otherwise, I could bang this out myself (granted I'm backed up with tons of mupen and real life things right now).

Even if your icon is perfect at 512x512, resizing a raster is never as good as rendering a vector. I also would like the freedom to tweak some of the gradient stuff in inkscape (I figured out how to do bezier curve gradients crystal effects) not on the model.

[CrispyXUK]

Except that 10.6 won't support anything but vector graphics for icons. /shrug

Since when? Thats crazy, the base work was all done in vector anyway, just the effects stage it was bitmapped.

[CrispyXUK]

I know beggars can't be choosers, but please do the icon as SVG. Most vector work is done in Illustrator or Inkscape. Does inkscape has an angle / length tool? I like to specify my vectors mathematically and that's currently giving me an issue. Otherwise, I could bang this out myself (granted I'm backed up with tons of mupen and real life things right now).

Even if your icon is perfect at 512x512, resizing a raster is never as good as rendering a vector. I also would like the freedom to tweak some of the gradient stuff in inkscape (I figured out how to do bezier curve gradients crystal effects) not on the model.

You'd never need an icon larger than 512x512

http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIcons/chapter_15_section_8.html#//apple_ref/doc/uid/20000967-SW1

[Tillin9]

I mean resizing to lower resolutions. A straight resize is often not the best way to get lower size (16x16, 22x22, etc.) icons. Doing things like changing the stroke width on a vector and removing some extra gradient effects can make a big difference. Anyway... its silly to argue over this.

P.S. I wanted this icon for mupen64plus in general, not just the OSX port. Yet another reason for SVG, since I can easily customize the look for GNOME, KDE4, and OSX by changing gradients, colors, and effects.

[CrispyXUK]

As I said, the base is vector, only small highlights and texture are bitmap, so it won't be a problem scaling down in anyway.

[DarkJezter]

Here's a test patch for osx support in blight_input. if this is confirmed working it can be included in the trunk

Index: blight_input/plugin.c
======================================== ===========================
--- blight_input/plugin.c (revision 824)
+++ blight_input/plugin.c (working copy)
@@ -15,12 +15,15 @@
* *
**************************************** ***********************************/

+
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <dirent.h>
+#ifdef __linux__
#include <linux/input.h>
+#endif //__linux__

#include "plugin.h"

@@ -43,11 +46,13 @@
#include <string.h>

/* defines for the force feedback rumble support */
+#ifdef __linux__
#define BITS_PER_LONG (sizeof(long) * 8)
#define OFF(x) ((x)%BITS_PER_LONG)
#define BIT(x) (1UL<<OFF(x))
#define LONG(x) ((x)/BITS_PER_LONG)
#define test_bit(bit, array) ((array[LONG(bit)] >> OFF(bit)) & 1)
+#endif //__linux__

static unsigned short button_bits[] = {
0x0001, // R_DPAD
@@ -453,10 +458,13 @@

BYTE lastCommand[6];

+#ifdef __linux__
+
struct ff_effect ffeffect[3];
struct ff_effect ffstrong[3];
struct ff_effect ffweak[3];

+#endif //__linux__
BYTE DataCRC( BYTE *Data, int iLenght )
{
register BYTE Remainder = Data[0];
@@ -513,7 +521,6 @@
void ControllerCommand(int Control, BYTE *Command)
{
BYTE *Data = &Command[5];
- struct input_event play;

if (Control == -1)
return;
@@ -549,6 +556,8 @@
if(dwAddress==PAK_IO_RUMBLE&&*Data)
printf("Triggering rumble pack.\n");*/

+#ifdef __linux__
+ struct input_event play;
if( dwAddress == PAK_IO_RUMBLE && controller[Control].event_joystick != 0)
{
if( *Data )
@@ -571,6 +580,7 @@
perror("Error stopping rumble effect");
}
}
+#endif //__linux__
Data[32] = DataCRC( Data, 32 );
}
break;
@@ -864,7 +874,6 @@
void
GetKeys( int Control, BUTTONS *Keys )
{
- struct input_event play;
int b, axis_val, axis_max_val, axis_val_tmp;
SDL_Event event;
Uint8 *keystate = SDL_GetKeyState( NULL );
@@ -1091,8 +1100,10 @@
*(int *)Keys = *(int *)&controller[Control].buttons;

/* handle mempack / rumblepak switching (only if rumble is active on joystick) */
+#ifdef __linux__
if (controller[Control].event_joystick != 0)
{
+ struct input_event play;
if (controller[Control].buttons.button & button_bits[14])
{
controller[Control].control.Plugin = PLUGIN_MEMPAK;
@@ -1112,6 +1123,7 @@
perror("Error starting rumble effect");
}
}
+#endif //__linux__
}

int InitiateRumble(int cntrl)
@@ -1124,7 +1136,7 @@
int iFound = 0;

controller[cntrl].event_joystick = 0;
-
+#ifdef __linux__
sprintf(temp,"/sys/class/input/js%d/device", controller[cntrl].device);
dp = opendir(temp);

@@ -1209,6 +1221,8 @@
ioctl(controller[cntrl].event_joystick, EVIOCSFF, &ffweak[cntrl]);

printf("["PLUGIN_NAME"]: Rumble activated on N64 joystick #%i\n", cntrl + 1);
+#endif //__linux__
+
}

/**************************************** **************************

[Auria]

For now i get this :

69-4-214-3:/Developer/SVN/mupen mmg$ patch -p0 < blight.patch
patching file blight_input/plugin.c
Hunk #1 FAILED at 15.
Hunk #2 succeeded at 50 (offset 4 lines).
Hunk #3 FAILED at 462.
Hunk #4 succeeded at 528 with fuzz 2 (offset 7 lines).
Hunk #5 succeeded at 563 (offset 7 lines).
Hunk #6 succeeded at 587 (offset 7 lines).
Hunk #7 FAILED at 881.
Hunk #8 succeeded at 1109 (offset 9 lines).
Hunk #9 FAILED at 1132.
Hunk #10 succeeded at 1147 (offset 11 lines).
patch unexpectedly ends in middle of line
Hunk #11 FAILED at 1232.
5 out of 11 hunks FAILED -- saving rejects to file blight_input/plugin.c.rej


With plugin.c.rej containing

***************
*** 15,26 ****
* *
**************************************** ***********************************/

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <dirent.h>
#include <linux/input.h>

#include "plugin.h"

--- 15,29 ----
* *
**************************************** ***********************************/

+
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <dirent.h>
+ #ifdef __linux__
#include <linux/input.h>
+ #endif //__linux__

#include "plugin.h"

***************
*** 457,466 ****

BYTE lastCommand[6];

struct ff_effect ffeffect[3];
struct ff_effect ffstrong[3];
struct ff_effect ffweak[3];

BYTE DataCRC( BYTE *Data, int iLenght )
{
register BYTE Remainder = Data[0];
--- 462,474 ----

BYTE lastCommand[6];

+ #ifdef __linux__
+
struct ff_effect ffeffect[3];
struct ff_effect ffstrong[3];
struct ff_effect ffweak[3];

+ #endif //__linux__
BYTE DataCRC( BYTE *Data, int iLenght )
{
register BYTE Remainder = Data[0];
***************
*** 871,877 ****
void
GetKeys( int Control, BUTTONS *Keys )
{
- struct input_event play;
int b, axis_val, axis_max_val, axis_val_tmp;
SDL_Event event;
Uint8 *keystate = SDL_GetKeyState( NULL );
--- 881,886 ----
void
GetKeys( int Control, BUTTONS *Keys )
{
int b, axis_val, axis_max_val, axis_val_tmp;
SDL_Event event;
Uint8 *keystate = SDL_GetKeyState( NULL );
***************
*** 1121,1126 ****
perror("Error starting rumble effect");
}
}
}

int InitiateRumble(int cntrl)
--- 1132,1138 ----
perror("Error starting rumble effect");
}
}
+ #endif //__linux__
}

int InitiateRumble(int cntrl)
***************
*** 1220,1225 ****
ioctl(controller[cntrl].event_joystick, EVIOCSFF, &ffweak[cntrl]);

printf("["PLUGIN_NAME"]: Rumble activated on N64 joystick #%i\n", cntrl + 1);
}


--- 1232,1239 ----
ioctl(controller[cntrl].event_joystick, EVIOCSFF, &ffweak[cntrl]);

printf("["PLUGIN_NAME"]: Rumble activated on N64 joystick #%i\n", cntrl + 1);
+ #endif //__linux__
+
}



I could not try compiling it because with latest changes in SVN i can't build mupen anymore (complains about not finding GTK... i'll need to investigate)

EDIT: okay, seems like mupen is trying to link against the gui even if i passe GUI=NONE...


/usr/bin/ld: Undefined symbols:
_gui_display
_gui_init
_gui_main_loop
_gui_message
_libiconv
_libiconv_close
_libiconv_open
_updaterombrowser


since i no more have GTK on my computer i can't really build mupen anymore

[CrispyXUK]

Is there a build floating about I could try out?

[CrispyXUK]

Ok, I've taken you're advice and done the icon as an SVG, got about 30 minutes to do on it to tidy it up.

[Tillin9]

Auria: The Gtk issue comes from the plugins. Basically since Rice and Gilde need Gtk even with GUI=NONE so we can't make the test for Gtk conditional in pre.mk in trunk. This was the general rule for all the plugins till I started trying to fix it. Now with some makefile tweaking, its possible to build nearly everything else, though glN64 is the only video plugin which can work without Gtk right now.

Luckily Rice and Glide use basically the same GUI scheme, so getting one Gtk free means basically getting the other. Its just they have a corner case interactive mode so their GUI is a fair bit more complex than say jttl_audio with its three GUI functions.

If you remove the GTK stuff from the mk.pre. and pass GUI=NONE the ifdefs in the main should prevent the GUI API from being needed.

Nogui
templarapheonix@Sonia:~/mupen64plus/trunk$ ldd mupen64plus-nogui
linux-gate.so.1 => (0xffffe000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7fa0000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7f7d000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7f07000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7e56000)
libGL.so.1 => /usr/local/lib/libGL.so.1 (0xb7dec000)
libGLU.so.1 => /usr/local/lib/libGLU.so.1 (0xb7d66000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7d4d000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7d49000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7c5a000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7c34000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7c27000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7acc000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb7a0a000)
libdirectfb-1.0.so.0 => /usr/lib/libdirectfb-1.0.so.0 (0xb79a2000)
libfusion-1.0.so.0 => /usr/lib/libfusion-1.0.so.0 (0xb799a000)
libdirect-1.0.so.0 => /usr/lib/libdirect-1.0.so.0 (0xb7986000)
libvga.so.1 => /usr/lib/libvga.so.1 (0xb7925000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7836000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7827000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7822000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb781f000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb781a000)
libdrm.so.2 => /usr/lib/xorg/lib/libdrm.so.2 (0xb7811000)
/lib/ld-linux.so.2 (0xb7fd2000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7807000)
libx86.so.1 => /lib/libx86.so.1 (0xb7804000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7802000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb77ea000)
libXau.so.6 => /usr/lib/xorg/lib/libXau.so.6 (0xb77e7000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb77e1000)


Gtk GUI
templarapheonix@Sonia:~/mupen64plus/trunk$ ldd mupen64plus
linux-gate.so.1 => (0xffffe000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7f54000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7f31000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7ebb000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7e0a000)
libGL.so.1 => /usr/local/lib/libGL.so.1 (0xb7da0000)
libGLU.so.1 => /usr/local/lib/libGLU.so.1 (0xb7d1a000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb798f000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7908000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb78ec000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb78d4000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb78ae000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb78a4000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7864000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb77fb000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb77bf000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb77bb000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb77b7000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7702000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb76fd000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb76f3000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb76da000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb75ec000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb75df000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7484000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb73c2000)
libdirectfb-1.0.so.0 => /usr/lib/libdirectfb-1.0.so.0 (0xb735a000)
libfusion-1.0.so.0 => /usr/lib/libfusion-1.0.so.0 (0xb7352000)
libdirect-1.0.so.0 => /usr/lib/libdirect-1.0.so.0 (0xb733e000)
libvga.so.1 => /usr/lib/libvga.so.1 (0xb72dd000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb71ee000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb71df000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb71da000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb71d7000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb71d2000)
libdrm.so.2 => /usr/lib/xorg/lib/libdrm.so.2 (0xb71c9000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb71c5000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb719b000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7192000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb718f000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb7187000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7180000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7177000)
/lib/ld-linux.so.2 (0xb7f86000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7150000)
libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb714c000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb7145000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb712c000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb7103000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb70ea000)
libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb70c1000)
libx86.so.1 => /lib/libx86.so.1 (0xb70be000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb70bb000)
libXau.so.6 => /usr/lib/xorg/lib/libXau.so.6 (0xb70b8000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7092000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb708d000)

[Auria]

Tillin9, thanks for the info. It was just slightly confusing that there is a NO_GUI option that still links GTK in. I'm not sure whether it's documented or if i just missed it.

Anyway, this is not a really important matter, if mupen depends on GTK let it be so. I recently got GTK installed back on my computer (GTK is not yet very solid on mac, there's no official package yet, so it needs to be built from scripts and it breaks often)

However i now get :

make: *** No rule to make target `r4300//assemble.o', needed by `mupen64plus'. Stop.


this is on a clean build, today's SVN (r860)

EDIT: oh, i think i get this cause i forgot to pass "NO_ASM=1". Trying again right now...

[Auria]

Okay, the BlightInput patch works fine :) I guess it can be comitted or added to the issue tracker (?).

I also finally made a proper patch for OpenGL types, and submitted it to the bug tracker.

[CrispyXUK]

I've no idea what any of this code means, but it sounds like the port is coming along well.

[CrispyXUK]

Logo updated a bit

http://www.realitydesign.co.uk/various/m64-2.png

[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]

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.

[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
http://uploads.imagup.com/05/1220492446_Image%204.png

[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]

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 :)

http://img512.imageshack.us/img512/9939/picture1eo5.th.png (http://img512.imageshack.us/my.php?image=picture1eo5.png)
http://img501.imageshack.us/img501/959/picture2ni7.th.png (http://img501.imageshack.us/my.php?image=picture2ni7.png)

[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!

[Shin_Gouki]

wow the screens look nice!

[sturmen]

I'd love to help beta test! I have two Intel Macs available:
Macbook (High-end white)
iMac (high-end 24", right before the speedup… 2.4 GHz)

[Tillin9]

We have Rice and Glide now working on OSX (x86/x86_64) also. Rice has a number of issues (not related to OSX) so don't be overzealous in bug reporting there. We also fixed the crash on ROM close.

I would love for someone (ideally with 10.4.x and 10.5.5) to test out
Issue 146. http://code.google.com/p/mupen64plus/issues/detail?id=146&colspec=ID%20Type%20Component%20Status%2 0Priority%20Stars%20Milestone%20Owner%20 Summary

Specifically I want to know if this is just a libiconv not installed issue and if -dylib_file has any negative effect on OSX < 10.4.

[CrispyXUK]

Are the build instructions the same?

[Tillin9]

I'm assuming dtm's instructions are still valid. Let me know if there are any problems.

[thatmariolover]

Update:

I am still encountering a build error:

-L/usr/X11/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -o blight_input.so
ld: library not found for -lSDL_ttf
collect2: ld returned 1 exit status
make[1]: *** [blight_input.so] Error 1
make: *** [plugins/blight_input.so] Error 2
mac-pro:trunk ericherr$ sudo port install lsdl_ttf


Shouldn't it be looking for SDL_ttf and not lSDL_ttf? Anyway, not sure if anybody can shine some light on this latest issue.


The issues below were resolved after I managed to deactivate the offending libraries using 'sudo port deactivate [library/version]' which in turn allowed me to install the libraries correctly:

So, I followed the instructions from here:

http://code.google.com/p/mupen64plus/wiki/MacOSXInstructions

However, I am getting a build error:

"ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib"

After doing some googling I found this help page from Apple:

http://developer.apple.com/qa/qa2007/qa1567.html

Background

The linker on Mac OS X v.10.5 searches -L paths for indirect libraries and in doing so it finds two copies of libGL.dylib. One in /usr/X11/lib and the other in /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries and this causes a cycle.

This is a side effect of various linker improvements in Leopard, which we may be able to mitigate in a future release.

Back to Top
Workaround

You can overcome this problem by providing the -dylib_file option to the linker. The -dylib_file option is described as:

-dylib_file install_name:file_name
Specifies that a dynamic shared library is in a different location than its standard location.
Use this option when you link with a library that is dependent on a dynamic library, and the
dynamic library is in a location other than its default location. install_name specifies the path
where the library normally resides. file_name specifies the path of the library you want to use
instead. For example, if you link to a library that depends upon the dynamic library libsys
and you have libsys installed in a nondefault location, you would use this option:
-dylib_file /lib/libsys_s.A.dylib:/me/lib/libsys_s.A.dylib.

I'm having trouble understanding what exactly I need to do to get this working.

Kind of a big edit:

Before I had followed the instructions on that page, I had attempted to install some of the libraries on my own. Unfortunately, this means I didn't use the no_x11 variant which I assume is what is causing my troubles.

Now when I try to install the libraries (using sudo port install pango +no_x11 cairo +quartz+pdf+no_x11 gtk2 +quartz libsdl_ttf), I get an error:

Target org.macports.activate returned: Image error: Another version of this port (name/version of library here) is already active.

Is there an easy way to remove those libraries to install them properly?

[roger6106]

The x11 version of some of these items being installed appears to be what's causing your problem. The command "sudo port uninstall pango cairo gtk2" should remove the x11 versions.

Macports may tell you that it can't remove those programs due to them being dependencies. If so, remove the program that depends on them (using sudo port uninstall [program name]). After all this is done you should be able to install the non-x11 versions.

[thatmariolover]

The x11 version of some of these items being installed appears to be what's causing your problem. The command "sudo port uninstall pango cairo gtk2" should remove the x11 versions.

Macports may tell you that it can't remove those programs due to them being dependencies. If so, remove the program that depends on them (using sudo port uninstall [program name]). After all this is done you should be able to install the non-x11 versions.

Yeah, I removed all of the dependencies using the uninstall command and reinstalled the non x11 versions. However, I'm still encountering this build error:

ld: library not found for -lSDL_ttf
collect2: ld returned 1 exit status
make[1]: *** [blight_input.so] Error 1
make: *** [plugins/blight_input.so] Error 2

[thatmariolover]

I managed to get it to build and execute. A quick video just to show stuff's working:

http://dl.getdropbox.com/u/113726/Mupen.mp4

[sturmen]

Okay, whenever I try to build according to these instructions (http://code.google.com/p/mupen64plus/wiki/MacOSXInstructions), I always get missing GTK+ dependencies, even after installing it through MacPorts. How do I use the best N64 emulator on the best operating system?

[Tillin9]

surmen: Did you install the gtk-dev packages? The build script uses pkg-config to get the gtk+-2.0 C flags and library flags. Is pkg-config installed and GTK registering? What does

pkg-config gtk+-2.0 --cflags

give on the terminal? If you can't get GTK configured, you can manually set them in pre.mk.

thatmariolover: That error just means SDL_tff and its development package are not installed. SDL has a few smaller optional libraries. Blight requires SDL_tff.

To all OSX testers, if you can please install SDL 1.3 from their svn or development snapshots. I believe the no keyboard input in GUI mode bug is purely an SDL issue and already solved on their upstream. If we can confirm this is the case, someone could theoretically make an Intel OSX app bundle with SDL 1.3 statically included.

[sturmen]

surmen: Did you install the gtk-dev packages? The build script uses pkg-config to get the gtk+-2.0 C flags and library flags. Is pkg-config installed and GTK registering? What does

pkg-config gtk+-2.0 --cflags

give on the terminal? If you can't get GTK configured, you can manually set them in pre.mk.
macbook-3:~ sturmen$ pkg-config gtk+-2.0 --cflags
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
printout from iTerm. How do I do that? I know where "gtk+-2.0.pc" is. But where do I type that in?

[thatmariolover]

thatmariolover: That error just means SDL_tff and its development package are not installed. SDL has a few smaller optional libraries. Blight requires SDL_tff.

To all OSX testers, if you can please install SDL 1.3 from their svn or development snapshots. I believe the no keyboard input in GUI mode bug is purely an SDL issue and already solved on their upstream. If we can confirm this is the case, someone could theoretically make an Intel OSX app bundle with SDL 1.3 statically included.

I already worked past the SDL_ttf bug, so it's compiling and running.

As for installing SDL 1.3 to fix the lack of keyboard input, that's possible. I've been using a 360 controller so I haven't had that issue. However, when I try to install SDL 1.3 using the Mac OS X instructions packaged with it, I get errors about it not finding a config file.

[Tillin9]

sturmen: You can manually add to PKG_CONFIG_PATH,

PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/my/additional/config

You can add an export PKG_CONFIG_PATH line somewhere to your shell's profile, however, this suggests something is wrong with your install.

thatmariolover: What error do you get? Maybe someone here can help.

[thatmariolover]

So I was reading here:
http://www.libsdl.org/svn.php

And I downloaded 1.3 from the svn using Terminal:
svn co http://svn.libsdl.org/trunk/SDL

That comes with README.MacOSX, which says:

======================================== ======================================
Using the Simple DirectMedia Layer with Mac OS X
======================================== ======================================

These instructions are for people using Apple's Mac OS X (pronounced
"ten").

From the developer's point of view, OS X is a sort of hybrid Mac and
Unix system, and you have the option of using either traditional
command line tools or Apple's IDE Xcode.

To build SDL using the command line, use the standard configure and make
process:

./configure
make
sudo make install

You can also build SDL as a Universal library (a single binary for both
PowerPC and Intel architectures), on Mac OS X 10.4 and newer, by using
the fatbuild.sh script in build-scripts:
sh build-scripts/fatbuild.sh
sudo build-scripts/fatbuild.sh install
This script builds SDL with 10.2 ABI compatibility on PowerPC and 10.4
ABI compatibility on Intel architectures. For best compatibility you
should compile your application the same way. A script which wraps
gcc to make this easy is provided in test/gcc-fat.sh

To use the library once it's built, you essential have two possibilities:
use the traditional autoconf/automake/make method, or use Xcode.

My guess is I just have no clue what I'm doing and I'm missing a step that should be self explanatory to somebody who compiles regularly.

What should I be doing now that I have it checked out?

I tried just make clean ; make all. That returns:
make: *** No rule to make target `clean'. Stop.
make: *** No rule to make target `all'. Stop.

Which I assume is because there's no 'makefile'.

If I try using:
sh build-scripts/fatbuild.sh
sudo build-scripts/fatbuild.sh install

I get this returned for the first line:
sh: ../../configure: No such file or directory

And this for the second:
sh /Users/username/sdlinstall/SDL/build-scripts/../build-scripts/mkinstalldirs /usr/local/bin
/usr/bin/install -c -m 755 build/x86/sdl-config /usr/local/bin/sdl-config
install: build/x86/sdl-config: No such file or directory

[Tillin9]

Ah, I think you need to run:

sh autogen.sh

to use autoconf to make the configure script for automake.

[thatmariolover]

That did the trick, SDL 1.3 is installed. Will test keyboard input.

Unfortunately, now that I installed 1.3, I get the following error upon building Mupen:

main/main.c:826: warning: passing argument 1 of ‘SDL_SetEventFilter’ from incompatible pointer type
main/main.c:826: error: too few arguments to function ‘SDL_SetEventFilter’
make: *** [main/main.o] Error 1

[dgm]

^ I couldn't figure out how to compile SDL_ttf with SDL 1.3. Maybe you're forgetting about this dependancy?

Anyone know how to compile SDL_ttf for the newest SDL?

[Auria]

Mupen 1.5 was just released - along with a first beta mac binary :)

http://mupen64plus.googlecode.com/files/Mupen64Plus-1.5-mac.dmg

Enjoy.

[CrispyXUK]

How do I build with the GT4 gui?

[Shin_Gouki]

now would that be QT 4?

and see waht my first google try did bring up :)
http://doc.trolltech.com/4.4/install-mac.html

[Pyromanik]

^no no, I think he means build mupen, not QT.

How do I build with the QT4 gui?

make all GUI=QT4

[CrispyXUK]

Yeah I tried that, didn't seem to work.

I'll give it another go.

[Pyromanik]

Don't forget to run ./mupen64plus from the compilation directory.

If you have a systemwide install (like I do) then it can be easy to make the mistake of running the wrong version and wondering why your changes don't seem to have changed anything.... doh! xD

[Slougi]

The Qt4 gui doesn't currently work correctly on the mac. There were issues with integrating SDL and Qt. Now that Qt 4.5 supports cocoa this can probably be solved... Unfortunately I don't have access to a mac anymore.

[Shin_Gouki]

i could test for you? Or is the testing process via "bugreports" too much off effort?

[Slougi]

i could test for you? Or is the testing process via "bugreports" too much off effort?

It's really difficult to write code "blind", especially for platforms you aren't intimately familiar with. It can be done, but frankly I'm just not that interested. Sorry.

[CrispyXUK]

Are there no developers on board for the mac side of things now then?

[argor]

Are there no developers on board for the mac side of things now then?

i thing there is only auria on the mac side of things

[Pyromanik]

There are a couple who come in every now and again, but never seem to stick around for that long.
But that perhaps doesn't mean they're not developing in their spare time without being in channel.

So who knows really.
But I'd expect very slow progress unless someone else comes to help.

[CrispyXUK]

Shame, wish I could help somehow, but I have no coding skills at all.

Would it be worth getting rid of the rom browser and just using the taskbar menus?

[Pyromanik]

What?

Oh, right. MacOS windowing layout.

Well no, the rom browser (and caching system these days) are far more user friendly for opening roms and giving information on which ones work well, etc.

Plus it puts something visual on the screen, which is always a plus.


And as far as I know the rom system is not an issue at all, besides the windowing toolkit bit.
I'm not really sure about the stage of the port with the rest of the emulator.
Of course, there's no reason one can't test it by compiling with GUI=NONE
But for that matter one could do ANOTHER GUI with a MacOS toolkit if they really wanted to.

[Shin_Gouki]

as stated above using QT 4.5 it would simply be an biuld option?!

[Pyromanik]

Well, unless it's not backwards compatible (highly unlikely) I'd imagine the same code can be compiled with Qt4.5 and run fine on MacOS.

[Auria]

Are there no developers on board for the mac side of things now then?



i thing there is only auria on the mac side of things


There are a couple who come in every now and again, but never seem to stick around for that long.
But that perhaps doesn't mean they're not developing in their spare time without being in channel.

So who knows really.
But I'd expect very slow progress unless someone else comes to help.

Hey there,

I haven't given up, I'm still interested in the mac port ;) mupen works qyuite well on mac at the moment, it's only the GUI acting up. I don't have much hopes of fixing the current GTK gui with the way mupen is currently designed, that would require refactors that mupen project leaders don't seem to want (or they disagree within themselves); so the best hope is the Qt GUI, but for this there's little I can do, because I know next to nothing about Qt, so I just let the Qt-GUI author continue. Also we're waiting on the next Qt version, which uses Cocoa and will hopefully play better with SDL (is it released yet? maybe, didn't check in a while :) EDIT: I see it is, but 186 Mb?? ouch...)

[Shin_Gouki]

wow that sounds nice ;)
Yeah i have tried some things too with QT on my mac. Is QT vastly diffrent from GTK?

well any way i'm looking forward to your next ( mac) release ;)

[Auria]

Yeah i have tried some things too with QT on my mac. Is QT vastly diffrent from GTK?


Technically they're quite different as they're written in different languages. From a user point of view, the only difference is one of skinning (Qt uses a native OS X theme + some native components, though in the future GTK+ will probably use a native mac theme too on OS X, so this difference would go away anyway

[Mr VacBob]

I'm still alive (I make sure to check all my dead projects once a year…) but the GUI threads thing is just a bit too much work for me. It might be useful to host it as an OpenEmu core once that's more mature - I think it expects everything to output a 2D texture at the moment.

I'm guessing if I build this all these libraries expecting X11+OpenGL won't work...