Mupen 64bit

[nmn]

This is a port of Mupen to 64-bit. It contains the port of glN64, RSP, Mupen64 Software Video, JttL's SDL Audio Plugin, Dummy Audio, Mupen64 Audio, Mupen64 Basic Input, And last but not least, the CPU and GUI. The glN64 port is VERY bad - It will get you through games like Kirby64 but it will quickly become corrupted on games like Mario 64 due to texture (cache?) bugs... Still plays, but with messed up textures. Sometimes you can use savestates to get around this.

--

Status:
Video - 80%, still buggy
Audio - 100%, flawless as far as i can tell
Input - 50%, blights plugin uses SDL_ttf, which will not build on my PC(improper truetype usage) so i could not do much to get it running
RSP - 100%, I can't find very much that could go wrong here because I'm not sure what it does.
CPU - 100%, Interpreter works excellently. DynaRec works exactly the same as it does already on Linux, Meaning not.
GUI - 99%, One little hack still somewhere...

--

I'll be trying to port Rice Video, but please help if you can. I really need it, after doing all of this work I'm beginning to lose my patience.

--

TO BUILD:
Edit Makefile with your favorite text editor... Enable the configuration you want by commenting the already in use configuration and uncommenting the one you want.

When your done, type make onto a terminal in the mupen directory.

OPTIMIZED BUILD IS NOT DEFAULT.
64-BIT BUILD IS DEFAULT.

[Tillmann]

Congrats man!
:D
it's nice to see mupen64 running under x64 :D

[nmn]

Thanks... I'll just be trying to port Rice which HOPEFULLY doesn't share the same issues with the newer GCCs that glN64 did. (If you look you'll notice some similar standards voilations in the source of Rice Video) Maybe Microsoft is to blame for MSVC being lenient on code it shouldn't be, I don't know. GCC is also to blame though, for having crap inline assembly. I wonder if i should just use ICC for Rice... Or try ICC for everything, considering how fast its made my code in the past... As much as i love GCC, ICC is more practical for porting code from MSVC. Too bad it doesn't do any cross-compiling or else it would be my compiler of choice... Well, Sometimes. For many of my projects, GCC is either more practical, Or its better because it would work and its Open Source.

[Tillmann]

Please try to rely on gcc if you can :D
It would be nice not only for portability but to the opensource community :D
Cheers and good luck!

[Hacktarux]

The dynarec has always worked on linux (x86 32 bits). I'm always testing with this core when developing and i'm sure many people are using it. So if it's not working on your system, i'd be very interested in your exact configuration: distro, glibc version, kernel version, kernel compilation options...

It is normal that it does not work on x64 architecture. The dynarec has to be rewritten for this target processor.

[nmn]

Weird, Everyone setup I have can't run with DynaRec, it just crashes. I just figured its broken in Linux like Assembly in glN64 and i didn't bother trying to porting it over.

Heres my setups:

Mupen64 Binary or from source, any version of GCC behaves the same from source.
Either a modified Gentoo (Sabayon) 64-bit distribution or OpenSuSE 10.0 32-bit distribution. My kernel is pretty messed up on 64-bit, but it seems to run OK. My other kernel is the stock OpenSuSE 10.0 32-bit kernel that came with it.

DynaRec seems to crash on all of the games I've tried: Super Mario 64, A whole crap load of Intros, Kirby 64, Some Puyo Puyo Game i have no idea why i have (probably accidentally picked it up when getting PDRoms from regular rompacks).

I'm gonna debug the issue sometime. I did once, but i failed to notice anything wrong.

[Richard42]

Hey, I'll help with the 64-bit port. I have a lot of experience in x86 and amd64 assembly language also, so maybe I can get the dyna-rec working natively in 64-bit mode. This is a cool project.

Should I start with the 6.1.0 Rice Video plugin source that was linked in another message, or is there something newer? Does your 64-bit port have any patches/fixes above mupen64 0.5?

Thanks.

[nmn]

Hey, I'll help with the 64-bit port. I have a lot of experience in x86 and amd64 assembly language also, so maybe I can get the dyna-rec working natively in 64-bit mode. This is a cool project.

Feel free to help, I'm only so good at assembly ATM... Just keep resubmitting changes and/or whole source packages (if you changed a lot) and I'll find a way to keep the fixes in sync. I'd do diffs, but that can get confusing without source control.


Should I start with the 6.1.0 Rice Video plugin source that was linked in another message, or is there something newer? Does your 64-bit port have any patches/fixes above mupen64 0.5?

Well, There is Mudlords awesome unofficial version if your feeling heroic ;) Theres alot of porting with it to do, but soon I'll submit a glade file for a configuration GUI, which should have equivalent naming.

