Tag: programming

Dev Log 5th of December 2014

This week, it was back to work on Quick Quote. There are a bunch of improvements I want to make with how quotes are handled, such as adding customer details, and marking them as an invoice. On Monday, I added the ability to attach a note to a quote, which appears when the quote is sent to the customer. However, when starting on the other features, I ran into difficulties with the way quotes are stored internally. It’s caused me problems in the past, and I’ve finally decided to spend time reorganising things.

Technical Debt

“Technical Debt” is a measure of how awkward the code is to work with. When developing software, often you don’t fully understand a problem until you’ve already solved it once. At that point, the solution works so you move on, but it might be overly complicated, or slow, or less versatile than it should be. As this debt builds-up, development takes longer and certain tasks become impossible. Paying-off this debt takes time, but makes things easier in the long run.

In this case, when I began on Quick Quote, in my inexperience I decided to store quotes as XML files, rather than in a database, as it would be simpler. Up to a point, this has worked well – I’ve been able to gradually add new things to the quote files in a backwards-compatible way without having to do potentially messy database changes. The downside is that files have limited metadata – they have a name, and the last time they were edited, and not a lot else. For the saved-quote list to display or sort by anything else, such as whether the quote is an invoice, it would need to read in each file and process it, which could be very slow if there were a lot of quotes. This is the main reason I wanted to switch to a database, the other being that Android’s data-synchronisation system is poorly suited to working with files, so I’ll be in a better position to implement that in the future.

The biggest hurdle for this change is that everything needs to be converted the first time that Quick Quote launches, and that’s what I’ve spent the rest of this week on. It’s been slow work, as there are lots of things I’ve not done before, but it’ll all be useful for when I make future apps.

Ludum Dare

This weekend is Ludum Dare 31! LD is an online event where people create a game from scratch over a weekend. I’m hoping to participate, in which case I’ll have a new game for you by Monday. I’m hoping that the theme will be ‘Deep Space’, so I can make a rocketry game, but we’ll see.

Dev Log 4th of October 2014

So, what have I been doing the last couple of weeks? Firstly, the disco modifier!

Not pictured: The cheesiest disco music
Not pictured: The cheesiest disco music

