Christmas was fun. I got some sketchpads, so now I can keep all my notes and junk all in one place, instead of scattered all over my desk (I should probably clean this up). I’m using one sketchpad for the notes, and the other for all my formulas and algorithms. I also bought myself some pretty nice pens, of different colors, so labeling shouldn’t be a problem.

Today, however, was admittedly disappointing in terms of progress. I started working on a quick reference, since the code was getting more and more complex, and keeping track of parameters for each function was difficult. This would be especially useful, since I’m developing Chase over a long time (up to a week or two between development days). The quick reference, however, wasn’t so quick. It ended up taking me longer to document the different functions than it did for me to actually make some of the functions, so I decided that it was a waste of time, and to ditch it. If it’s getting difficult for me to keep track of things, then it’s probably time for me to re-organize and clean up the code a bit.

I did get a working 3D rotation function in today. It’ll allow me to rotate models, polygons, and coordinates along the x, y, or z axis freely.

I’ll probably devote an entire day to organizing and cleaning up the code soon, and start following a little more strict and consistent standard of coding. I might even start naming functions the same way openGL does with their functions. Being somewhat new to programming,  it’s best for me to set some good habits for the long run.

Even though I haven’t programmed in the past week and a half until today, I’ve been hard at work at composing some of the formulas to be used in Chase. One that’ll be particularly essential is line to polygon intersection detection in 3D space. This would be used in my lighting algorithm and collision detection, unless I pick up a more efficient method of calculating these.

Another feature I’ll implement is culling. There’s a working zbuffer right now, but polygons intersection won’t actually draw that way. I’ll hopefully implement that eventually as well.

By the end of Winter Break, I hope to port the entire engine to C++. I originally chose Processing for ease of creation, and to make playing convenient and available to users from within their browser. Chase is looking a little too ambitious to be ran quickly within the browser. Making Chase in a lower level language (compared to Processing) will probably be a wise decision, since it’ll allow me more resources.

Development on Chase up to this point has been going super slow. I’ve only been able to use a few weekends to work on it. I’d work on it on the week days if I didn’t have school crowding my time, and family keeps making plans with me during some weekends. I’ve only had 6 days since the 21st of November to work on this. At this rate, Chase isn’t going to be completed any time soon, unless I get together a development team of some sort, which I doubt I’ll do.

Fortunately, Winter Break is coming up. It starts next Wednesday. I’d spend everyday developing, but no promises. I’ll take advantage of the time available as much as possible, and hopefully get some significant features done.

Even when I’m not developing Chase, I’m still perpetually thinking of the various algorithms and formulas to be implemented. Polygon to line intersection in 3D space, lighting and shading, 3D model collision detection, etc. The next time I develop, I plan to implement 3D model rotating along x, y, and z axis freely, have suspensions work with rotations on vehicles, and clean up.

I plan to later add different features, such as 3D rotations to the model drawing, and possibly lighting and texturing. It really depends on how much resources will remain when the engine nears completion.

I didn’t really want my game to be wireframe. It didn’t seem very ideal to me.  So I scripted up a simple hidden line removal algorithm, where lines being overlapped by polygons wouldn’t be displayed. mSL didn’t provide support for drawing custom polygons, and making a loop to draw each individual pixel of one would be way too slow. I went over every solution I could come up with, like storing different values that would be used in some of the frames. But I’d always run into one problem or another.

So I gave up on the idea all together. Later, I moved on to Processing. I made a couple of experimental apps, some being duplicates of previous scripts in mSL, and released them on OpenProcessing. After getting a feel for the language, I started to revisit the idea of the game I wanted to make. The idea of it kept coming back to me. In my mind, it seemed completely revolutionary. Concepts that are used very little, if at all, in main stream games.

I love isometric rendering. Something about the diagonal lines grabs my attention, and stimulates interest into the media. Photographers and artists would tell you that diagonal lines shows action, depth, and stimulation. They convey feelings of movement, and tend to lead your eyes throughout the piece.

Another reason I was interested in isometric rendering was the ease of use. All that’s required is a simple formula to plug the xyz coordinates, and you’re done. No rotations, matrixes, or whatever is really required. Just a basic knowledge of 3 dimensional Cartesian coordinates.

I began using an isometric formula I came across a number of months ago.
onScreenX = (x – z) * cos(radians(30)) + width/2
onScreenY = (x + z) * sin(radians(30)) – y + height/2
Assentially, adding width/2 to the x, and height/2 to the y, moves the point of origin (0,0) to the center of the window. I later came across the translate() function in Processing, which allowed me to do just that: translate(width/2,height/2);
onScreenX = (x – z) * cos(radians(30))
onScreenY = (x + z) * sin(radians(30)) – y

