[$threadinfo[title]]

[nmn]

More information [here] (http://nmnnotmyname.googlepages.com/home)

This is the first release of Mupen64Plus for Windows and Mupen64Plus Build Environment for Windows. The new port is more up to date, can use blight_input, should have less problems with graphics plug ins, and has a better looking GUI. And you can Stop and Go (If you get an error about "GetDC", press stop a few times and try again.)

Mupen64Plus Build Environment (http://www.mediafire.com/?d0xy90zkz9x)

Mupen64Plus For Windows (http://mupen64plus.googlecode.com/files/Mupen64Plus-Win32.7z)

Not recommended: You can additionally use the MediaFire link if the download above does not work.
http://www.mediafire.com/?d8xbbjtmrnh

[MasterPhW]

Great, will try it asap.
Thanks for not forgetting the windows users.
Where do the bug reports go for the windows version? Into this thread?

[EmuFan]

Tried it, seems to be working perfectly, no bugs so far.

[The Siskoo]

Hello
Great jobs, thanks.

I've found a small problem. Take a look on the picture. Unknow key is out of the dialog :)

http://img166.imageshack.us/img166/6026/mupen64winrj2.jpg

[MasterPhW]

Dunno, if it need to be the way it is atm, but glN64 hasn't a config window, same applies to JttL's Audio Plugin and the Mupen input plugin.
IIRC glN64 have a windows config GUI, the others I don't know, but you could add a no config box, like in the RSP plugin.
Is it the same, like the original one? Because it also had a GUI in its windows release.
The MD5 checksum also doesn't seem to be calculated into the Properties window.
Last thing I wonder is, why does country say Europe (0x50)?

[The Siskoo]

The MD5 checksum also doesn't seem to be calculated into the Properties window.
Last thing I wonder is, why does country say Europe (0x50)?
Same here :)

[Tillin9]

The MD5 code got messed up in the GUI/no GUI merge it's on my todo list.

The 0x50 is because there are 4 European ROM codes. There are also multiple Aussie ones too.

[MasterPhW]

The MD5 code got messed up in the GUI/no GUI merge it's on my todo list.

The 0x50 is because there are 4 European ROM codes. There are also multiple Aussie ones too.
But for the end user it isn't that much important to know, which kind of EUR rom it is. IIRC there are even 6 different EU rom types.
Nice to know, that the MD5 problem is already on your todo list.
Next thing, that bugs me is the incredible amount of libraries packed with this release. AFAIK these are all GTK dlls, so why not just pack an archiv with the libraries and one without.
E.g. I've installed GTK so I don't need all of them.
Btw: there are still a lot Roms missing in the ROM INI, could we help you to add the missing ROMs or should we wait till a newer release is done?
Btw: I've seen, that you are using still the glN64 sources. Did you ever looked into Arachnoid (http://sourceforge.net/projects/arachnoid/) sources? They are based on glN64 aswell but had some good improvements.

[olivieryuyu]

nice !!!

good job !!

[JKKDARK]

Amazing, glad to see this great emulator finally on Windows :D

[_Zack_]

Great job :)

Thanks for giving us Windows users a taste of this awesome emulator :)

Quick question, has this been set up so that when a fix is made in the Linux build it can be easily be fixed in the Windows build too?

Is this also going to be maintained at the same time as the Linux build ? By that I mean will each Mupen64Plus release from now on be Windows & Linux or will the Windows releases be less frequent?

Thanks again :D

[nmn]

Glad to see all of the success here.

- JttL "No Key Bug"
This is part of the SDL configuration system for JttL. It will be solved in the actual Mupen64Plus trunk and it should become effective once this port is stable enough.

- No Config Dialog bug
For some reason, It seems you must open a rom before a windows plugin will configure properly on Mupen64Plus for Windows. I've been looking into the reason why.

When the code is mature enough and more complete, I will ask for permission to slowly merge this in. I think I can do it if i incremently ensure there are no problems during the merge. However, It's not ready, and before i can do it I must update the platform specific files a bit.

And again, All are welcome, very glad to see the positive feedback.

[MasterPhW]

Glad to see all of the success here.

- JttL "No Key Bug"
This is part of the SDL configuration system for JttL. It will be solved in the actual Mupen64Plus trunk and it should become effective once this port is stable enough.

- No Config Dialog bug
For some reason, It seems you must open a rom before a windows plugin will configure properly on Mupen64Plus for Windows. I've been looking into the reason why.

When the code is mature enough and more complete, I will ask for permission to slowly merge this in. I think I can do it if i incremently ensure there are no problems during the merge. However, It's not ready, and before i can do it I must update the platform specific files a bit.

And again, All are welcome, very glad to see the positive feedback.
Nice that you already know about the problems and also seem to already know how to fix it. Really great support from your site.
If you need additional testers for the windows build or anything like that, you have here some handsome guys at the board. =)

