## Wednesday, March 5, 2014

### Code Bits: Linear Equation From Two Points

These days, I've been building a simple 2D physics engine to test with. While I was programming the collision detection, I needed to find the equation of the line between two points. I show a little bit of the Algebra here and write some code. I want the linear equation to be in standard form because I find it to be more useful than slope-intercept form.

Here is the standard form of a 2D linear equation:

\begin{aligned} Ax + By + C = 0 \end{aligned}
How do we calculate A, B, and C?

Method One: Calculating from Slope-Intercept
One way to calculate A, B, and C is to start with the slope-intercept form of the line and use some Algebra until its in the standard form. The following is the slope intercept form:
\begin{aligned} y = mx + b \end{aligned} In this form, m is the slope of the line and b is the y-intercept. This is m and b are fairly easy to figure out. For points (x_0, y_0) and (x_1, y_1) \begin{aligned} m = \frac{y_1 - y_0}{x_1 - x_0} \end{aligned} \begin{aligned} b = y_0 - x_0(\frac{y_1 - y_0}{x_1 - x_0}) \end{aligned} After filling in the variables and manipulating it so it is in the form whereby the equation equals zero, we get this: \begin{aligned} (y_1 - y_0)x + (x_0 - x_1)y + ((x_1 - x_0)y_0 - (y_1 - y_0)x_0) = 0 \end{aligned} so ... \begin{aligned} A = (y_1 - y_0) \\ B = (x_0 - x_1) \\ C = (x_1 - x_0)y_0 - (y_1 - y_0)x_0 \\ \end{aligned}
Method Two:
The second method takes some special properties of the linear equation into account. Notice the picture below:

The direction of the normal vector is the direction of the vector from (x0, y0) to (x1, y1) rotated 90 degrees. A and B in the linear equation can be thought of as a vector whose direction is the same as the normal vector. So we can calculate A and B just by calculating the normal vector. If we normalize this vector (make the magnitude 1.0), it will also be more useful when doing collision detection calculations. C is the dot product of the the normal vector and any point on the line.

Here's the code for method two:

typedef float vec2[2];

void Normalize2(const vec2 in, vec2 out)
{
float inv_length = 1.0f / sqrtf((in[0] * in[0]) + (in[1] * in[1]));
out[0] = in[0] * inv_length;
out[1] = in[1] * inv_length;
}

float DotProduct2(const vec2 a, const vec2 b)
{
return (a[0] * b[0]) + (a[1] * b[1]);
}

void LineFromTwoPoints(const vec2 p1, const vec2 p2, float &A, float &B, float &C)
{
// first calulate and normalize a vector from p1 to p2
vec2 dir;
dir[0] = p2[0] - p1[0];
dir[1] = p2[1] - p1[1];
Normalize2(dir, dir);

// calculate the normal vector of the segment this will be our A and B
vec2 normal;
A = normal[0] = -dir[1];
B = normal[1] = dir[0];

C = -DotProduct2(normal, p1);
}

The two methods give the same formula. In method two I make sure the magnitude of the vector (A B) is 1. This can be done using method one as well by dividing A, B, and C by the square root of ((A * A) + (B * B))

## Friday, February 28, 2014

### Latest

I'm hoping to get back into Android programming in a week or so. These days I've been putting a lot of time into the small experimental 2D engine that I've been working on. I've been focusing on PC development, but long term, I want it to also work on Android. I've been putting a lot of time into it because eventually it'll be the test bed for some of the other systems that I want to develop.

Currently the 3D engine, Squared'D, has too many parts to use it as a simple testing platform. I stripped out it's core 2D elements (these were mainly used for the GUI) and built it into a smaller game engine that doesn't require much set up. I'm using the 2D engine for experimentation as well. I've been trying to leverage more C++ features to make development easier. One big design decision was to limit the use of pointers and to use handles and C++ references as much as possible. I want to avoid using shared pointers and limit my code to only a few unique pointers when absolutely necessary. So far so good. I've gotten a component-based entity system working already. Entities only store handles to there components, and all components are stored in an std::vector inside their respective system classes. As I've been playing around with the system though, I think in the future, entities will not even need handles to their components. Entities will eventually just morph into position orientation with the components knowing which entity they belong to, but not the other way around. If it goes well, I'll incorporate these ideas into the next version of the 3D engine. Hopefully I'll be able to simplify things enough so that the next 3D engine will be good for testing and able to run on the PC and Android, but all this will happen after 6 months or so.

## Thursday, February 27, 2014

### New Game Engine Article Posted

I've just posted a new article that gives a high-level overview of my 3D game engine. You can check it out here: Squared Game Engine High-level Overview.

## Monday, February 24, 2014

### Latest - Game Engine Development

I'm hoping to get back into Android programming next week. These days I've been putting a lot of time into asmall experimental 2D engine. I've been focusing on PC development, but long term, I want it to also work on Android. I've been putting a lot of time into it because eventually it'll be the test bed for some of the other systems that I want to develop.

Currently the 3D engine, Squared'D, has too many parts to use it as a simple testing platform. I stripped out it's core 2D elements (these were mainly used for the GUI) and built it into a smaller game engine that doesn't require much set up. I'm using the 2D engine for experimenting with different programming concepts and paradigms as well. I've been trying to leverage more C++ features to make development easier.

One big design decision I made in the 2D engine was to limit the use of pointers and to use handles and C++ references as much as possible. I want to avoid using smart pointers and limit my code to only a few unique pointers when absolutely necessary. So far so good. I've gotten a component-based entity system working already. Entities only store handles to there components, and all components are stored in an std::vector inside their respective system classes. As I've been playing around with the system though, I think in the future, entities will not even need handles to their components. Entities will eventually just morph into position orientation with the components knowing which entity they belong to, but not the other way around. If it goes well, I'll incorporate these ideas into the next version of the 3D engine. Hopefully I'll be able to simplify things enough so that the next 3D engine will be simple enough for testing and able to run on the PC and Android. Major changes to the 3D engine will be long in the future. If you're curious about why I've chosen not to limit pointer use in newer versions of my engines, you can leave a comment.

I'm currently working on an article and video that will give details on how both the 2D engine and the 3D engine work.

## Thursday, February 13, 2014

### New Journal Entry - "Indies--Stop Treating Your Ideas Like Classified Secrets"

One of the most important lessons that I've learned is indies shouldn't be concerned with keeping their game ideas secret and that it's much better when indies let others know about their ideas.

....

For the complete entry: http://journal.squaredprogramming.com/2014/02/secrets.html