When multiplying anything by cosine and sine, the radius of an ellipse is created. (x-z) determines the width of the ellipse, and (x+z) is the height. The x-coordinate is then calculated to be 30 degrees counter clockwise from the x axis, and the z-coordinate is calculated 30 degrees clockwise from the x axis.

I was suggested to later on to use something like 33 degrees instead. Ideally to line it up so that the pixels aren’t abnormally lined up when drawn directly along the x or z axis. Instead of having 2 dots sideways, then one up, then 3 side, or whatever, it’d be a clean 2 dots to the side, then 2 dots vertical from that. I never adopted the idea, since none of my scripts ever heavily involved lines parallel to the x or z axis.

The isometric formula was an essential part of all my algorithms. It’d be used hundreds of thousands of times, for each coordinate involves this calculation. I later decided that it’d be a good idea to optimize it. Knowing that I’ll always be using 30 degrees for my isometric formulas, I precalculated that accordingly. 30 degrees in radians is 0.523598776,  cosine of that is roughly 0.866, and sin of our radians is conveniently 0.5.

Later, I rounded the 0.866 to 1. Rounding it that much seemed like it’d have a significant effect, and it sort of did. It was, however, only noticeable when placed side by side, or immediately compared, to an accurate rendering. The inaccurate rendering only appeared to be a slightly wider scaled version of the accurate rendering.  I ended up with an extremely simple formula:
onScreenX = x – z
onScreenY = (x + z)/2 – y

This, I planned to be the main component of the Chase Engine. Chase Engine is essentially going to be the name of the collective algorithms, functions, and classes in my game. I plan to make the graphical engine vector-based. Most isometric/dimetric/trimetric games are bitmap based, where images are used for every angle of every object.

I will render models polygon by polygon, just as if I were doing everything as if it were truely 3D. Textures would probably not be used, and if they are, they’d be procedural just as well as the rendering.

The isometric formula is the simple part of my game. Other, more complex and brain-tumor-inducing, things will be involved. They will involve my collective knowledge of everything I know about mathematics, programming, graphical algorithms, and plus some. I’ve thought about it for hours on end,  getting every basic concept ironed out. I knew my game inside and out before I even started, or so I assumed.

I started on November 21st, 2009. I’ve been dedicating entire days to the game. No less than 3 hours at a time, if you don’t count the brief breaks I take frequently to keep a fresh mind. The first thing I’ve accomplished was simple rendering. Functions that’d draw different shapes and lines in the isometric space. I then added a rough draft of the vehicle class, and of the environment class. The environment class was simply a place-holder, to test the vehicle class. In the vehicle class, featured a simple algorithm for calculating the y position of the vehicle’s corners, as they act as springs according to the wheels. This was to simulate suspension.

By day 2, November 22nd, I already had about 402 lines of code.  I created a model class and a function for reading files. I then wrote an algorithm to take on screen coordinates and convert them to isometric coordinates.

On day 3, or November 25th, the line count was cut down to 342, and the file reader was turned into a model importer. The model importer took in coordinates from a file, and loaded them into a 3D model class. I was lacking a z-buffer at that time.

I got a basic Scene buffer going by December 6th, 2009. There was no z-buffering yet. I also recreated the suspension algorithm for vehicles. This one was a little more dynamic, since it allowed me to change the mass, dampening, and other values with ease.

The algorithm I came up with for suspension was

newRest = rest + min ; The resting y position, is determined by a preset rest coordinate + min, or the tire’s y coordinate. This allows the resting coordinate to change as the wheel coordinate changes.

• The particle count is about 5,000. The code uses a custom class object for each particle, for easy updating and management. In the class for the particles, a number of variables are used to define the properties of each particle.
• The angle, to keep track of the position of the particle around the center
• The radius, or distance from the center the particle is
• dec and turnVelocity, both to decide the speed. dec is constant speed, where the particles closer to the center are faster (simply by multiplying by its distance inverted, 200-radius. We use 200 since that’s the max radius), and turnVelocity the speed of the particles controlled by the cursor’s x position, for when it’s dragged. turnVelocity is reduced by 5% every frame to simulate friction.
• tilt is pretty much the tilt of the particle’s orbit.

When each particle is initialized, the angle is set to in between 0 and 6.28 (2Pi), since 2Pi is about a full circle, this should distribute particles somewhat evenly. Radius is randomly in between 70 and 200. The 70 allows a visible gap about 140 pixels in diameter at the center.  The tilt is between -60 and 60 (60 below and 60 above the origin), and dec is (200-radius) * 0.00014. Since dec is the rotational speed, and the rotation is measured in Radians, our values will be pretty small (again, in between 0 and 6.28). So we multiply by 0.00014 to get a desired speed. Multiplying by radius will have the speed determined by distance from center, and by subtracting radius from 200, it will invert the speeds, meaning that the particles closer will be faster than ones on the outside.