The spotlights sway back and forth, the colours cycle, and the little dot lights spin around. (I want to show a gif of it, but the file-size is enormous. :() My current plan is to have it be pretty rare, but once you’ve seen it once,it unlocks as a secret option on the main menu, so you can enjoy it in all its glory whenever you want!

I had to learn a bunch of new shader tricks to get any of this to work. I was pretty happy, and then I tried it out on my Nexus 10 tablet and it ran at 11 frames per second, which is pants. Once I’d added an FPS counter, I discovered that even with only the subtle water ripples it was running at 55FPS, and the night shader at 33. So, a lot of time was spent trying to make these things faster. The end result is that with just the ripply water, 56FPS; the night shader at 48; and the disco shader at 20. (Disco reached 24, but then I added the player-light-circle because it was hard to see where you were, which dropped it to 20.) Optimising shaders was… interesting, as I barely know enough to make them work at all, and shader performance is almost a dark art. Simple things like using if statements to avoid doing work can be slower than just doing the unnecessary calculations. Someone explained somewhere that operations don’t really have a time cost: if a sin() takes 4 cycles, and a matrix operation takes 4 cycles, sometimes both together also take 4 cycles. So, my method was almost entirely trial and error.

You can save a bunch of time by doing calculations in the vertex rather than fragment shader, but the interpolation it does isn’t always what you want. For example, the weird blue lines on the water in the above screenshot are supposed to follow the spotlights, but the in-between values it calculates are wonky. You can see where the background is composed on two triangles from where the sharp bend is. In the end, I decided to leave it like this as, after all, it’s supposed to be a disco so goofy lighting is appropriate.

20 frames per second is not really good enough. I wouldn’t be happy unless the entire game always ran at 60. But, it seems the high-resolution on my tablet combined with mobile GPUs not being great might mean it’s impossible. I’m not trying to make excuses – I genuinely don’t know whether it can be any faster, or whether the hardware prevents that. On my desktop PC, with a graphics card that was OK in 2007, it’s fine. I’d love to be able to make it better, but ultimately I have to ship the game, and it’s not the end of the world. The 48/55 fps aren’t noticeable unless you’re looking, and 20 isn’t as awful as it sounds. I’ll have to see how it performs on other hardware.

I had one last idea for speeding the game up: using the depth buffer. To explain briefly, OpenGL can store a number for each pixel on screen, representing how near what’s drawn on that pixel is to the camera. Then, it only draws pixels that are closer than what’s already drawn. This way, you can avoid drawing on the same pixels over and over, wasting time. Now, currently the game draws back-to-front: first a fat blue rectangle is drawn, then fish, then the water’s surface, then the ground, then the player and plants, and finally the score and pause menu and such. Using the above screenshot as an example, this means that some of the pixels are drawn five times: behind the word “Score” is a tree, some grass, the water surface, and the blue background, and each of these is drawn onto those pixels. With the depth buffer, I could instead draw front-to-back, with “Score” being drawn first, and then skipping the tree, grass, etc. as they’re behind. (Not exactly, as semi-transparent things need to be drawn after what’s seen through them, but it would definitely cut out a lot of wasted work.)

So, why didn’t I do this? Because I discovered that the 2d-rendering parts of LibGDX are incompatible with the 3d rendering parts, so that I couldn’t swap things out, but would have to rewrite a significant portion of the library before I would know if this rewrite would make any difference. Unfortunately, I can’t devote that amount of time to this. Especially as this multi-week patch was supposed to be a minor fix to the Lake of the Day being stuck on a single game mode! I’m susceptible to feature creep, but not quite to that extent.

So, current plans: I have a few things left to clear-up before the next F!shing release, and then onto all the other projects I’m supposed to be doing! Some improvements to Quick Quote Professional are planned, to help with managing large numbers of quotable items, and multiple devices. Then, the business app that I barely started before F!shing distracted me. Once that’s done, I’m not sure, as I’ll probably have changed my mind multiple times before I get to it.

I’m also in the process of writing-up my month’s worth of shader experiences, things learnt and mistakes made. Not because I’m an expert, because I’m not, but because it’s such a confusing topic and I’d like to help other people be less confused. I’d been wanting to try writing shaders for ages before I finally dived in.

Multiple App Versions on Android

It’s fairly common for Android apps to be released with both a free version, and a paid one with extra features. Quick Quote is one example, and now that it’s been out a little while, I thought I would share some of the tricks and traps that I’ve come across in its development.

Android has a fairly strict security system, that stops apps accessing each other’s data. That’s great when you are storing private information, but not so great when you want to share that data between your free app and your paid one. Fortunately, there is a way to tell Android that it’s safe for your apps to access each other’s data. This is by specifying the same sharedUserID in the manifest files. You also need to ensure that the APKs are signed with the same key. This causes Android to see them as related, and allows you to bridge the gap between them.

You can then call the createPackageContext() method with the package name of the relevant app, in order to obtain a Context for it, and then access its files and resources as normal. A word of warning, however: If the app in question is not installed, createPackageContext() will throw a NameNotFoundException and not return the Context you are after. There are of course, multiple ways to solve this issue. In the case of Quick Quote, I decided to have the paid version look for the free version when it launches, and copy the data over if it has not already been copied.

Now, probably the majority of the code and resources in the different app versions will be the same. Duplication is often a signal that things need a rethink. The Android development tools support the creation of Library Projects as a solution: put the majority of the code in the library project, then include it in the release projects and extend it with any differences.

In the case of inserting advertisements, it’s helpful to know about the <include/> layout element. This lets you directly include another layout file within a layout. This makes it easy to include an activity layout, and add an advertisement without duplicating the whole layout file. It’s also generally useful if you want to use a segment of layout in several places.

Heinous Yak Destruction

The weekend just gone was the Ludum Dare Charity Game Jam! The theme was to make something NES-like, so I… made a game where you are a yak destroying a city? Um, yeah.

Anyway, it was a lot of fun and I’m pleased with the result! The game is playable here, or from the above link with the other games.

My current list of Android mistakes

As is traditional, I have made silly mistakes while starting a new project – this time, developing an Android app. Here are the biggest ones:

  1. Thinking it wouldn’t be that hard…

    When I finally got USB debugging to work, everything else seemed so easy in comparison. Sure, I’d never programmed for Android before, but it’s well documented… I don’t need to read all of those long, boring-looking guides! I’ll just jump into coding!

  2. … and then running before I could walk

    For my first application, I decided to do something that would mean creating my own custom views and widgets, before I’d even figured-out how the built-in ones worked.

  3. Coding while unwell

    All this, while I had a horrible cold that meant I couldn’t think clearly, and having slept poorly. This is not the best state of mind for debugging things you don’t understand.

Note that none of these are actually specific to Android… I just need to be more patient and read the manual, really!

Not helping this of course, was that the error complained about an invalid cast that didn’t appear in my code, and highlighting a line in the Choreographer class, simply indicating that it happened in a callback. I eventually figured it out:

If you get a complaint about casting between a LayoutParams class and a MarginLayoutParams class, it may well be that you’re using measureChildWithMargins() instead of measureChild().

As another point, when setting colours in hexadecimal, Android uses ARGB. So, while label.setTextColor(0xff0000) will compile fine, you’re giving it an alpha of 0 – fully transparent. To be opaque, it needs to be label.setTextColor(0xffff0000), or something along those lines.


I might reveal what the app will be soon, now that I’m actually making a bit of progress. I’m sort-of hoping to get it on the Android market before the end of October, along the lines of the Ludum Dare October Challenge… though it’s not a game, and I’m not sure if I’ll charge for it. No, I think I will charge. I’ll just have to make sure it works solidly.

Processing: arrayCopy() for multidimensional arrays

I discovered a quirk in how Processing‘s arrayCopy() method works, and as it took me a while to figure out, I thought I’d share it:

If you’re copying a 2d, 3d, etc array, then do NOT use arrayCopy(). It’s designed for use on 1d arrays only. If you try it, it will seem to work, however rather than copying the data, it actually copies the references – in layman’s terms, if you then make a change to one array, the change will also occur in the other.

Assuming you want the two arrays to be different for most of the time, you’ll need to iterate through them, like so:

for (int x=0; x<src.length; x++) {
  for (int y=0; y<src[0].length; y++) {
    dest[x][y] = src[x][y];

Where src and dest are your source and destination arrays.

Idea: Text Adventure to Teach Linux Terminal?

It struck me earlier today, and has done before I think, how similar text adventure games are to a text-based computer terminal. They both take the general form of “COMMAND TARGET”: “look at door”, “use key”, “cd ..”.

Now, the Linux terminal scares a lot of people. And yet, text adventures are less intimidating, even though they’re functionally identical. So… why not have a text adventure game that teaches you terminal commands?

Maybe the story is along the lines of hacking into a server for some purpose. In any case, it might be interesting to try.

SDL: Blitting to transparent surfaces

I mostly like SDL, but some of its ways are a little bizarre, requiring knowledge of how things work underneath, but without making that knowledge easily available.

Having just spent several hours trying to get blitting with transparent surfaces to work, I thought I would share so that hopefully others won’t go through the same frustrating period of confusion. Also, it’ll be here if I forget how to do this in the future.

To create a surface supporting transparency, you need to specify the bit masks for each pixel, which is a long way of saying ‘do this:’

SDL_Surface* surface;
surface = SDL_CreateRGBSurface(SDL_HWSURFACE,width,height,32, 0xFF000000, 0x00FF0000, 0x0000FF00, 0x000000FF);
surface = SDL_CreateRGBSurface(SDL_HWSURFACE,width,height,32, 0x000000FF, 0x0000FF00, 0x00FF0000, 0xFF000000);

Here, we set the flags differently based on the endian-ness of the computer. Otherwise, things could go horribly wrong, with colours being inverted and other stuff you really don’t want.

The surface will be filled-in with black pixels, but we want it to be transparent, so we fill it with transparent pixels using SDL_FillRect:

SDL_FillRect(surface, NULL, SDL_MapRGBA(surface->format, 0, 0, 0, 0));

Now, this is all pretty simple so far, and yet I had so much trouble getting some surfaces of text on a transparent background to blit to this surface. The trick is that you have to make sure that the SDL_SRCALPHA flag is not set on the source surface. Otherwise, the surfaces are blended together, and as the target surface is completely transparent, nothing will apparently be blitted.

You can remove the flag like this:

SDL_SetAlpha( sourceSurface, 0, SDL_ALPHA_OPAQUE );

Problem solving through soliloquy!

I just figured-out how some code should work, by writing a soliloquy from the point of view of the Display object. It took less than a minute to figure out this way, when I’d been struggling with it for a couple of days.

Maybe I should try this more often!

As a side-note, soliloquy is spelt really bizarrely. Apparently it comes from a Latin word soliloquium, which I guess is worse, but quy just looks really wrong… though there are no alternatives that look better. Hmmm.