Note that an alternative option to generating collision maps at runtime is to precalculate them and load them in. This would allow you to be more specific with the regions you wish to collide (i.e. you could edit the collision map after generating it). If you are simply going to use the alpha data as the collision data, however, storing it twice is a waste of space (not much space, but space nonetheless!) Also, I assume that the file format being used is the PowerVR format.

When encoding textures in the .pvr format, you have two options. The first is to use a standard format (ARGB8888, ARGB1555, etc) and the second is to use a compressed PowerVR format (PVR2bpp/PVR4bpp). The basic idea of generating a collision map is to alter the PowerVR texture loading code to grab a copy of the alpha channel, determine visible regions, and store a copy of this data for use as collision data.

As long as you are using an uncompressed format, this process is quite straightforward. Where you need to be aware of potential difficulties is when dealing with the compressed formats. The issue here is the fact that the PowerVR chipset in the iPhone supports these compression formats natively. When loading the textures, the SDK code checks for compressed textures support (which it finds in the case of the iPhone), and then simply loads the compressed textures into memory.

Because the texture is never decompressed, you can not simply access the alpha channel. The only option in this case is to separately decompress the texture and then generate the collision data. The decompression process is quite slow, however, so decompressing the texture should be avoided whenever possible.

My recommendations are:

1. Use only uncompressed formats when it is necessary to generate collision data from the texture.
2. If you must use compressed formats for these textures, precalculate the collision data.

void EVENT_onClick
{
   // ...
}

void onClick(float _fX, float _fY)
{
   // ...
}

The reason I implemented the event handler syntax like this is the structure of the engine. Unlike some event-oriented systems, the Stratum Engine does not require event handlers to be registered before receiving events. This is due to the layering system I have used – each event is handled by each layer in order of where the layer is in the stack. This is implemented by having a parent class from which all layers derive, and the base class having blank functions to handle each event. If a layer wishes to respond to an event, it overrides the corresponding function.

This is the first reason that macros are used – if any error is made in the function signature when creating a new layer class, the program will compile and run perfectly, but the handler will never be called. This can lead to difficult-to-diagnose errors. By using macros, the compiler will display an error if a mistake is made in the macro name.

The second reason is that the arguments passed to a function may change in the future. It would be a large refactoring effort to ensure that all derived layers have the function signatures updated to reflect the altered arguments. Additionally, any errors or missed classes when updating the functions would again result in the handler not being called. The benefit here is that simply updating the macro will result in all classes using it being automatically updated as well.

• Optimised for quick prototyping (shortest amount of code possible to get to a playable game)
• Pure C++ with a few Objective-C delegates to manage interaction with the iPhone OS
• Uses a stack-based state machine architecture
• Supports all iPhone input features
• Gesture recognition (similar to “$1 Unistroke Recognizer”¹)
• Hardware accelerated sprite engine

Each state of the game is defined within a layer. These layers can be pushed onto or popped from a central stack. The granularity of states represented by the layers depends largely on the type of game being represented. To give you an example, a set of layers for a simple puzzle game could be:

Main Menu

Game

Pause Menu

Credits

etc.

Alternatively, an RPG may have layers such as:

Main Menu

Overworld

Town

Battle

Inventory

Dialogue

etc.

Each of these layers receive and may respond to a number of events. It is not necessary to subscribe to events in order to receive them. Each layer is derived from a parent class, and simply implements event handlers for each event it wishes to respond to. Most events are handled by each layer on the stack, in order from top to bottom. The exception is the Draw event, which must necessarily be handled from bottom to top.

Each layer also has a filter that defines which events should not be passed on to lower layers. A typical filter for a Pause screen would be:

Event::All ^ Event::Render

This means that all events except the render event will be blocked (since input and update events are blocked, the lower layers are therefore automatically “paused”.

I will have more articles coming soon, but for now, here is a complete implementation of the aforementioned Pause screen:

class Pause : public ILayer
{
public:
   LAYER_FILTER(Event::All ^ Event::Render);

   // Called when the layer is added to the stack
   void EVENT_onAdd
   {
      m_sprBackground.Load("Backgrounds/Paused");
      m_sprBackground.SetFullscreen();
   }

   // Called once per frame when it is time to draw
   void EVENT_onRender
   {
      Sprite::Begin();
      m_sprBackground.Draw();
      Sprite::End();
   }

   // Called when the user taps on the screen
   void EVENT_onClick
   {
      Layers::Stack::GetInstance() -= this;
   }

private:
   Sprite m_sprBackground;
};

And the code to add this layer to the stack (effectively pausing the game):

Layers::Stack::GetInstance() += new Pause();

Simple, eh? You may have noticed the strange function signatures. Yes, this is C++ – I’ll explain the reasoning behind it in a future post

References:

1. Wobbrock, J.O., Wilson, A.D. and Li, Y. (2007). Gestures without libraries, toolkits or training: A $1 recognizer for user interface prototypes.
Proceedings of the ACM Symposium on User Interface Software and Technology (UIST ’07).
Newport, Rhode Island (October 7-10, 2007). New York: ACM Press, pp. 159-168.