Every frame, the particle is updated. Here is where we apply the rotational algorithms, and update the coordinates of the particles. Before the update function is called, a turn rate is determined by the cursor. The program finds out whether or not the user is clicking, and if so, it finds the change in x coordinate, and plugs it in to the update function. This is done so the program can run a lot more smoothly. If we were to have these 2 lines of code in the update function, then it’d have to be recalculated for every particle.

The first thing the update function does is, update the coordinates. It uses the formula:
x = radius * cos(angle)
y = tilt + 20 * cos(angle + 3.5)
z = radius * sin(angle)

In the x part of the formula, cosine is used to find the x coordinate around the center the particle is, and radius is multiplied on to apply distance. In the y part, tilt is added on to move the origin to (0,tilt,0).  20 shows that the y varies by about 20 pixels. In the cosine of the y value, 3.5 is added to the angle. The reason here is simply to orientate the swirl to face the camera at a correct angle. The calculation for z is the same as x, but uses sin to achieve a circular orbit.

The next part checks to see if turn is 0. Turn variable is the value plugged in earlier. The value was determined by the mouse’s effect on Galaxy’s spin. If it isn’t 0, it is multiplied by (200-radius), then set to turnVelocity. This makes the values so it’s larger if the particle is closer to center, rather than farther away. If it were 0, which is prevented, then (200 – radius) * turn would return 0. We don’t want this because we want to apply our own stopping algorithm, which will make it seemingly slow to a halt, but that is applied after angle is recalculated.

We use the formula: angle -= dec + turnVelocity to determine the angle. dec is the constant rotation the Galaxy goes through, and turnVelocity determined by the user.

turnVelocity is decreased by about 5% to simulate friction, and to make it seemingly slow down to a halt.

The previous coordinate is set if the current coordinate isn’t already (for the first frame).

A line is then rendered isometrically using the previous and current coordinate. I explain my isometric algorithm in the Explode post. Afterwards, the previous coordinate is set to the current, for drawing the tail in the next frame.

I also updated Galaxy, but I’ve yet to document the actual app on here. If you’ve seen the app before (on OpenProcessing), you’ll find that there’s a noticeable change now.  The speeds are inverted. Instead of being faster on the outside and slower on the inside, it’s now faster on the inside and slower on the outside. I also did similar changes to Galaxy as I did to Explode. Coordinates converted to PVector, and revised comments and code.

It’s been pretty hard in keeping up with programming. I’m taking Drivers Ed, which is taking up a good part of my day, and I’m often exhausted by the time I return from school.

Press any key to restart animation.

Explode was my first processing applet. It involves about 15,000 particles. It’s an animation of a particle fireworks effect.

In the setup, 10,000 particles are initialized in an array, using a custom Class. The class holds all the information and functions for the particle, so it allows easy particle management. When initialized, an x, y, and z variable is created for the particle’s coordinates all start at (0,width/4,0) in the format of (x,y,z), with y being up and down. Then another coordinate (px,py,pz) for the tail of the particle. There’s also speed, theta, and phi. These variables controls which direction, and how fast each particle goes. Speed (or in this case, rho), phi, and theta are all spherical coordinates. Rho simply defines the distance from the center, phi is the latitude (along the y axis, up and down), and theta is the longitude (along the x axis, around the sides). They’re randomly assigned when initialized. Last of all, there’s gravity. Gravity simply defines the y velocity (up and down).

All that happens for each frame is that the update function in the particle class is called, for each particle. Before any calculation is done, (px,py,pz) is set to the current coordinate, for the tail of the particle. Afterwards, the new (x,y,z) coordinate is calculated, using the speed, phi, theta, and gravity. These are used to calculate a coordinate on a theoretical sphere around the current coordinate, which ends up being the resulting coordinate.

The resulting coordinate is rotated along the x and z plane 2 degrees clockwise. This adds to the wow factor, and creates the illusion of 3d.

After the coordinates are calculated, the y velocity (gravity) is increased by 0.3, and the speed is decreased by 2% to simulate friction. Then the particle is drawn using an isometric formula.

The isometric formula is pretty simple in concept. It converts our 3D (x,y,z) coordinate to the 2D screen coordinate (x,y). Isometric pretty much means that the sides, x and z coordinates, are rotated 45 degrees along the x axis. In my formula, I simply rotate them 30 degrees. The x axis is adjusted to be 30 degrees diagonal one way (top left to bottom right), and z axis is rotated the other (top right to bottom left). The y coordinate, however, isn’t adjusted. It’s simply added or subtracted according to the x and z coordinates.

When the final on screen (x,y) coordinate is calculated, the color is set according to how far along the particle is along the x axis (top left is darkest, bottom right is lightest), and the particle is drawn.

You can view the app and her source on OpenProcessing (linked above), with the source commented.