Sprite compression

May 28, 2011 3 comments

Hello!

I was hoping to discuss our new title announcement in todays blog but unfortunately we’re waiting on the app review so we’ll be announcing early next week instead.

Credit for the topic of todays blog goes to our awesome long-serving coder Phil Jones (@logicstorm) who did the work on the system, some brief tests and produced the graphs for the team.

Our internal 2D framework is predictably focused around sprites. We have a sprite bank tool that imports various image files (both for single images and series of images making up animations), it then analyses, splits and packs these.

The build process

  • Removes blank space from any sprite (and stores an offset to compensate for the blank space)
  • Breaks down each sprite into cells (varies per platform but likely 64×64)
  • Each of these cells is then stored in sprite pages (again varies but 256×256 on iPhone)
  • Cells that are identical to ones elsewhere in the spritebank are only stored once (so an image of flat colour repeated elsewhere or a static part of an animated image won’t be duplicated in the pages)
  • For a frame of a sprite animation (or for a static sprite) we then store a list of cells that make up that sprite and the offsets to render them at.
  • We then compress each of the pages and store to file.

 

This system has been used by us very successfully over the years and has helped us package up lots of assets into some of our NDS games while performing real-time streaming + decoding of more complex animations.

The original compression method we used was LZSS , this decoded very fast and had pretty good results for us on NDS.

We still use the same sprite framework on our current 2D games pretty successfully, we’ve found however that we’ve needed to get the size of our sprite banks down a bit further and with increased CPU power available to us Phil investigated using JPG / Zlib / PNG and a combination of these (NOTE: No actual PNG tests were done but we compare to the source asset in PNG form).

The only change we need to make is by applying a different compression method in our sprite bank tool (we already supported uncompressed so it’s just a case of storing the type of compression used for each sprite page), on use of a sprite at runtime we lookup the sprite page needed, load it from file, decompress to RAM and then pass to GL/DirectX for use.

As mentioned most of the test was only across a single large image file , the graph below shows the compressed sizes of the sprite banks versus the source PNG. For the alpha in the image for JPG encoding we tried two methods PNG stored alpha and zlib alpha.

We did produce some data across a full project to show that these results are pretty similar across a more varied data set.

JPEG is obviously lossy unlike our other methods used, the above graphs are produced at 75% quality level. We did some testing at various quality levels to show the jpeg artefacts introduced versus the source.

Below 80% the results aren’t too great for a high quality asset and it isn’t great introducing some of these errors in our very pretty artwork.

Let us have a look at how the quality compares to file sizes to see how much tweaking the level could improve things.

Decoding time is very important to us (though can be hidden by  precaching during loading screens / streaming). The impressive speed of Sean Barrett’s stb_image versus libjpeg/libpng is shown in this chart.  It also shows that perhaps we should have considered zlib previously in our sprite system (though the NDS might have a different performance profile with zlib versus lzss).

Across the size and decode speed results then jpeg rgb + zlib alpha is a massive improvement on our current LZSS. We’re looking at using 85%-90% for our jpeg compression quality level for final game assets.

 

Further things to try

  • We didn’t try any of the pngcrush tools, we have used this before as a separate process and it has gained 30-40% savings on some alpha PNG images . We could have also tried this on a pure PNG spritebank storage method, it should beat the source PNG assets by a fair bit.
  • Vector assets! We’re aiming not to be using purely bitmap assets for much longer, especially for some of the artwork on current projects (which would adapt well).

 

Things we’ve been enjoying this week

 

Remix!

May 14, 2011 No comments yet

Hello!

It’s great to be back on the iDevBlogADay cycle, it’s quite amusing that @FredericTessier and I return together as we were the Saturday pairing several months back.

I’m also pleased to see that the success of iDevBlogADay (great work @mysterycoconut) has also spawned  the very successful AltDevBlogADay (credit to @mike_acton for that)

I hope to provide some interesting articles in the coming months, any questions or requests would be appreciated via email or twitter as before so please get in touch.

Since we last posted it’s been an interesting and exciting time for Four Door Lemon but it hasn’t seen a large amount of releases from us. We have two new games to announce in the coming weeks as well as updates to some of our existing titles.

 

Todays article

Today I’m going to write around the topic of updating and ‘remixing’ of existing games.

This is a topic which I’ve been thinking about a lot with our previous work as a company as well as our released games on iOS and I was reminded about it when attending Go Go Games this week.

Both Renate Nyborg @renate (Metro Apps) and Matt ‘Mills’ Miller @millsustwo discussed titles that they’d previously released and had remixed with either new business models (paid -> freemium or just entirely free and added cross promotion) or had integrated brands into them.

