I'm currently working on a jump 'n' prototype in html5 canvas.
The language is actually not that important, I just need a hint on the algorithm.
First look at this illustration: http://i.imgur.com/3CwBI.png
As you can see I have two rectangles that collide with each other (the white one is the player, the gray one a static obstacle).
While precalculating the next frame I need to fix the players position if a collision is about to happen. The human brain can clearly tell, that the white rectangle in the image is going to land on top of the platform (considering linear motion). But how does one tell this the program ?
I'm moving the player with 2d vectors.
Edit: I can already detect the collision, I just need to know the direction, so I can fix the players position on the corresponding side of the obstacle.
For each corner of your player, draw a line segment between where it is now, and where it will be next frame.
for each of these line segments, and for each line segment making up the platform, check to see if the two segments intersect.
If any intersections occur, then the player will collide with the platform in the next frame.
Edit:
90% of the time, the red line segments only collide with a single line segment belonging to the platform. If the red segments collide with the platform's left, the player struck the wall; if the segments collide with the platform's top, the player landed on the platform.
One corner case is when a collision occurs both on the top and the side.
In that case, in order to determine which collision "really" occurs, you need to decide which one occurs first in time. the earliest intersection is the one closest to the earlier player rectangle. In the above image, if the upper right player is the earlier one, then the earliest collision is with the top of the platform.
Related
As the title suggest my problem lies in some representation of a sphere surface in computer memory. For simplicity, let's say we are making a chess game where the board is on a sphere. If the board was a classic flat board, then the solution is simple: use a 2D table.
But I don't know what kind of a memory structure I should chose for a sphere. Namely, what I want from this representation are:
If I move a pawn stubbornly in one direction, then I should return to the point where I started,
During such "journey" I should cross a point directly on the other side of the sphere (I mean to avoid a common "error" in a 2D game where moving pass an edge of a board will move an object to the opposite edge, thus making the board a torus, not a real sphere)
the area of one board cell should be approximately equal to any other cell
a cell should have got an associated longitude-latitude coordinates (I wrote "associated" because I want from the representation to only have got some way to obtain these coordinates from the position of a cell, not to be eg. a table with lat-long indexes)
There's no simple geometric solution to this. The crux of the problem is that, say you have n columns at the equator, and you're currently near the north poll, and heading north. Then the combination of the direction and the column number from the top row (and second from top row) must be able to uniquely identify which one of the n positions at the equator that path is going to cross. Therefore, direction could not be an integer unless you have n columns in the top (or second to top) row. Notice that if the polygons have more than three sides, then they must have common edges (and triangles won't work for other reasons). So now you have a grid, but if you have more than three rows (i.e. a cube, or other regular prism), then moving sideways on the second-to-top row will not navigate you to the southern hemisphere.
The best bet might be to create a regular polyhedron, and keep the point and direction as floating point vectors/points, and calculate the actual position when you move, and figure out which polygon you land in (note, you would have the possibility of moving to non-adjacent polygons with this method, and you might have issues if you land exactly on an edge/vertex, etc).
I'm trying to filter out illegal moves efficiently for a game engine of an old board game. The rules nor the game don't really matter.
The board is a 2D grid with walls around its borders and with every move the player moves one of his pawns and places a wall (horizontal or vertical, of length 2 between any 4 squares) of his own. I need to test for every possible wall whether or not it splits the board into unreachable segments, or rather whether or not a path from a pawn to a goal is blocked.
e.g. If there's a wall vertically across the whole middle of the board, it splits the board into two segments; and if there's a pawn on one side and the goal's on the other, that's an illegal wall placement. I've tried the graph approach with the answers to my previously posted question, but it's pretty slow since I need to generate a move tree and it grows exponentially.
I'm not exactly sure how to approach doing this. I'm guessing processing the board first, then checking for every wall whether it connects to an existing wall and whether that creates new sections. Afterward, check if the crucial squares are in those newly separated sections.
I am planning on making a game that utilizes light (and shadows) as part of the gameplay, however I can't think of an efficient algorithm to implement them and I'm sure there is an elegant solution.
The white area is directly illuminated by light, light grey is illuminated by the walls that are directly illuminated and dark grey is darkness.
I wish to find those areas in an efficient manner. (real time, with the light being able to move)
Although not realistic, that is the simplest way I could think of my problem, any other implementation that includes direct light and reflected light is welcome.
...
My first attempt would be to draw lines from the light to the perimeter of the screen and find the first wall they intersect. But repeating this algorithm for every illuminated part of the wall to mark "ambient" light is not feasible.
Also note, the game is in Flash so I don't think I can utilize the gpu.
Inspired by Ryan's answer.
In a 2d grid, mark every point of the screen as lit. Then for every wall on the screen (in order of closeness to point) draw a shadow behind them as such: Before going to the next wall, first check which parts of it are lit and which are not, as to not draw the shadow twice. Mark all the walls for which the shadow was drawn for the next step, as these are the probably lit walls. (we should check again before the next part)
For every lit line segment (wall) first check if any wall intersect the segment. For every intersection split the lit segment in 2 at the intersection.
For the end points of every line segment, repeat the first part in a temporary array, and at the end add all the lit points into the final array.
The first part should go over all the points on the screen and all the points on the walls once. So O(area+length of walls), and depending on the complexity of the scene (number of walls, and interesections the second part should apply the first part about 20 times.
This may work in real time, however make sure to store the lit areas while the lights are not moving.
You don't need to draw all light lines, just the important ones. For example, with one point light source and one line, you only need to solve two intersections.
For reflected lighting, you would start with a point light of intensity n, then every time this light intersects a wall, you split the wall into smaller segments, and add a linear light source of intensity n-1 on the illuminated segment. You can do this as many times as you liked.
does anybody know of a good algorithm for this task:
a multi polygon contains the reserved areas
find an empty position for the given polygon which is closest to its original position but does not intersect the reserved areas
I have implemented some very basic algorithm which does the job but far from optimally.
Thank You!
Edit:
my solution basically does the following:
move given polygon in all possible directions dx and dy
check wether the new intersection is less than the previous intersection
if so, use new position and make sure that you don't move your polygon back and forth at the same position
repeat these steps a maximum of N times
Example: it is intended for placing text which should not overlap with each other.
One method that immediately pops into my mind is to shoot a ray (i.e. measure a line segment) from the original position to every vertex of the polygon. Do a comparison on those distances, and then based on those comparisons, narrow it down to the minimally far away line segment of the polygon. Compute the perpendicular intersection of that line with the origin, and you'll get the minimally far away point. If the vertex comparisons don't lead you down the right path, just shoot off lines in random directions, and just stop when you're happy with the result. It doesn't sound like you require optimality.
Let's look at the original problem: making sure that one piece of text doesn't overlap another. Presumably this is for labelling a map. The way I do it is this: draw the text invisibly, checking for overlap (by using a specialised graphics context that instead of drawing a pixel, checks whether a pixel is already there) then try another position along the line on which the text is to be placed - usually a street. I try the middle of the line first, then successive positions further and further left and right of the middle. If that fails I try again with a condensed (narrower) font.
I'm working on a 3D tile based game and I'm using AABB collision detection. For every cube that the player is intersecting, I find the axis along which the player is intersecting the cube the least, and push the player out of the cube along that axis.
Depending on the order that the cubes are checked in, this can cause problems when sliding along the edge of multiple cubes. I have created a diagram that should explain the problem:
http://imgur.com/mmK0W.png
Arrow #1 is the attempted movement of the player. The other arrows are the collision response.
In the left diagram, collision is tested against the right cube first, causing the player to be pushed to the left, and then upwards. (bad)
In the right diagram, collision is tested against the left cube first, causing the player to be pushed upwards, at which point the player is no longer intersecting the other cube. (good)
Any ideas on what the most efficient way to solve this might be? Or any better ways to handle the collision response?
Thank you.
A discrete implementation forces you to inject some continuous math in the system, only when required (cubes / directions overlap).
For each cube c1, c2 ... ci with which the user cube (uc) intersects at the time of the check, you want to find out which cube was "touched" first - there is only one, as in real life. Consider the direction d of uc, and, taking the amount of uc in ci (overlapping) find the position of cu at the time it "touched" ci.
Determine which cube was "touched" first cj (the one that required the most rollback on the d axis - the sooner in time) and use only this one to calculate the collision reaction.
Not only you'll reach accuracy. but it will help if all cubes are moving, have different speeds etc...
From your diagram, it seems you want the smallest move that minimises the overlap between the player and the cubes. Each cube with overlap will try to "push" the player in two orthogonal directions. Can you do something like pick the minimum push of the maximum pushes in each direction?
You might implement a kind of hybrid broad phase when your two (or more) stationary cubes in a row can be combined into one larger rectangle. Test against the larger rectangle first. It will give you the results of your green check mark and be faster than checking each cube anyway. Then, after that, only if you need to, check against the individual cubes.
A collision can push an object on 1 axis only. To determine the axis to push:
else -- not this
elseif -- change to this
if w > h then
push x
elseif h > w then
push y
end
This works if your tiles are aligned.
Use circles to avoid the stick on unaligned tiles