What's new

Mupen64 0.4 source code

Hacktarux

Emulator Developer
Moderator
Here, you can download the source code of mupen64 0.4 and all the plugins included in its binary package. Some plugins were already published but i've updated the source code to compile on my system.

The core source code:
http://mupen64.emulation64.com/files/0.4/mupen64_src-0.4.tar.bz2

RSP plugin:
http://mupen64.emulation64.com/files/0.4/hack_azi_rsp_hle.tar.bz2

Input plugins:
mupen64 basic input plugin:
http://mupen64.emulation64.com/files/0.4/mupen64_input.tar.bz2
blight input plugin 0.0.8-b:
http://mupen64.emulation64.com/files/0.4/blight_input-0.0.8-b.tar.gz

Sound plugins:
jttl SDL sound plugin 1.2:
http://mupen64.emulation64.com/files/0.4/jttl_sound-1.2.tar.bz2
GAP 0.5:
http://mupen64.emulation64.com/files/0.4/gap-0.5.tar.bz2
dummy audio plugin:
http://mupen64.emulation64.com/files/0.4/dummyaudio.tar.bz2
mupen64 audio plugin:
http://mupen64.emulation64.com/files/0.4/mupen64_sound.tar.bz2

Gfx plugins:
rice daedalus (an old version but that's the one that had best opengl support):
http://mupen64.emulation64.com/files/0.4/riceplugin.tar.bz2
Gln64 0.4.1:
http://mupen64.emulation64.com/files/0.4/glN64-0.4.1-rc2.tar.bz2
Glide64 0.7 ME SP1:
http://mupen64.emulation64.com/files/0.4/glide64_0_7_ME.tar.bz2
 

linemu

New member
When I run ./configure it tells me I have no working c compiler and exits! :mad: I know I have a c compiler... I've compiled the past releases, in fact most of the software I install now I compile from source. This is really weird. Any help would be fine......
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
Comment the c compiler test in the configure script and it should work... But i'm wondering why it's not detected on your system....
 

linemu

New member
I skipped ./configure and ran make, and it worked flawlessly! :D
p.s The glide64 port is COMPLETE AWESOMENESS!!!
 

wild-fuchs

New member
Hi, Hacktarux
I have download your programms but I can´t play.
It started but I see no text and pictures.
Please, can you explain me who I must put in the files when I will ply games.
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
Can you explain a little bit better what you have tried and what's happening ? Do u have tried the binary release ?
 

evangoav1111

New member
Segmentation fault

I just downloaded the new source code, and it compiled fine but when I try to run it it segmentation faults before it does anything. is this because I haven't tried to compile the plugins?
-------------------------------
I fixed it by recompiling and installing it for the individual user, but it's strange that it didn't work. also, is there a way to make gcc use shared libs but use them like static libs, the best example of this I can find is something like prelink.
 
Last edited:

evangoav1111

New member
glide64

I also get this problem when trying to compile glide64 . . .

In file included from wrapper/textures.cpp:9:
wrapper/main.h:19: `void (*glActiveTextureARB)(unsigned int)' redeclared as
different kind of symbol
/usr/X11R6/include/GL/gl.h:2041: previous declaration of `void
glActiveTextureARB(unsigned int)'
wrapper/main.h:20: `void (*glMultiTexCoord2fARB)(unsigned int, float, float)'
redeclared as different kind of symbol
/usr/X11R6/include/GL/gl.h:2053: previous declaration of `void
glMultiTexCoord2fARB(unsigned int, float, float)'
make: *** [wrapper/textures.o] Error 1
 

GameboyHippo

New member
When I compiled blight's input plugin, I had to change a line of code from SDL_ttf.c
If I remember correctly, it was at line 42 I commented out that line and added the following.

#include <ft2build.h>
#include FT_FREETYPE_H

Using the origional source it would throw the following error:

In file included from SDL_ttf.c:42:
/usr/include/freetype2/freetype/freetype.h:20:2: #error "`ft2build.h' hasn't been included yet!"
/usr/include/freetype2/freetype/freetype.h:21:2: #error "Please always use macros to include FreeType header files."
/usr/include/freetype2/freetype/freetype.h:22:2: #error "Example:"
/usr/include/freetype2/freetype/freetype.h:23:2: #error " #include <ft2build.h>"
/usr/include/freetype2/freetype/freetype.h:24:2: #error " #include FT_FREETYPE_H"


Hopes this helps someone in the future. :8)
 

jdratlif

New member
Compiling in Windows...

Would like to compile under Windows. I didn't notice any instructions.