In the case of ustwo the integration of other IP wasn’t hugely successful financially but as Mills noted these apps possibly increased their profile on the device even further and gained them some great work-for-hire projects.

We’ve not been quite as quick to actually act on our hunches with what to do along these lines and it’s only now that we’re close to actually putting into actions some of the changes to hopefully improve our catalogue further.

 

So what sort of remixing of our existing products can we perform?

Let’s say we have unreleased game prototypes, released games which are in later stages of their life cycle (but perhaps still doing ok due to the Long Tail nature of digital distribution marketplaces) plus some games no longer selling due to them being on defunct platforms. What options should we consider for each of these to develop our business?

 

  • Apply a new business model

 

There are many different ways to charge for content nowadays (Freemium, Ad-supported, Lite + Paid, Cheaper paid price + In-App purchases to name a few) , all of which are understood by customers and looking at certain stats it seems some are more popular than others.

It may be that your game was originally a very simple straight up purchase, perhaps due to the current consumer pricing expectations people who would potentially love your game are overlooking you. Adopting a new business model is a risk but there have been a lot of success stories especially with the freemium and ad-supported models.

If your current paid app isn’t making money for you making it freemium isn’t that much of a risk and at minimum will increase your userbase to help cross-sell new games to them!

 

  • Find an IP which might boost the profile of the product further

 

Standing out from the crowd can be hard, brands come with an existing fanbase and possibly marketing support that can raise the games profile.

Hopefully your game mechanic fits perfectly with the brand otherwise there may be no connection for fans of the brand to make and other than initial hardcore fans who buy anything with a certain brand on it you’ll not see much traction.

If you have a great game which would benefit from a certain type of endorsement then giving away 10-30% of a larger amount of revenue could certainly be worth it and may open other doors to you in terms of revenue generation or licensing.

 

  • Re-release / Re-promote at a more applicable time of year

 

Unlucky timing releasing on certain markets can mean that your app may be hidden during another companies sales promotion or big IP releases, larger console marketplaces would traditionally help advise on release dates to avoid whereas markets such as iOS can be a bit more of a free for all.

Seasonal events or events relating to your app may provide an opportunity for the marketplace to feature you at that time or simply for more users to be looking for apps of that type, increasing your marketing at this time is something that should be planned for.

 

  • Retarget (port to other platforms)

 

Certainly very applicable with the huge amount of emerging platforms and marketplaces, with technology requirements being fairly consistent behind most of them this makes moving products to other platforms relatively easy if planned correctly.

It may also be that your game doesn’t fit a particular control method or gameplay session length (i.e. a short burst game on PC/Mac right now would make a perfect iPhone/iPod game for commutes?).

 

  • Retry? Apply more polish.

 

Perhaps the first iteration of the product wasn’t quite as good as it could have been which is why it missed the mark. Making sure to learn from feedback from gamers who did play the original adjust and re-release the game either as a sequel or as an update.

Expectations are very high now with ‘AAA’ quality games such as Angry Birds, Flight Control, Cut The Rope, Infinity Blade and Plants vs Zombies. Fixing all those little niggly issues is very important to make sure your game is a polished high quality experience.

 

How do you make your decision?

Some of these changes could be costly to implement or perhaps backtracking could be detrimental to the product or your business, how do you build up enough evidence to support the decision being made.

A couple of ideas..

 

  • Look at other similar products

 

If you’re the only game of a certain type then hopefully you don’t have any problems to solve – if you do have competitors then look at their history, their communities, the business models they use, promotion tactics they have in place. Do there decisions match with your thinking, are they missing a trick?

 

  • Look at your own product and its analytics

 

Analytics really help reaffirm business model decisions, knowing how many active players you have, how long they play for, where they are in the world, perhaps their demographics in terms of age/gender can drive the choice you make on your next steps.

Be sure to consider the design of your product though and that you’re not betraying your original vision.

 

  • Talk to your users

 

While analytics are great for remotely monitoring your users actual actions it can still be worth talking to users about your proposed changes, they may have suggestions you’ve not considered to help you improve the product and those requested improvements may give you a much easier way to improve the product as well as increase the earning potential for your business.

 

Conclusion

Fire and forget is no longer a sensible approach for games development and publishing. All finished (and unfinished) games have value. Evaluating opportunities for all of your projects should be a regular exercise as with a slightly different approach each could be a commercial or critical success beyond their current realisation.

 

Things we’ve been enjoying recently

  • http://altdevblogaday.org/
    • Most likely something people are already familiar with, another great regular resource of interesting blog posts from some very talented people.