[$threadinfo[title]]

[nmn]

Sorry, It is not done yet. This is discussion of it.

1. I will be submitting code soon today. I made a crude port but then realized I wanted to improve the code organization more.
2. The windows port will probably lack a GUI initially.

So far, I had gotten it to build but not run. However, I want to quickly rewrite the port now that I know what must be done.

Anyways, Suggestions on things I should be aiming at? Should we just throw up the GTK GUI initially?

[X-Fi6]

Yeah initially you should use GTK for the Windows port as to avoid confusions between the Windows port's GUI and all other OS's GUI.

Apart from that I don't really know what you should be aiming at. I want the Windows port to stay alive because after all Mupen64 stands for Multi Platform Emulator for n64 and without the Windows port it doesn't feel like it's complete.

It's also a great base for curious people to code in their own stuff that they would personally want. Without a Windows port they can't do that.

[_Zack_]

Sorry, It is not done yet. This is discussion of it.

1. I will be submitting code soon today. I made a crude port but then realized I wanted to improve the code organization more.
2. The windows port will probably lack a GUI initially.

So far, I had gotten it to build but not run. However, I want to quickly rewrite the port now that I know what must be done.

Anyways, Suggestions on things I should be aiming at? Should we just throw up the GTK GUI initially?

I think the aim should be on keeping the Linux fixes current with the Windows build. All those core & plugin updates and new features should defiantly be in the Windows build too.

Why not just use the Gui from V0.5 nmm?

[nmn]

The old GUI would work but it would require too much change.

BTW, the port should allow us to merge into the latest version so that we will always be current with updates.

[Richard42]

So far, I had gotten it to build but not run. However, I want to quickly rewrite the port now that I know what must be done.

Anyways, Suggestions on things I should be aiming at? Should we just throw up the GTK GUI initially?

For the sake of simplicity it might be best to just use a cross-platform GUI system (either the GTK or KDE code) on Win32 instead of adding yet another gui framework to support. I don't know how badly it would impact the installer though.

[Richard42]

BTW, the port should allow us to merge into the latest version so that we will always be current with updates.

This depends on how the port is built. If it's written in a way which clutters up the common code with #ifdef WIN32s then it's going to live in its own branch and someone will be responsible for merging patches back and forth. If the changes are clean then I'll merge it into the trunk. If it the Win32 port adds a new Win32 GUI, then someone will have to keep the GUI code up to date as features are changed and added. But if it's written to use one of the pre-existing platform-independent GUI libraries, then it may be able to be fully integrated with the existing software, with very little maintenance required as we go forward..

[nmn]

If it's written in a way which clutters up the common code with #ifdef WIN32s then it's going to live in its own branch and someone will be responsible for merging patches back and forth. If the changes are clean then I'll merge it into the trunk.

It should be clean enough, there are a few ifdefs but it uses another macro that is defined by the CFLAGS in a seperate file. The reason is Cygwin may allow using the POSIX-like interface from inside of Windows. I had to split main.c, main.h, plugin.c, plugin.h, volume.c, and volume.h. Most of main.c and main.h are intact in the main/ directory but the remaining non-platform independent parts are seperated, and plugin.c plugin.h, volume.c, and volume.h are completely split.

The initial crude port was not good enough, So I went toward this idea.

[sultanoswing]

A tad off topic, but as a linux fan, it tickles me pink to see discussions hoping software will be ported to windows, rather than from it. Welcome to the future, people :)

[mudlord]

but as a linux fan, it tickles me pink to see discussions hoping software will be ported to windows, rather than from it. Welcome to the future, people

And way to show GNU zealotry there....>.>

Sheesh.

This is EXACTLY whats turning me off from using Linux altogether, is people like you.

[Slougi]

And way to show GNU zealotry there....>.>

Sheesh.

This is EXACTLY whats turning me off from using Linux altogether, is people like you.

Huh? I don't see the zealotry.



Anyway, I hacked on this a few days back. The KDE interface compiles fine, the core does need some work. So, if you can land the core changes we might get mupen64plus feat. KDE gui on windows ;) I don't know how easy deployment currently is though.

[Richard42]

And way to show GNU zealotry there....>.>

Sheesh.

This is EXACTLY whats turning me off from using Linux altogether, is people like you.

