Remember yesterday, I said “If tomorrow also provides the convenience of a snow day, I’ll take advantage of that as well…”? Well, today happened to also be a snow day (woohoo!), and I did as I told you. I worked on Chase’s Engine. I’m currently at about 744 lines of code, so I’ve made some progress since I started the conversion. Yesterday’s version included support for handling coordinates, polygons, and models in 3D space. It also had some transformation functions (translate, dilate, and rotate) for coordinates and polygons.

I’ll probably delete those transformation functions the next time I edit. Today I’ve nested support for adding, subtracting, dividing, and multiplying in both the polygon and coordinate function. Not only an add/sub/etc function, but operator overloading (like for +, -, or *). This will allow me to use coordinate and polygon data types, for example:

polygonA * ((coordinateA + coordinateB) / coordinateC)

This will be exactly why I won’t need my transformation functions. Any sort of geometric manipulating can simply done using the nested math functions or use the coordinates/polygons in a formula. I also added in a rotation function to both classes. Another neat feature I’ve implemented is 2 and 3 dimensional support for the Coordinate and Polygon class. I was originally going to have a separate class for 2 and 3 dimensions (eg. Coord2D and Coord3D), but that won’t be necessary with the mighty convenience of function overloading in C++.

The picture above shows a rough draft code flow chart of Chase’s graphic engine. I drew this on the first this month (and year!), and will probably, if not definitely, will change as I refine my concept for Chase’s engine.

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.