On Sunday of last week, I had a pretty neat idea. I was looking around the internet, and ran into some sort of gaming glove. I thought “Hey! That’s pretty cool.” I had something different in mind, and found that this glove didn’t have the capabilities I’d hope for. I was thinking of something like a wiimote but in the form of a glove.

I remembered seeing Johnny Lee’s videos of his wiimote hacks. He set up his wiimote to receive input from external infrared lights, and to track it while doing several neat things like head-tracking or a multi-touch projector white-board. This was all very impressive, considering he was using very cheap supplies to accomplish these things. He also made a finger-tracker using an infrared light array (grid of lights), and some reflectors taped onto his fingers. I eventually came to the idea of using an IR light with the webcam. I understood that cameras have a tendency of picking up infrared lights, unlike our human eyes. I grabbed a TV remote, wrote a quick script, and it worked greatly!

I went to Radio Shack that evening, picked up an IR light, a battery holder, and a button. I then went to Lowes and got a pair of gardener gloves. When I got home, I taped it all together using some electrical tape, ran the script, and it worked beautifully. The glove wasn’t perfect yet though. The algorithm takes all the pixels the webcam inputs, finds the brightest ones, then averages them and use that. I actually discovered that sunglass lenses blocks visible light from entering, but NOT infrared light, which was extremely convenient on my part. I popped the 2 lenses out of the glasses, taped them together, and made a little holder so it can slide onto the webcam. This also helped reduce glare, which is another cause of some error in accuracy. Another fall-back was the jitterness that occurs naturally in your hands, and the wide range of brightnesses the infrared light can give off when angled differently. Fixing this was simple, simply load all the calculated positions into an array of 5, 10, or however much and average those out to significantly smooth the cursor.

Hopefully I’ll be able to work on from that. Add another infrared light and add some sort of “multi-touch” capabilities, or maybe even attempt something like a virtual tablet, using the same methods as Johnny Lee’s white-board. The possibilities are endless. Below is a gallery of a bunch of different high-res images involving the cursor glove.

This doesn’t mean I’m letting go of Chase, however. I’m working on it as much as I can. I worked on it again, and got even closer to a working graphics engine. I’m currently creating a Scene datatype. It’ll act much like Adobe Flash Professional’s scene, but in programming. In my engine, you’ll plot different models and polygons in a 3D or 2D space in the scene. All 3D coordinates are rendered, but 2D coordinates are kept the same. Using a scene class will make it easy for the developer to rotate, translate, dilate, or do whatever globally to all the coordinates being displayed.

I got rid of all of the transformation functions (translate, dilate, etc), since they’re already existent inside Coordinate and Polygon’s class. Hopefully I can get the Scene class to work pretty soon here, so I can proceed to start adding actual new features and tools to the engine.

Below is a library of pictures of the cursor glove and webcam filter made out of sunglass lenses:

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.