Cross platform question

Apprentice
Posts: 6
Joined: 2007.08
Post: #1
Hi everybody

This is the first post in this forum. I've been searching through it but couldn't find the right answer. I want to create OpenGL based game for Mac, including a simple game engine. I want to use OOP so I'm thinking Objective C. However I want to keep the game and engine as cross-platform as possible in case I decide to widen the audience (mainly with Windows).

1. Is Objective C the right choice - is it possible to do OpenGL in ObjectiveC on Windows? GCC should support it, but what about the ObjC runtime libraries, like foundation classes?

2. I'm thinking about implementing the windows/keyboard/mouse with GLUT so it's more easy to port. Would Cocoa implementation with NSOpenGLView mean a lot of redesign during porting to PC?

3. Which sound library would you recommend to be easily ported between the platforms?

4. If I decide to go Cocoa way - what are the options for doing "standard game loop"? NSTimer is currently the only one I'm aware of, but is this solution good (read fast) enough for a production game?

Thanks for your opinions,
Tom
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
1) No. You'll inevitably have a little ObjC for interaction with Cocoa, but ObjC as a language is a second class citizen on other platforms, and none of the Cocoa libraries are available there. Pretty much any other language you pick would be a better choice than ObjC. Except Visual Basic.

2) GLUT isn't suitable for a shipping game. SDL is a cross-platform solution, or you can write windowing code for 3 platforms yourself, which isn't all that difficult.

3) I would say OpenAL, but there's been a lot of negativity toward it on platforms other than the Mac recently, and it has its share of problems even on the Mac. Other potential possibilities are SDL_mixer, PortAudio, and FMOD.

4) NSTimer is perfectly good enough for this. If you really want, you can take control of the event loop yourself, but there's no *performance-related* reason for doing so.
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2007.08
Post: #3
Thanks for the quick reply.

1. Looks like I'm "stuck" with C++ then (or maybe C, but I would prefer OOP). I am experienced in both languages, but prefer the ObjC...

2. Can you tell me a bit more why GLUT isn't suitable? I also read in some posts about SDL not being recommended either? Using Cocoa for the windowing wouldn't mean much trouble porting the application anyway, so what do you think about NSOpenGLView? I guess user interaction should then be handled with SDL to have a common code for all platforms.

4. I read about NSTimer lowest frequency about 50/100ms, so I thought it cannot be used for very fast FPS.

Thanks again, Tom
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #4
kordeul Wrote:4. I read about NSTimer lowest frequency about 50/100ms, so I thought it cannot be used for very fast FPS.
This is incorrect. NSTimer can run much faster than this. I'm not aware of an upper limit other than the one imposed by your physical CPU speed.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #5
ThemsAllTook Wrote:This is incorrect. NSTimer can run much faster than this. I'm not aware of an upper limit other than the one imposed by your physical CPU speed.
I *suspect* they might cap it at 1000 Hertz, at least that's the way it seems when being used with OpenGL from what I've seen, but that obviously wouldn't be a problem anyway Wink

kordeul: SDL should be perfectly fine for commercial cross-platform products.

GLUT was not designed for commercial products (which is even stated in the Red Book), but rather as more of a learning tool for OpenGL. There are various issues you may encounter when trying to get it to do everything you might want as far as windowing. You can certainly start with it, and if you find you need nothing more from it then you may even release a commercial product with it. But from our own experiences we can tell you that you will more than likely come up short with it for a commercial product, and wind up posting a question like: "Why can't I get GLUT to do blah blah blah for me?", for which you will receive a reply something like: "Because GLUT wasn't designed for commercial products."

If you do prefer to go with Cocoa for your windowing on the Mac, yes NSOpenGLView is what you're looking for, but don't use the one in Interface Builder. You'll either have to make your own from an NSView or subclass one yourself (my favorite) to use as a custom class for the CustomView from InterfaceBuilder.
Quote this message in a reply
Apprentice
Posts: 11
Joined: 2007.02
Post: #6
I wish to add my two cents here as well. As some already have stated, don't use GLUT. I would go as far as saying, don't look at it at all.

