I'm making the skeleton for the typical BubbleShooter game in XNA, and I'm having issues with my collision detection algorithm, which is explained in the picture here
Depending on where the colliding Rectangle position is at the moment of collision, a new position is assigned to the colliding Bubble.
The issue appears when I shoot a bubble and this happens at the moment of collision.
I have run the debug step by step, and the moment when the collision happens is exactly like the picture, so my algorithm fails.
I tried to post the images directly, but it seems I can't since I'm still a new user here. Sorry about that.
Is there a way I can detect exactly when the boundaries of the Rectangles touch each other?
You can perform a per pixel collision instead, it is explained here:
Click here
So, if I understand, your problem is that you miss the exact moment of collision ?
I guess you are computing collisions in a discreet way, ie. even if your algorithm runs 60 times a second, it is only 60 times when a second could be subdivised in an infinity of instants.
The simple (and bad) solution is to make your objects move slower.
The good one implies to retrieve what happens between the frames. you will need some kind of direction vector and the object speed. With both these values, you can determine where and when the collision did occur.
You will also need the elapsed time between frames. This is the purpose of the GameTime object : it has a property "ElpasedGameTime", which has a property "TotalElapsedMilliseconds".
MSDN Documentation on GameTime class : http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.gametime.elapsedgametime.aspx
Some reading material on Wikipedia about collision detection: http://en.wikipedia.org/wiki/Collision_detection#A_posteriori_.28discrete.29_versus_a_priori_.28continuous.29
"A priori" and "A posteriori" detection : that's the keywords you might be missing.
I don't have time to test it right now but you should try to limit your number of collisions per frame to 1.
With a counter when it enters the update part if one collision has been detected block all other collision for the same frame.
This way if your projectile its the bottom part, your code for
if(hitBottomPart)
{
// Logic
}
part will execute in this same frame before the projectile has time to hit another rectangle of the texture.
Although this is just a guess.
Good luck with your game ! Collisions are always a pain to implement.
Related
I'm fairly new to game development and I'm trying to develop a 2D game in unity where the main character has a jetpack with two thrusters and I want him to control each one individually. So if he only turns on one thruster he goes 5 meters above ground and hovers there while using both would make him hover at a height of 10 meters. How would i go about doing this?
I tried just simply adding forces as if the character was jumping and freezing the y-axis to 0 until he let go of the jetpack button but that did not give me the feel i was looking for. I also tried raycasting a line out of the jetpacks to the closest surface and adding a force to the jetpack to allow the player to float at that height but that I couldn't figure out a proper way to implement it.
The Raycast sounds like a great idea. Do the raycast to the next available platform and do as #Ahndwoo said in a comment, `
What you would need to do is divide the force of your thrusters by the
magnitude of the Ray. Thus, as the Ray gets longer, the force
decreases.
By doing this you'll get the natural movement from a force and you'll control how high can you get.
I would Make your thrusters holder as an object and as more turbines it has, the more powerful i'll get.
I had an idea in my game of having 3 layers to the map, the first being the ground, the second being the roads/grass/etc, and the third being impassable objects such as walls/buildings/lakes/rivers/trees. I have it so the player is centered at the middle of the screen and the layers of the map move in the inverse direction that the player wants to go. I was thinking I would have the different layers that way if the playerModel overlaps whereever something is drawn on the impassableLayer, then the playerModel would shift back. However, as I am new to xna, I don't know how to get the game to recognize that the playerModel is overlapping the impassable objects on the impassableLayer. The impassableLayer obviously only has objects drawn on it, and is empty anywhere there isn't an object. Therefore I can't just say:
if (playerModel.X > impassableLayer.X)
{
impassableLayer.X++;
}
As this would always be true.
Is there a way to tell if an object is overlapping a layer?
What you are looking for is collision detection I belive. You want to keep objects from passing through each other. It isnt as simple as the idea you had. True collision detection will take alot of work, but their are tons of tutorials for it.
Youtube tutorial on per pixel collision
Per-pixel collision on MSDN
Bounding Box Collision
You can always to a search here on the site or google, there are lots of resources for this out there.
I'm trying to get a general smooth scrolling mechanism that I can implement in my mobile applications.
I want it to be generic enough so that it can port to any platform, but I am currently working in C# on the .net Compact Framework.
What I'm doing right now is:
Create a Stopwatch object (in the panel's ctor)
on mouse down start the Stopwatch and save the current mouse point _lastMouse
on mouse move, stop the Stopwatch, and store velocity = (_lastMouse - curMouse) / Stopwatch.TotalSeconds then reset the Stopwatch and start it again
In most cases Stopwatch.TotalSeconds is between 0.02 and 0.03
on mouse up, I pass the velocity value into a smooth scrolling function, and that function continues to scroll the panel until either the end is hit or the increasing friction causes the velocity to be == 0
My problem is in the final step. The velocity values are generally int the 2,000-3,000 pixel range. The velocity is in pixels per second, so this is to be expected. I take the Stopwatch (which should be still running), stop it and I find the elapsed time from last mous move and multiply velocity by Stopwatch.TotalSeconds, get that distance and then reset and start the Stopwatch, then loop back and start all over again.
The expected result is that the elapsed time between refreshes multiplied by the velocity should give me the number of pixels (according to the last mouse move) that I should scroll. My actual result is that sometimes the panel goes flying and sometimes it bearly moves! the gradual slowdown is fine, it's just the beginning velocity that is off
Is there a flaw in the logic? Should I be doing something else?
Thanks for any help!
It seems to me that there are three possible sources of inaccuracy here. Firstly, as "A.R." said, you'll have problems if the granularity of your timer isn't good enough. Have you checked IsHighResolution and Frequency to make sure it's OK?
Secondly, even if your timer is perfect, there may be some inaccuracy in your position measurements, and if you're taking two in very quick succession then it may hurt you. My guess is that this isn't a big deal, but e.g. if you're on a capacitive touchscreen then as the finger lifts off you may get variation in position as the contact area goes down.
Thirdly, the physical motion of the finger (or stylus or mouse or whatever you've got doing the actual input; I'm going to guess a finger) may not be all that well behaved. At the end of a gesture, it may change from being mostly horizontal to being mostly vertical.
All these problems would be substantially mitigated by using a longer sampling period and maybe (try it both ways) ignoring the very last sample or two. So, keep a little circular buffer of recent samples, and when you get the mouse-up look back (say) 100ms or thereabouts and use that to decide your velocity. Or, if you don't want to keep that much history, use a simple IIR filter: every time you get a sample, do something like
filtered_dt = filtered_dt + SMALL*(latest_dt-filtered_dt);
filtered_dx = filtered_dx + SMALL*(latest_dx-filtered_dx);
filtered_dy = filtered_dy + SMALL*(latest_dy-filtered_dy);
where SMALL should be, at a guess, somewhere around 0.2 or so; then use filtered_dx/filtered_dt and filtered_dy/filtered_dt as your velocity estimate. (I think this is better than calculating a velocity every time and filtering that, because e.g. the latter will still blow up if you ever get a spuriously small dt. If in doubt, try both ways.)
If you use the IIR approach, you may still want to make it ignore the very last sample if that turns out to be unreliable; if you remember the latest dt,dx and dy you can do that by undoing the last update: use (filtered_dt-SMALL*latest_dt)/(1-SMALL), etc.
Here's an off-the-wall suggestion that may or may not work. You mentioned that you get more erratic results when there's a "flick" at the end of the gesture. Perhaps you can use that to your advantage: look at, say, how rapidly the estimated velocity is changing right at the end of the gesture, and if it's changing very rapidly then increase the velocity you use somewhat.
I'm designing a 3D game with a camera not entirely unlike that in The Sims and I want to prevent the player character from being hidden behind objects, including walls, pillars and other objects.
One easy way to handle the walls case is to have them face inwards and not have an other side, but that won't cover the other cases at all.
What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
One probably not so good idea I had in mind is to scan from the camera to the player in a straight line and see if you hit a non-hidden object, continuing until you reach the player. Unfortunately, I am an almost complete newbie on 3D programming.
Demonstration SVG illustration < that wall panel obscures the player, so it must be hidden. Another unrelated and pretty much already solved problem is removing all three wall panels on that side, which is irrelevant to this question and only caused by the mapping system I came up with.
What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
This is a good plan. You'll want to incorporate some kind of bounding volume onto the player, so the entire player (plus a little extra) is visible at all times. Then, simply run the intersection algorithm for each corner of the bounding volume.
Finding which object is at a given point on screen is called picking. Here's an XNA link for you which should direct you to an example. The idea is that you retrieve the 3D point in the game from the 2D point, and then can use standard collision detection methods to work out which object is occupying that space. Then you can elect to render that object differently.
One hack which might suffice if you have trouble with the picking approach is to render the character once as part of the scene, and then render it again at the end at half-alpha on top of everything. That way you can see the whole character and the wall, though you won't see through the wall as such.
One easy way, at least for prototyping, would be to always draw the player after you draw the rest of the scene. This would ensure that the player is rendered on top of anything else in the scene. Crude but effective.
Create a bounding volume from the camera to the extents of the player, determine what objects intersect that volume, and then render them in whatever alternate style you want?
There might be some ultra-clever way to do this, but this seems like the pretty straightforward version, and shouldn't be too much of a perf hit (you're probably doing collision every frame anyway....)
The simplest thing I can think of that should work relatively well is to model all obstacles by a plane perpendicular to your ground (assuming you have a ground.) Roughly assuming everything that is an obstacle is a wall with some height.
Model your player as a point somewhere, and model your camera as another point. The line in 3d that connects these two points lies in a plane that is particularly interesting to you, because if this plane intersects an "obstacle plane" below the height of the obstacle, that means that that obstacle is blocking your view of the player point.
I hope thats somewhat clear. To make this into an algorithm you'd have to implement a general method for determining where two planes intersect (to determine if the obstacle is tall enough to block view.)
I think the title is rather self explanatory but just to clarify I am trying to figure out how to tell which side the collision has occured on.
For a bit more detail, I'm trying to make a maze-like game so I can't simply stop all movement upon a collision. Instead I need to be able to tell which side the collision has happened on so I can block that direction.
Any help is appreciated and if there is a better approach to this issue, I'm all for trying it out.
I hope this is enough details but if you need anymore, ask and I'll edit. Thanks in advance.
[edit]
#viggity - No, I'm not using any specific game engine and I would post the current "detection" code but it's a little, absurdly, robust.
#Streklin - I'm using the this.Paint event to draw onto the form itself as it was recommended I start by doing that to get better at drawing real time. I'm also using a location that's updated each time the timer ticks based on what I press (left, right, up, down). Yes the maze is tile based. Currently it only consists of 3 colors even. I'm not a very advanced programmer.
#Eric - Definately a one-d game. Again, I only have 3 colors, the lines are black, the background is white and the square (the user) is green. I'm using the DrawImage() with Bitmaps to draw onto the screen.
[edit psuedo-code summary]
foreach(Wall _wall in walls)
if(player.intersectsWith(_wall))
stop movement;
#JeffH - I'm not really sure what you're asking as that's pretty much all there is besides testing code that I was using to try and get it working. The only thing I left out was the if statement to check if it was the x axis or not so that x and y could move indepedently from each other. So instead of getting "stuck" because you touched the wall, you could slide against it. I didn't see the point in including that though since the problem occurs before that.
Assuming you're talking about a 3D game here.
The normal of the face you can see points towards you, so the dot product of your direction vector with the face normal will be negative. If it's positive then you are coming at the face from the back.
If it's zero you're travelling at right angles to the face.
| <---------- your direction of travel
|
|----------> <- face normal
|
| <- face
If you're not in 3D then you could store the direction the wall is facing (as a 2D vector) and do the same dot product with your 2D direction of movement.
Based on your edit you can only go one direction at a time? Or can you go in diagonal directions? If it's the later, ChrisF has provided you the answer in 3D and the corresponding information for 2D. If not, you should just have to stop travel in the direction of travel - since there are only four possibilities it should be easy enough to check them all for simple starter game.