OpenGL choices

Apprentice
Posts: 14
Joined: 2005.12
Post: #1
I've searched around here a little and didn't see anything really comparing the different options of using OpenGL. I'm looking for some guidance in choosing the best approach. I know C, C++, and Obj-C, so any of those languages is fine. I know a little Carbon and some Cocoa.

From reading postings here, it seems there are a couple of different ways to go:

GLUT/OpenGL - Start with a blank project, addin the frameworks, etc. and use GLUT for the setup/menu/etc. and OpenGL calls for the drawing. This follows the NeHe tutorials (with the addition of GLUT for the Mac).

Carbon/OpenGL - Haven't looked at this much since the Carbon basics of menus/dialogs seems more of a hassle than Cocoa.

Cocoa/OpenGL - This looks really interesting since Cocoa is handling all the low level setup stuff and I basically just have to handle the drawing via OpenGL calls. (I'm meaning using a custom NSOpenGLView subclass here).

What I'd like opinions on are the following areas:
- If I want my game to be more Mac like (using Aqua interface elements) for preferences and other dialogs, which is the best choice above?

- If I'm wanting most of the code to be used cross-platform, which is the best choice? I'm okay with non-OpenGL elements like preference dialogs and menus being platform specific, but I'd want the bulk of the OpenGL drawing code to be reusable on something like Windows.

- Are any of the choices above more likely to give me problems when producing Universal Binaries?

- Is the animation timing under Cocoa a problem when porting to other platforms since one doesn't seem to use the main application loop but rather an NSTimer instead?

- Other areas of consideration/pitfalls?

So far it is looking like Cocoa/OpenGL for me using Objective-C++. Then I can have all the OpenGL drawing code and objects used in drawing things be regular C++ and I would also have the ability to use Cocoa for any dialogs I wanted to show.

PS. At this point I've settled on using OpenGL. I have looked at various packages such as Torque and have looked at other API's like Quartz.
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #2
Cocoa/OpenGL is your best choice if you want to use aqua items,
I write OpenGL code with cross platform'ness in mind, like this

ObjC subclasses of NSOpenGLView to handle setting up the pixel format, calling an animation timer, calculating frame's per second etc, anything platform specific basically, and keep it to a minimum.

then in plain C I write non platform specific functions like
gamename_init();
gamename_draw();
gamename_animate(float dt);

and any other callback, like for example
gamename_slider_1(float value);

Here's an example of such an application
http://www.fax.evolpenguin.com/01_src.zip
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #3
Carbon and OpenGL will be your best bet if you want to port to other platforms: that way you just have to translate the function calls, rather than both the function calls and the language. However, Cocoa is the easiest for normal GUI elements. (just out of curiosity, what kind of game are you making? I think that in most games, aqua GUI elements would look out of place) GLUT would actually be the easiest to port, but I don't recommend it since you don't have much control over things such as the OpenGL context. For universal binaries, GLUT might give you a problem, as well as other 3rd party libraries if they aren't compiled as universal binaries. Also, you have to be careful that you don't do anything that is byte-order dependent.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
GLUT isn't a 3rd-party library, and SDL was ported within fifteen minutes of the keynote finishing Smile
Quote this message in a reply
Apprentice
Posts: 14
Joined: 2005.12
Post: #5
I'm probably going to make a simple kids educational game. Since it's my first game (I've done other applications that I've sold) I want to keep it simple. I'm mainlyl thinking of a preferences type dialog where I would want to use Aqua on OS X. I agree that in game controls would need to be drawn and not Aqua controls.

Looking a simple example of drawing by using an NSOpenGLView subclass, it looks like the drawing (if done in a c++ class called from drawRect) would port over quite nicely. It doesn't seem like there would be a lot of other Cocoa/Objective-C++ code that I would need. Or am I missing something (aside from the animation call)?
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #6
It's also somewhat different if you're doing windowed or full screen. If it's windowed, everything is just contained in your view, so there isn't much to translate. If you do it fullscreen, your code tends to be a little more spread out. At least mine was when I made a full-screen OpenGL app. I would do things differently now, however. (I would also use carbon, though)

I guess GLUT isn't really 3rd party after all, since it's made by OpenGL and Apple does OpenGL on the Mac. Rasp
Quote this message in a reply
Apprentice
Posts: 14
Joined: 2005.12
Post: #7
Thanks for all the input, it helps to find out what has worked for other people so I don't have to go through as big of a learning curve.
Quote this message in a reply
Moderator
Posts: 387
Joined: 2002.08
Post: #8
unknown Wrote:Cocoa/OpenGL is your best choice if you want to use aqua items
...
Here's an example of such an application
http://www.fax.evolpenguin.com/01_src.zip

That project, along with some other OpenGL projects, are giving me an error in Xcode 1.1. Yes, I need to update to 2.x... but I still think this error is strange:

Quote:Couldn't open /Users/funkboy/Documents/Chapter 4 OpenGL Optimizations/OpenGL Optimizations.xcode.

Reason: *** -[PBXToolbar _notificationPostingEnabled]: selector not recognized [ self = 0x11d4240 ].

Anyone have any ideas what the cause (and a possible solution) is here?

KB Productions, Car Care for iPhone/iPod Touch
@karlbecker_com
All too often, art is simply the loss of practicality.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #9
It means that the it doesn't see the method _notificationPostingEnabled for PBXToolbar. Rasp To fix it, make sure that the method is spelled correctly etc. If your PBXToolbar class doesn't have that method, then I don't know.
Quote this message in a reply
Post Reply