Newbie Inquiries

Doobfoo Wrote:That's wicked man, I said hello world in 1990, LOL. In 2001 I started programming in vb and c++ though, but as you can assume I stopped. I remember reaching pointers though, I didn't get too far.

Not many self-taught programmers get past pointers. I suppose that explains the popularity of Java...

Mister T Wrote:Objective C is slower in an apple's to apple's comparison. For example, if you made a game in C++ that uses objects for everything, and re-wrote it using Objective-C objects for everything, the C++ version would be faster. Reason being, that an Objective-C object is "dynamic," performing common operations at runtime rather than compile time, such as dynamic type checking, dynamic binding, dynamic dispatch, garbage collection (if enabled), etc... On the other hand, in C++, a class is almost a fancy word for "struct." Type checking, dispatch, etc, are all done "statically," and can be easily circumvented --sometimes, unintentionally. A C++ program may behave unexpectedly in such circumstances, whereas an Objective-C program will crash or throw an exception. This is probably the biggest advantage of a language like Objective-C. C++ has the advantage of performance.

Personally, I'm using Objective-C for Mac-specific stuff, C++ for some data structures, and straight C for everything else.

Built using LLVM-G++ in Release Mode build using whatever the heck settings are default for an Objective-C command line tool in Xcode 3.2.

So, if nothing else, the action of sending a message and the action of calling a method on a C++ object and the action of making a function call in C are somewhat similar in terms of how long it takes to execute.

Yes, the gauntlet of performance testing, I haz thrown it! (perhaps we should fork a new thread for this?)

It really depends on what you're doing, but in this example, a few problems immediately grab my attention. First, you're just calling one function of this one object repeatedly. I assume the Obj-C runtime recognizes this, and steps aside after the initial call. Secondly, you're not just measuring the function call time; you're also measuring the execution time of the measuring code! This will make the difference appear to be less significant. Third, your C function is pushing arguments, which is something the other functions aren't. This won't make a tremendous difference because everything's likely in cache anyway. Lastly, competing processes on your machine may interfere with your results.

I think that if you had a data structure or something (with objects for nodes), the results would be more significant. But in general, I wouldn't expect more than a 5% difference in performance, though it may be higher in unusual circumstances.

To make it fair you'd have to throw some object creation and destruction in there too; and you're seeing a best-case scenario because of method caching.

Still, it proves your point well - Objective-C is not Java, and it's pretty lightweight. In my opinion what you get in return is completely worth it.

In my own game, the impact of the model/simulation stuff written in Obj-C was minuscule compared to the drawing time (OpenGL). I could have rewritten the whole thing in C++ and seen no speed improvement.

Mister T Wrote:Hey, I just said it would be faster. Never said by how much!!

It really depends on what you're doing, but in this example, a few problems immediately grab my attention. First, you're just calling one function of this one object repeatedly. I assume the Obj-C runtime recognizes this, and steps aside after the initial call. Secondly, you're not just measuring the function call time; you're also measuring the execution time of the measuring code! This will make the difference appear to be less significant. Third, your C function is pushing arguments, which is something the other functions aren't. This won't make a tremendous difference because everything's likely in cache anyway. Lastly, competing processes on your machine may interfere with your results.

I think that if you had a data structure or something (with objects for nodes), the results would be more significant. But in general, I wouldn't expect more than a 5% difference in performance, though it may be higher in unusual circumstances.

I've never had a problem with Objective-C's speed, and sometimes people use the same language that we would use about Java 1.4.2 when they talk about Objective-C's speed. Objective-C is nowhere near Java 1.4.2 in terms of how slow it is, so sometimes I just get an itch to prove that in most situations Objective-C isn't going to be that big a problem.

When it comes to memory usage, that is a different story, obviously. There's a lot of extra baggage that an Objective-C object carries around which you can easily jettison by using a C structure. If the baggage is greater than the data in your Objective-C object, it's a great candidate for demotion to a C struct!

cmiller Wrote:I've never had a problem with Objective-C's speed, and sometimes people use the same language that we would use about Java 1.4.2 when they talk about Objective-C's speed. Objective-C is nowhere near Java 1.4.2 in terms of how slow it is, so sometimes I just get an itch to prove that in most situations Objective-C isn't going to be that big a problem.

When it comes to memory usage, that is a different story, obviously. There's a lot of extra baggage that an Objective-C object carries around which you can easily jettison by using a C structure. If the baggage is greater than the data in your Objective-C object, it's a great candidate for demotion to a C struct!

I agree with that entirely. In theoretical terms, Obj-C is in the same category of languages as Java and C#. They're all dynamic, and they all have associated runtime environments. The thing that sets them apart (besides syntax) is the process by which the high-level code is transformed into a running application. Obj-C compiles to C and then to native binary with an associated runtime. Java and C# compile to an intermediate language, which is then dynamically translated to native machine code by the JIT. It's actually harder for a language like Java to perform as well as Obj-C (as evidenced by Java 1.4.2), but things have changed quite a bit since Java's early days, and at least C# is considered perfectly acceptable for game development (eg. XNA) --I can't speak for Java.