Do I use mingw? cygwin? djgpp? MSVC?

The configure script did not work under mingw, and just calling make failed.

There is no program tempfile in mingw. Don't know where that comes from. I have the libSDL for mingw development installed. Also zlib and libpng.

Didn't notice any Makefiles but for Linux and BeOS.

Any suggestions would be much appreciated.
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
jdratlif said:
Would like to compile under Windows. I didn't notice any instructions.

Do I use mingw? cygwin? djgpp? MSVC?

The configure script did not work under mingw, and just calling make failed.

There is no program tempfile in mingw. Don't know where that comes from. I have the libSDL for mingw development installed. Also zlib and libpng.

Didn't notice any Makefiles but for Linux and BeOS.

Any suggestions would be much appreciated.

You should use DEV-C++. Open the .dev file that's stored in winproject folder with this software.
 

jdratlif

New member
Hacktarux said:
You should use DEV-C++. Open the .dev file that's stored in winproject folder with this software.

Thanks, but I've run into another problem.

gcc.exe -c ../main/win/configdialog.c -o ../main/win/configdialog.o -I"C:/Dev-Cpp/include" -I"C:/MinGW/include" -I"zlib" -D__WIN32__ -DX86 -DVCR_SUPPORT -fomit-frame-pointer -fexpensive-optimizations -O3 -march=athlon -msse
../main/win/configdialog.c: In function `CreateTrackbar':
../main/win/configdialog.c:884: `TBS_TOOLTIPS' undeclared (first use in this function)
../main/win/configdialog.c:884: (Each undeclared identifier is reported only once
../main/win/configdialog.c:884: for each function it appears in.)
make: *** [../main/win/configdialog.o] Error 1

I thought this might have something to do with the windows.h header as it looks like a Windows thing. But I stuck my VS .NET include path in there (first and then last in the includes), and it didn't help matters.

I didn't use the mingw with Dev-c++ as I already had it installed. I even upgraded to the "curent" gcc and w32 api and headers. This has made no difference.

Any suggestions?

Thanks...
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
well... if it doesn't work with your compiler, just delete this flag, it's not important. Btw, why do you need to compile it ?
 

jdratlif

New member
Hacktarux said:
well... if it doesn't work with your compiler, just delete this flag, it's not important. Btw, why do you need to compile it ?

I want to modify mupen to do auto-incremented save states like in ZSNES.

When you press F5, it increments the save slot, then saves. Rather than saves to the same save slot.

In addition, I would like to have it print a message on the screen saying that it saved to slot X.

These will of course be options. Since I primarily use Windows, I want to modify the Windows version. But if I can, I will make the change for Linux as well.

May I ask what compiler you use for Windows? I have Visual Studio .NET 2003 and mingw installed. I could grab cygwin if that's what you use. I would like to have the source compile correctly. It shouldn't need to have that flag commented out (right?), even if it adds little.

On another topic, I was reading your docs. I must say I take offense at these statements:

"We give you the source for Mupen64 for two major reasons, for your own reference (or help) and to aid us in the project. We don't want people taking the source, renaming the dialog, changing the GUI around and releasing it. Please honor the fact that we spend a lot of time toward the project and releasing a renamed Mupen64 is dishonest and detours the authors from ever releasing the emulator again. We trust you with the source; we trust you will use it honorably"

These statements lead me to believe you don't share a belief in the principles of the FSF or the GNU GPL which you have chosen for the project.

If this is indeed true, you might want to consider an alternative open source license. There are other licenses which will do the things you seem to want. Make the source available, but don't allow other people to modify or redistribute their modifications. People can always take your source and abuse it, but according to the terms of the license you used, renaming the dialog and releasing it is not abuse. It's one of the freedoms guaranteed by the license. I would agree this is shady, but it is perfectly legitimite within the terms of the GPL.

I seriously hope you don't take this step, as I highly value the GPL and the principles of the FSF, but this is not my work.

I love muen, as it is the only N64 emulator that works well in both Linux and Windows.

Note that I have no plans to release a renamed mupen. I also plan to contirbute my changes back to mupen so that others can benefit. This is why the GPL exists. To give people the freedom to make the changes to software that they value and then to release those changes back to other people.

I don't mean to offend you. I just have a very firm belief in free software and the principles of the FSF. I release almost all my software as GPL or BSD (only when the GPL is too restrictive).
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
I'm using the mingw version that's distributed with dev-c++. And yes you can remove the flag safely without losing anything, i think it was there because we though we would need it later, but it never happened.

