Carbon (AGL) or Cocoa?

webwarrior
Unregistered
 
Post: #1
I'm currently coding all my OpenGL stuff using SDL. I used SDL because I didn't want to bother about mac related stuff in the beginning and there is a lot more source code on the net. I don't need my programs to be platform independent at all as I would like to make the mac demoscene a bit bigger ;o) (and even with SDL my programs are not completely platform independent). My question is, should I use AGL, CGL or Cocoa? Most of the time I want to have things fullscreen, but I'd also be able to play it in a window. Beside that, as a democoder, I use lots of algorithms written be me or some other guy and I don't want to port them to Objective-C. I absolutely want to code the main parts in C++. Do you have good experience using Objective-C++? I think this way I could code my things in C++ and do the window/event managing in Objective-C right? Does it work good? Or should I better stick to AGL? I don't want to be old-fashioned, but....;o). What about performance?

Thx for your help.
Quote this message in a reply
Member
Posts: 156
Joined: 2002.11
Post: #2
Short answer is that CGL only will let you work in fullscreen. Use AGL if you want your game to run in a window and/or fullscreen. Performance with Obj-C/Cocoa or C++/Carbon is pretty much the same. GLUT has some bugs on OS X in some hardrware configurations.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
Short answer is, with SDL you don't need to worry about CGL vs. AGL vs. NSGL -- just use SDL's functions.
Quote this message in a reply
marlfxx
Unregistered
 
Post: #4
GLFW (glfw.sourceforge.net) is a tiny, functional alternative to SDL. I've found GLFW easier to use — usage resembles OpenGL.

Note: GLFW is based on AGL. To integrate GLFW in an app, you need to use a Carbon target. Without a resource path (ie, as a C++ 'tool'), GLFW windows cannot be brought to the front.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
The Mac port of GLFW is still fairly incomplete... are you saying you've been using it without problems? If so, that's kinda cool...

(I did the initial GLFW Mac port, and am in contact with the current maintainer)
Quote this message in a reply
marlfxx
Unregistered
 
Post: #6
So far, at least, there've been no problems. If you start with a Carbon application target, the window comes to the front. (That was my main problem initially) The key/mouse callbacks work correctly. (I haven't needed to use any other callbacks, or fullscreen mode) What problems have you encountered? (It feels strange asking this question to the mac programmer behind GLFW Smile
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
I don't expect things like toggling windowed <-> fullscreen or closing a window and reopening a new one to work, at least. Basically, I only did enough work to get the demos going :/
Quote this message in a reply
marlfxx
Unregistered
 
Post: #8
Is there a GLFW interface to toggling window/fullscreen? I just use glfwOpenWindow/glfwCloseWindow repeatedly : ) Window toggling is not performance-critical, so I didn't really think or care about a workaround.
Edit: ah, I see what you mean. The above does not work. :/ Back to SDL?
Quote this message in a reply
webwarrior
Unregistered
 
Post: #9
OneSadCookie Wrote:Short answer is, with SDL you don't need to worry about CGL vs. AGL vs. NSGL -- just use SDL's functions.

But I still think that SDL is less efficient isn't it? Aonther advantage would be that I could simply distribute executables, without requiring the user to install any other libraries. Does SDL make sense if I'm coding for OS X only? It's still sort of pain to make it really platform independent even with SDL, header files have different names on diefferent platforms, images flip upside-down... there is a lot of work to do to prevent these things. So my hope was that code gets clearer and more efficient when I'm using AGL or NSGL.

The second question is still: do you have good experience with Objective-C++? That would be the only possibility for me to use NSGL, but the resulting code seems rather confusing to me.

Thx
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
OpenGL is OpenGL is OpenGL -- SDL doesn't interfere with that. Yes, SDL_SwapBuffers is marginally slower than -[NSOpenGLContext flushBuffer], since the one calls the other -- but unless you Swap Buffers several hundred times each frame Rasp, you'll never notice that difference in a real application.

You shouldn't be requiring people to install SDL anyway. You should be including the SDL framework in your application bundle. Search the forums.

I don't see what the problem programming cross-platform with SDL is -- SDL is designed so that one codebase can work on all three platforms without change. This works for various projects I know of, why doesn't it work for you?

Header files that have different names on the different platforms aren't cross-platform; why are you using them? I've never heard of an image being upside down depending on which platform you load it on, though it's true different libraries have different conventions -- but SDL_image is always going to do the same thing; that's the point.

Yes, if you're going to program Mac OS X only, you might as well use AGL or NSGL in some senses, though SDL is probably easier to use.

WRT Objective-C++, I've never seen the point. It's very slow to compile, and C++ is evil anyway -- you might as well just use Objective C.
Quote this message in a reply
webwarrior
Unregistered
 
Post: #11
OneSadCookie Wrote:OpenGL is OpenGL is OpenGL -- SDL doesn't interfere with that. Yes, SDL_SwapBuffers is marginally slower than -[NSOpenGLContext flushBuffer], since the one calls the other -- but unless you Swap Buffers several hundred times each frame Rasp, you'll never notice that difference in a real application.

I wasn't just talking about swapping buffers, but also about timers and things like that. I have the impression that AGL gives me a lot more flexibility than SDL.

OneSadCookie Wrote:You shouldn't be requiring people to install SDL anyway. You should be including the SDL framework in your application bundle. Search the forums.

Yes I should do that :-)