I see nothing wrong with using Obj-C for game development. In practice, there's not going to be a significant difference in most cases. And like you said, when it does matter, you can always revert to C (e.g. trade objects for structs).

Mister T Wrote:I agree with that entirely. In theoretical terms, Obj-C is in the same category of languages as Java and C#. They're all dynamic, and they all have associated runtime environments. The thing that sets them apart (besides syntax) is the process by which the high-level code is transformed into a running application. Obj-C compiles to C and then to native binary with an associated runtime. Java and C# compile to an intermediate language, which is then dynamically translated to native machine code by the JIT. It's actually harder for a language like Java to perform as well as Obj-C (as evidenced by Java 1.4.2), but things have changed quite a bit since Java's early days, and at least C# is considered perfectly acceptable for game development (eg. XNA) --I can't speak for Java.

I see nothing wrong with using Obj-C for game development. In practice, there's not going to be a significant difference in most cases. And like you said, when it does matter, you can always revert to C (e.g. trade objects for structs).

Java would be a lot better for game development if it had a set of common and easily-installable libraries that would work for game development. Using an AWT graphics engine to render even 2D game graphics is going to get really hairy, really quickly (personal experience - don't try it kids, it's not worth your sanity!)

There has been a lot of interesting indie work coming out of C# and XNA, though I'm very leery of selling my soul to Microsoft when I can't even keep my PC working well enough to play EVE Online without d/c -ing during fleet fights (yes, warping to desktop should be the player's decision, not the operating system). FWIW, EVE Online is an excellent example of how NOT to design a game GUI, though it is a good example of how to iteratively pull yourself out of the pit of horrible GUI design. They're not good yet, but getting better with each version.