For the GPL license, the key sentence of our help file is :"We trust you with the source; we trust you will use it honorably". And it was added because we've seen source code of GPL emulators not used honorably in the past... Freedom doesn't mean everything you're authorized to do is respectful... For example i don't care if large portions of my projects are copied in other ones, but i believe putting some words in the about box or somewhere else about what's used of the original project is morally required... even if the license doesn't require it. I like the concept of GPL license, and i think most people use it nicely, that was just a warning towards disrespectful people that we've seen regularly on the emulator scene.
 

jdratlif

New member
Hacktarux said:
I'm using the mingw version that's distributed with dev-c++. And yes you can remove the flag safely without losing anything, i think it was there because we though we would need it later, but it never happened.

For the GPL license, the key sentence of our help file is :"We trust you with the source; we trust you will use it honorably". And it was added because we've seen source code of GPL emulators not used honorably in the past... Freedom doesn't mean everything you're authorized to do is respectful... For example i don't care if large portions of my projects are copied in other ones, but i believe putting some words in the about box or somewhere else about what's used of the original project is morally required... even if the license doesn't require it. I like the concept of GPL license, and i think most people use it nicely, that was just a warning towards disrespectful people that we've seen regularly on the emulator scene.

Okay. Good to know. I hope you were not offended by my statements. I completely agree with your moral position.

Have you thought of distributing a gmakefile with it instead of requiring Dev-C++? I don't really care for it. I plan to write one so I can compile in mingw sans Dev-C++. I suppose it would be difficult if you use Dev-C++ to be forced to update a Makefile for every release.

May I have the patch you used to fix the save state bug in Mario 64? I would also like to have your Makefile.in and configure.ac (or configure.in files) so I could see if I could make configure work in mingw/msys.

Thanks.
 
Last edited:
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
For the save state bug, open main/win/main_win.c and search this line:
audio_info.AI_STATUS_REG = &(ai_register.ai_status);
replace it by:
audio_info.AI_STATUS_REG = &dummy;

I'm not using autoconf for this project. The configure script is only used to add optional stuffs to the linux gui, so it's totally useless for windows. I'd suggest compiling one time with dev-c++, it automatically generates a makefile that you can use with mingw. (the file is named Makefile.win and it's stored in the winproject folder)
 

jdratlif

New member
Hacktarux said:
For the save state bug, open main/win/main_win.c and search this line:
audio_info.AI_STATUS_REG = &(ai_register.ai_status);
replace it by:
audio_info.AI_STATUS_REG = &dummy;

I'm not using autoconf for this project. The configure script is only used to add optional stuffs to the linux gui, so it's totally useless for windows. I'd suggest compiling one time with dev-c++, it automatically generates a makefile that you can use with mingw. (the file is named Makefile.win and it's stored in the winproject folder)

For future source releases, could you also include the Makefile.win in the tarball? That would eliminate people's need for Dev-C++, while at the same time allowing them to use it if they choose.

Are you sure that's all you changed to fix the save state bug? When I recompile, I still get the bug. I also noticed that my uncompressed executable is 607 KB, while your fixed binary was 599 KB. There could be many reasons that account for this, but the relased binary was 610 KB. It seems like there have been changes since the source code you posted here. The version number for instance said 0.3.5 in Windows.

On another topic, I have created my patch for auto incremented save states. I have attached a win32 binary, linux binary, and the diff from the source tarball I downloaded off this message board.

I added your line to fix the save state bug, but it's not fixed in the binary. So my win32 binary still has the problem.

I haven't tested the Linux version with an actual game. I didn't have any plugins compiled. But the GUI changes work, and I'm all but certain that's all that matters since the win32 version tested fine on a game, and there are only GUI and Config changes for the Linux version which seem to work.

Unrelated, but included in my patch (because I'm anal and couldn't stand it) are fixes for all the "integer constant is too big for long value" warnings. I just appended ULL to all the big ones. I know, it doesn't make any difference. I just don't like warnings.

Finally, since the windows config is so different from the gtk config, I had to stick in a global pointer (and an extra variable in gtk) so that savestates.c didn't depend on how the config/GUI was implemented. This seemed like a poor solution, but I couldn't think of a better one. Maybe if I had a better understanding of the config and how it interacts with the core. Or maybe you will see what I did and have a better idea.

Well, I digress for now. I hope you add my patch to the next version of mupen. (and I also hope we get the savestate bug quashed too).

autoinc.diff.bz2 - the diff patch for the source
mupen64.bz2 - the linux binary (the binary is upx compressed)
mupen64.zip - the win32 binary (the binary is upx compressed -- don't know why that makes it lose the icon...)
 

Top