It’s been over a month since my last post. I apologize for the lack of updates. I truly wish I could keep up with Chase at the moment, but I’ve been getting some other things done lately. For a month I’ve been training to get into track. My primary reason for training is for health though. I find that running for 3 miles can have the same effect on me as a cup of coffee, except longer lasting. This, hopefully, will help me productivity-wise in the long run. I have been getting into the habit of running a mile before school on week days, which hopefully will keep me in top conditions.

Not much has happened on Chase, or any other of my projects. I re-organized some of the files in Chase, and made some progress in the Scene classes. I also started on a data importer and exporter (a function that can save and load models and other junk). I’ll likely not get much done on Chase in the next week or so due to some after-school classes I’m taking, and me training for the last week before track starts. But after that, I’ll hopefully be able to get a good pace going, and start making progress again.

I have made some updates on the glove cursor though. After I made my last post about the glove last month, I took apart an old mouse and experimented with the circuit board. Keep in mind that I have almost no knowledge on how most circuit boards work, but I did manage to figure out which parts I should connect with which to send certain commands to the computer. If I take a wire connected to any of the ground connections, and tap it against to any of the connections for the left-click, right-click, or middle-click connections, it’ll send a command to the computer respectively. After some painful burns and an attempt at getting lead poisoning, I eventually soldered a wire to a ground connection and wired it to the thumb of the glove, then soldered a wire from the left click connection and wired it to the middle finger. From this, you can simply click by tapping your middle finger to your thumb. I plan on doing the middle click and right click later, after I get some significant progress done in Chase.

Good day! Over the winter break, I began working on Chase’s conversion over to C++. Today, I’ve had the convenience of a snow day, so I took advantage of it and proceeded to work on Chase’s Engine. Note, however, I haven’t really made any *real* progress. I will count this as a day though, since a lot has been done in the conversion.

The conversion isn’t done yet. I’ve got all the coordinate, polygon, and model classes converted (although certainly not finished in terms of features), as well as the transformation functions. If tomorrow also provides the convenience of a snow day, I’ll take advantage of that as well, and hopefully get Chase’s C++ engine up to an equivalent of Chase’s Processing (the API for Java!) engine.

I’ve uploaded a picture of my colorfully written rough draft for how my .h and .cpp files should work out. My compiler (Dev-C++) has an awfully convenient feature which allows me to place individual files in their own folders unlike the Processing IDE, as far as I’m aware of. You can check out the picture by clicking the image to the left/top of this post’s text. Feel free to give me any feedback or comments.

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.

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 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.

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.