Best Porting Options - Mac (Cocoa/OpenGL) to Windows

Moderator
Posts: 1,140
Joined: 2005.07
Post: #16
Jake Wrote: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.
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #17
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
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #18
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
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #19
#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.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #20
Jake Wrote: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++.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #21
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.
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #22
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
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #23
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.
Quote this message in a reply
Jones
Unregistered
 
Post: #24
Isn't import like copying and pasting one file into the location of the #import, and #include is something different?
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #25
Jones Wrote: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
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #26
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 Sad
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #27
Jake Wrote: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.
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #28
OneSadCookie Wrote: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!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #29
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 Smile
Quote this message in a reply
Member
Posts: 509
Joined: 2002.05
Post: #30
Debug symbols are on.

OneSadCookie Wrote:or that your bug had corrupted the stack to the point that GDB couldn't tell you anything useful Smile

That sounds like something that I am very, very, capable of Wink
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Options for Web Game Development in OS X Nick 4 4,034 Sep 20, 2008 01:13 PM
Last Post: Nick
  Trying to port an OpenGL Windows game anthony 2 3,830 Jan 26, 2007 02:16 PM
Last Post: anthony
  initializing opengl in cocoa FreeKQuency23 6 3,817 Apr 2, 2006 12:10 PM
Last Post: arekkusu
  XCode project build options + makefiles = compiling fun! Lavareef 2 6,420 Nov 10, 2005 04:30 PM
Last Post: dair
  Windows Event Loop -> Cocoa Timers maaaaark 2 4,128 Apr 11, 2005 11:22 AM
Last Post: Red Marble Games