The same exact plugin?
Mupen64Plus for Windows
- Thread starter nmn
- Start date
The same exact plugin?
Danny
Programmer | Moderator
Afaik yes. There both mudlords builds of rice video. Il see if i can get the versions for you
Edit : Yep defiantly identical version
Both are 6.1.4
The versions don't matter, it's the actual code. Try swapping them... I think we fixed this in the Linux version... nmn has to confirm this though
Hmmm...
On another note, I updated the first post to reflect a mirror since our first one went out of bandwith.
Thanks.
- Thread Starter
- #28
In this build we are currently using some of the Binary versions for some of the Windows plug ins. Several reasons:
- Mupen64Plus's Rice Video will never have DirectX support.
- Because they don't build for Windows just yet (It's mostly an OpenGL extension problem, GL programmers will know about this.)
Thanks for mirroring this, MasterPhW and okaygo. I really should had mirror'd it to a few places, but I had no idea it would get enough attention to knock it down in a day.
- Mupen64Plus's Rice Video will never have DirectX support.
- Because they don't build for Windows just yet (It's mostly an OpenGL extension problem, GL programmers will know about this.)
Thanks for mirroring this, MasterPhW and okaygo. I really should had mirror'd it to a few places, but I had no idea it would get enough attention to knock it down in a day.
I was actually wondering where you got this from (besides the Mupen source code - I agree there's 6 in there
), since two of those Europe codes seems only to be for non-game items when loading the full GoodName set. I was actually going to bring this up in my thread about the new rom cache system, since I'm currently thinking they should be moved. Either way, if anyone has gone further to document the N64 ROM format, I'd love to read that. I went through all kind of troubles to find out that the ROM internal name was SHIFT_JIS encoded. The good news is that eventually when RCS is merged, this will allow proper hires texture replacement for all games.P.S. the MD5 fix is now in trunk. Not sure if its made it to the Windows port yet.
MasterPhW
Master of the Emulation Flame
I think I have some N64 docs somewhere on my HDDs... will looking for it and send you a pm.I was actually wondering where you got this from (besides the Mupen source code - I agree there's 6 in there
P.S. the MD5 fix is now in trunk. Not sure if its made it to the Windows port yet.
MasterPhW
Master of the Emulation Flame
Sad news, but the M+ team did already a great job, so waiting for a good port is better than having a buggy and crappy port.
Looking forward to it, would be nice, if we would get some more infos here.
Please correct me if I'm wrong, but from discussions on IRC the major issue with the Windows port is that the current port requires a lot of extra libraries and can't compile with MSVC. I believe this is why, or at last believed to be the reason why, a number of binary plugins from other emulators don't work with the Windows port.
Also, a number of people have had issue getting the Windows port to compile due to the large and complex build environment. In an effort to reduce dependencies and make it easier for Windows devs to help contribute to the project, we need to resolve this. A major barrier here is that many people currently on the project don't use Windows or know next to nothing about Windows development, myself included.
One area which had been causing issues was the fact that we use pthreads and Windows doesn't natively support this. My instinct was to suggest just try compiling against the Win32 pthread library, but the consensus was to switch to native Windows threading in the port.
One area where nmn was stuck was in converting the pthread implementation. Another was that the error messages from MSVC were too cryptic and not very helpful in finding where the code was actually causing issue. If anyone thinks they can help with these issues and are interested in advancing the Windows port they should download the source and lend a hand.
Also, a number of people have had issue getting the Windows port to compile due to the large and complex build environment. In an effort to reduce dependencies and make it easier for Windows devs to help contribute to the project, we need to resolve this. A major barrier here is that many people currently on the project don't use Windows or know next to nothing about Windows development, myself included.
One area which had been causing issues was the fact that we use pthreads and Windows doesn't natively support this. My instinct was to suggest just try compiling against the Win32 pthread library, but the consensus was to switch to native Windows threading in the port.
One area where nmn was stuck was in converting the pthread implementation. Another was that the error messages from MSVC were too cryptic and not very helpful in finding where the code was actually causing issue. If anyone thinks they can help with these issues and are interested in advancing the Windows port they should download the source and lend a hand.
Last edited:
Pthreads shouldn't be that big of an issue - threading is not used extensively in the emulator. Requiring the huge mingw-based build environment is a pretty big inconvenience for Windows users, so it would be better to use MSVC instead. But making project files for MSVC and getting everything to build correctly under this compiler will require a lot of work.
The other major issues with a Win32-native build are the OpenGL extensions and the GTK GUI. Including the GTK headers and binary libs is a bad design decision, but there's no way around it without writing a Win32 GUI.
Because of these problems, I think the best way forward for a multi-platform Mupen64Plus project with a native Win32 or OSX build is to split the project into a core command-line emulator module which only uses OpenGL and SDL, and a separate GUI. A couple of recent features (the debugger and the RCS) make this more difficult but I still think it's the cleanest way.
Since all of our current developers have pretty much abandoned Windows and now focus our work on the Linux platform, I think we're going to have to get a good solid Win32 developer before doing this kind of a port will be feasible or compelling. Anyone willing to take this up?
The other major issues with a Win32-native build are the OpenGL extensions and the GTK GUI. Including the GTK headers and binary libs is a bad design decision, but there's no way around it without writing a Win32 GUI.
Because of these problems, I think the best way forward for a multi-platform Mupen64Plus project with a native Win32 or OSX build is to split the project into a core command-line emulator module which only uses OpenGL and SDL, and a separate GUI. A couple of recent features (the debugger and the RCS) make this more difficult but I still think it's the cleanest way.
Since all of our current developers have pretty much abandoned Windows and now focus our work on the Linux platform, I think we're going to have to get a good solid Win32 developer before doing this kind of a port will be feasible or compelling. Anyone willing to take this up?
MasterPhW
Master of the Emulation Flame
Aren't you working on a QT GUI for some time? Like we do at the VBA-M project, QT is a good decision for a multiplattform GUI and don't need to be worked on seperately for every plattform.
It would be to much work to create for every plattform a own GUI, because it would end in some missing features via the GUI on some plattforms.
Regarding the project files, you can probably use the cmake files in the kde4 branch to generate them.
DarkJezter
New member
With the debugger nearing what I see as a relatively major milestone (there is still some core work to be done with it) the next biggest thing I feel it needs is a GUI rewrite, however, I'm beginning to feel that extensive GUI work should wait until after we've settled the cross-platform question.
I've got an osx dev box ready, and I can set up a win32 build system relatively soon. If we can compile the emulator on all three platforms with the NOGUI build flags, than I'd say this is a great start, and I would like to see gui that compiles cleanly on all three platforms. (hopefully, if it can compile on those three, everything else shouldn't be a far stretch) While I haven't a lot of experience with it, I agree as well that Qt is a likely candidate for this (it also includes it's own threading support, however I'm still investigating whether or not this will meet our needs)
Last edited:
MasterPhW
Master of the Emulation Flame
Nice!