Windows Port

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

 

[Danny]

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.

 

[Danny]

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

Keep it up mate

 

[okaygo]

It's time for a sexy party.

 

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