MVC Collision +other question

Member
Posts: 306
Joined: 2009.03
Post: #1
I'm trying to figure out how my MVC game will implement collisions. Units will be pngs, and so i would like to use a system level function to see if there is a boundary collision(something I could do in flash). So first can you do this? Such that pngs with transparent edges will not have square box collision rectangles?

Secondly MVC... So image collision detection as mentioned above is a view thing, but in MVC collision detection should be in the model. Having each object maintain its own collision code would mean it would need the UI info for the shape of its png. And then you are re-inventing the wheel anyhow by writing your own image comparison testing code. Any suggestions here? I maybe have odd shaped things so I don't think a simple circle bounding model level math trick will work.

Finally, the c++ front. I have been learning objective c now for a while to do this and I am seeing talk of just straight coding in c++ and opengl. Is this for iphone as well? Can you make 100% c++/opengl ES iphone apps? Is that the way most successful apps are being written? Of all the tutorials, I haven't seen any that show how to switch between c++ code and objective c.
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #2
kendric Wrote:Finally, the c++ front. I have been learning objective c now for a while to do this and I am seeing talk of just straight coding in c++ and opengl. Is this for iphone as well? Can you make 100% c++/opengl ES iphone apps? Is that the way most successful apps are being written? Of all the tutorials, I haven't seen any that show how to switch between c++ code and objective c.

Yes, you can code in (nearly) 100% c++/OpenGL ES on iPhone. You'll need minimal amounts of Objective-C to interface with the OS in a few places.

You name your Objective-C files' extensions to be .mm if you want to compile them as Objective-C++.

No one knows what all the most successful apps are using, but I'd wager >75% of them are C or C++ (the rest probably using Objective-C), with likely well over >90% of games using OpenGL ES.

I don't really have any good suggestions on the collision detection, except to say that I've tried all kinds of approaches over the years, and found that 99% of all my situations worked just fine using axis-aligned bounding rectangles or circles, even when I thought they'd need higher precision. Best thing to do is to actually try the simplest solution first, and then go for higher precision later if needed (polygonal or pixel collision detection).
Quote this message in a reply
Member
Posts: 306
Joined: 2009.03
Post: #3
Thanks for the answers. So if i name it mm i can use c and obj-c interchangeably? There aren't any syntax collisions between them? And what about pointers. If I have some NSObject, are its messages directly related to c functions? Or are there a different library set for each object for c++, or yet still you can't do any c++ calls on things like UIView?
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #4
kendric Wrote:Thanks for the answers. So if i name it mm i can use c and obj-c interchangeably?

No, you can rename them to .mm to use ** C++ ** in your Objective-C files (actually, using .mm, they would then technically be Objective-C++ files). C and Objective-C are already no problem whatsoever using the regular .m extension.

Remember, unlike C++, Objective-C really is a strict superset of C, so you can use C right there alongside your Objective-C without any issues. Any Objective-C object is simply represented as a pointer as far as C is concerned. For instance, you can call out to a C function by passing a void *object, and then the function can call back into Objective c, using that pointer as an object (might need to cast it to the correct class to suppress a warning). It seems a little non-obvious to newcomers but it's all pretty straight-forward once you fiddle around with it for a while.

There is only one library "set", and that is Cocoa (or Cocoa Touch on iPhone), and it requires that all calls be in Objective-C. That is, you can't call Cocoa directly from C or C++. However, you can use C and C++ alongside/intermixed with Objective-C. For instance, you might have a C function or C++ class which has Objective-C messages in it which call Cocoa.
Quote this message in a reply
Member
Posts: 306
Joined: 2009.03
Post: #5
Thanks a ton for your input!
Quote this message in a reply
Member
Posts: 306
Joined: 2009.03
Post: #6
While your being so helpfull.. another question. Is the C++ fully compliant? For instance if I wanted to grab the boost shared pointer library and drop it in, it would work? Is there a shared pointer library provided for you?
Thanks again!
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #7
I don't use C++ very much (I prefer C/Objective-C) so I can't give you a straight answer on that. I know boost works great on the Mac, and I've messed with it a little myself, but I don't know how much is supported on iPhone. I seem to recall reading someone had troubles with it a while back, but don't quote me on that. I don't see why it wouldn't work though, since it appears that most conventional stuff is robustly supported on iPhone.

