I would really love if someone could tell me how to tell whether 2 objects have touched (An image or a button) I know how to make them draggable but not how to tell if they have touched and to do something when they touch!
Thanks!
If you never rotate the objects, you can use CoreGraphics functions.
BOOL objectsTouch = CGRectIntersectsRect(object1.frame, object2.frame);
This requires of course that the two objects are in the same superview. Otherwise you have to transform the frames using functions of the NSView.
The classical approach is to calculate a minimal circle that encompasses each object, then calculate the distance between circle centers (Pythagorean theorem) and see if it's less than R(object1 circle) + R(object2 circle). If less then you have to get down and dirty with bit mapping or some other scheme, but if greater then you can assume the objects don't touch.
Related
When creating an object that will be graphically represented but also have data and functionality independent of that representation (i.e., a card in a card game will have a graphic, but also know its value, suit, maybe be able to flip over), from a best practices approach, should that object know its own image and position?
If not, how should it be handled? I understand that at the very least another class should be responsible for drawing said object, and it appeals to me that the class shouldn't need to be concerned with its graphics at all: the program should be able to change the design and look of the cards without impacting the class itself - a seven of spades is a seven of spades no matter how you draw it - but I'm finding it difficult to think up a solution to having the 'drawer' class know the image and location of the card.
My present solution is to have a sprite class, and the card contains a sprite object, which is constructed along with the card - the sprite simply contains an image and vector (location), but I feel that I could break this down.
Any design patterns or common sense solutions I'm missing? Or am I just thinking incorrectly that this should be separated?
Since this is a matter of opinion: I believe it would be best for the object not to know its own image. It should know its own position. When a card is drawn, like you mentioned, a Seven of Spades is a Seven of Spades. Leave it to a different handler to draw the image based on what type of card it is, rather than asking the card for its image.
When you draw a card, you could make a method call, ex: drawCardImage(cardObject.type). The method could then check, using if statements, "if card == 'sevenofspades': draw("/images/sevenspades.png")
I'm working on an iPad application and that's my problem:
I elaborated an algorithm to know if a point is inside a polygon, in an image. So I need when touching the Image, to know the coordinates of the touched point and then do an action using those coordinates (an NSLog to make the example easy), the problem is that I can't use an IBAction on an UIImageView, and so can't recover the point's coordinates. Thanks for any help
I think at first you have to make polygon which fit to your image. And then you can use touchesBegan:withEvent: to get the coordinate of touch point and judge whether the point is inside of polygon or not.
Here is similar question like yours.
How to get particular touch Area?
I think this is a little difficult work, so maybe you would better use cocos2d library which have collision judgement function.
http://box2d.org/forum/viewtopic.php?f=9&t=7487
But also I think iOS is well constructed for handling touch, so this is beneficial effort for you.
I have a UIView that a user drags around via setting its center in the touchesMoved: method. When the user lets go, I want the UIView to fall off the screen according to how fast and what direction they were moving it in.
Do I need to somehow create a vector by comparing the UIView's last center point to it's new center point? And subtract a fixed amount to the vector's y value every so often with a NSTimer?
Yes, you will need to a decent amount of physics in calculating
Speed of swipe
Direction of swipe
You will need to use the touchesMoved method along with a timer to track the amount of time for the swipe and also the co-ordinates for the new location of the object. This should be fairly straight forward. Once you are done finding those you can simply add a UIAnimation for the object to move to its new place.
~ A suggestion:
I would suggest that you have a look at Cocos2D and integrate the library with you app. You will not need to implement touch delegate methods and compute things yourself ~ there are libraries for that :) It has a lot of libraries especially for moving objects (or sprites if you wish to call them that way) and you have animation method like easeInEaseOut, etc.. that can be impacted on the moving object. If you are developing a game of some sort, have a look at chipMunk engine in Cocos2D as well.
I have a limited area (screen) populated with a few moving objects (3-20 of them, so it's not like 10.000 :). Those objects should be moving with a constant speed and into random direction. But, there are a few limitation to it:
objects shouldn't exit the area - so if it's close to the edge, it should move away from it
objects shouldn't bump onto each other - so when one is close to another one it should move away (but not get too close to different one).
On the image below I have marked the allowed moves in this situation - for example object D shouldn't move straight up, as it would bring it to the "wall".
What I would like to have is a way to move them (one by one). Is there any simple way to achieve it, without too much calculations?
The density of objects in the area would be rather low.
There are a number of ways you might programmatically enforce your desired behavior, given that you have such a small number of objects. However, I'm going to suggest something slightly different.
What if you ran the whole thing as a physics simulation? For instance, you could set up a Box2D world with no gravity, no friction, and perfectly elastic collisions. You could model your enclosed region and populate it with objects that are proportionally larger than their on-screen counterparts so that the on-screen versions never get too close to each other (because the underlying objects in the physics simulation will collide and change direction before that can happen), and assign each object a random initial position and velocity.
Then all you have to do is step the physics simulation, and map its current state into your UI. All the tricky stuff is handled for you, and the result will probably be more believable/realistic than what you would get by trying to come up with your own movement algorithm (or if you wanted it to appear more random and less believable, you could also just periodically apply a random impulse to a random object to keep things changing unpredictably).
You can use the hitTest: method of UIView
UIView* touchedView=[self.superview hitTest:currentOrigin withEvent:nil];
In This method you have to pass the current origin of the ball and in second argument you can pass nil.
that method will return the view with which the ball is hited.
If there is any hit view you just change the direction of the ball.
for border you can set the condition for the frame of the ball if the ball go out of the boundary just change the direction of the ball.
I am working through Aaron Hillegass' Cocoa Programming for Mac OS X and am doing the challenge for Chapter 18. Basically, the challenge is to write an app that can draw ovals using your mouse, and then additionally, add saving/loading and undo support. I'm trying to think of a good class design for this app that follows MVC. Here's what I had in mind:
Have a NSView-subclass that represents an oval (say JBOval) that I can use to easily draw an oval.
Have a main view (JBDrawingView) that holds JBOvals and draws them.
The thing is that I wasn't sure how to add archiving. Should I archive each JBOval? I think this would work, but archiving an NSView doesn't seem very efficient. Any ideas on a better class design?
Thanks.
Have a NSView-subclass that represents an oval (say JBOval) that I can use to easily draw an oval.
That doesn't sound very MVC. “JBOval” sounds like a model class to me.
Have a main view (JBDrawingView) that holds JBOvals and draws them.
I do like this part.
My suggestion is to have each model object (JBOval, etc.) able to create a Bézier path representing itself. The JBDrawingView (and you should come up with a better name for that, as all views draw by definition) should ask each model object for its Bézier path, fill settings, and stroke settings, and draw the object accordingly.
This keeps the knowledge of how to draw (the path, line width, colors, etc.) in the various shape classes where they belong, while also keeping the actual drawing code in the view layer where it belongs.
The answer to where to put archiving code should be intuitively obvious from this point.
Having a whole NSView for each oval seems rather heavyweight to me. I would descend them from NSObject instead and just have them draw to the current view.
They could also know how to archive themselves, although at that point you'd probably want to think about pulling them out of the view and thinking of them more as part of your model.
Your JBOval views would each be responsible for drawing themselves (basically drawing an oval path and filling it, within their bounds), but JBDrawingView would be responsible for mousing and dragging (and thereby sizing and positioning the JBOvals, which would be its subviews). The drawingView would do no drawing itself.
So far as archiving, you could either have a model class to represent each oval (such as its bounding rectangle, or any other dimensions you choose to represent each oval with). You could archive and unarchive these models to recreate your views.
Finally, I use the JB prefix too, so … :P at you.