For 2D (sprite) games, do I use OpenGL or something else? - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: iPhone, iPad & iPod Game Development (/forum-11.html)
+--- Thread: For 2D (sprite) games, do I use OpenGL or something else? (/thread-1342.html)
Pages: 1 2
For 2D (sprite) games, do I use OpenGL or something else? - lindsay - May 5, 2009 12:15 AM
Hi all, new here, apologies if this has been covered but I wasn't quite sure how best to search for it.
I've got a long programming background (almost 30 years) and I'm currently getting myself up to speed with Objective-C with a view to writing iPhone games.
My specific area of interest is 2D games - side shooters, platformers, basically old arcade-style games. I have no interest in making 3D games in the forseeable future.
Is OpenGL the way to go to write tile- and sprite- based games, or should I be learning something else, and if so, what?
I realise there are a number of third party engines out there (TGB, etc) but for me part of the fun is doing all the coding myself, even if it is reinventing the wheel.
For 2D (sprite) games, do I use OpenGL or something else? - kodex - May 5, 2009 12:46 AM
OpenGL ES is probably the way to go.
For 2D (sprite) games, do I use OpenGL or something else? - kendric - May 5, 2009 07:20 AM
Also consider using c++ instead of objective c for framerate reasons in games.
For 2D (sprite) games, do I use OpenGL or something else? - ThemsAllTook - May 5, 2009 08:29 AM
kendric Wrote:Also consider using c++ instead of objective c for framerate reasons in games.
See discussion here before taking this at face value.
For 2D (sprite) games, do I use OpenGL or something else? - AnotherJake - May 5, 2009 08:49 AM
Forget face value... Kendric's statement is totally false! Objective-C is not "slow". What is slow for games is Cocoa if you use it wrong (e.g. don't be using NSArray in games!). Do not confuse performance of Objective-C (the language) with Cocoa (the API).
For 2D (sprite) games, do I use OpenGL or something else? - Nosredna - May 5, 2009 08:57 AM
I used OpenGL. Objective-C for anything to do with API calls, and plain old C for game logic and calls to OpenGL. Worked great.
For 2D (sprite) games, do I use OpenGL or something else? - AnotherJake - May 5, 2009 09:04 AM
Nosredna Wrote:I used OpenGL. Objective-C for anything to do with API calls, and plain old C for game logic and calls to OpenGL. Worked great.
FWIW, yes, that's what I do too. Performance is excellent.
For 2D (sprite) games, do I use OpenGL or something else? - kendric - May 5, 2009 09:55 AM
You cannot deny that objective c is slower then c\c++ by more then a negligible amount for core language features. Forget about NSArray. That was the only thing in my code I think that I used that was coaca. I was still able to optimize my performance incredibly by removing obj c code and replacing.
If you do
where isSomething simply returns a bool, you will have a significantly slower time then if you did it in c.
I had this in my code where all that happened in isSomething is 1 line, return someVar; and I was getting a large % cpu usage on that line in shark. Infact I even saw performance bloat from using a synthesized function vs doing my own implementation. Maybe shark was giving me bogus info but that's what It said.
You can't claim that a language is fast if you are constantly having to decide if you want to revert back to the c superset to avoid bottlenecks.
A language is fast if it can perform high intensity tasks with minimal overhead. A language is slow(er) if it cannot. The speed of a language is not dictated by what the task is, its a general statement. Program the same thing in assembly, c, java, and objective c and you will be able to determine something about their relative performance.
For 2D (sprite) games, do I use OpenGL or something else? - kendric - May 5, 2009 09:57 AM
I never said don't use objective. I said to use c for framerate reasons. If you are not worried about framerate(for example your writing a low intensity app) then it wouldn't apply. I also said consider, that doesn't mean its 100% hard fast rule.
For 2D (sprite) games, do I use OpenGL or something else? - AnotherJake - May 5, 2009 10:13 AM
I'm sorry, but according to the impression I've been getting from your posts on it lately, you do seem to recommend against it:
Quote:Objective c is very slow for things that need to pull off 60 frames per second.Objective-C is plenty fast enough to use and get high frame rate on iPhone, it just depends on how you use it. I saw in that other thread that your perception of Objective-C's performance was based upon how you were using it with Cocoa, which is completely misleading -- do not use Cocoa in performance critical areas! Also, there's no sense in doing lots of Objective-C messaging in tight loops either (although there optimizations that can be made there). That does not mean one shouldn't use Objective-C, and it doesn't mean Objective-C is too slow for games.
For 2D (sprite) games, do I use OpenGL or something else? - kendric - May 5, 2009 10:25 AM
I can give you a history of how I used objective-c and what problems I am facing because of it, and then you can advise me if I did not use it correctly or have any suggestions.
I wanted to make my game engine a very elegant OO solution. I setup the following hierachy (this is 100% objective c class structure)
Each game object has a passTick function in it, and in there they can manipulate things, often multiple levels up their inheritance hierarchy.
What this results in is a lot of messaging. Each guy also is ading his custom flavor to the game logic and all of those require many gets and sets of variables that are private in super classes. This results in more messaging. Sure I could do this all procedurally, or make everything public or something like that, but that defeats the whole purpose of doing it OO. The other thing is all that stuff has a matching protocol hierarchy to create separation of implementation and interface. Thus I am likely getting another performance hit for obj-c having to translate those(I looked at what was involved in the assembly for an instanceof id<ISomeInterface> to be created and assigned and it seemed like quite a few commands.
This type of behaviour is what leads me to see the large %cpu usage in the obj_c_message thingy in shark and why I am concerned about using this in high intensity games. Sure you could write wrapper code, some glue, couple high level things, and do the rest in c, but then you aren't really the subject of my comments since your doing most everything in c\c++.
For 2D (sprite) games, do I use OpenGL or something else? - kendric - May 5, 2009 10:35 AM
I meant to add, with this complex structure, the game loop encompasses tons and tons of code. You cannot simply not use objective c in the game loop when your programing it OO like I did. How would you talk to your super classes, and how would you access values on objects you want to talk to? You could argue not to program it like this but then why are we using an OO language? The fact that my game setup allows me to add to it super easily without any work is what made objective c so appealing in the first place.
For 2D (sprite) games, do I use OpenGL or something else? - Nosredna - May 5, 2009 10:46 AM
"Objective-C is plenty fast enough to use and get high frame rate on iPhone, it just depends on how you use it."
I think that's absolutely true. But I also think that if you code in C, you end up programming in ways that help the speed of your code. It's a matter of removing abstractions that prevent you from seeing what's happening when the code is compiled.
As a historical analogy, I've seen people write code C and then translate functions into assembly. They have a hard time getting much of a boost. But if you start in assembly in the first place, you see ways to organize your data differently that you don't tend to see in C.
I'm not saying anyone should be writing a game in assembly anymore, but I am saying that the choice of language and the habits you develop in it can absolutely affect performance. I moved a whole group of functions from Objective-C to C and got a huge boost, but mostly because of a change in perspective, not because of any individual choice or problem with Objective-C.
If you code in Objective-C, I think it's worth the time to write things several different ways and learn which things are slow and which are fast. Getting rid of the worst few performing habits of usage will probably get you close to C speeds.
For 2D (sprite) games, do I use OpenGL or something else? - Nosredna - May 5, 2009 10:48 AM
Also, you can't say "Objective-C" is slow. C is a valid subset of Objective-C, so Objective-C can be as fast as C (just don't use anything that's slow).
For 2D (sprite) games, do I use OpenGL or something else? - kendric - May 5, 2009 11:10 AM
For me opengl and game logic is like 90% of my code. How about you guys?