Cocoa speeds - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: Cocoa speeds (/thread-7373.html)
Cocoa speeds - skyhawk - Jan 26, 2003 02:27 PM
I don't mean to get off on a rant here, but Cocoa is NOT slow. Yes, like ANY programming language, it CAN be slow, but it does not have to be. I have made cocoa games that are blazingly fast. And once any game runs faster than 120fps, it is ALL excess waste. This was of course stemmed from someone's idea that cocoa is not good for games. I beg to differ. Cocoa allows for easy control implmentation. It has an easy to use Foundation. And it allows for easy building of an interface, even if all that interface is is a 640x480 window that has an opengl context in it. Time to make: 15 seconds (or slightly longer for those with slower computers and slower hands)
Also, BOB2 got 150fps on a 400MHz G4
Smiley Tag was capable of hundreds and hudreds of fps (I heard some people saying thousands, but I would like to see evidence of that) The fact of the matter is, these games were designed in cocoa and they are MUCH faster than many games on the same machines. Of course, these are just my opinions, I could be wrong.
Cocoa speeds - David - Jan 26, 2003 02:39 PM
I've had no problems with Cocoa speed but I still like Carbon and C++ better for compatibility
Cocoa speeds - DoG - Jan 26, 2003 02:51 PM
ObjC really screws you when you have a lot of small functions (one-liners), where the function calling overhead really shows. In C++, the overhead is already slower, and the functions can be additionally inlined, zeroing function call overhead. So, depending on what you do, ObjC can hold you back a lot. It is not as slow as the BASICs or the likes, but it is not as fast as C++ either. If you think about it, except for sending messages, you are working in C, which is as fast as it gets.
Anyhow, speed is not running your game at 120 fps, but making it look amazing at 20-30fps. I can make anything run at 120 fps if I throw everything out.
I do use Cocoa for interfaces, because Carbon just can't beat it there, but I would not implement my vectors and matrices as ObjC objects.
Cocoa speeds - skyhawk - Jan 26, 2003 02:55 PM
Quote:Originally posted by DoooG
mmhmmm, Good point. This of course will be going in my AIM profile
Cocoa speeds - geezusfreeek - Jan 26, 2003 06:42 PM
Dooog, two things to mention here. First, C++ has almost no overhead, and none at all (compared to C) if you program it well. Second, you are not supposed to create tons of tons of objects in Objective-C, whereas you are supposed to in C++. In Objective-C, it is better to use a few larger objects, thus saving messaging time. When programmed with a good design, Objective-C will run almost as fast as C++. In any case, the speed difference is not enough to make a programming decision. The only reasons I can see to choose C++ over Objective-C would be if you are using Carbon rather than Cocoa, or if you're porting something which was originally in C++.
Cocoa speeds - FCCovett - Jan 26, 2003 06:59 PM
Don't get upset but I can barely get 20 fps playing BOB2 on a iMac 333 in a tiny window, and it's a simple sprite game.
Any game I make with Director runs faster than that, with lots of sprites, fullscreen at 1024 X 768. I am not impressed at all with the performance of BOB2. Perhaps it has something to do with hardware acceleration, but it isn't a good example of high performance.
Cocoa speeds - OneSadCookie - Jan 26, 2003 07:07 PM
Quote:First, C++ has almost no overhead
That's what they'd like to make you think...
The truth is that object-oriented design has significant overhead. I wouldn't make a Vector3D class (for a 3D game) in C++ any more than I would in Objective C (although it would be faster in C++).
Cocoa speeds - skyhawk - Jan 26, 2003 07:11 PM
BOB2 does not use sprites
BOB2 does use a lot of particles ( The version I made after the contest lowered the numbers of particles and increased the quality of their displaying) Think 10k-20k of particles.
BOB2 uses OpenGL, if you don't run other OpenGL programs well, you won't run BOB2 well.
All this being said, I should make it more scalable for machines 5+ years old. But, I've ran it on 3 machines so far. Mine ( G3 400Mhz 8MB graphics card), my dad's (G4 400Mhz, 16MB graphics card), and my friend's (dual 533, Geforce3) and from my experiences on all 3 of these computers, it scales up amazingly well. As for making BOB2 in Director, I doubt it. Especially with the extensiveness that the BOB2 engine has. Plus, if BOB2 really runs that "bad" you can always shrink it to be 320x240.
Cocoa speeds - Tycho - Jan 26, 2003 08:11 PM
The 333 iMac had a Rage Pro which, if I recall correctly, does not have accelerated opengl drivers for OS X.
Cocoa speeds - FCCovett - Jan 26, 2003 09:05 PM
There's probably little to benefit from scaling BOB2 back to work on olders machines; it's clear that the problem is the lack of hardware acceleration.
I still think you could do a similar game with Director and get better performance on older machines, specially because the game is basically 2D. I say that because my latest game is more involved than BOB2 in the sense that it offers 6 DOF in a 3D space and it performs very well in older machines. Of course you wouldn't be able to have as many particles on the screen at one time, but the game would detract very little from that. If you are interested, I can give you a courtesy copy of my game so you can see what I mean.
In the end, I conclude that BOB2's performance is mainly affected by the speed of the graphics card and the OpenGL layer.
Cocoa speeds - skyhawk - Jan 26, 2003 09:35 PM
So that means 2 things can contribute to speeding up BOB2 dramatically versus only 1 thing can improve the Director game. A graphics card or a cpu enhancement would both aid the speed of BOB2. Same with all OpenGL games. But, also conversely, that gives it 2 things to be drawn back upon. But as I said, Cocoa was more than fast enough for it. In fact, I don't think you could get a much faster OpenGL game (there are a few exceptions I know). The fact of the matter is, Director's speed doesn't scale up as much as one that uses hardware acceleration.
But, the thing is, people are saying COCOA isn't fast enough, and that just simply isn't true.
And I would appreciate a courtesy copy of your game to see what you mean, email@example.com
Cocoa speeds - David - Jan 26, 2003 09:41 PM
BTW... what game is this?
Cocoa speeds - Bachus - Jan 27, 2003 02:00 AM
For non-accelerated 2D graphics Cocoa is far, far slower than Carbon. At least, if you use standard calls (Quickdraw versus Quartz basically).
About 6 months ago I ran some simple tests that just blitted a couple of sprites to the screen. Using Carbon calls I could get 200fps easy but under Cocoa I was lucky to get 10fps. With a hell of a lot of optimization I could get around 30fps, but we're talking with like 10 sprites max, and no other code going on. And hell, with BlitPixie or some other custom blitter I could get over 800fps. The Cocoa Sprite Kit got similar results in speed, maxing out at around 10fps. On a G4 the framerate was quite playable, but if you're severely limiting your audience if you require both OS X *and* a G4.
Cocoa may not be slow depending on your point of view, but it's definitely slower than Carbon. At least for non-accelerated graphics.
Cocoa speeds - DoG - Jan 27, 2003 03:11 AM
Quote:Originally posted by Bachus
And it is hell slower for OpenGL, too! I can play war3 in OS 9 1024x768 full detail, but it is already barely playable on 800x600 lowest detail in X. The same goes for all other games, where q3a seems to be the least affected, though it still is.
Cocoa speeds - Damian - Jan 27, 2003 03:56 AM
Quote:Originally posted by geezusfreeek
Doubtless you know, but for any newbies reading this thread, you can of course use Carbon functions in a Cocoa app.
Cocoa is great for GUI-intensive games (e.g. turn-based strategy or cards) which by their nature don't have to run fast anyway. For intensely graphical games, what matters is the centre of the loops, which will be calling the same OpenGL, QuickDraw or QuickTime code no matter what language the app is written in.
You can use NSQuickDrawViews in a Cocoa GUI, getting the best of both worlds if you want. Games generally run faster under OS 9 because of co-operative multitasking. A high performance game can simply not co-operate, hogging the CPU. OS X's pre-emptive multitasking doesn't let you get away with that. Thus even Carbon games can be faster under OS 9 vs X.