Graphics Engine Development Under Mac OS X/Cocoa

I am in the process of evaluating different technologies for the creation of a 3D visualization engine that will run under Mac OS X developed in Cocoa.

The question, is Cocoa and Objective-C to prohibitively slow to use as a real-time 3D graphics engine base? Is it a better choice to program the engine in ANSI C/C++ and simply create Obj-C wrapper classes for the graphics library?

I would prefer to create the entire engine in Cocoa even for low-level structures (i.e. vertex, triangle, mesh, etc.) But I do not want to get 6 months down the road and find out that Cocoa’s message handling run-time environment is preventing reasonable framerates at neccesary triangle counts.

Additionally, I am reasonably well versed in Cocoa/OpenStep development, so technical or advanced details are appreciated.

You’ll probably get a better response at the http://www.idevgames.com forums than here.

My advice: “Mesh” is probably OK as a class, anything much more low-level there’s probably too much overhead.

My advice: You probably don’t want a triangle or vertex class anyway, but a VertexArray or VertexBuffer class, which you might well be able to get away with writing in ObjC.

Thanks for the advice. I’ll check out idevgames.com.

The question, is Cocoa and Objective-C to prohibitively slow to use as a real-time 3D graphics engine base

About Objective-C: It’s depends a lot how you use the langage and how do you plan to model classes. IMHO Objective C is far more productive than plain C and even C++ (which is rather complex for a novice).

About Cocoa: if you engine must use Aqua interface this is the way to go, if not, you might get better performances by using CGL in fullscreen.
The only differences is in the way you initialize and manage OpenGL contexts, so you probably can sill use Cocoa for a windowed version, and CoreGraphics for a fullscreen version.

I used carbon to do Gizmo3D (www.tooltech-software.com) which is a c++ engine. It is fully windowed aqua friendly so there is no need to use Cocoa if you need only C++.

I guess objective c is as fast as c++ in most cases…

Some good resources here; obviously you folks know the score.

Can I ask about Cocoa from the standpoint of retain/release counts?

It seems really stoopid to me to have to budget time in my day to manually account for object retail and release counts.

I just can’t seem to get over the gumption trap! Java has auto garbage collection, and even C++ destructors seem reasonable, but for a new platform like Cocoa to ask programmers to account for object usage (PER EVENT LOOP?!?) seems outright looney.

As you guys have real trigger time with Cocoa, can I ask: am I over-reacting?

Grats,
Baffled

How do you handle shared objects in C++?

The retain/release/autorelease calls can be thaught of as a manual garbage-collection. C++ doesn’t have this feature at all, this lack of a standardised memory management for shared objects in C++ tend to lead to eather memory leaks (when are we allowed to deleate objects) or to much memory beeing used due to copying of objects.

The release/retain counting does in no way compare to the C++ destructors. The destructors are avilable in ObjC as well, but in ObjC they are known as the dealloc method.

And the tracking per eventloop is only done when using autorelease, wich you should avoid doing, unless absolutely necissary.

The retain/release-method (actually this is called reference counting) is in my opinion a very conveniant way of handeling object diposals.

Actually i prefer pure C, but I beleve that ObjC is more useful (for application development that is, I would never code low level stuff in ObjC) than C++.

Thanks very much for the insights!

I just picked up the 10.2 release and will have another go at Cocoa.

I’m trying to port my OpenGL code from Windows to OS X and needed a kick in the pants to get over my philosophical blockage with reference counting. I’m sure I’ll be okay once I just buckle down and get started.

Thanks again…

You’re welcome!

I must point out these two articles about writing accessor methods, they should shead some light on the ref-counting mechanism.
http://www.stepwise.com/Articles/Technical/2001-03-11.01.html
http://www.stepwise.com/Articles/Technical/2002-06-11.01.html/

If you want to I can send you two C++ classes that implement the same concept (not thread safe though). Send an e-mail to: “mattias dot holm at contra dot nu” if you want the code.

I have just uploaded the C++ development kit for MacOS X 10.2 for the 3D engine Gizmo3D. It is a high performance scene graph used by many professional customers.

If you are interested in how to manage C++ smart pointers then you should have a look at it :wink:
www.tooltech-software.com

/Anders

I’ve developed a very successful (for me :P) engine in C++/Obj-C. It was very fast, compared with my other stuff. The only reason i ditched it was because i got pissed off at my ColDet code (now i’m writing a full C++ one, for some reason :P). Basically the design of “Snoochums Ninjapants” (that’s it’s name!), was that all the rudimentary stuff (Meshes, bla bla) was C++, then higher level stuff (AI, Cameras, Characters, etc) was in Obj-C++ (to call down to the meshes). It worked great, and if you like, i can send you the most recent code (or a working level).

Erik

(ethorteran@mac.com)

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