A fairly comprehensive C++ iPhone example that comes to mind, which you might check out, is the oolongengine. Lots of goodies in there!
Quote this message in a reply
Member
Posts: 306
Joined: 2009.03
Post: #8
Ok thanks. i will take a look at that. I meant smart pointer, not shared pointer btw Wink
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #9
Ah yes, smart pointers... hehe... There is a member here, TomorrowPlusX, who introduced me to boost, and he especially loves smart pointers.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #10
To answer the collision question, I would second that you probably can get away with simple bounding spheres or boxes (or a combination). I'm 95% certain that the first Halo used ellipsoids/sphere to implement the collisions for all of the vehicle to vehicle collisions. You could sort of tell that was the case when things would get stuck, but otherwise I don't think anybody noticed.

As far as implementing collisions in some sort of MVC way, don't bother. When two objects collide, the reaction isn't really going to be definable for each part separately unless you are doing something really funky. What I've found works very well is to let a "space" or "world" object that controls the collision response whether it be physics or logic related. The behavior of the collision itself might be completely disconnected from the objects, though it might call methods on one or both objects in order to provide an appropriate response.

In my physics library (Chipmunk), I allow the user to define shapes to have a collision type, and also to define callbacks that are invoked when particular pairs of collision types collide. For instance, you might want to register a callback for when a bullet collides with a wall. In that case, you'd probably want to:
  • Play a noise based on the type of bullet and wall material.
  • Draw some sparks at the impact site.
  • Remove the bullet from the game, or ricochet it off in another direction. (again possibly depending on the material the wall is made of)
Trying to fit this into a wall.collided_with_bullet() + bullet.collided_with_wall() method combination gets really messy really fast. You end up with a lot of empty methods, and a lot of cases where you aren't sure which method should be responsible to play the sound, and which should draw the sparks. If you want to do some sort of real physics interaction, forget the dual method combination entirely.

* Skorche just thought of a nifty feature to add to Chipmunk (runs off)

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 306
Joined: 2009.03
Post: #11
Thanks for the feedback!
Another question that came to mind. Is objective C slower if your using apples to apples graphic display(ie opengl) then doing your code in say c++? Lets say you avoid the special features like key value observing and coaca bindings(which in my mind aren't needed in opengl since you render the whole screen every frame anyways right?). I kinda liked the objective c since I already spent 4-5 days getting over the learning curve so if its just compiler magic that makes it end up as the same assembly as c++, or close enough, I may just stick with it. Thoughts?
Quote this message in a reply
Member
Posts: 306
Joined: 2009.03
Post: #12
Oh, I should add, specifically what concerns me is I read somewhere that every function in objective c is virtual, and I remember that virtual functions are slower then regular functions.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #13
Based on my last speed tests, an Objective-C method call is 4-7 times slower than a C function call, but this is almost always dwarfed by other things in your code that take longer. In the extremely rare situation that the Objective-C message system is your bottleneck, you can retrieve a C function pointer for any Objective-C method and call it that way instead.
Quote this message in a reply
Moderator
Posts: 3,574
Joined: 2003.06
Post: #14
When I first started programming for iPhone I did everything in Objective-C, using Cocoa stuff like NSArrays and dictionaries for everything. It worked okay, but then I did a test and switched to pure C and got a massive performance increase, like greater than 200% better. I highly suspect my liberal usage of Cocoa stuff like NSDictionary and NSArray were the biggest hit. I still use some Objective-C here and there and it doesn't seem to be any problem when used sparingly, for things like general program organization. Gotta be mindful of which features you're using and how you're using them though. You don't want to be using Obj-C in critical things like tight loops for collision detection, etc. .. at least not on iPhone -- desktop systems seem to have zero issues with throwing as much Obj-C/Cocoa as you can at them.
Quote this message in a reply
Member
Posts: 306
Joined: 2009.03
Post: #15
Thanks for that data. I'm concerned that in a well written OO program there are going to be a lot of function calls, so that speed difference is a bit concerning. For example lets say you are rendering a screen with 50 things, thats 50 function calls, each one will prob make a function call to a few of its child objects for rendering data, then you will prob make a few function calls to your GL framework classes to render various things. So unless the actual open GL render calls are slow, I would think a good portion of what you will be doing is function calling, if statements, and basic math statements, and then library calls.
Quote this message in a reply
Post Reply