I would classify that particular comment more as "rooting for the underdog" than zealotry. We all have our own faults, though: Linux users are more prone to arrogance regarding a feeling of superiority, while Windows users are more prone to arrogance at the ubiquity of their platform. Hell, when Mupen64 was first developed Multi-platform was sort of a euphemism for everything outside of Windows, because most people assumed that all software ran on Windows. :)

In the end it comes down to each individual's comfort level with software. I have a friend at work who used to be a fairly big Windows fan and do some Linux bashing from time to time. He recently had to setup a new Linux machine because his project supports Linux in addition to Windows and he needed a Linux system for development and testing. He told me that he has been surprised by the quality of the software and likes working in Eclipse quite a bit.

Personally I switched to Linux a couple of years ago just because of software acquisition issues. There is so much more high quality software available for free in the open source world, and I was tired of having to pirate everything because office costs $200, photoshop costs $500, etc. Everybody wants to get paid in the Win32 world, even for crappy little shareware utilities -- there's no community sense of building a better future for all users and developers - it's more like "I gotta get mine".

[mudlord]

We all have our own faults, though: Linux users are more prone to arrogance regarding a feeling of superiority

Yeah, and that was were I sensed the zealotry in the offending user's post.

Personally, I find such vocal evangalism for Linux disturbing. Thats why I don't really want to use it full time, because simply, I don't want to be personally associated with a community that seems to me that continually touts its OS as the only thing to solve the world's problems, and the best thing since sliced bread.

Like, I want to make my own choices when it comes to software, and not have others force thier opinions. But anyway, this is getting seriously OT..

[okaygo]

mudlord should join the development team.

[vision]

So, if you can land the core changes we might get mupen64plus feat. KDE gui on windows ;) I don't know how easy deployment currently is though.

As far as I know, it's a lot easier to either pick GTK or QT (which is the toolkit that KDE uses, latest major release 4.x compiles on Windows, this is the first major version number to do so) and then stick with one or the other, as opposed to having a Linux version in GTK and a Windows port in QT. They're two completely different toolkits, and one or the other (probably the Windows port) would fall behind in upstream changes.

Both GTK and QT compile on Windows now, but where Mupen is already interfaced in GTK, well.. :) Although, Tillin9 is working on a QT port..

Lots of great Linux apps have been successfully ported to Windows in GTK, including Pidgin and GIMP. Personally, I enjoy both toolkits, they each have their strengths and weaknesses.

Side note: in Linux, QT 4 draws faster than GTK 2 most of the time. But I have no idea if that's the case on Windows.

[MasterPhW]

Are there also plans in providing a 64bit binary for windows or are most of the 64bit changes linux specific? Because I know, windows handles 64bit in a very different manner than linux, so just a question.
Btw: I am really looking forward to the first MupenPlus RC on windows! You all had done a great job! =)

[Slougi]

As far as I know, it's a lot easier to either pick GTK or QT (which is the toolkit that KDE uses, latest major release 4.x compiles on Windows, this is the first major version number to do so) and then stick with one or the other, as opposed to having a Linux version in GTK and a Windows port in QT. They're two completely different toolkits, and one or the other (probably the Windows port) would fall behind in upstream changes.

Both GTK and QT compile on Windows now, but where Mupen is already interfaced in GTK, well.. :) Although, Tillin9 is working on a QT port..

Lots of great Linux apps have been successfully ported to Windows in GTK, including Pidgin and GIMP. Personally, I enjoy both toolkits, they each have their strengths and weaknesses.

Side note: in Linux, QT 4 draws faster than GTK 2 most of the time. But I have no idea if that's the case on Windows.

*cough* Please read the Qt/KDE gui thread.

[Richard42]

Are there also plans in providing a 64bit binary for windows or are most of the 64bit changes linux specific? Because I know, windows handles 64bit in a very different manner than linux, so just a question.

The hardest part of the 64-bit port (the dynamic recompiler) is platform-agnostic and would only require a few small changes to work. The C code however was not written with Windows in mind and would require significant changes to work in Win 64. There are currently no plans to add support for 64-bit windows.

[vision]

*cough* Please read the Qt/KDE gui thread.

Just saw that after I posted.. thanks. :satisfied

[MasterPhW]

The hardest part of the 64-bit port (the dynamic recompiler) is platform-agnostic and would only require a few small changes to work. The C code however was not written with Windows in mind and would require significant changes to work in Win 64. There are currently no plans to add support for 64-bit windows.
What a shame... but we'll see, what the future will bring! Probably you will find some more windows devs, which will take the win64 part.

[Tillin9]

Not sure whether that was a cough over the KDE==Qt issue or over credit. FYI: Slougi deserves all the credit with the KDE GUI. My real job lately has been hellish, and the current KDE4 GUI is much more complete than anything I whipped up, so I basically dropped my (more or less KDE3) GUI and when I have time will try to extend the current KDE4 GUI (i.e. configs for plugins, etc.).

[nmn]

I landed a HUGE commit on the Win32 branch. It is terrible, But I had too much to keep it in any longer. I will be doing clean up, but if anyone else wants to work on anything, It would be nice to let me know how and what you plan to do because I may be doing commits in bulk for a bit so the branch never gets too broken. (Though as an initial port its broke to hell right now, barely running, and the core itself is probably not even getting started)

I will work on simplifying the way I abstracted the platforms - It's low quality right now, with 2 ifdef blocks in place of #include "winlnxdef.h"... I will be cleaning that system up A LOT.

Oh and Mudlord, Please don't feel like those little posts are zealotry. Usually at first Linux users feel it necessary to be loud and blunt, but the only thing about that post i found potentially annoying was the "Welcome to the future" part. Much worse is "GO UBUNTU!!!" and we generally do not promote that. I believe the reason is that Linux users often get ridiculed because they do not wish to use Windows so they end up taking it out on Windows users by consistantly suggesting its superiority. Honestly the only time I push Linux is when somebody shows ignorance at a more than normal rate or trolls. I don't mean to single out Vista or Microsoft fans, but they bash Linux MUCH more than a regular computer user.

If you develop software from scratch, try to atleast get it working on Cygwin - Leave us a stub for development. I don't generally ask for ports because I'm a programmer (Who does porting ;)) but it's hard to transform a very large MSVC or MinGW project into a completely platform independent project. Linux itself is nice to work with. I would gladly try FreeBSD if NVidia straightens out the remaining issues and I can find a spair CD :P I hear it's an actual UNIX. Oh, BTW, If you find Cygwin annoying, your not alone. It's pretty damn annoying to have your toolchain so far away from the OS. That's half my reason to be on Linux right now tbh.

[Slougi]

nmn, how do you plan to port this? Will you implement windows threading or use one of the pthread libraries? Will you work on a native GUI, use GTK or what? Just some general info would be appreciated :)

[nmn]

nmn, how do you plan to port this? Will you implement windows threading or use one of the pthread libraries? Will you work on a native GUI, use GTK or what? Just some general info would be appreciated :)

Currently it uses Win32 threads and No GUI. I will attempt to support GTK and Qt along with a Win32 GUI default. Yes, A very large amount of work, but If i can get one using GTK cleanly enough I may be able to get permission to back port it into the trunk. Unfortunate that I have so much to do on it before it would be near that state.

edit: I did not mention this, but of course, when I'm adding Qt and a new GUI I'd be doing it in the branch again, or a new one.

[_Zack_]

Currently it uses Win32 threads and No GUI. I will attempt to support GTK and Qt along with a Win32 GUI default. Yes, A very large amount of work, but If i can get one using GTK cleanly enough I may be able to get permission to back port it into the trunk. Unfortunate that I have so much to do on it before it would be near that state.

edit: I did not mention this, but of course, when I'm adding Qt and a new GUI I'd be doing it in the branch again, or a new one.

Keep it up mate :)

[sultanoswing]

A brief return off-topic, if I may:

mudlord, please note my original post was affixed with a smiley - it was never meant to be a zealot-like post - to each their own, I say - still - think evil, see evil...

In retrospect, the "welcome to the future" comment reads a little more harshly than I intended, and so I retract that comment.

OK - back on topic...

[nmn]

Back on topic indeed. I found out that everything was ported OK, threading and plugins were all working all along - I just had to print to stderr. Anyways, I have JTTL Audio working nicely right now so I can hear the game run. I'm trying to get glN64 up and running, and It's already compiled. However, I'm going to need to use GLEW for the port because I'm not skilled enough to properly solve the extension problem. It's sad that I have to dump it because GLEW works so good and everything else looks cleaner with it, but I guess that's the way it goes.

[_Zack_]

Back on topic indeed. I found out that everything was ported OK, threading and plugins were all working all along - I just had to print to stderr. Anyways, I have JTTL Audio working nicely right now so I can hear the game run. I'm trying to get glN64 up and running, and It's already compiled. However, I'm going to need to use GLEW for the port because I'm not skilled enough to properly solve the extension problem. It's sad that I have to dump it because GLEW works so good and everything else looks cleaner with it, but I guess that's the way it goes.

Awesome :D

Keep it up mate :)

[okaygo]

It's time for a sexy party.
http://www.freesexgames.org/assets/images/stewie_sexy_party.jpg

[Richard42]

However, I'm going to need to use GLEW for the port because I'm not skilled enough to properly solve the extension problem. It's sad that I have to dump it because GLEW works so good and everything else looks cleaner with it, but I guess that's the way it goes.

I don't understand what you've written here. It appears that you've said that you need to use GLEW, but then you say you're not going to use it?

[nmn]

I don't understand what you've written here. It appears that you've said that you need to use GLEW, but then you say you're not going to use it?

I need to dump it eventually for it to get merged. I mean AFAIK anyways, I just assumed so.

[Slougi]

Excuse my ignorance, what's GLEW?

[nmn]

The OpenGL Extension Wrangler, which handles runtime linking of extensions cleanly. It's a library i use often. The same thing can be achieved via SDL, but I don't see the point of doing that just to get this thing up and running. If it becomes bothersome I can try replacing the GLEW code now, but I think it's okay since probably nobody else will compile the MinGW version (though I will leave instructions and probably some material related to setting up MinGW, possibly included a precompiled MinGW with GCC 4)

[Richard42]

The OpenGL Extension Wrangler, which handles runtime linking of extensions cleanly. It's a library i use often. The same thing can be achieved via SDL, but I don't see the point of doing that just to get this thing up and running. If it becomes bothersome I can try replacing the GLEW code now, but I think it's okay since probably nobody else will compile the MinGW version (though I will leave instructions and probably some material related to setting up MinGW, possibly included a precompiled MinGW with GCC 4)

