Fastest Game?

clapton541
Unregistered
 
Post: #1
What would be the best way to have the fastest game possible?
Cocoa
Carbon
SDL
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
Completely irrelevant.

To get the fastest graphics, you'll need to use OpenGL.
Quote this message in a reply
Member
Posts: 90
Joined: 2006.11
Post: #3
You would use OpenGL rather than SDL for graphics...
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #4
Carbon is technically the fastest in a general sense, but trying to decide which API to use for games based on speed is a big mistake (and irrelevant, as OSC pointed out). No matter which one you choose, after you decide to use OpenGL for the graphics, the number one limitation to speed is always the developer. Good design is where the speed is at, not the base API. You might be surprised to find out that all of those AAA games that tout how fast they are, often do their game logic in a scripting language! Wuh, you say? Yeah, a scripting language, sometimes multiple orders of magnitude slower than the base API. There are several reasons for that, but since the graphics are mostly off-loaded to video hardware nowadays, that often leaves lots of space on the processor to do the game logic with whatever API you wish -- even a lowly scripting language. So don't worry about API speed, look for features you like instead.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
AnotherJake Wrote:Carbon is technically the fastest in a general sense

Lots of people claim this, but I have never seen any indication that Carbon is any faster than Cocoa for these purposes. It's also impossible to use OpenGL in a Carbon window without calling deprecated functions, so it's not a good path for the future.

You could claim that SDL is slower than Cocoa legitimately, but the layer is so thin I doubt you could measure the difference.
Quote this message in a reply
Member
Posts: 90
Joined: 2006.11
Post: #6
Just don't use SDL when you have OpenGL, like the game Wesnoth.
Quote this message in a reply
clapton541
Unregistered
 
Post: #7
Thanks but do you know a really good Cocoa OpenGL tutorial that teaches simple things like getting time, drawing to the screen, using bitmaps, user input, and maybe 3d mesh loading?
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #8
clapton541 Wrote:Thanks but do you know a really good Cocoa OpenGL tutorial that teaches simple things like getting time, drawing to the screen, using bitmaps, user input, and maybe 3d mesh loading?
http://nehe.gamedev.net/

OneSadCooki Wrote:Lots of people claim this, but I have never seen any indication that Carbon is any faster than Cocoa for these purposes.
Me neither. I put in the `technically' qualifier because of the messaging overhead of Obj-C/Cocoa. In terms of end results, that messaging overhead doesn't seem to matter much, if at all. Heck, I wouldn't touch Carbon with a ten foot pole regardless. SDL or Cocoa are the only two currently sensible paths IMHO.
Quote this message in a reply
Apprentice
Posts: 11
Joined: 2007.01
Post: #9
OneSadCookie Wrote:Lots of people claim this, but I have never seen any indication that Carbon is any faster than Cocoa for these purposes.

Actually I think it's written in the Apple docs, although I'll have to try and find it again. The speed differences between the Cocoa Obj C messaging system and straight C calls to Carbon API's are substantial. Cocoa's actually pretty slow in that regard. Although in this case 'slow' is a relative term, and as you said, once the graphics work is put on the video card it's somewhat irrelevant.

But, technically, Cocoa's Obj C messages are slower than their straight C Carbon equivalents from what I've read.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
Yes, an ObjC message send is slower than a C++ virtual function call which is slower than a C function call... but it provides flexibility. By saying "Carbon is faster" you're assuming that it doesn't need equivalent flexibility underneath, at equivalent or greater cost.

If you're sending thousands of ObjC messages, you might end up needing to improve your performance, but such cases are very few and far between. For creating a window and handling events, you're not going to notice.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #11
Objective-C messages are about 4-7 times slower than C function calls last time I checked... But you may very well make about 4-7 times as many API calls in Carbon as in Cocoa to accomplish the same thing. Smile

Objective-C messages can be made as fast as C function pointer calls, where necessary. See NSObject's +instanceMethodForSelector. Note that in the three Cocoa games I've released, I've only had to use this in one place for one of them. Most of the time, it's not something you'll need to worry about.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #12
When I've profiled my code in Shark, the system level ObjC stuff accounts for less than maybe 1 or tops 2% of total CPU time. The rest is spent in my C++ game code ( and obviously OpenGL ).

So, they way I look at it, I've got a thin shim of beautiful easy to read, easy to edit, easy to write Cocoa code interfacing cleanly and robustly with the system, so my more or less portable C++ can do the actual work.

Carbon has an important role in OS X: legacy apps. You couldn't pay me to write fresh code in carbon.
Quote this message in a reply
Member
Posts: 37
Joined: 2006.08
Post: #13
The beautiful thing about Objective-C is that it is still C. So write your game engine in C with OpenGL and tie it in to Cocoa for the OS-specific functions (io/display setup/sound/whatever). Then you have a very portable game with a good Mac interface.
Quote this message in a reply
Member
Posts: 28
Joined: 2006.12
Post: #14
So using Python with pyOpenGL will be almost as fast as carbon and openGL?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #15
You can't compare a language (Python) with an API (Carbon).

Python is slower than C. Most of the time, that's not a problem.

OpenGL is OpenGL is OpenGL. It doesn't matter what language you use.
Quote this message in a reply
Post Reply