https://ricevideo.bountysource.com/

Thats not ported to linux yet, though. I was trying to port it but i never came up with any good code because it makes extensive use of WGL code (Though i made an attempt to port that i hadn't finished yoet)

Anyways, yeah, anyone can submit code or full packs here and i'll adopt the code into any of my future versions if it works.

And BTW: Since this version works on both 32-bit and 64-bit, I think it would be OK if we tried to improve any of Mupens weak spots in the rare case that this code ever becomes official. I can tell you right now i wouldn't mind spending a few weeks writing some networking code ontop of Zoidcom or with a plugins system or something.

[Richard42]

Thanks for the link. I checked it out, and unfortunately Mudlord doesn't provide the source with the newer versions, so I guess I'll have to stick with 6.1.0.

I've attached a zip of some diffs off of the vanilla 0.5 source which provide screenshot capability in the glN64 driver - it requires libPNG, which means makefile changes. I didn't include a diff for the makefile because my makefile is set to build the 32-bit version on a 64-bit machine. If you want that, I can upload that too.

Richard

[nmn]

To get his source, use SVN. Its opensource.

edit: Almost forgot: https://svn.bountysource.com/ricevideo/trunk

You can use your svn utility with that.

[niteice]

First off, thanks for providing this groundwork, it's incredible to actually be able to emulate n64 (well) on my box. Unfortunately, there seems to be a nasty bug in glN64 - the same texture is used on almost all polygons:

http://i24.tinypic.com/9sw9rq.png

http://i22.tinypic.com/smrtw8.png

If it matters, I used GCC 4.1.2, but also have ICC 10 available.

[nmn]

Unfortunately, I can not pin point the source of the above bug. I suppose it has to do with texture caching. Its a well known bug, though. It effects games less when they use less textures, but you'll still find most n64 scene intros that worked before biting the dust.

[niteice]

Ah OK, I thought it was related to the 64-bit code.

[nmn]

Well, It appears to be related to the very few changes in GCC. After i solved my byte swap problems, i noticed that textures were mixed, but it would take some debugging that I'm not up to in order to find the exact roots of the problem... I should really work on Rice Video, but it has assembly code, which makes the default code sometimes not work and is usually not the most efficient after porting.

[Richard42]

Well, It appears to be related to the very few changes in GCC. After i solved my byte swap problems, i noticed that textures were mixed, but it would take some debugging that I'm not up to in order to find the exact roots of the problem... I should really work on Rice Video, but it has assembly code, which makes the default code sometimes not work and is usually not the most efficient after porting.

Tell you what; this weekend I'll spend a day and port all of the assembly to 64-bit. I looked around and it doesn't seem to be too much. You'll need to install YASM to assemble the 64-bit code. The stuff which isn't MMX/SSE2 is pointless; I'll convert it to C or verify any existing C code. I can post it here or PM me with your email address.

[nmn]

That sounds great... Love to see that.

And as for where to put it, just put it up on here.

[Richard42]

Hello NMN,

I have ported the ricevideo-6.1.0 plugin to the 64-bit architecture, and also worked on your port of mupen64 itself. The zips are attached here, but I have opened also up an SVN server, the URL of which is:

svn://fascination.homelinux.net:7684/mupen64-amd64/trunk/

The svn login is 'mupen64', and the password is 'Dyson5632-kart'. Anyone who feels qualified is welcome to commit fixes or improvements, providing that you also write a good commit log message.

So, the RiceVideo port was fairly straightforward – I changed the data types as necessary and re-wrote the assembly code. I found a couple of notable things in this code. The assembly stuff was fairly messy; I deleted some of it and replaced with straight C code, and ported the rest. The changes which I made to the RiceVideo vanilla build should be portable, and it should still build just fine in both Windows and 32-bit Linux, though I didn't test this. If you use this video plugin with a different version of Mupen than what I've put here, you should make sure that the data types in the GFX_INFO structure in 'winlnxdefs.h' are the same as in your version of Mupen. Otherwise it may hang or GPF. Also, you must have the RiceVideo6.1.0.ini file in a subdirectory called 'plugins' relative to the location of the executable. Otherwise it may throw a bunch of GTK warnings and crash.

I made some modifications to Mupen64 also. I started with the vanilla 0.5 source which I had earlier patched for saving PNG files from the glN64 plugin. Then I merged in most of your changes for the 64-bit port. I did it a little differently though. To avoid having a definition for the int64 type, I used 'long long' everywhere for 64-bit integers. This will work on both 32-bit and 64-bit systems. There were a couple of discrepancies that I saw while merging, and I don't know if your code was newer or if mine was newer, so this is something that remains to be resolved.

I modified the makefile to add the 'SDL_ttf' library to the build, so that the blight input plugin would link, because the Mupen one doesn't recognize my joystick. It built, but crashed upon startup. I debugged it and found the cause to be that the SDLK_* enum consists of all positive numbers, and in this case the compiler forces the enum to be an unsigned int. One of the SDL routines was returning a -1 for this value, causing an array to be indexed by 2^32-1, and crash. I fixed this and now the blight input plugin works, so I was able to really play some N64 games in 64-bit on the PC! Super Mario 64 looked very good and ran at full speed with the Interpreter on my Athlon64 3800x2. Mario Kart 64 reveals that there is still a porting issue in the RiceVideo plugin – sometimes the polygons in the road flash gray.

There are a lot of little things that need to be fixed or cleaned up in this source code. I'll try to get a few more things done on this in the next week or so. The ultimate goal is to port the dynamic recompiler, but that could be a big project. :)

Richard

[nmn]

_WOW_

Thats extremely good. Man. You should be the one leading me.

[Richard42]

_WOW_

Thats extremely good. Man. You should be the one leading me.

Thanks. :) I write software for a living; I love it. The nice thing about open source is getting such a huge base of high quality software for free, which others have poured so much time and effort into. Now it's my turn to give back and get involved too.