I looked at the GLEW web site a little bit but I'm still not sure what problem this tool solves. I'm not exactly an OpenGL wizard but I do know that there are no linking issues involved with using the extensions. You only link against a single library (libGL) and use the standard interface to query the extensions available (I think it's done with text strings). It looks like GLEW simplifies this a little bit by giving you some macros to use instead of parsing the strings, but other than that I'm not sure what it does for you. I thought that all this stuff was being handled in a standard way in the plugins, but I guess not if you're having trouble making it run in Win32.

[nmn]

I looked at the GLEW web site a little bit but I'm still not sure what problem this tool solves. I'm not exactly an OpenGL wizard but I do know that there are no linking issues involved with using the extensions. You only link against a single library (libGL) and use the standard interface to query the extensions available (I think it's done with text strings). It looks like GLEW simplifies this a little bit by giving you some macros to use instead of parsing the strings, but other than that I'm not sure what it does for you. I thought that all this stuff was being handled in a standard way in the plugins, but I guess not if you're having trouble making it run in Win32.

Well, This one is Microsoft's own little problem. Obviously to help DirectX along its way to taking over, they stopped updating OpenGL after version 1.1. Driver developers have to use the extension system to implement the most basic of OpenGL features. Sounds easy until you factor in that it acts COMPLETELY DIFFERENT in nearly every platform...

GLEW does most of the work for us in between platforms, That's all.

[Richard42]

Well, This one is Microsoft's own little problem. Obviously to help DirectX along its way to taking over, they stopped updating OpenGL after version 1.1. Driver developers have to use the extension system to implement the most basic of OpenGL features. Sounds easy until you factor in that it acts COMPLETELY DIFFERENT in nearly every platform...

I see; that doesn't sound too convenient. :ermm: It's hard to justify adding another lib dependency if there was a way that you could do it with SDL. If you're really just trying to get it running as soon as possible you could take a lot of shortcuts and just maintain it as a separate branch. We could form a win32-maintainer team to port and test changes from the trunk, and I would be willing to port code for new features coming the other way.

Complexity is the enemy of software development, and I'd like to keep to the smallest number of duplicate code paths for different systems as possible. The assembly code is bad enough but at least it's low-level mathematical stuff and so rarely changes. That's why in the Win32 branch I'd prefer to see the platform-specific things like pthreads and usleep() calls replaced by their SDL equivalents. Some things just can't be handled in a totally platform-independent way (like loading DLLs), but there are good design patterns which can abstract this nicely.

[nmn]

Well the main reason I didn't do the extensions by hand is BECAUSE it would be dirty. I don't know If I could do it right, but If I could, It would be a mess.

On the other hand, if I setup things up just write it would be a matter of SDL_GL_GetProcAddressing all of the functions and for the ones it works flagging the corresponding 'OGL.feature' bool true. But, this would likely break the Windows code. It's tough.

edit: Alright, I'm starting to get a little pissed off. SVN just destroyed my codebase. I had /alot/ of modifications but it reverted me back to a morphed version of what I had before and what I had when the branch was first made.

edit 2: Yep, it fucked my code... I guess it's nobodies fault, but who made the commit? I'm trying to figure out what it did in the first place.

[Richard42]

edit: Alright, I'm starting to get a little pissed off. SVN just destroyed my codebase. I had /alot/ of modifications but it reverted me back to a morphed version of what I had before and what I had when the branch was first made.

edit 2: Yep, it fucked my code... I guess it's nobodies fault, but who made the commit? I'm trying to figure out what it did in the first place.

In r189 you made a huge commit, but you committed most of your code to the trunk, not into your branch. So in r190 I reverted the portion of your commit which was on the trunk. You gotta pay attention to the commit email notification; that's why it's there. To correct your situation from this point, you need to:

0. Leave your "trunk" local copy alone because it contains the changes you made since rev 189
1. Check out the actual branch and begin working on the branch, not on the trunk
2. "svn merge -r 190:189 svn:/..../trunk ." to get back your changes from rev 189
3. Commit these into the branch
4. Manually merge the newer changes from your trunk local copy into the branch. Use svn diff on the trunk to see the changes.
5. Commit your newer changes into the trunk.

Three lessons to learn here:
A) I strongly recommend using "svn status -u" and "svn diff" to see what you're actually going to commit to the repository before you do it. I catch a lot of mistakes this way.
B) Waiting to commit until you have massive numbers of changes is a recipe for trouble. You should develop and commit incrementally, one feature/bugfix at a time.
C) Read the email notifications, at least the log messages

I hope you didn't lose any work.

[nmn]

Okay. This is confusing me ALOT.

However, I found out what happened. I'm very sorry for the issues. Somehow I ended up getting perverse .svn folders! I have no idea why, but most of them pointed to the trunk. I never copied those directories which is my typical mistake - Or maybe I did but not the typical way. I apologize for ruining the trunk, AGAIN. It seems everything I could possibly do wrong with Version Control I do with this project...

[Richard42]

Okay. This is confusing me ALOT.

However, I found out what happened. I'm very sorry for the issues. Somehow I ended up getting perverse .svn folders! I have no idea why, but most of them pointed to the trunk. I never copied those directories which is my typical mistake - Or maybe I did but not the typical way. I apologize for ruining the trunk, AGAIN. It seems everything I could possibly do wrong with Version Control I do with this project...

It wasn't a major problem since SVN insures that the code won't be lost.. It's just more work for me. There's never any need to copy a version-controlled directory. If you want another copy, just do another checkout. If you want a copy without the .svn stuff, do an export. One of the problems that I've run into is with Eclipse and Subclipse. If you're using these tools you have to never use the command-line svn client or the eclipse client will get hosed.

[nmn]

It wasn't a major problem since SVN insures that the code won't be lost.. It's just more work for me. There's never any need to copy a version-controlled directory. If you want another copy, just do another checkout. If you want a copy without the .svn stuff, do an export. One of the problems that I've run into is with Eclipse and Subclipse. If you're using these tools you have to never use the command-line svn client or the eclipse client will get hosed.

I don't normally use Eclipse but sometimes I use KdeSVN which works nicely provided your repository is correctly setup (however, I normally screw it up by doing normal file operations instead of using SVN ones, as you can tell.)



edit: Alright. Now the GUI runs, but I have yet to report glN64. And the GUI is broke so don't bother. I'm fixing it right now.