Tag Info

Hot answers tagged

27

I think the direction of the coordinate axes are holdovers from different domains where the crucial plane was different, and X/Y were aligned with that crucial plane. In some applications the ground plane was the most important, thus X/Y were the ground and Z ended up perpendicular to that. For games however the crucial plane is usually the screen ...


16

First, here is the code. An explanation will follow: /* * tw, th contain the tile width and height. * * hitTest contains a single channel taken from a tile-shaped hit-test * image. Data was extracted with getImageData() */ worldToTilePos = function(x, y) { var eventilex = Math.floor(x%tw); var eventiley = Math.floor(y%th); if ...


13

LERP - Linear Interpolation I gave this answer for a similar problem some days ago, but here we go: Linear Interpolation is a function that gives you a number between two numbers, based on the progress. You could actually, get a point between two points. The Great Formula - How to calculate it The general LERP Formula is given by pu = p0 + (p1 - p0) * ...


11

Okay, a couple of questions here, so I'll do my best to explain them all. Coordinate System The coordinate system of anything affects more than just the orthographic projection. It affects translation and rotation as well. For example, set up your camera projection as you have described. Now create an object and set it to move either toward you or away ...


9

What you need is to know the geometric distance between the user's touch (T) and your "difference point" (D). distance = squareroot((T.x - D.x)² + (T.y - D.y)²) Then as another answer said, just check if the distance is less than the circle's radius, 5 pixels in your example.


8

It's just tradition. Neither system is objectively better than the other, so you just have to get used to using both and switching between them from time to time! Right-handed coordinates are traditional for modelling where one imagines the XY-plane to be horizontal, and the Z-axis to be vertical. Left-handed coordinates are traditional for cameras where ...


8

As you already noticed, there's no way around UV coordinates for games. Thankfully, blender comes with some very good UV unwrapping tools. The simplest way to get UV coordinates from a 3D model in blender is to use Smart UV Project. You can do that by pressing U while in edit-mode and then select "Smart UV Project" from the menu. This creates UV "patches" ...


7

You can use either the x or the y value of the intersection to compute the z-value (using x): t = (x - X1) / (X2 - X1) z = Z1 + (Z2 - Z1) * t Where x is the x-intersection. X1, X2 and Z1, Z2 are your known x and z-values, respectively, of the segment's endpoints.


7

Sounds like you might want to start using a delta time and a time-based movement speed. It could be a little difficult considering that it looks like you could be using a tile-based engine, but if you use a delta-time, your movement equation will look something like this: x += unitsPerSecond * deltaTime; Where x is a floating point variable (float or ...


7

In the image the red vector is the one we are trying to convert to cartesian, given angles phi & theta (in the description I will refer to the length of the vector as r, for radius of the sphere). So, the y-coordinate is the easy one, we know what the angle is between the red vector and the y-axis (phi), we just project the vector onto the y-axis; ...


6

This depends on the combination of frameworks you are using. Sometimes a 2D game framework makes it very difficult to work with coordinates that are not bound to pixels because they were designed specifically for designers to think about their game world in pixel units. However, it's not a requirement. A game I'm currently working on relies on Box2D units ...


6

I'm not sure about OpenGL but DirectX allows you to over write the default left-handedness therefore it wouldn't matter. As you've said, it's "nothing but" a convention, and at least DirectX allows you to work with both. Conventions do not matter by themselves, the only problem is that you need to be consistent with your choice. Mixing two such systems leads ...


6

Before I answer the question you already asked, some notes: You can use A* with the original grid system you are using. The key things you need are neighbors and distance (for the heuristic). For neighbors with your grid system, you need to do something different for even and odd columns (as you mention); here's how: neighbors = [ [ [+1, +1], [+1, ...


5

The simple answer is: Whatever you want them to be. There isn't a "right answer" here. In effect, you've asked a question like "I have a tetrahedron, what is the right color?" Nobody can give you a meaningful answer. You'll need to rephrase the question in a way that can be answered, such as "What are the texture coordinates of the 'bottom' face if I ...


5

Unless you're going to have so much going on that the speed of trig functions is going to be a concern, I think focusing on a Polar system will be sufficient. Storing the angle and distance-from-center for your sprite (Theta and R, respectively) will make the logic for moving based on Left, Right, Up, and Down understandable: Moving Left and Right would ...


5

I think that for creating the matrix you should get the front vector first, you do: Vector3 vFront = Camera.vTarget - Camera.vPosition, vUp = Camera.vUp, vRight(0,0,0); vFront.Normalize(); vRight.Cross( vUp, vFront ); // Up x Front = Right vRight.Normalize(); vUp.Cross( vFront, vRight ); // Front x Right = Up vUp.Normalize(); then you build the matrix ...


5

Basically, you need to repeat performing multiple different tasks at independent intervals. In pseudocode that will typically look something like this: updateTime=1000/120 nextUpdate=time() repeat{ while(nextUpdate<time()){ updatePlayerPositionPhysicsAndStuff() nextUpdate+=updateTime } render() } So ...


5

I find your question very confusing but I believe that this will do what you want. Assuming you want the center of the object to be draw to the center of the screen irregardless of resolution. var screenCenter = new Vector2( GraphicsDevice.Viewport.Bounds.Width / 2, graphicsDevice.Viewport.Bounds.Height / 2); var textureCenter = new Vector2( ...


5

Your question sounds a bit confused; there's no such thing as "the matrix of a point"; matrices just convert from one coordinate system to another. Did you mean that you have the two matrices that go from A to world coordinates, and B to world coordinates? And you want to find the matrix that converts from B to A? In that case, you'd just want B_to_world ...


4

Downvote me if I am wrong, but I don't see why people are recommending swapping y and z. That would make your coordinate system from being right handed to left handed. Try this yourself, swap the y and z, and reorient the axis so that x points right and y points up. You will see that z points the opposite direction from its original (away from the screen). ...


4

If you dont mind using your rect as two triangles, here is the code from my (working) raytracer: //RAY-TRAINGLE test Vec3f e1 = p2 - p1; Vec3f e2 = p3 - p1; Vec3f s1 = cross(aRay.dir, e2); float divisor = dot(s1, e1); if (divisor == 0.) return false; //not hit float invDivisor = 1.f / divisor; // Compute first barycentric coordinate Vec3f d = aRay.org - ...


4

Having tried every conceivable way of doing it, I have found if it's purely a 2D game, just use the screen drawing system, it will make your life much easier. Sin, Cos, and atan2 need to be used slightly differently, but this inconvenience is easily made up for by the simplicity of knowing which way up, down, clockwise and anti-clockwise are. I would also ...


4

PhysX can pre-process your collision meshes into it's own optimised collision structures (probably a series of convex meshes). The process is called cooking, and it is described in a blog here: http://actuated.wordpress.com/2010/06/26/mesh-collision-in-physx/


4

You can convert between 3D and 2D coordinates in a variety of ways, some of which have more meaning than others. For example you could just drop the Z coordinate, yielding an (x,y) pair, but that probably doesn't do what you want semantically. But you're specifically asking how to convert between model, world or view space 3D and screen space 2D as used by ...


4

So I guess that your initial attempt is to iterate through all meshes in your scene, for each mesh, check all triangles if they intersect, right? The brute-force way. I'm not sure if there's a lightweight library for you to solve your problem, but the problem is quite a large discussing area. I would suggest using a bounding-volume structure, such as a ...


4

Actually, "most pathfinding algorithms" don't rely on any specific set of coordinate systems at all. Most algorithms, like the most widely spread and probably most popular of them, the A* algorithm, just rely on a set of connected nodes in a graph and functions which estimate or straight up calculate the cost of moving from one node to another. The ...


4

If all you want is for those objects to be unaffected by the camera, why don't you just use a separate view matrix for them (one that never changes)? Simple! And since you probably want them to always appear on front of everything else, don't forget to clear the depth buffer, or use separate render targets. Edit I just realised a problem with this ...


4

First of all, X points right, not left, in screen coordinates. But yes, the normalized device coordinates are a left-handed system. It doesn't matter for backface culling, though. From the OpenGL FAQ: OpenGL face culling calculates the signed area of the filled primitive in window coordinate space. The signed area is positive when the window ...


4

I had this same problem for a game that I was writing. I imagine that this problem will differ based on how exactly you implemented you isometric system, but I'll explain how I solved the problem. I first started with my tile_to_screen function. (I assume that's how you are placing the tiles in the right location in the first place.) This function has an ...


4

represent the distance you travel as a number between 0 and 1. The problem with your code is that you don't have any notion of "how far am I between the two endpoints." function lerp(start, dest, dist) { var x = start.x * (1 - dist) + dest.x * dist; var y = start.y * (1 - dist) + dest.y * dist; return [x,y]; } lerp(start, dest, 0) -> start ...



Only top voted, non community-wiki answers of a minimum length are eligible