“Bugger!” is now officially Open-source, and safely uploaded to sourceforge. Check it out if you like spaghetti code
It’s been a while
This is not to say I’ve been sitting idly by, a lot of progress has been made so let’s get right into the thick of things!
1. “GL_TRIANGLE_STRIP”
As I explained the time before last, GLES doesn’t support GL_QUADS for rectangles. Instead you’ll have to draw a pair of triangles using GL_TRIANGLES. Or not. In fact there are more efficient ways of drawing a pair of triangles, notably GL_TRIANGLE_STRIP, which each vertex added plus the previous two to specify the new triangle. This is great for triangles which share an edge, and our two obviously do: it means that we only need to specify the 4 unique vertcies that make up our quad.
2. Animation: “source” rectangle
A while back I discussed sheet-based animation for “Bugger!”. I decided to use a similar technique here, so concatenated all the various frames together using ImageMagick’s “montage” command. This is much more fun than doing things by hand with an image manipulation program, and much faster.
We now need to be able to specify which part of the image we want to draw. SFML’s Sprite class makes this very easy (SetSubRect) and even SDL has this functionality, it’s just that for whatever reason it doesn’t work on my phone. As a result I ended up writing my own GLES wrapper, cannibalising various parts of SDL’s in the process. With this functionality implemented I could pretty much copy-paste my old code across to get animations working!
3. Scaling: “destination” rectangle
As I learnt while working on “Gone”, smart-phones are not like desktop computers: each device has its own screen-size and pixel-density, both of which can vary immensely. In theory the two should be taken into account, but I’ll only be worrying about the resolution (= size * density) here. I’ll explain the problem using an example. Let us imagine that our player-character is represented by a 32×32 sprite which must avoid 16×16 asteroids in order to survive as long as possible, remaining within the bounds of a 640×480 screen:


4. Virtual destructors
Let us say B inherits from A, and I reference my B instances with A pointers: when clean up all my A references the destructor of class A will be called, not that of class B.It makes sense: after all, for all the compiler knows my A pointer do, indeed, point to A instances. But this is a serious problem if the child class B is allocating its own memory: memory leaks will invariably occur en masse!
Thankfully it is possible to force the program to look for the overriden destructor: as with other methods we need to declare the mother class’s destructor “virtual”.
This is probably obvious for a lot of people, but I managed to miss out on advanced C++ while off in Italy (it’s a third-year course in France and a second-year course across the border). Which reminds me: I have a Bachelor’s degree
5. constants vs. hashed strings
If an object requests a given image or sound, it’s better to have it identified with a number: there’s no sense comparing two strings at runtime. That said specifying all these numbers, be it as #defines, enumerations or constants, is just plain frustrating. Surely there’s a way of getting the best of both worlds?
As a matter of fact yes. Well sort of, every technique has its disadvantages. Generating and comparing hash-codes is easy to program and fairly quick to execute if you use the right technique. Just be careful using std::hash on a const char*: what you’re hashing is the address, not the string!
What’s rather annoying is the hash_map is depreciated and unordered_map is is still experimental (I’m not even going to try using it on Android). Ultimately I just went with map as in “Bugger!” and wrote my own hash functions.
6. Programming by components
I talked about this earlier, here once again is the video explaining components and why they’re a better choice than excessive object hierarchies (like the one found in “Bugger!”):
There’s only one kind of object in my current architecture, the “Thing”. This class has a position, a list of events it has received (more on this later) and a bunch of components which completely define its behaviour. In other words, game objects are defined purely by parameterisation, with said parameters stored in an XML file.
I got this idea from JSP and JSF: programmers define custom tags which web-programmer can then use to make dynamic web-pages. New tags can be requested and implemented (though the JSTL contains about everything most sites will ever need), but otherwise programmers and designers keep out of each other’s way.
I want to experiment with writing my own library of reusable game-object components, the end goal being to need only minimal code to implement each new project.
That’s all for now. I’m pretty busy so posts may not come so thick or fast, but I’ll do my best. Also having some trouble with Disqus, possibly due to latency. Not sure yet what the latency is due to though…