I was originally trying to base some of what I was doing off of some tutorials I found for tile-based games (tonypa?) since my stage terrain is tile-based. His example code was utilizing a function to get the corners of a shape, and using those for part of the collision detection routine. It sort of worked for me, but in the end, I realized my situation was too different for me to adapt it in a way I understood. His movable sprite was exactly the same size as the tiles in his map; mine's not (or wouldn't normally be).
I went through and added a lot of debug messages to paint as clear of a picture as possible of what was going on prior to coordinate adjustments, with adjustments applied temporarily, and then after the adjustments are actually applied. I think I have it working to a point where my left and right collision checks are at least returning the correct results when they should. It's just not doing anything in response to the collisions yet.First - don't panic
Second - step through on debug and set watches or inspect your values at run time and you will no doubt find a logic error in there. If stepping through isn't supported start catching those fringe cases in condition statements and output some values in console to see why it may be dropping into a collision erroniously.
Last resort post your code and we'll help.
No worries, man. I appreciate the advice! I did actually change my function to do what you suggested previously. My problem now is just how I should be applying correction (post-collision resolution).
Points, I think? All of my positioning has the upper left corner as 0,0. The box is defined like so (pseudo-code below):
box.top = y
box.bottom = y + height
box.left = x
box.right = x + widthI'm not really tripped up on which force to apply when as I am to simply managing persistent force. That is, should I always be applying downward force -- aka gravity -- when the sprite isn't "jumping", and let the downward/bottom collision detection handle keeping it from falling through the floor and infinitely downward?
I think I follow... So when the user presses the specified key/button, that sets the sprite into a jumping state and I start applying upward movement. When the sprite either has a top-side collision or reaches the maximum height, I set it to a falling state and start applying downward movement. And when the sprite is in a falling state and a bottom-side collision occurs, I set it to a grounded state and stop applying any vertical force.
A platformer is pretty much the use case that I'm building. My biggest concern - other than it working right - is that the same logic can be applied to both the player's sprite and any of the AI-driven sprites. The more generically I can make any of the components, the better.
Question for everyone: how long do you take a break for once you're done with a game before jumping into another one? I'm finally done with one game and I have ideas for another, but I kinda want to play some Borderlands for a bit.
Question for everyone: how long do you take a break for once you're done with a game before jumping into another one? I'm finally done with one game and I have ideas for another, but I kinda want to play some Borderlands for a bit.
Do you have any good examples of this? I don't think that I understand what you mean by "apply a big force".
For C++, new and delete will allocate and release memory for objects. I wouldn't expect you would need to worry about efficiency or object recycling for that unless your game involves a huge number of objects, like 1000+, being spawned and/or destroyed often and repeatedly. If you DO have such a case, one thing that might help is the "flyweight" design pattern, though I don't think I've ever used it myself.
Yo yo yo, new gameplay video of Chopper Mike: http://youtu.be/-lkCQ3NMbtY
Unedited video here: http://youtu.be/K5L2iTRZSLc
Currently designing more levels on paper. So much radder than in an editor!
GF just mentioned "spinning rings". There shall be spinning rings!!
A spinning follow cam would make a load of other problems, and this is simpler.
After a few goes at a level you know where everything is. The levels are tiny!
just trying to be constructive.I agree with Dynamite's point. As a developer you're going to memorize the levels much more than a player would and telling them to get around camera issues through trial and error is bad game design. You could consider zooming out the camera a bit because the perspective seems to be quite narrow relative to how fast you're going, or you could make the zoom level depend on your speed like in the top down GTA games. Stuff like that can be really tedious to design and implement but in the end it's going to be critical to how much people enjoy your game. I don't mean to sound harsh btw
Ok, which text box does GAF prefer?
Textbox 01
Textbox 02
Textbox 03
Textbox 04
tks alot for your input
Thanks dude! That's "programmer typography" right there!
I got my T-Shirt today:
I put the text too low, but other than that, I like! That's from streetshirts.co.uk, BTW.
On the camera subject, I do set the camera at different angles and distances per level! So you can see far ahead on the bigger, high speed levels!
public struct AABB
{
public Vector2 _center;
public Vector2 _extents;
public Color _debugColor;
public Rectangle XNARec
{
get
{
return new Rectangle
(
(int)(_center.X - _extents.X),
(int)(_center.Y - _extents.Y),
(int)_extents.X * 2,
(int)_extents.Y * 2
);
}
}
public float Right
{
get { return _center.X + _extents.X; }
}
public float Left
{
get { return _center.X - _extents.X; }
}
public AABB(Vector2 center, Vector2 extents)
{
_center = center;
_extents = extents;
_debugColor = Color.Black;
}
public bool IsColliding(AABB b)
{
return AABB.TestAABBCollision(this, b);
}
public static bool TestAABBCollision(AABB a, AABB b)
{
if (Math.Abs(a._center.X - b._center.X) > a._extents.X + b._extents.X) return false;
if (Math.Abs(a._center.Y - b._center.Y) > a._extents.Y + b._extents.Y) return false;
return true;
}
public bool IsColliding(AABB b, ref Vector2 MTV)
{
return AABB.TestAABBCollision(this, b, ref MTV);
}
public static bool TestAABBCollision(AABB a, AABB b, ref Vector2 MTV)
{
if (Math.Abs(a._center.X - b._center.X) > a._extents.X + b._extents.X)
{
MTV = new Vector2((a._extents.X + b._extents.X) - Math.Abs(a._center.X - b._center.X), 0);
return false;
}
if (Math.Abs(a._center.Y - b._center.Y) > a._extents.Y + b._extents.Y)
{
MTV = new Vector2(0, (a._extents.Y + b._extents.Y) - Math.Abs(a._center.Y - b._center.Y));
return false;
}
MTV = new Vector2((a._extents.X + b._extents.X) - Math.Abs(a._center.X - b._center.X),
(a._extents.Y + b._extents.Y) - Math.Abs(a._center.Y - b._center.Y));
//MTV = new Vector2((a._extents.X + b._extents.X) - (a._center.X - b._center.X),
// (a._extents.Y + b._extents.Y) - (a._center.Y - b._center.Y));
if (a._center.X > b._center.X)
{
MTV.X = -((a._extents.X + b._extents.X) - Math.Abs(a._center.X - b._center.X));
}
else
{
MTV.X = (a._extents.X + b._extents.X) - Math.Abs(a._center.X - b._center.X);
}
if (a._center.Y > b._center.Y)
{
MTV.Y = -((a._extents.Y + b._extents.Y) - Math.Abs(a._center.Y - b._center.Y));
}
else
{
MTV.Y = (a._extents.Y + b._extents.Y) - Math.Abs(a._center.Y - b._center.Y);
}
if (Math.Abs(MTV.X) > Math.Abs(MTV.Y))
{
MTV.X = 0f;
}
else
{
MTV.Y = 0f;
}
//MTV = new Vector2(1, 1);
return true;
}
public void DrawDebug(Texture2D t, SpriteBatch sb)
{
sb.Draw(t,
new Vector2(_center.X, _center.Y),
XNARec,
_debugColor,
0f, _extents, 1f, SpriteEffects.None, 0f);
}
}