This part of the tutorial is actually not going to explain proper procedures for preloading images. There are a number of methods available, all of which can be found by doing a simple Google search for “preload images”. This article will instead concentrate on ways to reduce the necessity of preloading altogether by means of self-contained data and CSS Sprites.

I’ll start off by briefing explaining the importance of CSS Sprites (since Part 4 below will explain how to use self-contained data). An in-depth discussion of CSS Sprites can be read on A List Apart. In a nutshell, a sprite map is a collection of smaller images mapped onto one large image. By combining images, you will reduce server requests and speed up download times. CSS Sprites especially come in handy when dealing with hovers.

Without sprites, displaying a different image for the hover state of an element requires making an extra call to the server for the new asset. This results in another download (at the time of mouseover), which can take time and create jerky mouseover experiences (especially in Internet Explorer). If a sprite map is used instead, the sprite can be setup to contain images for both the default state as well as the hover state. The sprite is downloaded as the page loads (if the element which will use the sprite is initially embedded on the page), and voilá, the hover state is downloaded with it and ready for use.

I’ve used sprites a couple of times on this site. To demonstrate how easy they are to use, let’s take a look at the “press” button at the bottom of the page.

Figure 1. Example sprite image
 

The sprite is illustrated above. The actual image is a PNG and contains elements which would be hard to decipher on a light grey background. The turquoise box was added to make things more viewable. Using an anchor tag as a button, we can crop out the backgrounds we need for the default and hover states using the following CSS.

Background, width and height styles: Because we are cropping the button to a width and height of 50 pixels, it is not necessary to specify a background position for the default state. Why? The default background appears at the top of our sprite. So as long as we assign a width and height that are the exact dimensions of the default background, the remainder of the background will extended past the boundaries of the button and will not be seen.

Display style: By default, anchor tags display inline, so in order to represent the anchor as a button (and specify things like width and height), we need to force the anchor to display as a block element.

Text-indent and overflow styles: If, in your markup, you include text within the anchor tag (for example: <a id="press" href="javascript:void(0)" onclick="dropBlock()">Press</a>), you can hide the text by assigning a negative text indent and hiding overflow.

The hover state: Now, all we need to do in order to fire up the hover state of the button is offset the top background position of the background enough so that the hover image is used instead of the default image. In this case, we need to offset by 50 pixels. When a sprite map only includes two image states, the offset can be either positive or negative. Both will achieve the same result. When dealing with sprites with three or more states, I recommend strictly using negative values. You’ll understand why as you experiment more with sprites.

And that’s CSS Sprites in a nutshell. Now on to the actual Part 4 update where I’ll discuss self-contained data.

Part 4: ‘Preloading’ Commonly Used Game Assets

If you’ve ever used Dreamweaver, you’re probably familiar with the code that’s used to preload images:

Look at the highlighted line. In Javascript you can create Image objects. By doing so, you can store images in the DOM’s (Document Object Model) memory and quickly access them later. But preloading images in this fashion still requires an HTTP call out to the image so that it can be downloaded. When designing games for the iPhone, we want to limit the number of HTTP requests as much as possible. There’s actually a way to embed some of your images in your Javascript file so that there’s no need to download them.

If you’ve ever tried to open a GIF or JPEG in a text editor you’ll notice that the guts of the image are a bunch of letters, numbers and symbols. There’s a free program online, called the URI Kitchen that will read an image and print out the letter/number/symbol/gremlin guts for you.

To use the program, go to URI Kitchen, upload a file and then copy the resulting data from the address bar. Here’s the data I get when feeding the program a graphic of the number 5 (one of the numbers used to mark the crossword grid):

Pretty, huh? Now, take that data, and use it as follows:

I can now access five anytime I want to load that image in my game, and since it’s embedded in the code there’s no need to run off to the Internet to fetch it. I can draw the image to the canvas (at coordinate 100, 50) like this: ctx.drawImage(questionMark, 100, 50).

Now, you won’t want to use this approach for every image in your game. You’ll still have to elegantly handle load times for large images. But this approach works great for smaller, commonly used images. What are the most commonly used assets in a crossword puzzle? The numbers used to label the grid, and the letters that will spell out each word. And those are the exact images that we’ll “preload” into Javascript using this method.

And this has officially been the longest blog post I’ve ever written. I hope you’ve enjoyed it!

—Ryan