Go directly SDL for cross-platform as it can handle (basic) windowing, keyboard and mouse perfectly. As an example, if you would go GLUT, difficulties with keyboard and mouse would quickly arise. Also as a game developer, you immediately loose your game-loop as GLUT uses callback functions.

Hope this helps, and good luck! Smile
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
UT2k4 and Feeding Frenzy at least are commercial games ported with SDL, so it's not that poor a choice Wink
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #8
If all you want is a nice x-platform way to open a GL context, and get input (mouse, keyboard, gamepad) then SDL is quite nice. I have less than 300 lines of SDL code to do everything I need for my Ruby game environment.

I'd stay far far away from it's low level graphics features though. They're a real pain, and pretty slow too.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2007.08
Post: #9
Wow, thanks for all feedback. I think I will start with Cocoa using AnotherJake advice for drawing - this will also make debugging and parameterizing much easier - I plan to have a helper panel where I can set various flags and parameters during the runtime so I can get immediate feedback on how it affects the gameplay. This would not be included in the final product, only to get the desired feeling to the game. Then I'll check SDL for keyboard/mouse/sound.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
You don't seem to understand that SDL isn't really a mix and match option. You take SDL's window, events, and audio, or you take none.

It may be possible to add small additional bits of Cocoa (eg. a preferences dialog), but it may equally not be; I'm not an expert in the internals of SDL.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #11
Yeah, if you're going to use Cocoa for windowing instead of SDL, you might as well use Cocoa for keyboard and mouse too, which is pretty easy. Like OneSadCookie said, and as far as I I've ever seen it used, SDL is an all or nothing proposition.

Either way, you can use OpenAL for sound.

This is a dilemma that everyone has to go through when choosing how they want to get started with it, so don't feel too bad if it all seems like a major pain.Wink

It boils down to this: Either you use Cocoa and all its stuff for your windowing and basic facilities, or you use SDL. There isn't very much in-between those two directions. If you use SDL then you get cross-platform compatibility out of the box, but you lose some UI flexibility. If you go with Cocoa then you get no cross-platform compatibility but you get ultimate UI flexibility.
Quote this message in a reply
Sage
Posts: 1,066
Joined: 2004.07
Post: #12
While using Cocoa for windowing and SDL for keyboard/mouse input is a pain, you can initialize just the audio or joystick subsystems and only use those. Check out http://docs.mandragor.org/files/Common_l...linit.html.

But like Jake and OSC said, probably easier to just use one or the other than mix them together.
Quote this message in a reply
Member
Posts: 104
Joined: 2007.01
Post: #13
OneSadCookie Wrote:UT2k4 and Feeding Frenzy at least are commercial games ported with SDL, so it's not that poor a choice Wink

Don't forget Dirk Dashing!

Using SDL + OpenGL has worked very well for me, and is an excellent cross-platform solution: Dirk Dashing is available on Windows, Mac, and Linux. I also use SDL_mixer for audio and FreeImage for loading textures, both of which are also cross-platform.
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2007.08
Post: #14
I see. In this time I compiled a quick Cocoa based framework for testing and it was very simple. From all discussion here I think I will start with Cocoa. My idea is to completely separate the game from other screens - this way I can use Cocoa for the setup part, and create a defaults file based on user choices, then read that defaults when starting the game; the game state would also be saved back to the defaults, so the rest of the application can update it's data based on that. I can then use whatever system I want for preferences and other "static" stuff. This should only mean implementing static screens from scratch when porting and this shouldn't present any big obstacle. My main idea behing this is I think it should be much easier implementing UI stuff using standard system widgets then doing it in OpenGL. At least for quick setup, perhaps the real thing would still need to be ported to SDL to make it more appealing.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Cross-platform gui? Duane 13 5,462 Jul 6, 2007 06:38 PM
Last Post: mac_girl
  Best cross platform API for PC & MAC Tarek Demiati 6 3,226 Apr 16, 2006 03:07 PM
Last Post: Dan Potter
  cross-platform code leggo 35 12,372 Jul 18, 2004 05:05 PM
Last Post: Fenris
  Cross platform game code on a budget Carlos Camacho 7 3,716 Apr 19, 2003 09:29 PM
Last Post: Mars_999
  Cross-platform Solutions DJBlufire 13 4,946 Feb 16, 2003 02:40 PM
Last Post: athomson