[okaygo]

Also remember to join us in IRC!

irc.freenode.net
#mupen64plus

you may even find some PJ64 developers hanging out...

[olivieryuyu]

i can't use nrage or jabo input plugin :(

the emu crashes :(

[okaygo]

i can't use nrage or jabo input plugin :(

the emu crashes :(

Mupen64Plus is different from any other emulator... even the plugin system has changed. As of now we don't have any intentions of supporting these plugins, however the fact that they are incompatible is not due to some restriction we set, so it is a bug.

I want to be clear about this:

We can only support as developers what is given to us on Linux...

That means that we wont support anything Jabo does, and eventually you will be missing out if you are using a 3rd party plugin. We really suggest sticking with Rice Video since it's an already well written plugin, that is abandoned and could be picked up and developed on again.

We want things to work as close as possible on Linux as they do on Windows... so reporting graphical errors for our plugins is much better than using 'a better one'.

This is why we reported everything....

Anyways happy gaming,

okaygo

[olivieryuyu]

fb notification with glide64 doesn t work i am afraid.

okayo, i was not speaking about gfx plugin, just input plugins. And Rice is nice, that is true, even i can t get correct resolution in window mode (ok in fullscreen) with Mupenplus.

[okaygo]

fb notification with glide64 doesn t work i am afraid.

okayo, i was not speaking about gfx plugin, just input plugins. And Rice is nice, that is true, even i can t get correct resolution in window mode (ok in fullscreen) with Mupenplus.

As for input we only support blight_input (which is really not that bad)

[Richard42]

The other input plugins should work (the interface is pretty simple), so this is probably a bug.

There is a possibility that the other plugins that you're having trouble with do not conform to Zilmar's API which is used in Mupen64Plus. Did the other emu/plugin developers add extensions which aren't backward-compatible? We have added some extensions in Mupen64Plus but these should still work with other components.

[_Zack_]

Id just like to report a bug.

The Rice Video Plugin has a bug with loading/using Hi-Res texture packs.

I am getting 85% of textures missing on mario 64 with risio's pack. I have tested on Project64 with the same plugin and they work perfect.

[okaygo]

Id just like to report a bug.

The Rice Video Plugin has a bug with loading/using Hi-Res texture packs.

I am getting 85% of textures missing on mario 64 with risio's pack. I have tested on Project64 with the same plugin and they work perfect.

The same exact plugin?

[_Zack_]

The same exact plugin?

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

[okaygo]

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

[_Zack_]

No joy unfortunatly

[okaygo]

No joy unfortunatly

Hmmm...


On another note, I updated the first post to reflect a mirror since our first one went out of bandwith.

[MasterPhW]

Here (http://rapidshare.com/files/112853513/Mupen64Plus-Win32.7z)'s an additional mirror on my RS.com premium account to support your work.

[okaygo]

Here (http://rapidshare.com/files/112853513/Mupen64Plus-Win32.7z)'s an additional mirror on my RS.com premium account to support your work.

Thanks.

[nmn]

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.

[Tillin9]

But for the end user it isn't that much important to know, which kind of EUR rom it is. IIRC there are even 6 different EU rom types.
Nice to know, that the MD5 problem is already on your todo list.

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]

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.
I think I have some N64 docs somewhere on my HDDs... will looking for it and send you a pm.

[okaygo]

nmn has had troubles porting Windows code, which means that for now... this port is currently being delayed.

[MasterPhW]

nmn has had troubles porting Windows code, which means that for now... this port is currently being delayed.
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.

[Tillin9]

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.

[Richard42]

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?

[MasterPhW]

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?
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.

[Slougi]

But making project files for MSVC and getting everything to build correctly under this compiler will require a lot of work.
Regarding the project files, you can probably use the cmake files in the kde4 branch to generate them.

[DarkJezter]

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?

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)

[smcd]

For pthreads, this site (http://sourceware.org/pthreads-win32/) has a good package that works well and is free

[Slougi]

/me whistles (http://www.student.oulu.fi/~louaialk/mupen64plus_win32_1.9.2008.png)

:whistling

[MasterPhW]

/me whistles (http://www.student.oulu.fi/~louaialk/mupen64plus_win32_1.9.2008.png)

:whistling
Nice!

[okaygo]

Expect to see a lot more Windows progress.

[HyperHacker]

Does the debugger work? I know a few Windoze users who'd like to get their hands on it. (I'm telling you guys, just use Linux already. :P)

[Slougi]

Not currently, no. I need to write a Qt4 gui for the debugger, after that it should work though.

[Tillin9]

HyperHacker: The debugger currently has some issues (crashing on rom stop) due to the conversion to SDL threads. I spent some time trying to figure out what exactly was the issue, but besides honing in on some SDL / gdk threading conflict was unable to actually fix it.

If you could take a look at it, it would be appreciated.