I have a 2d randomly genrated map for a platformer made of block(squares 40 by 40) stored in an array of 30, i have a push function to move the blocks around push changes the xpos aswell as the position on the array i'm only ever drawing the 5-25 position on the array.
When i move i'll only be moving the character within the first half of the screen. so there is collision between the middle part and the 0xpos of the screen now the problem i'm having is moving the blocks .
I cant think of a way to move them so it looks natural. Any ideas on how to do it? so far i have it so that every time the character collides with one side of the screen equivilant to 40 pixels worth of velocity it pushes a block and randomly genorates another.
Instead of trying to move all the blocks through an array it may be easier to use a standard queue.
http://www.cplusplus.com/reference/stl/queue/
With this method you would just have to deal with the movement of the blocks on the screen, and could remove the blocks from the front of the queue when they are no longer needed, adding another to the end.
This kind of effects are better achieved by using some physics engine. Look for example this one. Such engines really simplify the live in game developement, and the results always worth the effort of learning how to use them.
Related
We're making a hexagon-shaped pipe-connecting puzzle game. Our code is based on Objects, and we are making the puzzle piece components by object functions we made. We don't have any physics yet either. Each pipe is able to move and rotate.
How can we write a function to check whether two or more pipes are connected?
What game engine do you use? I'd suggest keeping track of the pipe hexagons objects in a grid (a 2D array). Just imagine that every second row of the grid is shifted in by half the size of a hexagon). Then you can simply access all neighbors through that grid.
Eventually you need a function within the pipe tiles object like
bool canFlowTo(pipe_tile & other)
where you implement the right answer for each possible constellation of the pipe tile itself and the "other" tile.
To check where a pipe flows to, just call this function with all its neighbors in the grid.
Of course you can also approach this with a physics engine and not check correctness of the maze with code. For that just have colliders for each tile that have the right shape. For liquid physics you should definitely use some existing engine.
Oh and by the way, game questions that are not really related to a general C++ algorithm would probably fit better here: https://gamedev.stackexchange.com/
I have a small application I have built where there are a few balls on a blank background. They all start flying through the air and use the physics I wrote to bounce accurately and have realistic collision responses. I am satisfied with how it looks except I have an issue where when my balls land directly on top of each other, the attach together and float directly up.
Here are the functions involved
https://gist.github.com/anonymous/899d6fb255a85d8f2102
Basically if the Collision function returns true, I use the ResolveCollision to change their velocities accordingly.
I believe the issue is from the slight re-positioning I do in ResolveCollision(). If they collide I bring them a frame or so backwards in location so that they are not intersecting still the next frame. However, when they are directly on top they bounce off eachother at such small bounces that eventually stepping back a frame isn't enough to unhook them.
I'm unsure if this is the problem and if it is, then what to do about it.
Any help would be awesome!
The trick is to ignore the collision if the circles are moving away from each other. This works so long as your timestep is small enough relative to their velocities (i.e. the circles can't pass through each other in a single frame).
When the circles first collide, you will adjust their velocity vectors so their relative velocity vector pushes them apart (because a collision will do that). After that, any further collisions are spurious because the circles will be moving apart, and will eventually separate completely. So, just ignore collisions between objects that are moving apart, and you should be fine.
(I've implemented such an algorithm in a 3D screensaver I wrote, but the algorithm is entirely dimension-agnostic and so would work fine for 2D circles).
I'm learning SFML right now, and I have just managed to implement some basic jumping and gravity. However, I can't figure out how to put in collisions because I need to also detect which side of an object is being hit. For example, I need upward movement to stop if it hits the bottom of an object, downward to stop if it hits the top, and left or right movement if it just hits a side. These would just be rectangular objects, so I wouldn't have to program weird for circles or unnatural shapes, just the 4 sides. Thanks!
There are a number of different ways to do this, some more complex (and efficient) than others. For your sake, I would begin with simply putting a "bounding box" around your character. This bounding box will move everywhere that your character goes and should surround him or her. Whenever this bounding box intersects with a solid object, there is your collision.
Here's where the fun comes in:
What does "intersects" mean? A lot of things. You can write a function to find out if two shapes are intersecting, or use a function from SFML, or use some sort of physics library (like Box2D).
How do you stop a character from passing through? Find out how far they will intersect (you check collision BEFORE you move the character), then make it so the character only moves to the bounds of that solid object.
This is an extremely simplified explanation. Collision detection and handling are difficult. Your best bet is to spend a lot of time DETECTING the collision then worrying about how to handle the collision. Many beginners try these at the same time and get frustrated.
I'm self learning C++ and playing around 2D tile mapping.
I have been reading through this scrolling post here, which is based on this tiling tutorial.
Using the above tutorial and some help from the Pearson, Computer Graphics with OpenGL book I have written a small program that draws a 40x40 tiled world and a Sprite (also a tile).
In terms of drawing/render order, the map(or world) itself is that back layer and the Sprite is the forward most (or top) layer. I'm assuming that's a good way of doing it as its easier for 2 tiles to interact than a tile and a custom sprite or rectangle. Is that correct?
I have implemented a Keyhandling() function that lets you move the map inside the viewport using the keyboards arrow keys. I have a variable called offsetx, offsety that when a key is pressed increases or decreases. Depending on whether I assign the variable to the map or sprite, I can more one or the other in any direction on the screen.
Neither seems to work very well, so I assigned the variables to both (map and sprite) but with positive values for the sprite, and negative for the map. So upon a key press, this allows my Sprite to move in one direction whilst the map moves in the opposite direction.
My problem is, the sprite soon moves enough to leave the window and not enough to bring the more of the map into the scene. (The window only shows about 1/8th of the tiles at any one time).
I've been thinking all day, and I think an efficient/effective way to solve this issue would be to fix the sprite to the centre of the screen and when a key is pressed the map moves around... I'm unsure how to implement this though.
Would that be a good way? Or is it expected to move the viewport or camera too?
You don't want to move everything relative to the Sprite whenever your character moves. Consider a more complicated world where you also have other things on the map, eg other sprites. It's simplest to keep the map fixed, and move each sprite relative to the map, (if it's a movable sprite). It just doesn't make much sense to move everything in the world whenever your character moves around in the world.
If you want to render your world with your character always at the center, that's perfectly fine. The best thing to do is move the camera. This also allows you to zoom your camera in/out, rotate the camera, etc. with very little hassle in keeping track of all the objects in the world.
Be careful with your usage of the word "viewport". It means a very specific thing in OpenGL. (ie, look at the function glViewport). If your book uses it differently, that's fine. I'm just pointing this out because it's not 100% clear to me what you mean by it.
I'm working on a little 2D platformer/fighting game with C++ and SDL, and I'm having quite a bit of trouble with the collision detection.
The levels are made up of an array of tiles, and I use a for loop to go through each one (I know it may not be the best way to do it, and I may need help with that too). For each side of the character, I move it one pixel in that direction and check for a collision (I also check to see if the character is moving in that direction). If there is a collision, I set the velocity to 0 and move the player to the edge of the tile.
My problem is that if I check for horizontal collisions first, and the player moves vertically at more than one pixel per frame, it handles the horizontal collision and moves the character to the side of the tile even if the tile is below (or above) the character. If I handle vertical collision first, it does the same, except it does it for the horizontal axis.
How can I handle collisions on both axes without having those problems? Is there any better way to handle collision than how I'm doing it?
XNA's 2D platformer example uses tile-based collision as well. The way they handle it there is pretty simple and may useful for you. Here's a stripped down explanation of what's in there (removing the specific-to-their-demo stuff):
After applying movement, it checks for collisions.
It determines the tiles the player overlaps based on the player's bounding box.
It iterates through all of those tiles...
If the tile being checked isn't passable:
It determines how far on the X and Y axes the player is overlapping the non-passable tile
Collision is resolved only on the shallow axis:
If Y is the shallow axis (abs(overlap.y) < abs(overlap.x)), position.y += overlap.y; likewise if X is the shallow axis.
The bounding box is updated based on the position change
Move on to the next tile...
It's in player.cs in the HandleCollisions() function if you grab the code and want to see what they specifically do there.
Yes. Vector based collision will be much better than tile based. Define each edge of a tile as lines (there are short cuts, but ignore them for now.) Now to see if a collision has occured, find the closest horizontal and vertical line. if you take the sign of lastPos.x * LineVector.y - lastPos.y * LineVector.x and compare that with thisTurnsPos.x * LineVector.y - ThisTurnsPos.y * LinePos.x. If the signs of those two values differ, you have crossed that line this tic. This doesn't check if you've crossed the end of a line segment though. You can form a dot product between the same lineVector and your curPosition (a little error here, but good enough probably) and it is either negative or greater than the line's magnitude squared, you aren't within that line segment and no collision has occured.
Now this is farily complex and you could probably get away with a simple grid check to see if you've crossed into another square's area. But! The advantage of doing it with vectors is it solves the moving faster than the size of the collision box problem and (more importantly), you can use non axis aligned lines for your collisions. This system works for any 2D vectors (and with a little massaging, 3D as well.) It also allows you slide your character along the edge of the collision box rather easily as well because you've already done 99% of the math needed to find where you are supposed to be after a collision.
I've glossed over a couple of implementation details, but I can tell that I've used the above method in countless commercial video games and it has worked like a charm. Good Luck!