Having a source control repository is very important for working together and making controlled progress. Sending zip files doesn't scale. I just hope others will take advantage of this and contribute; using SVN is a piece of cake. There are a lot of little things which need to be fixed: the printout of the selected plugins is incorrect, the program segfaults when exiting about half the time, the command-line options and config file stuff is all messed up. I looked at the SVN commits on Mudlord's server for Rice Video since 6.1.0; there are only about 5 of them that are relevant, so they could easily be merged.

We could make the 64-bit port just as good as the 32-bit one. The AMD64 instructions are extremely advantageous for the performance of this emulator; 64-bit is the way to go.

[nmn]

Yes. I write software as a hobby ATM. I'm only in high school right now, but i highly support Open Source Software and the ability to also sell the products for a nominal fee (Of course alongside the source being free, Kinda like Crossover office and nothing like Cedega who just don't understand).

SVN rocks, glad you have a server up for it.

Also, since our port goes backwards, I believe that we should attempt to improve the emulator beyond the core. I think we should try to improve it GUI wise, and feature wise, too. Kaillera seems to be in the windows build. It shouldn't be too hard to have that code ported to a library like Zoidcom or POSIX networking (Not SDL_net, but only because SDL_net is blocking only and its not thread safe either.)

So I have a question: You agree we should try to improve it too?
And also, as a side question: about removing int64. I know that using long long is safe. The point here is that C and C++ don't define the sizes of the types. This leaves a large problem: Architectures, even in other little-endian ones, won't be guaranteed to have the same type sizes... ARM comes to mind... Shouldn't we try to make all of the basic types customizable? Or is there another way? And this makefile dislikes my computer. It picks the wrong libs. I'll modify my pkgconfig files later on and see if i can fix that.

[Richard42]

I do agree that we should improve the emulator. I haven't yet tested my SVN server from outside my home network so I'm not 100% sure that the port forwarding is working, but once it's set up right this will give us a practical way of working together.

I'm using mupen64 as part of a larger video game museum that I'm building; as a part of this project I have my own GUI written in python with pygame. So I'm really only interested in the 'nogui' build of mupen64 and its integration into this system. You're welcome to commit GUI improvements to the repository, however. If you want to make big changes that may break people's builds or take time to stabilize, we can make a branch to work on until it's ready to go back into the trunk. Most of the work that I plan to do will be fixing little bugs/annoyances and hunting down the remaining porting bugs. Maybe I'll do the dynamic recompiler some day too, because that's cool technology.

The best pattern that I've found for dealing with data types in a cross-platform way is to have a system/typedef header file where you define custom types like 'Int'/'Short'/'Char', or 'u32'/'s32'/'u64'/'s64'/etc. And then replace _all_ of the standard C/C++ types with the custom types in the code. This might be a worthwhile thing to do for mupen64, but it will be tedious. You would have to define a special Int-which-is-the-same-size-as-a-pointer type, in order to handle the code which does XOR on pointers for byte swapping. The only issue I see with applying this type handling to mupen64 is the plugins. It wouldn't be very clean to just copy this header file into all of the plugin sub-projects. To do it right would require having some common header file(s) which are shared between mupen64 and the plugin projects.

Richard

[MIO0]

There is a standard header file (stdint.h) that contains typedefs for fixed sized integers, and even a typedef for an integer that is the same size as a pointer. I used it to make myself a 64 bit copy of Mupen, but it really isn't suitable for release as I ripped out the recompiler.

