Getting started on a Mac with OSX

I’m familiar with using Visual Basic C++ on a school PC to dabble into OpenGL. At this point, I want to get hooked up at home on my Mac that’s running OSX (10.2.8).

What programs and files do I need to get everything up and running? Will I be able to easily run the work I’ve done on the PC?

You need the developer tools. You can download them from http://connect.apple.com (free registration required; must be 18+). Be aware that the latest version only works with Mac OS X 10.3, so you’ll need an older version.

(Incidentally, Mac OS X 10.3 is a highly recommended upgrade for OpenGL work; a number of important bugs have been fixed since 10.2.8).

There’s a quick tutorial on how to get OpenGL working in Xcode (10.3-only) here: http://onesadcookie.is-a-geek.net/~keith/XcodeGLUT . Most of the tutorial would be the same for Project Builder 2.x (10.2.x only); the only major difference should be that you create an “Application” target rather than a “Carbon Application” target.

You should stop by the idevgames forums at http://www.idevgames.com/ ; that’s by far the best resource for game and gamelike development on the Mac.

Thanks for that nice Xcode/glut tutorial Keith.

Strange that you’d add the Cocoa framework… my little glut programs work just fine with the Foundation framework rather than (the larger?) Cocoa (see makefile below). Am I missing something?

Also, why would you choose “Carbon Application” as your target, while at the same time linking in the Cocoa framework?

vos3 – I’ll add that you don’t need to use Xcode for your OS X glut programs if you don’t want to. I just use a simple makefile:

makefile for simple glut programs on Apple OS X.

APP_NAME = osx_glut_program
CPP_FLAGS = -c
FRAMEWORKS = -framework OpenGL -framework GLUT -framework Foundation

(APP_NAME): main.o g++ main.o -o (APP_NAME) $(FRAMEWORKS)

main.o: main.cpp
g++ $(CPP_FLAGS) main.cpp

explain:
@echo “APP_NAME == (APP_NAME)" @echo "CPP_FLAGS == (CPP_FLAGS)”
@echo “FRAMEWORKS == $(FRAMEWORKS)”

clean:
rm -f $(APP_NAME)
rm -f *.o

and build from the command line by running ‘make’. Try using this makefile along with the simple code from OneSadCookie’s tutorial. :slight_smile:

It’s true that the Foundation framework is sufficient, in fact -lobjc in the linker flags is sufficient. It’s just easier to say “GLUT on Mac OS X is implemented in Cocoa so you need the Cocoa framework” than it is to say “Because your application links with Objective C code (in GLUT) the static linker requires that you link to the Objective C runtime library so that it can initialize the Objective C runtime at program startup”.

As for why a Carbon application – because Xcode’s precompilation stuff is buggy. If you make a Cocoa application, you must call your main file main.m (or main.mm?) to avoid compile errors. Go figure… but a Carbon application works fine. Under PB, I create a generic “Application” target, which is neither Cocoa nor Carbon. Xcode’s Carbon app template is the closest Apple-supplied template to this.

If you’re working with Makefiles (or have the guts to try to change the warning flags in PB or Xcode), I highly recommend these flags:

-Wall -W -Wno-unused-parameter -Wnewline-eof -Werror

(-Wall is warnings you always want because they’re always errors; -W is warnings you almost always want because they’re almost always errors; -Wno-unused-parameter turns of warnings for unused parameters to functions, which -W turns on; -Wnewline-eof is an Apple-only flag which restores GCC’s default of warning if your source file doesn’t end with a newline. This is for compatibility with GCC on other platforms; -Werror makes all warnings into errors so you can’t ignore them)

Your code will be much better for it

Hi Keith,

Any chance you have a few minutes to compile my SpaceTime Screen Saver with Xcode, just to see if it works under Panther?

I’d be pleased to buy you a pint of your best local bitter next time I’m down your way :wink:

Cheers,
/p2

(Incidentally, Mac OS X 10.3 is a highly recommended upgrade for OpenGL work; a number of important bugs have been fixed since 10.2.8).

Too bad Apple actually introduced more bugs in 10.3 than they fixed. I used to be a Mac die-hard, but now I’m disgusted with their engineers’ complete lack of competence. If you want your OpenGL application to actually work correctly, use a PC. The Windows drivers are stable as hell compared to the Mac.

My understanding is that the division is severely understaffed, but yes, I find the bugginess highly annoying. At work, we have a product which could ship on the Mac if the OpenGL drivers were stable and behaved according to spec. As is, we only support Linux.

Apple’s approach of a hybrid OS vendor / hardware vendor driver has certain benefits, but bug-free-ness and up-to-date-ness certainly doesn’t seem to be one of them.

[This message has been edited by OneSadCookie (edited 12-06-2003).]

Frankly, I don’t see how Apple is allowed to display the OpenGL logo on their web site, since they are shipping non-conformant drivers. Did they bribe the conformance test people?

All the vendors ship nonconformant drivers. NVidia’s drivers advertise 1.4 support for the GeForce4Ti, despite not implementing the full feature set, for example.

Apple’s drivers are just buggier than most

well - I’m not sure what you mean about Windows OpenGL driver being stable.
We ship a commercial product on OSX and Windows. We get litterally hundreds of support emails from Windows users whose drivers are so buggy our app won’t run - and our app doesn’t do anything particularly weird or complex.
Sometimes the problems are cured by updating to the latest drivers, sometimes even the latest ones don’t work properly. We have ended up recommending that the last resort for some users is to use DirectGL - which is an openGL driver which just wraps the hardware’s DirectX driver. A lot of times this is necessary because the cards don’t even have ANY openGL drivers, or they are so out of date they’re useless.
In contrast we’ve only ever had one bug in the Apple drivers, and Apple and ATI worked with us to sort it out with a week.

I’m not saying the Windows drivers are perfect, but relative to the state of the Mac drivers, they are in much better shape.

It sounds like you support older cards. I tend to use the latest and greatest features, and Apple’s stability when it comes to advanced extensions is utterly abysmal to the point of being unprofessional. They should be embarrassed.

Originally posted by OneSadCookie:
All the vendors ship nonconformant drivers. NVidia’s drivers advertise 1.4 support for the GeForce4Ti, despite not implementing the full feature set, for example.

Not sure what you mean by this. Its perfectly valid to export support for OpenGL 1.4 and not support some features in hardware, as long as there is a software fallback in the driver.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.