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.