My local 64 bit copy of glN64 works well. I'll see if I can get it working with the SVN code, but I have another project I need to finish first.

[Richard42]

There is a standard header file (stdint.h) that contains typedefs for fixed sized integers, and even a typedef for an integer that is the same size as a pointer. I used it to make myself a 64 bit copy of Mupen, but it really isn't suitable for release as I ripped out the recompiler.

My local 64 bit copy of glN64 works well. I'll see if I can get it working with the SVN code, but I have another project I need to finish first.

Using stdint.h would be a good solution too. We could include that and replace all of the 'long long's with int64_t; that wouldn't be too hard.

It would be great if you could help with the glN64 plugin. It works okay but exhibits the texture problem which was illustrated earlier in this thread.

[kdubya]

Is yalls port of rice's plugin a port of hackatrix's port, or the latest version of rice?

[Richard42]

Is yalls port of rice's plugin a port of hackatrix's port, or the latest version of rice?

This port was based on the Linux source which Hacktarux ported from Rice v6.1.0. A couple of days ago I looked through all of the SVN commit logs between v6.1.0 and now on Mudlord's SVN server, and it looks like there have only been a few changes in-between then and now. Later this week I may merge these changes into our 64-bit port.

[nmn]

!!!ABOUT THE GLN64 PLUGIN PROBLEMS!!!

They are GCC induced. The updates to GCC made it incompatible. Well, Okay, I think. When compiling to 32-bit with my old code it had the same problems.

[_Zack_]

This project sure is getting interesting :D

Keep up the great work guys :)

[nmn]

Leaving the note, my GCC is broken and therfore it may be a while before i commit anything... sry.

[Richard42]

!!!ABOUT THE GLN64 PLUGIN PROBLEMS!!!

They are GCC induced. The updates to GCC made it incompatible. Well, Okay, I think. When compiling to 32-bit with my old code it had the same problems.

I compiled a 32-bit build (mupen64 v0.5) with GCC 4.1.2 (64-bit binary, cross-compiling) on my HTPC box with Fedora 8 test 3, and it does not exhibit this problem. The 64-bit port I did on my desktop box which is Gentoo, also using GCC 4.1.2, and the port exhibited the problem.

