Optimal Asset Loading - HTML5 Game Development Insights - page 27

function renderLoopFn() {
var textureURL = "textures/wall.png";
var texture = textureCache.get(textureURL);
if (texture) {
drawTexture(texture);
}
else if (!textureCache.isLoading(textureURL)) {
textureCache.request(textureURL);
}
}
In this example, an asset cache is created with a limited size of 100. Imagine that you only have the memory
allowance to store 100 textures uncompressed in graphics memory at a given time. The game may require more than
this number over its lifetime, but not at a single point in time. The aim is to provide the game with the set of textures it
requires most often, which are available as it needs them. In addition, you want to avoid re-requesting a texture where
possible. By allowing an asset cache to manage the texture storage, the game is able to access the texture quickly while
it is in memory and make a request if it is not.
In this example, the textureCache.get function will be called in the render loop every time a texture is required
to draw on screen. If the function returns “null”, then the texture is not yet in the cache (or not available). If the texture
is not already loading, then the game will request it. The request function will in turn call the onLoad function that
the game provides for the AssetCache . This gives the game control over how it loads the asset that the cache will
store. In this case, it simply calls a requestTexture function, which will request and allocate memory for the texture.
It is assumed that this function will locate the texture using the quickest method, whether that be from an HTTP
request, the browser cache, or client-side storage. The onLoad function also provides a callback to the requestTexture
function to return the loaded asset. In the case where a request to the textureCache is made but exceeds the
100-texture limit, then the cache will find the least accessed texture and call the onDestroy function, destroying the
texture and releasing the memory. If the game attempts to get a texture that has since been removed from the cache, a
request will be made and the process will start again.
This allows the game to access many different textures without having to worry about filling up texture memory
with unused textures. Other heuristics such as texture size could be used in conjunction with this approach to ensure
the best use of texture memory. The “Leaderboards” sample, which can potentially require hundreds or thousands
of textures for avatar images, is a more complete example. It is included as part of the open source Turbulenz Engine
(see https://github.com/turbulenz/turbulenz_engine ) .
Data Formats
When building complex HTML5 games with an ever-increasing demand for content, inevitably the amount of asset
data required will increase. The previous topic discussed methods to quickly access this data, but what about the cost
of the data itself? How it is stored in memory and the processing costs play a part in how quickly the game will be able
to load. Memory limitations restrict you from storing all data uncompressed and ready for use, and processing costs
have a direct impact on the time to prepare the data.
The processing of data can be a native functionality provided by the browser features of the hardware, such as the
GPU, or written in JavaScript and executed by the virtual machine itself. Choosing the appropriate format for the data
on a given browser/platform can help utilize the processing and storage functionality available by avoiding long load
times and reducing storage cost.