It's really great that the Marmalade SDK allows us to target so many different devices and platforms. However, a certain degree of care and awareness is required in order to optimize your application fully for all of these varying device types.
In this chapter we'll be covering the following subjects:
- A general overview of the kinds of things to be wary of when trying to support a wide range of different devices
- A more advanced look at the ICF filesystem we encountered back in the first chapter of this book
- Using Marmalade's built-in systems to allow multiple different data sets to be used and to process those data sets in different ways (for example, allowing the final texture format used on the device to be specified)
- Configuring the deployment system to make different types of builds
- Using the Derbh archiver to reduce the size of our assets in the install package
Mobile operating systems such as iOS or Android are capable of running on a widely varying range of devices. Before we get on to discussing the ways in which Marmalade makes it easy for us to target multiple device types, we'll first highlight some of the things to keep in mind when developing a game so that it will look and run its best on as many different devices as possible.
Marmalade also ships with a whitepaper that covers some of the things to be careful about when developing a game destined to run on more than one device specification. You can find it in the Marmalade documentation at Whitepapers | Device Independent Code.
Probably the most immediately notable difference between different devices will be the screen resolution. Taking iOS as an example, you may find yourself having to support screen resolutions ranging from 320 x 480 at the low end through the two different iPhone Retina screen resolutions (640 x 960 and 640 x 1136) and iPad at 1024 x 768, right up to the frankly crazy resolution of 2048 x 1536 of the most recent iPad (you'll be hard pressed to find a PC monitor capable of displaying that resolution!).
We've already touched on this subject in Chapter 6, Implementing Fonts, User Interfaces, and Localization, when we discussed the best way of implementing a user interface. We should never hardcode our game to work at a fixed screen resolution as it will be much harder to port it across to other screen resolutions later.
Instead, we should query Marmalade for the screen dimensions and then use these values to position and size everything we want to draw, whether that be through using percentages of the screen size, by clamping objects to the edges of the screen, or indeed some other method of your own choosing. We can find the screen width and height as follows:
uint32 lScreenWidth = IwGxGetScreenWidth(); uint32 lScreenHeight = IwGxGetScreenHeight();
These functions will also automatically take care of device orientation. The returned values will change when the player rotates the device, unless we have disabled this functionality using the DispFixRot ICF file setting (more on this setting shortly).
Using the screen dimensions to position and size the elements we wish to draw works well, but it does lead to a further problem. We may find that any images used to render items on screen start to look blurry or blocky if they have to be scaled up in size too much.
Similarly, fonts that work well at a low resolution may become impossible to read because they are too small when used on a higher-resolution device. While we could just apply a scale to the font when rendering, a more aesthetically pleasing solution is to use a different version of the font created at a bigger point size.
Luckily, as we'll see later in this chapter, Marmalade has a very easy-to-use solution for this problem that allows us to provide alternate sets of resources that can be used when targeting different sets of screen resolutions.
Another thing to be vigilant of when targeting a large number of different devices is that some devices may not include support for certain Marmalade SDK features.
Some devices may feature a multi-touch display while others only have single touch or indeed no touch screen at all. Some may not feature accelerometer inputs or keypads. It is therefore a good idea to ensure that we call the various Marmalade functions that enquire whether these and other features are available for use and what capabilities are provided, so that we can then provide the user with options tailored to their device.