Does anybody know the differences between glN64 and RiceVideo? I think I should focus my work on one of the other. It seems to me like glN64 actually looks a bit better (no gaps between polygons in mario's face at startup, for instance). Are either of these plugins compatible with more games than the other? That's the most important factor for me.

[_Zack_]

I compiled a 32-bit build (mupen64 v0.5) with GCC 4.1.2 (64-bit binary, cross-compiling) on my HTPC box with Fedora 8 test 3, and it does not exhibit this problem. The 64-bit port I did on my desktop box which is Gentoo, also using GCC 4.1.2, and the port exhibited the problem.

Does anybody know the differences between glN64 and RiceVideo? I think I should focus my work on one of the other. It seems to me like glN64 actually looks a bit better (no gaps between polygons in mario's face at startup, for instance). Are either of these plugins compatible with more games than the other? That's the most important factor for me.

Rice would be the most compatible imo.

[kdubya]

I like rice because it allows you to specify any resolution you want, and the way I have my HTPC set up there is no way to use any resolution other than my screwy one of 1240x702 without going into nvidia-settings. It also does high resolution texture packs, which are awesome.

Problem is mario kart flickers under rice and not glN64. A man has to have his mario kart. This was why I asked if you used the same version of rice as Hacktarix, I think the flickering is caused by some frame buffering issues in older versions of rice.

[nmn]

I haven't read to see if theres more to this convo on page 3, but the flicker bug may be fixable in various ways* (I experienced the same problem in various intros, Mario at some points, and Kirby64 during cinematics or decently heavy loads of polygons, even with 1964 under Wine with Rice)

In nvidia-settings:
- Try turning Vsync on and off. Yeah, I'm not kidding the least bit. You wouldn't even believe how sometimes this fixes the worst of problems.

In Rice:
- Try setting the pergame settings around - for some reason i could get certain games to not flicker 0_o
- In 1964 changing the counter factor worked for getting Wine to not flicker with Rice Video. (Interestingly, this leaves me to believe the flicker is a GLX or NVidia driver bug) Theres an equiv sitting somewhere in Mupen or Rice, i believe, but if not, you can probably find something similar enough.

*This list is definitely very incomplete.

--
-About the glN64 problems:

Maybe 64-bit induced. Not sure anymore. I need to get a new compiler, and well, I'm on Gentoo, so upgrading GCC means i need GCC which means I'm SOL. But I've ruined this installation enough, time to test another distros length of life.

-About Rice vs glN64:

Rice wins in compatibility by a long shot (Well, at least I'm pretty sure at least for frame buffer effects if nothing else) glN64 seems to get some things that Rice doesn't (which genuinely took me by surprise) but i don't remember it actually surpassing it at any point. I was especially surprised by some of the effects it understood which were likely not well written ones (on the game developers part)

And I'm downloading a new distro to handle my GCC problems. I'll try to port the GUI to Qt4, improve the makefile a bit, and have some new features in (Perhaps a special version of the graphics plugin API that calls special emulator functions to handle the GL context, leaving us the ability to have graphics appear in the emulator GUI in Mupen64 for Linux, something that would normally be a major problem to do.)

[i23098]

Hi,

Is there a chance to provide a amd64 compiled build, so I could just untar/unrar/unzip :freak: and execute it? :huh: :saint:

For some reason I can't compile the source code :cry: :stupid:

Can't wait for 0.6 official release :party:

Keep up the great work :D

[Richard42]

No worries i23098,

I'm going to make a tag hopefully in the next week or so with a bunch of fixes and I'll provide 32-bit and 64-bit binary packages as well as the source. I fixed a crash in Rice Video for Carmaggedon tonight. The full-screen textures look weird but the game is playable now.

Richard

[sl1pkn07]

i have a problem with RiceVideo-6.10-64bits

sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn/ricevideo610-64bit$ ./configure
Found a working C compiler (gcc).
Found a working C++ compiler (g++).
Checking SDL...
./config.temp: 3: Syntax error: "(" unexpected
*** Couldn't find a working SDL library!
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn/ricevideo610-64bit$

i have all SDL library installed. im used kubuntu 7.10 Gutsy 64Bits

[Richard42]

i have a problem with RiceVideo-6.10-64bits

Checking SDL...
./config.temp: 3: Syntax error: "(" unexpected
*** Couldn't find a working SDL library!
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn/ricevideo610-64bit$

i have all SDL library installed. im used kubuntu 7.10 Gutsy 64Bits

This is another example of the configure file not failing gracefully. Your problems is that you also need to have the SDL development packages in order to compile the application. This contains the header files. You'll also need the GTK development packages while you're at it.

[sl1pkn07]

o rly? XD

http://sl1pkn07.no-ip.com/imagenes/sdl.png

[Richard42]

Okay, so it looks like you have the dev packages. If there is a real issue with the path to the SDL header files you could get more debugging information by doing an "sdl-config --cflags" and looking at the config.log file. But if it's just that the configure script is broken because it does weird shit like compiling an executable into the same file as the source that it came from, then this would be a waste of time.

I would just ignore the 'configure' file - it's hosed and you don't need it anyway. Extract the 'config.h' file from the original archive to make sure that it didn't get overwritten and just run 'make'. If the build breaks on SDL_Init() or other SDL functions then you'll know that your system has an actual problem.

[Richard42]

o rly? XD


One more thing to watch out for: I'm not sure about Ubuntu 7.10, but in the Fedora repository there are separate <tool>-devel packages for 32-bit and 64-bit development. For some tools they cannot be installed at the same time, so you have to make sure you have the right one installed.

It looks like what's happening for you is that the compile is failing and the test source code is being marked executable and running as a script, and the shell interpreter is throwing that 'Syntax error: "(" unexpected' error. The config.log file should tell you why it failed to compile.

[kdubya]

I finally got around to compiling this...

Mupen compiled with no effort, installed it and it works perfectly.

I had some trouble getting the rice plugin to compile at first but it was just that the configure script does not detect the gtk2 development packages if you are in a remote shell. It worked fine when I was actually on the machine.

Once I got rice compiled... I cannot get rice to work at all for about 75% of the games I tried (probably tried about 30 of them). Most games just segfault immediately. For the few that actually do something, I was only able to play 2 of them, Excite Bike and some other random racing game. Some games would show the company logos and then segfault right before the main menu and others would die when I tried to start gameplay. Nothing interesting was output.

Are there any debugging flags I could use so I could provide you with something useful? I am running 32 bit Fedora 7, and I am using the nvidia drivers from the livna repos

[Richard42]

I finally got around to compiling this...
Mupen compiled with no effort, installed it and it works perfectly.

I had some trouble getting the rice plugin to compile at first but it was just that the configure script does not detect the gtk2 development packages if you are in a remote shell. It worked fine when I was actually on the machine.

Once I got rice compiled... I cannot get rice to work at all for about 75% of the games I tried (probably tried about 30 of them). Most games just segfault immediately. For the few that actually do something, I was only able to play 2 of them, Excite Bike and some other random racing game. Some games would show the company logos and then segfault right before the main menu and others would die when I tried to start gameplay. Nothing interesting was output.

Are there any debugging flags I could use so I could provide you with something useful? I am running 32 bit Fedora 7, and I am using the nvidia drivers from the livna repos

Don't worry about the previously-posted Mupen64 and RiceVideo source; I've fixed a bunch of bugs since then. I'm going to make a release tonight of the latest in my SVN repository. I'm hoping that people will download and play with this new release; if you find problems with it (I'm mostly interested in segfaults), just tell me what game you were playing and what you were doing when it crashed. If I can duplicate any segfault I can probably fix it. It's much harder for me to fix things like display problems (ie, Star Wars Ep 1 racer) because that's a result of the emulator not accurately emulating the real N64 system. Without technical documentation for the N64 itself there's no way that I can tell what is correct or incorrect behavior. :)

[kdubya]

Well i was using rev 50 from your SVN. Look forward to the release.

[sl1pkn07]

ricevideo-64bits

sdl-config --cflags
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT

sl1pkn07@SpinFlo:/ cat /home/sl1pkn07/aplicaciones/mupen64-64bits-svn/ricevideo610-64bit/config.log
lun nov 12 11:42:09 CET 2007
./config.temp: En la función ‘main’:
./config.temp:3: error: falta carácter terminando "
./config.temp:4: error: falta carácter terminando "
./config.temp:4: error: expected expression at end of input
./config.temp:4: error: expected declaration or statement at end of input
./config.temp:4: error: expected declaration or statement at end of input
sl1pkn07@SpinFlo:/etc/fonts/conf.d$

mupen64-64bits

compile options: make all GTK=20 (for compilling a 64bit binary)
make results:

......
gcc -o r4300/x86/gr4300.o -Wall -pipe -O3 -march=athlon64 -ffast-math -funroll-loops -fexpensive-optimizations -fno-strict-aliasing `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c r4300/x86/gr4300.c
r4300/x86/gr4300.c: En la función ‘gennotcompiled’:
r4300/x86/gr4300.c:60: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gendebug’:
r4300/x86/gr4300.c:83: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gencallinterp’:
r4300/x86/gr4300.c:104: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genj’:
r4300/x86/gr4300.c:219: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genj_out’:
r4300/x86/gr4300.c:244: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genjal’:
r4300/x86/gr4300.c:299: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genjal_out’:
r4300/x86/gr4300.c:331: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gentest’:
r4300/x86/gr4300.c:438: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:446: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gentest_out’:
r4300/x86/gr4300.c:478: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:487: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gentestl’:
r4300/x86/gr4300.c:999: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1008: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gentestl_out’:
r4300/x86/gr4300.c:1041: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1051: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genlb’:
r4300/x86/gr4300.c:1320: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1322: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genlh’:
r4300/x86/gr4300.c:1360: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1362: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genlw’:
r4300/x86/gr4300.c:1405: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1407: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genlbu’:
r4300/x86/gr4300.c:1444: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1446: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genlhu’:
r4300/x86/gr4300.c:1486: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1488: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genlwu’:
r4300/x86/gr4300.c:1533: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1535: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gensb’:
r4300/x86/gr4300.c:1575: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1596: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1596: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1601: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1601: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gensh’:
r4300/x86/gr4300.c:1632: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1653: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1653: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1658: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1658: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gensw’:
r4300/x86/gr4300.c:1694: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1714: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1714: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1719: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1719: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genlwc1’:
r4300/x86/gr4300.c:1781: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genldc1’:
r4300/x86/gr4300.c:1820: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genld’:
r4300/x86/gr4300.c:1865: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1867: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘genswc1’:
r4300/x86/gr4300.c:1908: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1928: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1928: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1933: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1933: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gensdc1’:
r4300/x86/gr4300.c:1966: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1988: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1988: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1993: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:1993: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c: En la función ‘gensd’:
r4300/x86/gr4300.c:2026: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:2048: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:2048: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:2053: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gr4300.c:2053: aviso: conversión de puntero a entero de tamaño diferente
gcc -o r4300/x86/gregimm.o -Wall -pipe -O3 -march=athlon64 -ffast-math -funroll-loops -fexpensive-optimizations -fno-strict-aliasing `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c r4300/x86/gregimm.c
gcc -o r4300/x86/gspecial.o -Wall -pipe -O3 -march=athlon64 -ffast-math -funroll-loops -fexpensive-optimizations -fno-strict-aliasing `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c r4300/x86/gspecial.c
r4300/x86/gspecial.c: En la función ‘genjr’:
r4300/x86/gspecial.c:167: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:167: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:169: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:169: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:171: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:171: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:201: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:215: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:219: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:222: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c: En la función ‘genjalr’:
r4300/x86/gspecial.c:236: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:236: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:238: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:238: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:240: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:240: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:276: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:290: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:294: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/gspecial.c:297: aviso: conversión de puntero a entero de tamaño diferente
gcc -o r4300/x86/gtlb.o -Wall -pipe -O3 -march=athlon64 -ffast-math -funroll-loops -fexpensive-optimizations -fno-strict-aliasing `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c r4300/x86/gtlb.c
gcc -o r4300/x86/regcache.o -Wall -pipe -O3 -march=athlon64 -ffast-math -funroll-loops -fexpensive-optimizations -fno-strict-aliasing `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c r4300/x86/regcache.c
r4300/x86/regcache.c: En la función ‘free_register’:
r4300/x86/regcache.c:78: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c:78: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c: En la función ‘lru_register’:
r4300/x86/regcache.c:135: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c:137: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c: En la función ‘lru_register_exc1’:
r4300/x86/regcache.c:150: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c:152: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c: En la función ‘allocate_register’:
r4300/x86/regcache.c:203: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c:205: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c: En la función ‘allocate_register_w’:
r4300/x86/regcache.c:371: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c:373: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c: En la función ‘build_wrapper’:
r4300/x86/regcache.c:790: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/regcache.c:808: aviso: conversión de puntero a entero de tamaño diferente
gcc -o r4300/x86/rjump.o -Wall -pipe -O3 -march=athlon64 -ffast-math -funroll-loops -fexpensive-optimizations -fno-strict-aliasing `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c r4300/x86/rjump.c
r4300/x86/rjump.c: En la función ‘dyna_jump’:
r4300/x86/rjump.c:41: aviso: conversión de puntero a entero de tamaño diferente
r4300/x86/rjump.c:43: aviso: conversión de puntero a entero de tamaño diferente
......

compile OK

crash by segfault on config blight's SDL input plugin 0.0.10 (pulse button config on options menu)

compile options: make all BITS=32 GTK=20 (for compilling a 32bit binary)
make results:

.......
gcc main/adler32.o main/ioapi.o main/md5.o main/mupenIniApi.o main/plugin.o main/rom.o main/savestates.o main/unzip.o memory/dma.o memory/flashram.o memory/memory.o memory/pif.o memory/tlb.o r4300/r4300.o r4300/bc.o r4300/compare_core.o r4300/cop0.o r4300/cop1.o r4300/cop1_d.o r4300/cop1_l.o r4300/cop1_s.o r4300/cop1_w.o r4300/exception.o r4300/interupt.o r4300/profile.o r4300/pure_interp.o r4300/recomp.o r4300/special.o r4300/regimm.o r4300/tlb.o r4300/x86/assemble.o r4300/x86/debug.o r4300/x86/gbc.o r4300/x86/gcop0.o r4300/x86/gcop1.o r4300/x86/gcop1_d.o r4300/x86/gcop1_l.o r4300/x86/gcop1_s.o r4300/x86/gcop1_w.o r4300/x86/gr4300.o r4300/x86/gregimm.o r4300/x86/gspecial.o r4300/x86/gtlb.o r4300/x86/regcache.o r4300/x86/rjump.o main/gui_gtk/main_gtk.o main/gui_gtk/translate.o main/gui_gtk/messagebox.o main/gui_gtk/aboutdialog.o main/gui_gtk/configdialog.o main/gui_gtk/support.o main/gui_gtk/rombrowser.o main/gui_gtk/romproperties.o main/gui_gtk/config.o main/gui_gtk/dirbrowser.o -m32 -m elf_i386 -lz -lm -lpng `sdl-config --libs` -L/usr/X11R6/lib -lGL `pkg-config gtk+-2.0 --libs` -Wl,-export-dynamic -z execstack -lpthread -ldl -o mupen64
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libpng.so when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libpng.a when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libpng.so when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libpng.a when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libpng.so when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libpng.a when searching for -lpng
/usr/bin/ld: cannot find -lpng
collect2: ld devolvió el estado de salida 1
make: *** [mupen64] Error 1

libpng + libpng-dev (64bits) (1.2.15-beta5) + ia32-libs + ia32-libs-dev (32bits)(2.1) installed
zlib + zlib-devel + zlib-bin (64bits) + lib32z1+lib32z1-dev (32bits)(1.2.3.3) installed
libc6 + libc6-devel (64bits) + libc6-386 + libc6-386-devel (32bits)(2.6.1) installed

mupen64-64bit and ricevideo610-64bit downloading from SVN (rev50)

[Richard42]

Well i was using rev 50 from your SVN. Look forward to the release.

I'm in the middle of putting things together for release right now. I'm surprised you got RiceVideo to work for a 32-bit build with any games at all. I found a couple of problems - one was in Mupen64: a segfault caused any time it would try to write the EEPROM to a directory without permissions.. There was another one that was even worse - the SSE code in RiceVideo would crash in SSEVec3Transform. I didn't even try to debug that one because the Position Independent Code was way more complicated than it was worth, so I nuked it and replaced it with inline AT&T style asm derived from the 64-bit stuff I wrote a month ago. Hopefully the release will work better for you. :)

[Richard42]

@sl1pkn07:

Glad to see that other people are using the SVN repository as well. The fact that you were able to build without the 'configure' script proves that it was a problem with the script and not your system; that's good.

Regarding your 64-bit build; that appeared to work, which is great. Were you able to run any games? I gather that you hit a segfault when you tried to do the 'pulse button config' on the options menu? That's probably a legitimate bug which needs to be added to the Todo list.

Your 32-bit build failed because the compiler didn't find a 32-bit version of a file called "libpng.a". It skipped over several incompatible versions of this file; they were 64-bit versions. The libpng.a file is a 'stub' static library which contains the necessary dlopen/dlsym/dlclose code to handle the dynamically loaded stuff. It's not surprising that the compiler couldn't find it - the bugs aren't all worked out of these systems yet. I would suggest trying the 32-bit release that I'll hopefully make later tonight, though I assume that the earlier bug which you found will still be present.

[sl1pkn07]

i found error (and fix) in configure script on ricevideo plugin:

before:

echo "int main(void) { if (SDL_Init( 0 ) < 0) { printf( \"SDL_Init(): %s\\n\", SDL_GetError() ); return 1; } return 0; }" >> "$FILE"

after:

echo "int main(void) { if (SDL_Init( 0 ) < 0) { printf( \"SDL_Init(): %s\", SDL_GetError() ); return 1; } return 0; }" >> "$FILE"

sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn/ricevideo610-64bit$ ./configure
Found a working C compiler (gcc).
Found a working C++ compiler (g++).
Checking SDL...
Found SDL version 1.2.11.
Checking GTK 1.2...
Found GTK version 1.2.10.
Checking GTK 2...
Found GTK version 2.12.0.
Your system support both GTK 1.2 and GTK 2, do you want to compile mupen64 with GTK 2 support ?
(Y)es or (N)o [Default is Yes]: y
Mupen64 will use GTK 2

Writing config.h...
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn/ricevideo610-64bit$

compile plug in OK (no warnings and no message)

Version SVN= 80

mupen64-64bit: fail build

gcc -o main/gui_gtk/configdialog.o -Wall -pipe -O3 -march=athlon64 -ffast-math -funroll-loops -fexpensive-optimizations -fno-strict-aliasing `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c main/gui_gtk/configdialog.c
make: *** No hay ninguna regla para construir el objetivo `main/gui_gtk/support.o', necesario para `mupen64'. Alto.

[Richard42]

gcc -o main/gui_gtk/configdialog.o -Wall -pipe -O3 -march=athlon64 -ffast-math -funroll-loops -fexpensive-optimizations -fno-strict-aliasing `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c main/gui_gtk/configdialog.c
make: *** No hay ninguna regla para construir el objetivo `main/gui_gtk/support.o', necesario para `mupen64'. Alto.

Sorry about that. The Makefile got broken in SVN, which caused that error. I've fixed it now, so you can do an update and it should build.

BTW Good call on the configure script. The escape characters to make a newline didn't work right in your shell. I'll update the copy in SVN also.

[nmn]

Whoops sorry bout the makefile, forgot to update that when i did away with ugly pixmaps... Also, I haven't gotten the CD stuff down because i was improving a couple of other things. The only thing i've decided worked better improved was the Rom List, which now has scroll bars on it... This means it should not stretch the configuration window out when you add a very large directory name to your list. If theres any problems with that let me know and i can try to trace them, but i'm pretty sure that not much can go wrong with it.

Oh, and yeah, that whole configure script thing was one we'd never had noticed.

[Richard42]

Oh, and yeah, that whole configure script thing was one we'd never had noticed.

I tested that on my machine, before and after making the change which fixed it for sl1pkn07. Oddly enough, the original source didn't cause a problem for me, so he must have a different version of BASH or a different shell. This is one of the reasons why open source is so awesome; we can all contribute and make it better for everyone. All of you guys testing this thing and reporting bugs are just as important as us programmers fixing them, because you can't fix what you don't know is broken. :)

[sl1pkn07]

sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn/mupen64-64bit$ yakuake --version
Qt: 3.3.7
KDE: 3.5.8
Yakuake: 2.8
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn/mupen64-64bit$ bash --version
GNU bash, version 3.2.25(1)-release (x86_64-pc-linux-gnu)
Derechos Reservados (C) 2005 Free Software Foundation, Inc.
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn/mupen64-64bit$

OpenSource POWA! XD