Resource Management and 2D Graphics Rendering - Marmalade SDK Mobile Game Development Essentials - page 43

A resource handler is a subclass of CIwResHandler that is used to load and process
resources of a particular type, identified by one or more filename extensions.
When the text parser comes across a filename in the GROUP file, it looks at the
file extension and then checks to see if a resource handler has been registered for
that extension. If no suitable handler is found an error will be raised, otherwise the
filename is passed to the relevant resource handler class that will then do whatever
needs to be done to the file to make it usable in our code.
The entire resource manager system in Marmalade relies on resource handlers in
order to work. GROUP files, ITX files, and bitmapped image files are all processed
by classes derived from CIwResHandler , and we can create our own custom resource
handlers should we want to make use of some other file type not supported by the
core Marmalade SDK.
We will be coming back to the subject of resource handlers when we talk about
implementing sound in Chapter 7 , Adding Sound and Video of this topic, since
Marmalade does not have support for any sound file formats as part of the core SDK.
Graphics APIs provided by the
Marmalade SDK
Now that we are familiar with resource management, we can get on to the more
interesting task of showing a picture on the display.
Marmalade spoils us by providing several different ways in which we can draw
graphics on the screen. The following sections provide an overview of the different
options available to us.
The s3eSurface API
The lowest level of display access is the s3eSurface API. This provides access to
the display by using a memory pointer that you can then use to directly read or
alter pixels.
You can discover the width and height of the display in pixels and also the pitch,
which is the number of bytes that you need to skip through memory to get to the
next row of the display image.
The pitch is affected by the pixel format of the display (16-, 24-, or 32-bit displays
are all possible) and often extra padding bytes are also added to allow each row
to begin on a word-aligned memory address, which can improve display memory
access times.