Development diary week 02 - GideonPARANOID/olandroid GitHub Wiki

Progress since last week has been drastic! At the end of last week, I simply had one line drawing on a grid. I've got a lot more going on now!

That first line was a component. These are the building blocks of the manoeuvres aircraft can do - for example, a loop consists of eight consecutive components. These components make the abstraction of the manoeuvres simple, with a component being defined as being a unit vector with 45 degrees of movement up, down, left & right (giving it a sort of cone of movement). Components are currently restricted to either full lock or none - minimum (being down 45 degrees), zero (straight) & maximum (being up 45 degrees) - on two planes - pitch & yaw - giving eight possible directions like a compass (not inclusive of straight). This is quite a blatant abstraction, but it works for the manoeuvres I aim to express.

When I had these components working, I plugged them into a manoeuvre class, which consists of an array of components, each drawn sequentially. To draw them sequentially, I needed to know the relationship between the beginning of their line & the end - this can be stored as a matrix operation. Starting with the original drawing matrix for the start position, I can multiply the current previous draw matrix with the one of the current line to work out the matrix operation to begin drawing at the end of the previous line. This results in manoeuvres having an array of matrices corresponding to the array of components. This works, but it's pretty darn inefficient with this matrix stack being needed to be recomputed every time the perspective is shifted. It might be worth using these matrix operations to compute the locations of the ends of these components in relation to one matrix, saving a lot of computing resources for a component. One for more thought in the coming week!

I consider the shape of a manoeuvre to be data, & not something which should be hardcoded into the application. With this in mind, manoeuvre representations were encoded in an XML file using components to describe them & make relationships to their OLAN figures. I built an XML parsing class to read this file & produce a hashmap which is used as a catalogue of sorts. This will be used for building flights (which consist of many different manoeuvres). I had a few problems implementing this, as to reference a resource (the XML file) in Android requires a reference to the application context. When I originally tried to do this, the class I was working on was way down the class diagram of ownership I ended up with issues with the OpenGL wanting to use the context too. This prompted a redesign to balance that tree & think in a more model-view-controller way. That refactor was one of the most valuable ones so far.

This week I also started & nearly finished the outline specification brief. This document discusses the project's goals, deliverables & resources used & provides a more concise outline of what the aim of this project is.

This coming week will involve a fleshing out of the current manoeuvres file, a redesign of the constituent parts of a manoeuvre for efficiencies sake, & thinking of a way of better visualising the flight.