View Full Version : Best Porting Options - Mac (Cocoa/OpenGL) to Windows
After releasing my sales stats for GL Golf here - http://www.idevgames.com/forum/showthread.php?p=121362 - I decided I NEED to get it ported to windows. I'm now trying to figure out my best option for this.
Background-
GL Golf is programmed in Objective-C using Cocoa and Open GL using XCode. It is about 13,500 lines of code (all files and whitespace). Cocoa is used for the interface, internet connections, and sound (NSSound), and the preference file.
Options-
* Pay someone (maybe around $1000 and/or percentages of sales) to port it for me.
* Convert it from scratch to cross platform C/C++ code, reprogramming lots of Cocoa things along the way.
* Convert it from scratch to cross platform Objective-C code, reprogramming lots of cocoa things along the way, but keeping the majority of MY classes/code unchanged.
* Gradually start converting everything I can in my current XCode project to be cross platform, and eventually it will build on both the mac and windows.
I think I want to stay with Objective-C and go with the last method I chose. That way I can stay in Objective-C and then when I update the game I can keep one set of files and everything I change on the mac will be changed on the windows version.
Does anyone have any experience or advice about OPENSTEP? Is it worth using or looking into, does it do things like NSString and other relatively simple cocoa methods?
EDIT : Also, what is the best method for interfacing for both Mac and PC? Should I go with SDL or use Cocoa for Mac and then something else for windows?
Also, if someone has a cross platform game that sells decently, could you post your percentage of mac buyers and windows buyers, I'm curious to what I should expect.
Thanks
Leisure Suit Lurie
2006.10.17, 01:32 PM
I'm probably talking through my a$$, but maybe you could use GNUStep (http://en.wikipedia.org/wiki/GNUstep) to port it.
I'm probably talking through my a$$, but maybe you could use GNUStep (http://en.wikipedia.org/wiki/GNUstep) to port it.
Oops, thats what I meant by Openstep, I'm going to have to look into that some more!
Leisure Suit Lurie
2006.10.17, 01:53 PM
Oops, thats what I meant by Openstep, I'm going to have to look into that some more!
Ah. Not am I talking through the wrong end. I can't read, either.
*hides under a rock*
Leisure Suit Lurie
2006.10.17, 01:59 PM
I should probably beat Jon to suggesting using Unity to port it to Windows. Might be the least aggravating path, although it'll set you back over 1 grand for the crosss platform version. OTOH, you were willing to pay someone that to port it for you...
akb825
2006.10.17, 02:13 PM
The most "cross platform" way to do it would be to do everything in C/C++ and have everything work in SDL or similar cross-platform libraries. However, GNUStep would provide a quicker option assuming all your Cocoa classes are also implemented in GNUStep, and that you can somehow get GNUStep working on Windows without requiring Cygwin. (or perhaps there's just a set of libraries you can include with your install)
Edit: Apparently there are Windows binaries available (http://www.gnustep.org/resources/sources.html#windows).
Malarkey
2006.10.17, 02:49 PM
EDIT : Also, what is the best method for interfacing for both Mac and PC? Should I go with SDL or use Cocoa for Mac and then something else for windows?
I've been experimenting with creating Win32 versions of a couple of my projects using wxWidgets. I haven't been too entirely successful at it (due to lack of time and what not) but it seems a promising route. I used it to create my OMG entry, Chemical Bonds. It will give you classes for preference handling, basic internet connectivity (I think), and maybe sound.
Okay... the website appears to be not there. I'll point you to the Wikipedia article then: http://en.wikipedia.org/wiki/WxWidgets
OneSadCookie
2006.10.17, 05:15 PM
I'll just say, everyone I know who's gone "Ooh, GNUStep!" has later gone "Argh! The pain!".
I'd really recommend ditching Objective C entirely and going for C/C++ with SDL.
I'll just say, everyone I know who's gone "Ooh, GNUStep!" has later gone "Argh! The pain!".
I'd really recommend ditching Objective C entirely and going for C/C++ with SDL.
Thats the advice I was waiting for someone to say before I tried it, I remember looking into it a while back and not ever installing it/trying it.
What are your thoughts on Objective-C and SDL, just using the language without cocoa, that way I wouldn't have to reprogram most of my code, and I have no speed concerns because hardware has advanced so much sense uDevGames 2004 when I started.
So if I used GNUstep I would have to use an installer and install files just to allow my game to run on windows? I just remembered how much I hate windows and installers!
OneSadCookie
2006.10.17, 05:57 PM
What are your thoughts on Objective-C and SDL, just using the language without cocoa, that way I wouldn't have to reprogram most of my code, and I have no speed concerns because hardware has advanced so much sense uDevGames 2004 when I started.
I bet you're using more of Cocoa than you think you are. Objective C as a language gives you very little functionality...
It also ties you to developing using MinGW as your compiler, with whatever ObjC support (or lack thereof; I doubt anyone actually cares or tests if it works) it provides.
So if I used GNUstep I would have to use an installer and install files just to allow my game to run on windows? I just remembered how much I hate windows and installers!
I don't know about installers, but you'd have at least one more DLL to bundle with your application...
skyhawk
2006.10.17, 06:08 PM
Where's the rewrite in Unity option? =)
Anyways, Jake, do you think this program will be as well received in the Windows world as the mac world?
I guess it can't hurt to switch to C++, I have the C++ pocket guide and know a little bit about it, and then I'll be much more experienced in C++. Does cocoa include things like memory management and/or does it add more to the language then I would expect?
I wonder what the easiest way to do this is, I wonder if I can transition slowly by gradually changing over each of my classes to C++, linking them together with Objective-C++. That way I can get what I think is cross platform code running in XCode, and when I'm all done with that I can try to get those files to compile on Windows.
And I seem to be hearing alot about Unity from people (Dan comes to mind), maybe I could do that but I'm afraid to take on anything to big because I really don't have the free time like I use to when I was single and in high school.
And I doubt it will be as well perceived by the windows world, but I figure even if it does 10% as well it will be worth it, and it has the potential to do much higher then that (although it probably won't)
skwirl42
2006.10.18, 06:58 PM
A few years back, I took a look at GNUstep. I even wrote some documentation for it. The sense I got then was that Foundation support was pretty good, but that AppKit stuff wasn't nearly as well developed. That was 6 years ago, things might have changed. The code I wrote for GNUstep I ported into Cocoa when I got the chance, and didn't go back.
akb825
2006.10.18, 07:19 PM
The majority of your stuff should transition into C++ fairly easily. The only thing is, depending on how "Cocoa" your style of memory management is, you might have to redo some of that. Also, if you're making some assumptions about message calling using id, then you might have to tweak some things. Other than that, it's essentially changing how you define the classes, how you call your methods, changing a few data structures (like if you use NSArray), and switching out your window setup/event code.
The majority of your stuff should transition into C++ fairly easily. The only thing is, depending on how "Cocoa" your style of memory management is, you might have to redo some of that. Also, if you're making some assumptions about message calling using id, then you might have to tweak some things. Other than that, it's essentially changing how you define the classes, how you call your methods, changing a few data structures (like if you use NSArray), and switching out your window setup/event code.
I think most of my actual "game" code is pretty procedural, and doesn't really use Cocoa too much, so C++ might be a good idea, I do want some experience with C++ instead of just Objective-C.
I have a question about mixing C++/Objective-C. Say I have my controller class, which controls the UI and starts the game. the Controller class controls my glView class, which runs the game. glView creates a level class, which handles everything associated with a level. The level class creates a tree class, which loads and draws trees ect.
Could I first reprogram the Tree class in C++, then make my level class an objective C++ file, and then start replacing things like [trees doMethod] with trees::doMethod(), then keep repeating the process until I get everything class to C++? That way I could do this gradually, and keep making other updates to the mac version while I'm working.
Oh, and I talked to Dan on AIM I'm pretty sure he's on the Unity payroll ;), which I'm considering but I think it would almost be better to make a new game from scratch using Unity
akb825
2006.10.19, 02:06 PM
Could I first reprogram the Tree class in C++, then make my level class an objective C++ file, and then start replacing things like [trees doMethod] with trees::doMethod(), then keep repeating the process until I get everything class to C++? That way I could do this gradually, and keep making other updates to the mac version while I'm working.
Yeah, that should work. Just a semantic issue here: is trees the class name, or an object? If it's a class name, great. If it's an object, you'll need to use . if it's a stack/global object, or -> if it's a pointer to an object.
Awesome, I'm going to start working on that tonight, I'll probably grab all of the functions and data structures that overlap between all of my code files and make a NNMath.c/h file first and then start replacing the old ones with the NNMath.c functions, something I should have done when I started (but I was 16 and had no C experience before, so I can see why I missed it)
And yeah trees is the class name
Wow, I'm surprised I made it two hours coding in a language I've never actually used before without hitting a roadblock! I now converted one of my lowest level classes from Objective-C to C++, and the game looks EXACTLY the same as before! I had to rename pretty much EVERY file .mm instead of .m, and it looks like they will have to all stay .mm until I get everything out of objective-C (i think). I noticed I made a MESS with #import, so I'm trying to fix that up a little bit. Should I change from #imports to #include, or is #import supported with C++ and the PC?
Thanks for the suggestions and help, I'll probably hit some roadblocks down the road and will probably have to ask some more questions
OneSadCookie
2006.10.19, 05:33 PM
#import is a GCC-only thing. If you think you might want to compile with MSVC, you should change to #include.
#import was broken for a long time even in GCC. Apple fixed it, but I'm not sure when that change made it to the main line. It's possible that even MinGW for Windows hasn't picked up the change yet.
akb825
2006.10.19, 06:00 PM
Wow, I'm surprised I made it two hours coding in a language I've never actually used before without hitting a roadblock! I now converted one of my lowest level classes from Objective-C to C++, and the game looks EXACTLY the same as before! I had to rename pretty much EVERY file .mm instead of .m, and it looks like they will have to all stay .mm until I get everything out of objective-C (i think). I noticed I made a MESS with #import, so I'm trying to fix that up a little bit. Should I change from #imports to #include, or is #import supported with C++ and the PC?
Thanks for the suggestions and help, I'll probably hit some roadblocks down the road and will probably have to ask some more questions
Definitely change #import to #include. To add to what OSC said, I've only seen #import used with ObjectiveC. For the extensions, .m is ObjectiveC, .mm is ObjectiveC++, and .cpp is C++.
For all I know, #import works fine with MSVC, at least it did so 2 years ago.
Also: If you're moving from ObjC to C++ without actually knowing C++, I can almost guarantee more pain than giving GNUStep a shot. Lots more pain. If your app is not relying heavily on AppKit's obscurities, it might just work without too much trouble.
Thanks for the feedback about #import!
After spending 3 hours I tried to convert my static model class (for trees) over to C++ code, and it went good and compiled/ran, except only about half the time the trees even show up at all! No compile errors/warnings at all, so its going to be tricky to try to figure out next time I start working again.
DoG, I think you might be right. After spending 5 hours converting 2 smaller classes over to C++ I can tell its going to be a lot of work to get the other classes, then I will have to reprogram a UI in SDL or something for the PC. I'm going to take another look at GNUStep again before I start converting more code, because I don't rely on Appkit much, mostly Foundation
akb825
2006.10.22, 05:00 PM
It all depends on how feasible GNUstep is. If it looks like all the classes you're using are available and have all the same functionality, great. Otherwise, you may want to do some simple problems to familiarize yourself with C++, then try again when you have a better handle on the language.
Jones
2006.10.24, 09:31 PM
Isn't import like copying and pasting one file into the location of the #import, and #include is something different?
Isn't import like copying and pasting one file into the location of the #import, and #include is something different?
I'm pretty sure #import protects from including files that have already been including, therefore eliminating infinite loops where A.h imports B.h, and B.h imports A.h. It makes things simpler but allows for bad programming style because you can get sloppy #imports to compile and work correctly
Wow... they sure didn't make it easy to instal GNUStep and get programs running! After two hours of fiddling last night I managed to download the core packages and instal GCC, and then using MiniGW I build the project editor program (I'm assuming its like Xcode), and tonight I'll build the GUI program (like Interface Builder).
I'm very surprised of how much like OS X everything is, the command line is the same, there is even a Users/Jake Leveto/ director, and Library-System folders around everywhere!
Does anyone know what is needed to actually run the compiled programs on any random PC that downloads it, I wonder if its a DLL or if they have to instal the frameworks or something. I didn't have time to research it last night so I'll have to do it tonight if nobody knows the answer. I'm also going to have to find out how compatible Interface builders NIBs are with whatever GNUStep uses.
Ahh... no more time to do anything now, back to class after lunch :(
OneSadCookie
2006.10.25, 02:29 PM
I'm also going to have to find out how compatible Interface builders NIBs are with whatever GNUStep uses.
Not at all.
GNUStep has a tool called nib2gmodel which attempts to do a conversion. Whether it works or not is a bit of a crap-shoot.
Not at all.
GNUStep has a tool called nib2gmodel which attempts to do a conversion. Whether it works or not is a bit of a crap-shoot.
Thanks for the tool, I'll definitely take a look at it if I choose to go that rout.
While the forum was down yesterday I tried to debug my C++ class that I converted from an old Objective-C class a few weeks ago, and I had a hell of a time! I finally found the problem, it was because in an Objective-C "int array[10]" was filled with 0's initially, and in C++ it was filled with garbage. BUT it was hard to find because the debugger just listed two thread steps, ?? and ??, instead of finding the right part of the code that was causing the errors. Is this because I'm using Objective-C++ and the debugger was using the wrong language, if so how do I change that in XCode, I looked and couldn't find it!
OneSadCookie
2006.10.30, 02:30 PM
No, it's unlikely to be a problem with the debugger; more likely that you've turned off debug symbols, or that your bug had corrupted the stack to the point that GDB couldn't tell you anything useful :)
Debug symbols are on.
or that your bug had corrupted the stack to the point that GDB couldn't tell you anything useful :)
That sounds like something that I am very, very, capable of ;)
dajtxx
2006.12.18, 10:05 PM
I ported Oolite from Obj-C/Cocoa to GNUstep/SDL so I could run it on Windows and Linux (me not having a Mac).
Just say no to GNUstep - it is terrible. I had to:
Create a main function to get the game running that had to do something with memory pools and get the objects set up like the NIB did on the Mac.
Redo all the screen handling code to use SDL rather than Cocoa (obviously you have no choice in this, even going to C++).
Convert all plists to ASCII format because GNUstep windows can't handle XML plists. I later made a version that did but then you have to distribute the custom version. We also just added some XML plist parsing code into the game itself because most people wouldn't convert the plists in their add-ons.
Debug using NSLog because debugging Obj-C on Windows with gdb is no fun at all - it doesn't handle Obj-C stack traces well either - lots of frames show up as ??
Write replacements for the sound classes because GNUstep doesn't handle them as far as I can see.
There is probably more but I've happily forgotten most of the early porting effort.
Trying to get a Mac app running under GNUstep is a world of development pain. So is converting all your code to C++ but at least you can stop suffering once you've done it!
Note, I'm no C++ fan, but for cross-platform purposes with code already written in an OO extension to C, it is probably the best choice.
Regards,
David.
vBulletin® v3.6.8, Copyright ©2000-2008, Jelsoft Enterprises Ltd.