OneSadCookie Wrote:I don't see what the problem programming cross-platform with SDL is -- SDL is designed so that one codebase can work on all three platforms without change. This works for various projects I know of, why doesn't it work for you?

Of course it works, in the end, that's what it is for. But did you ever try it? It's not that simple because of endianess for example. SDL isn't perfect, you still have to write proper functions that deal with it yourself.

OneSadCookie Wrote:Header files that have different names on the different platforms aren't cross-platform; why are you using them?

I agree completely, but then GLUT isn't cross-platform anymore, Mac vs Win, they have different names.

OneSadCookie Wrote:I've never heard of an image being upside down depending on which platform you load it on, though it's true different libraries have different conventions -- but SDL_image is always going to do the same thing; that's the point.

That's not true, it flips, if you don't care about endianess.

OneSadCookie Wrote:WRT Objective-C++, I've never seen the point. It's very slow to compile, and C++ is evil anyway -- you might as well just use Objective C.

I think SDL is based on Cocoa right? So if you use SDL, under the hood, you use Objective-C++ as you write code in C++ and SDL needs Cocoa/Obj-C, so compilation is slow anyway. I'm not an expert in Objective-C, but as far as I know you don't have STL, Templates...

Thx for your help, I'll most probably use AGL :-)
Quote this message in a reply
Member
Posts: 156
Joined: 2002.11
Post: #12
The other members of the forum are already tired of seeing me posting this over here, but there it goes anyway. You can download the source code that shows how to create a window, load textures, create an OpenGL context with AGL or CGL, handle Carbon events, parse XML files, play AIFF files, and some other basic stuff at http://webpages.charter.net/utopiaplanet...Struct.dmg

It uses OpenGL, Carbon, and CoreAudio, so you are pretty much Mac-bound if you decide to use this stuff.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #13
webwarrior Wrote:I wasn't just talking about swapping buffers, but also about timers and things like that. I have the impression that AGL gives me a lot more flexibility than SDL.

Timer's aren't AGL's province... if we're talking SDL vs. Carbon, of course Carbon gives you more flexibility -- it's the API for a whole operating system, not a small cross-platform layer Rasp

Incidentally, SDL's timers aren't useful. Don't use 'em.

Quote:Of course it works, in the end, that's what it is for. But did you ever try it? It's not that simple because of endianess for example. SDL isn't perfect, you still have to write proper functions that deal with it yourself.

Well, you should always be handling endianness anyway... don't tie yourself down!

Quote:I agree completely, but then GLUT isn't cross-platform anymore, Mac vs Win, they have different names.

True, Apple fucked that one up. But aside from the <GL/glut.h> vs. <GLUT/glut.h> issue, it's cross-platform.

Quote:That's not true, it flips, if you don't care about endianess.

Um, SDL_image does exactly the same thing on Mac/PowerPC and Linux/Intel. No flipping. No endianness concerns.

Quote:I think SDL is based on Cocoa right? So if you use SDL, under the hood, you use Objective-C++ as you write code in C++ and SDL needs Cocoa/Obj-C, so compilation is slow anyway. I'm not an expert in Objective-C, but as far as I know you don't have STL, Templates...

Wha?

Objective-C++ refers to the use of both Objective C and C++ from within one source file. SDL is just a C API -- nothing about it forces you into any particular language choice. Just pretend you don't know it's implemented in ObjC Rasp
Quote this message in a reply
marlfxx
Unregistered
 
Post: #14
My take:
Use a cross-platform library, like SDL, because it's simpler. Apple's NSGL and AGL interfaces, while more specific to Macs and thus provide more features, are excessively complex compared to the ease of use of, say, SDL. [Unless you plan to take advantage of Mac-specific features, like window transparency (ie, Bounce)]
You are correct that they give more flexibility, but how much flexibility do you need? I prefer to contain my OpenGL programming to OpenGL rather than the OS's windowing system (then again, I'm a cross-platform programmer).

Also, I wouldn't rely on SDL for anything other than cross-platform video (opengl) — use DevIL for image loading (it's cross-platform and very fast- much faster than QuickTime for certain file types) and OpenAL for audio, mainly because they're specifically made for those purposes. [That is also the reason why I used to prefer the small, specific GLFW over SDL, but apparently it's incomplete]

Timing? Why not gettimeofday?
Quote this message in a reply
Vertizor
Unregistered
 
Post: #15
My understanding about Objective-C++ is that it lets you use C++ classes within Obj-C code. You can design and implement C++ classes within *.m files that normally are parsed by the Obj-C compiler. BUT... you can not use Obj-C classes in C++ code. For that reason, I gave up on Obj-C++ and chose to either go full C/C++ or full Obj-C.

I prefer C/C++ for its syntax and semantics. But since I can't use the NS* classes in pure C++ code, Obj-C++ is useless to me.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Carbon vs Cocoa? Jamie W 11 4,954 May 27, 2009 11:07 AM
Last Post: Ingemar
  is sdl+opengl slower than cocoa/carbon+opengl? Najdorf 9 4,812 Nov 16, 2005 09:45 PM
Last Post: WhatMeWorry
  Carbon vs Cocoa OpenGl Byron Clarke 2 2,833 May 31, 2005 05:47 PM
Last Post: maaaaark
  SDL, Cocoa or Carbon? Taxxodium 7 4,481 Jan 10, 2004 10:58 PM
Last Post: OneSadCookie