The one thing that has been bugging me recently about C/Objective-C work is the lack of a good template mechanism. I constantly want to make a C-level vector, but unless I use void pointers it will have to be rewritten for every new type. So I think there are definitely some drawbacks to C/Objective-C (let's face it - array work can be hard).

The other drawback (the reason I'm not advocating using Objective-C++ and making everything C extern "C" blocked) is that the CLang frontend isn't yet C++ supportive. CFE offers lots of cool tools for debugging and analyzing code, and it seems a real bother to have to dump all those features just because you want to use std::vector.

Eventually CFE will support C++, so eventually we'll have C, C++, and Objective-C/C++ to play with all at the same time with all our new shiny tools. But that time is not now unfortunately. They are getting close though: http://clang.llvm.org/cxx_status.html

Doobfoo and I had a chat on IRC, and I think he's going to go read about two things, C/SDL and Python/PyGame, and dabble in both until he figures out what he wants to do.

The proper response to someone asking about learning to program for the first time on the iPhone is not "Learn language X," but rather, "Why do you want to have the iPhone as your first platform?" It's overly complicated for beginners and therefore the wrong approach.

I disagree. The OP asked about those languages and we had a nice discussion about them; there was no "war". Being as how this is a programming forum, it is completely normal to see these kinds of discussions come up, and they do quite frequently. In this context the discussion was definitely relevant, and I believe it was helpful too, in that it appears we all pretty much agree on several points, and so those points can be taken for what they are by other visitors, including the OP.

In terms of kind of wandering on the topic of the speed debate alone, I've seen it happen so many times over the years that I didn't feel it was necessary to split the thread for a short diversion. If it had continued then a split would have been called for.

diordna Wrote:Doobfoo and I had a chat on IRC, and I think he's going to go read about two things, C/SDL and Python/PyGame, and dabble in both until he figures out what he wants to do.

The proper response to someone asking about learning to program for the first time on the iPhone is not "Learn language X," but rather, "Why do you want to have the iPhone as your first platform?" It's overly complicated for beginners and therefore the wrong approach.

I didn't know Python/PyGame were available on iPhone.

As far as iPhone being a first platform, that's a good question. Last year I would have said "start on Mac", but there are so many books and blogs now that I believe it is feasible to start on iPhone. Plus, many are getting into game programming for the first time just because of the excitement of iPhone, so I see that excitement as a good source of motivation, which is something I believe beginners need. So personally, I say "go for it", rather than "weeelll.... you'd better take it slow and jump through hoops a, b and c first... theeen maybe you might be ready for iPhone". I figure they'll find out whether or not they can tackle iPhone at first on their own and then back off to something else if they really want to learn bad enough. I mean, let's face it, there really is no "easy" way to learn how to do this stuff

AnotherJake Wrote:I didn't know Python/PyGame were available on iPhone.

It's not. But it's a hell of a lot easier to figure out how a game is put together using that set of tools.

I perceive the iPhone as a bad beginner platform because:

More technical challenges between you and a game: memory management and sound in particular. You have to do more just to get moving images.

High starting cost: yes, you have the simulator, but if you actually want to get it on your device, which most people do, you have to pay

Delayed feedback: the review gap limits the amount of early feedback you can get

More knowledge required to build a complete game: sort of goes with the first point, but the fact that he has two books to read now should say something. And he won't be able to stop there, because there's still the iPhone API to learn.

Motivation is great, but I would rather people be a little less motivated but actually follow through, rather than being all excited about platform X and then get frustrated and quitting with the conclusion that game programming is too difficult. You say there is no "easy" way to learn "this stuff" (whatever that means), but we don't have to torture ourselves either.

As long as learning game programming is a hobby, this entire process is about personal fulfillment. Is he going to have a better time with platform X, or platform Y? If he really wants X, nothing I say is going to stop him from achieving his goal. If he wants to make games and X is a side-goal, then trying to get both at once might actually impede him. Everything varies from person to person, and ultimately, only he can decide what his level is. I'm just trying to provide an informed opinion.

Doobfoo and I had a chat on IRC, and I think he's going to go read about two things, C/SDL and Python/PyGame, and dabble in both until he figures out what he wants to do.

The proper response to someone asking about learning to program for the first time on the iPhone is not "Learn language X," but rather, "Why do you want to have the iPhone as your first platform?" It's overly complicated for beginners and therefore the wrong approach.

I absolutely do not believe that the iPhone is a bad choice for someone's first game development platform. I absolutely agree that it isn't the easiest platform to write for.

Building games is mostly motivation. If you're motivated by the iPhone, then you're only ever going to have success on the iPhone because you aren't motivated to develop for anything else. I think it's a prudent choice to learn something like Python first, absolutely, but I don't think it's necessarily The right choice.

diordna Wrote:More technical challenges between you and a game: memory management and sound in particular.

While that is true to some degree, sound effects aren't really any harder on iPhone than on Mac since you're just using OpenAL. Music is done with either AVAudioPlayer, which is dead-simple but doesn't loop seamlessly, or you can also stream using Ogg/Vorbis via Tremor which loops seamlessly but you pay a performance price to do so.

Memory management isn't like some awful demon waiting to swallow you up. Just being mindful about it is all you have to do. Plus, you don't have to worry about memory management unless you plan to ship the game -- if it works on your device it works for you!

To be clear, I have never recommended iPhone be the platform the OP should start with, but I'm not recommending against it either. There are indeed some extra challenges to developing on iPhone, but I don't think they're so tough in comparison to developing on Mac either... unless you want to do something like Pygame instead. But then you're learning something that won't work on iPhone, so that is a point for the OP to consider. If your goal is to include development for iPhone then it would seem to be inefficient to learn stuff that won't help you get there. Not that I'm saying anything against Python, because it's a great language, but it didn't fit the parameters of where the OP was saying he wanted to go, so it was logically left out.

diordna Wrote:but the fact that he has two books to read now should say something

Yeah, but what does it say? Like I said, there's no "easy" way to learn this stuff. You have to put in the work to learn it one way or another. I don't have just two books, I probably have fifty books! Now *that* should say something! ... before you say "whatever that means" again I guess I should clarify that I mean this stuff is hard no matter which approach you take. Some approaches will be easier up front but won't let you do all the stuff you might want later on, but other approaches will be harder up front but will allow you more flexibility. No matter which path you choose, it will require lots of effort so you might as well choose the one that points most directly at your goal.

I suppose I should add, if I were to do this myself and I wanted to be as cross-platform as possible and I wasn't worried about putting in the effort up-front, this would be my recipe, in order:

1) learn C
2) learn how to program OpenGL using GLUT on the Mac or Windows
3) learn how to use SDL instead of GLUT for more robust support
4) learn a little Objective-C and Cocoa for a couple weeks -- not much, but just enough to understand what's going on
5) learn to develop games in OpenGL on iPhone

[Adding] If I wanted to just develop games on iPhone first and didn't want to prioritize cross-platform compatibility but wanted to learn stuff that would eventually be portable, here's that recipe:

AnotherJake Wrote:You can easily use Obj-C for game programming on the Mac, but you'll eventually run into performance problems on iPhone if you use it for things like tight loops and other performance intensive areas. It's okay for general game structuring on the iPhone, but you'll want to stick to C/C++ for the critical stuff.

I read Programming in Python for the Absolute Beginner a few years ago. It was a lot of fun, but I never continued with the language. As of now, I am considering relearning the language because I just want to create games.

AnotherJake Wrote:I suppose I should add, if I were to do this myself and I wanted to be as cross-platform as possible and I wasn't worried about putting in the effort up-front, this would be my recipe, in order:

1) learn C
2) learn how to program OpenGL using GLUT on the Mac or Windows
3) learn how to use SDL instead of GLUT for more robust support
4) learn a little Objective-C and Cocoa for a couple weeks -- not much, but just enough to understand what's going on
5) learn to develop games in OpenGL on iPhone

[Adding] If I wanted to just develop games on iPhone first and didn't want to prioritize cross-platform compatibility but wanted to learn stuff that would eventually be portable, here's that recipe: