Notice

Just to let my thousands of die-hard followers know, the lack of updates for the next week is normal, and fret not, I'll be back again.

Week Four / Day Three

Didn't start working until a little later today due to my grounds keeper duties here at home, though I was able to make some decent achievements regardless.

I dove head first into trying to get the timers working today, but unfortunately I haven't quite gotten it yet. I never realized decoupling the physics and display updates could be such a touchy subject, but it makes quite a bit of sense now that I've read over a few articles on it about 100 times. The idea is that if the animation updates are tied directly to the display updates, than the 'world' time of the game is different on every machine, and every time it is executed on each machine. The reason for this is display updates are not constant. Even with simple primitives a game could run between 50-60 fps inconsistently. What happens when the objects updates aren't decoupled from the frame updates is every change in fps results in a change in the speed at which the animation updates. Even if an object is moving on a straight line at a constant speed, the drops in framerate will result in a 'slower' (to the eye) object.

What's involved in the process of separating the two is integrating over a specific delta time based on the last time the frame was drawn. Since there are differences between the draw calls each update, the world needs to be updated in different time spans. For example, if draw call 1 takes place at time 5, and draw call 2 takes place at time 10, dt = 5. Now, let's say our physics timestep is 0.5; that means 10 calls need to be made to the world updater in between those two calls. Now, if draw call 3 takes place at time 13, dt = 3 and the physics updater only needs to make 6 calls.

Unfortunately I don't have my head wrapped around the integration used for the update yet. Euler's integration was the method that I thought would work for what I needed, but according to what I've read the integration over the velocity is only accurate with a constant acceleration. I do not have a constant acceleration at all (it changes every frame update), so that leaves me in the boat of implementing what the author of this article suggests, the RK4, or Runge Kutta order 4 integrator. Unfortunately for me, despite the foresight of getting my Bachelor's in Math as well as Comp Sci, I never took differential equations. It turns out the differential equations is one of the most important concepts for those of us interested in 'real-world' simulations. Who knew? So, even though the code for the integration is simple, I don't get it. I mean, I get that it's an integration of my force function that goes to the 4th derivative to get an accuracy good enough for my needs, but I don't necessarily get how. If I don't get how something works at its deepest iterative level, it just doesn't click in code. Though, I understand more about differential equations now than I did 4 hours ago (none?), so I think I'll get the kinks worked out eventually.

Today's big hit is the first working texture! Even though it isn't an actual game texture (that is, it's simply a white box with a black border over my ship) it is a working texture that didn't break the whole game. Which is great, considering last night it was a non-working texture that did break the whole game. OpenGL needs lighting for textures, otherwise the world gets very dark; news to me. But from here I can start to get some better place holder art in for my buttons and the objects onscreen, and finally start work on the menu (tomorrow's first project, I promise). I think that is it for today, so bask in the glory of my textured game:

Week Four / Day Two

Today went alright. In turns out that what I needed to do for the level loading was actually much easier than I had expected, so right now my test level is loading at runtime from a resources file. I need to add in an option for loading custom levels as well (not compiled in), which hopefully shouldn't be too difficult either. I was going to start building the menu system today, or at least a skeleton of it, but I figured getting the textures working was more important. I have the idea of the menu all worked out but I still need to learn a lot for the textures though, so they took priority.

One of the problems I've had with using tutorials for OpenGL is the different drawing methods. Whether I'm using specific vertices, vertex arrays, or vertex buffer objects changes how everything gets drawn, and the tutorials each use whatever they feel like it seems, and I had an established setup for my renderer already set in place. Well, as is the norm with these things, it wasn't quite as simple as I had expected. I have some design decisions to make at this point about rendering, and I guess I'll make that tomorrow's focus.

Short update today, but decent progress. Happy coding.

Week Four / Day One

After a brief, unexpected hiatus we return to your regularly scheduled program.

Today was a very productive day. When I left off I had the basic game up and running, but the backend was a mess. I had gamestate information all mixed up in the renderer, just to get the proof of concept down. This morning I took care of all of that, implementing the gamestate proper and stitching it to the renderer through the base application engine. This provides much more organization and makes debugging much easier due to classes being separated without deep reliance upon other classes unnecessarily. This will also come in handy when I finally implement the animation update separate from the draw call so the game will run smoothly and consistently across different versions of the iPhone (that is, better on everything else from my lame 3G).

Once I had the backend to a point I was satisfied with I continued working on getting the core game engine to a playable point. I decided to go with a fixed camera that follows the player's ship as they move around the playing field. I had considered a 'frame' setup where the camera would only move when the player left a certain boundary, but the simplicity of the fixed camera out weighed any gain provided by the other method. Proper controls are also implemented now to change color, so they game can actually be 'played'. I've started playing around with level borders as well, so that got a basic implementation in place.

Two things that go together that I need to work on now are the menus, and the level loader. I haven't decided the format of my levels yet and how I'm going to store them, but I've asked on the forums and weighing a few options. Once that's squared away I can build the (basic) menu system around it and be very close to the framework of an actual game. It shouldn't be too long to where I'm focusing on content creation rather than engine work, but that's to be seen.

Something my stepdad and I were talking about, and I've always thought is a really neat feature of a game engine is a debug menu. I don't have the game engine tuned to where everything interacts correctly just yet, and a debug menu would make things way easier. Plus having a back door to poke and prod at my engine in realtime makes me feel all fuzzy inside. Something to consider for the not too distant future.

Also, here's some evidence of the work being done:

Rounding out Week Three

So, I've changed plans again.

Let me explain.

Going into my iPhone work, I did not admit to knowing everything I was going to need to know, nor do I believe anyone expected me to. I've had quite a few game ideas over the years, and I had a handful that I wanted to work towards when doing app development. My first idea that I started with is still a viable option, and I plan to continue with it eventually. My tornado work caused me to shift focus as I thought it would be easier to get something up onto the app store quicker. My tornado construction however was a bit of a memory hog, and there was no way around it. I even tried simplifying things, but when it came down to it I could not got results similar to running on a PC, so the effect lost most its appeal. On top of that, I still have the same memory issue. I'm intent on solving it, but exploring options that won't cause the same hindrance.

I realized that the level of real-time I was going for was too much for my first application. Too many moving parts without a solid understanding of the system I was working on. So my new project is based off code Ryan Morrow and I wrote a few years ago as an introduction to OpenGL. It's simple, small data bandwidth and pretty much has one moving part. This means the core game mechanic can be polished up quickly (I hope, I'm pretty sure I got it all working tonight), and I can focus on all of the other fluff that needs to wrap the game up and make it worth playing. It breaks one of the original design paradigms I had which was randomly generated levels, but makes up for it with the possibility of a PC based level designer. The benefit to this is quick level creation, easy updates to the game, and user generated levels. It's all still far off, but within the realm of possibility.

So, Monday morning I'll be starting fresh and trekking on once again into new territory. I have not lost faith, but rather gained some resolution. I knew this would all be a learning process, and that I might not make the mark the first time. Let's just hope I got it this time and don't have to step down into...turn based games.

Week Three / Day Three and Four

The last two days have not been very good development days. Given that game development was going to be the biggest leap I've ever made with programming, I knew I would hit snags; big snags like the one that is plaguing me now. My game world uses a class called objects, which right now contains only a vector< vertex > for storing the vertices that make up the model. It also only contains one method right now to construct an object, a cone. My rendering class then contains a vector< object* > to dynamically allocate a set of cones at run time with a loop that runs during the initialization of the instantiated rendering class object. So far, so good. A few tests show that accessing this vector of object pointers within the init method returns no errors. Now, once I get into the actual draw calls in the render class via a render method, everything hits the fan. I cannot for the life of me stop getting weird invalid memory access errors within the vectors when I try and loop through and draw each of the objects dynamically created. If I don't use pointers, and instead create the objects in a vector< object>, everything works fine, but that is far too rigid. To put that sort of limitation in my project at such an early (and deep) stage is extremely poor design as the world generator is going to be creating, deleting and passing around objects all over the place. I'd really like to be able to work with pointers for their flexibility in what I want to do. Unfortunately, it has become very clear to me that I don't have a strong enough understanding of the standard template library. A bit of research earlier today revealed than when working with something as dense and structurally complex as a vector of class pointers which contain vectors of structs themselves, which is what I'm doing, what you see is not what you get. Many precautions need to be taken when digging around with that much memory and at the level I am, and it's apparent to me that I don't really know what all those precautions are. As Uncle Ben once said, with great power comes great responsibility. This is the longest a bug has ever taken me to fix, and it's extremely frustrating, but I'm hoping the education I get while solving it will be valuable information I end up using again and again.

Week Three / Day Two

Today was fairly uneventful, and I'm a bit rattled from dealing with pointer issues all afternoon. I have a structure called vertex which contains a vector for position and a vector for color. I use it to define vertices within the gamespace. To do so I needed a place to keep track of collection of dynamically allocated vertices, a vector of vertices, or rather vector. But if I'm dynamically allocating, I need to keep these somewhere as well. A vector suffices, and I want to be able to pass these around amongst vectors, so that leaves me with a vector<>* >. Now, as I said before a Vertex contains a vector of position and a vector of color, each with x,y, and z values. Now, for me to actually use these values I pass a reference to the space in memory where the first x value occurs; this isn't too bad, except that to reference that point requires the following line:

&(*(*void)[0])[0]).Position.x)

Or something similar, I think I have the index wrong. It's a mouthful, and referencing and dereferencing that many layers of points gets a little messy. I ended up replacing the inner vector with an object structure, but my memory reference errors remain. To make things worse, it runs fine on the simulator and seg faults on the device. Fantastic.

Earlier today I did get some camera issues worked out, as well as some control smoothing. There is still jitter that occurs around the first 30 seconds of execution as well as randomly throughout the use of the app, but I'm pretty sure I've isolated it as an issue with accelerometer data which shouldn't be too large of an issue. Other than that I just worked on the tornado model design a bit more but haven't coded anything in yet. I posted a thread on idevgames about my issue, so hopefully someone gives me some pointers. Ha, computer joke.

Week Three / Day One

Things have changed, once again.

Yesterday while reading iPhone Game Development there was a section on novelty apps. Apps that don't really have a purpose, they are just meant to be a fun "trick" app that you show people and than forget about really. Well, I hadn't planned on doing a novelty app, because I'm not really sure how I feel about them. I like the idea of a true game, something that you can play and get better at, that people will get hooked to. On the other hand, I myself have gotten stuck on websites that weren't for any particular purpose, they just did something that was neat to play with.

So I decided to make a novelty app.

But only because I realized I already had something that could be used as a novelty app. For graphics Junior year I made a tornado simulator as my final project. Almost all the code was already written (or so I thought), I just had to port it. By last night I had my original code running, and when I finished today I had a landscape with some shapes and the ability to move the tornado around via the accelerometer. I have a lot of work to do with the tornado, as its flow and shape just aren't quite right yet, but it's coming together rather well. Hopefully this will only take a few weeks to fully implement and I can meet my original goal of September 1st for having something on the app store, while my original game will hit the back burner for the time being.

Week Two / Day Four

I literally write this as I am finishing up today. Considering I had to take Monday off and woke up an hour late this morning, along with no desire to stop, I just kept working. Today was a bit different than most other days. While I didn't write a ton of code or anything, I did get a lot figured out.

When I started this morning I really didn't have a solid understanding of OpenGL's matrix transformations. While I could use them to do simple work, whenever I tried to stitch them together they never worked quite how I expected. When you perform transformations with matrices, you are actually creating one matrix. Starting with the identity matrix you apply translation, scaling and rotation matrices in order to create a new matrix that is multiplied by each piece of geometry in your scene. Matrix multiplication is not transitive, and OpenGL uses a reversed call pipeline with the transformations, so I was getting six types of twisted. After drawing some diagrams and reading a few more tutorials I finally 'get' it.

Once I had all that squared away, I worked for about another hour or so before I started to realize I was really wasting time. I reached a point in working with my test bed app where I wasn't actually exploring new technologies, I was spending so much time hard coding junk in that wasn't going to be reusable at all. So, instead of barging on brute forcing things worthlessly I spent a few hours figuring out a few of the core mechanics required for my final engine to be at the point the test bed is currently at. I now have a decent framework for the engine that handles some of more abstract backend work that I was tediously hard coding. I'm not quite to the point I was at with the test bed with what you see and can do, but when I've written the back end for it and reach that point the engine itself will be far more capable and ready for improvement than the testbed.

I've reached my first odd point. I still haven't heard back from O'Reilly, so I think I'm going to start looking for other solutions in implementing a PVRTC loader. I really would like to finish that book so I can work on other areas besides rendering and graphics. I have a pretty solid idea of the look I'm trying to achieve, so once I have the know how I should be able to get it polished up and move on to other areas. But, other than that I'll continue working on the engine design, figuring things out piece by piece and implementing as I go. I'm changing a lot of the ideas I originally had for my "first game" I'd ever write, mostly backend work and tool development, but I'm on a pretty strict time frame right now so here's hoping for the next game.

Lastly, Lennon suggest posting a screenshot of my current work. Here is where the test bed was at when I stopped working with it earlier today. It doesn't look like much, but touch control, accelerometer control and lots of relational transformations are bringing you the scene you see:

Happy coding.

Week Two / Day Three

Today was a basically a half day since I spent most of the afternoon out having lunch with my Dad, but I still managed to make progress. O'Reilly hasn't written me back yet, so I'm still on hold with continuing with the graphics. This isn't necessarily a bad thing, as I now have no choice but to to work on the test bed getting some of the core technologies working just how I want them. Today was pretty trig heavy, testing my abilities to move about different coordinate planes in order (semi) efficiently calculate different angles I'm using in my game. I've got a very basic version of touch input tied to main player control, as well as the basics of the accelerometer control. I won't say exactly what it is I'm doing now, but I will say implementation is progressing well with the vision I had for the over all feel over the game. I have quite a bit of physics to brush up on. I'm not sure I ever learned about rigid body kinematics, which requires taking into account mass of an object and not only tracking and adjust velocity and acceleration as a particle but its angular velocity, inertia and momentum as well. It sounds a lot worse than it is, and I'm guessing what I'll be needing is 100 lines of code or less; just need to figure out what those 100 lines are.

Tomorrow will just be a continuation of today's work. While I have the interface connected to player control, it isn't 'exactly' moving the player. I have a few ideas about the world implementation, that is the surface the game takes place on, but there are still some considerations I have to make, so I'd like to get some of those worked out tomorrow as well. Other than that I'm still just piecing together ideas for the final engine design and waiting to hear back from O'Reilly. Also, I've been thinking for months about two names. Project and Studio. You'll know when I know.

Week Two / Day Two

Another day of ups and downs. I only got to work until around 3.30 today as I had a doctor's appointment, but I still managed to get some decent work in. I continued working through the texture examples in the book, but unfortunately hit my first major bug with code from this book (whose praises I couldn't sing enough up until this point) while implementing a texturing format called PVRTC. I got PNG textures to work fine. I was able to load a texture in, read its image size from the raw data, parse it and use it as a texture. However, when attempting to use PVRTC, the book's method for getting the header information was funky, and I'm now using a middleware SDK provided by Imagination Technologies, the company who supplies Apple with the iPhone, iPod touch and iPad GPUs, the PowerVR SGX and MBR Lite. I've written to O'Reilly, the publishers of the book to see if they can help me with a solution. It's a problem with getting values from a struct pointer which is acting as though it hasn't been initialized. Normally this wouldn't be a big deal, but the initialization is done in a round-a-bout way using parts of the iPhone's Objective-C framework that I really haven't taken the time to learn. Losses have to be cut somewhere, and since I'm depending on Objective-C wrappers with a majority C++ code base, I don't really have the time to learn all the ins and outs of Cocoa touch and Objective-C.

Things weren't all bad today though. I'm starting to understand OpenGL better than I ever did before, and it's making me less worried about implementing things poorly as I've feared doing since I've started. For example, I finally got the touch screen figured out, but I still wasn't exactly sure about rendering the HUD for my game. I tried to make exact changes to the lines and models, but I felt like I didn't have true control over the space. Well, since I was working in 3D, I was rendering everything with a perspective view as the human eye, rather than an orthogonal view which creates a flat surface with no perspective. So all I had to do was switch between perspective and orthogonal spaces for drawing the 3D world and the interface respectively.

Tomorrow I'll be working primarily on fine tuning the interface and then trying to connect it up to a basic model for interaction. I could have the first "demo" of my game up and running tomorrow, a pretty exciting feat for 7 days on a brand new platform. Happy coding.

Week Two / Day One

So, this weekend didn't go exactly as planned. Home life took precedence and programming hit the back burner for over 72 hours unfortunately. But, we trek on. Today wasn't a very eventful day. I continued working through the book examples, adding surface rendering to the model viewer and even moving onto lighting and textures. The lighting is very simple, at least for what I'll need it for, but I'm not entirely comfortable with textures yet. The examples I've worked through haven't clearly shown how a simple texture is patterned onto a parametric surface without any clipping. I'm sure like most things I'll get to an "ah ha!" after staring at the code some more.

I also played around with my "testbed" app a bit. The testbed is where I implemented the accelerometer control, and I've now started to work on touch implementation a bit more. The coordinate planes of openGL and touch screen on the iPhone are not scaled the same, and so far my work of mapping the two has been a little screwy, but with a bit more tweaking it should be fine. I think I'm going to continue implementing technologies in the testbed, just to work out the kinks, so when the time comes for true implementation I'll have the hard parts figured out.

I really need to start considering overall engine design, but before that I need to nail down exactly how the game is going to work. After really considering the implementation of some of my original ideas I think I would be biting off more than I can chew, which I've only done once before. I'd rather that not happen again, at least if I can avoid it. I would really like to have a basic tech demo of the controls working by the end of the week, as well as a full design layout of the engine. I think I can do that.

Day Five: End of Week 1

Today was a fairly successful day. It was going well enough that I worked an extra hour, and probably could have gone a bit longer if I wasn't tempted with mojitos from upstairs. Earlier this morning I finished coding the 3D version of the arrow application, named HelloCone. Once I had this running I messed around with the rotations a bit to try and get a feel for manipulating objects in OpenGL in the 'proper' manner.

OpenGL is based on seperate matrices, such as the model matrix, the projection matrix and the view matrix. The API is optimized for performing matrix operations on these separate matrices. Therefore, the best performance comes from representing all your data in terms of matrices and operations on those matrices. I learned about a few new concepts today, such as different buffer objects with provide standard methods of inputing data into the OpenGL pipeline. I've also learned a bit about Quaternions, which are vectors used for interpolating between different points in space, allowing smooth animation translation over multiple axis. The current project I'm working through in the book introduces a knew application model with better isolation of modules comprising the program. I'm getting closer to being able to start a fresh project in XCode to begin piecing together my game engine, except I'm hoping there are a few more useful concepts I will get from the book. Looking ahead at the next sections shows I be upgrading from wireframes to triangular models, adding lighting and performing model injection into the engine. Within a week I should have enough knowledge to begin building the core elements of the modeling and rendering engines.

Later in the afternoon I decided to take a break from the graphics work. The book had introduced touch elements which I'll be using quite a bit, but aren't necessarily that difficult to implement. I don't think I'll be using gestures in the first game, or at least not the first version, so that simplifies touch implementation quite a bit. However, I have been struggling for a few days to get the accelerometer to really work. Well, today I got it tied into an OpenGL view and have a little line demo that points in the direction the iPhone is oriented. I've also implemented some smoothing that is almost perfect for what I need, as well as a calibration method in case someone doesn't feel like playing my game straight up and down.

All in all it was another successful day. I'm sure I won't be able to stay away from working at all this weekend, so hopefully I'll have some extra updates or at least a standard update at the beginning of week two.

Happy 4th of July!

Day Four: First major shift, but for the better

This morning started out a little rough. At the end of the day yesterday I had been messing around with some OpenGL examples, just trying to figure out how to get my own shapes to render. I had found a tutorial on OpenGL ES, but it basically required I use a template provided by the author which I could not get to compile to the correct target device, and wouldn't recognize the SDK changes I made, so I was trying to merge that with the template in XCode. It was getting pretty rough, I could not get the desired results, and I knew the problem. I didn't have a strong enough understanding of the OpenGL pipeline and its ties to the iPhone's view environment.

So, I started to look for a better starting point. I had seen a book while browsing on bn.com, Iphone 3D Programming, so I did a google search for the corresponding site to try and find some sample code. It turns out the entire book is available online, and is updated to the newer APIs! Even better, the book forces the reader to start programming from the base iPhone windowed application, which provides nothing except a basic view. From here, all the OpenGL dependencies are added, and the linking view necessary with OpenGL are created. The pipeline has to be instantiated by hand as well. Those who know the CS side of me know I don't like taking anything granted. I appreciate the low level side of programming, and I prefer to implement as much as I can myself.

So, the book starts off with drawing a simple triangle to the screen. This is much more than just a drawTriangle function. Basically, the API is defined, and a RenderEngine interface is created, and a rendering engine is implemented for API V1.1 and V2.0. From here vertices are defined an objects are built out of vertices and triangles. After implementing this the second chapter takes you through the OpenGL ES methodologies and reintroduces the linear algebra needed for 3D graphics, and than starts on converting the simple triangle example to a 3D cone. Here is where I got to today and will continue with tomorrow.

I plan to work through this entire book, and basically get much more graphics knowledge than needed so as to get as much out of OpenGL as I can. I still plan to do a 2D top-down game, but I think there will be much more of a 3D backend controlling the whole thing. There are lots of optimizations that I would like to get from the book as well. In the end I'll be better off, especially for game number two.