Create cross-platform HTML5 games - Episode I

Creating games is the most exciting and challenging area of the software development. Once you have created the next hit game of the year, the challenge for your newborn baby is to support as many different platforms as possible since there are thousands of different devices out there. Thus, unless your target is a specific device, like iPhone, Android, Smart watch, Windows PC, Mac, etc. with previously known technical characteristics, then the need of such a wide support could become a real headache.

An approach to this is to re-write the source code (or specific parts of it) for every platform using the SDK and the tools for this platform. 

Another approach is to write the game using technologies that come with the promise "write once, run everywhere". One such very promising technology is HTML5. Orienting your coding habits into this direction, a cross-platform implementation becomes feasible. 

In this tutorial I am going to show you how I have used HTML5 to write such a cros-platform game. The reader could easily be confused with the term“HTML5” believing that somehow it is possible to write such complex applications using HTML-tags (something like <game><img src=”….”, …, put some game logic here </game> and …that’s all. NO!). In fact, HTML5 is 1% HTML and 99% JavaScript. The tutorial assumes that you already have a basic experience with JavaScript programming, or with …programming. 

Actually, an HTML5 game (or application) runs inside a browser that supports this level of the markup language. Fortunately, almost every browser on any device of the last half decade can translate HTML5. 

You can play a game that I have created with HTML5 and combines all these promises. Just visit from everywhere the link bellow. If you open it from a desktop browser please keep changing the dimensions to experience the effect of responsive resizing in real-time. 

http://www.liknongames.com/spaceball 

Now, let’s begin with the fun.

Room (or scene) loader for games with non-linear storyboard

In a game with linear storyboard when the player completes the tasks in the current scene/room (henceforth: room) then the loader reads the next record from the rooms-file where all rooms are stored and the core engine of the game designs the next room.

This is the case in almost any platform, arcade game, like it is Pac-Man, Solomon’s Key, Bobble Bobble, Bob Jack etc.  But this is the easy case, the good one.

Recently I have uploaded my new game for java-phones called Vampire. You can find more details and how to install it on Liknongames - Vampire. It is a platform, multi screen game where the main ghost-like character walks inside a complex castle searching for the vampire.  On his path there are a lot of unfriendly creatures and lethal traps.

Here is a part of the huge map of some rooms in the castle including the starting one. Every rectangle with white border is a room of the castle.

Picture 1

As you can see there are rooms with one, two, three or even four openings that lead to another  room in other floor or in other side, thus it doesn’t make any sense to speak for “the next” or for “the previous” room.

Let us see now how I store every single room and how I implemented this navigation system. It will help.

This is a screenshot of the room at the right side of the starting one. 

Picture 2

You understand now that It has no meaning at all to say “…this is the second room…” because from the starting room he may either fall into the (trap-)room or exit from the right edge of the room.

And this is exactly what I am going to explain in this post: How to make an automated navigation mechanism that is responsible for the transition from one room to another in such a game world where there may be openings in all sides of the current room.

Vampire is a tile-based game. Every room is a grid of 16 cells along the horizontal and 8 cells along the vertical direction. So there are 128 tiles in each room.

Picture 3

There are (and will be) about 200 different objects (tiles, enemies, goodies, etc).  Each kind of object is given a numerical code used also for the storing into the file. So, I need values from 0 to 200 (0 is the value for an empty tile).  As we know, one byte is enough to keep such a value since a byte can keep 256 different values.  It means that each room can be considered as a sequence of 128 bytes.

Inside the rectangle is the part of the binary file with the values of the bytes of the room of the screenshot in hexadecimal system.

Picture 4

How ugly is it, isn’t it? Let’s remove the 00’s and we get a friendlier and already known picture:

Picture 5

Yes, this is the same room in picture-3 seeing it through X-rays.

Short F.A.Q. about this actinography:

Q: In the upper row I see only green tiles. The values however are different: 0x42, 0x43,0x4D, 0x45…
A: The tiles are different too. Stare at them carefully and you can see slight differences.

Q: What is the “74” in the middle column?
A: This is an almost hidden canon that throws arrows if the player is in its height and on its side.

Q: I see a “97” in the middle column under the “83” but nothing is it to be seen in the screen:
A: This is an completely transparent tile. Its value is out of the range of the tiles the player can collide with, however it belongs to the range of values that the enemies can collide with.  It forces the bird (62) in the same row not to reach the blue wall at the right, but to bounce earlier.

At the upper left side of the rectangle there is a value, 00000180h. It is the position in the room-file where this screen is started from. This is in hex. 0x180=384.

From the 384^th byte begins this room. How many rooms are stored in the file before it? Since every record that represents a room has a constant length of 128 bytes, we have 384/128 = 3 rooms.

After the player has passed the right edge of the starting room the loader knew that it has to spring to the 384^th position of the binary file that keeps all rooms and read from there the next 128 bytes.

How did the loader know this?

For this reason I had to split in tiles not only the room but the entire map of the game and use a coordinate system to specify the location of a room into the castle starting from the room 00x00 to be the leftmost room in the lowest basement of the castle.  The first coordinate is increased by +1 from left to the right and the second coordinate is increased by +1 when climbing in a room on the ceiling of the current one.

By this addressing the rooms in the part of the map in picture are assigned with the coordinates as in the picture

 Picture 6

Oh! I have just given away that by the starting of the game you are already in the 7^th floor !!!!

Now that we always know the exactly coordination of a room in the map of the castle that is going to be visited it is easy to know from which position in the rooms-file to start reading from.

One thought would be to extend the record that stores a room from 128 bytes to 130 bytes,  keeping in the first two the coordinates of the room.  Then every time the player touches an opening the loader would scan the entire file with the levels trying to identify the possibly “next” room with the values of these first two bytes.

However I decided for a more clear solution.  I introduced another file that correlates map-coordinates into positions in the rooms-file. The first idea was to store in it records of a length of 4 bytes. The first two are the map-coordinates and the last two a short value of the position in the levels-file. 

Finally I decided to keep for the position only one byte since the position is always a multiple of 128. Thus, I multiply the value of this byte with 128 and I have the position where the pointer in the levels-file has to be spring and read from there.

I hope I didn’t ruin your mind.

If you like it please leave a comment, share it, or give it a "g+1".

In a “coming soon” tutorial I will describe how to design rooms with a freeware tile editor and how to produce from the xml (its output) the room file and correlation file.

(The easy way) OpenGL, Bypass the power of two (POT) restriction

Many friends have mailed me and told me that they faced difficulties when they tried to apply inside their application the algorithm in my previous post about how to bypass the ‘power of two’ restriction in Open GL ES.

Thus I decided to approach the issue with a much simpler algorithm than the previous one.

Why didn't I do that already in the first post ?

Well, the cost of the simplicity is a little loss of quality.

No, no, don't leave the page. It will be insignificant loss and you can base on this method even commercial products and nobody will observe any issue in the final product.

Let me start again by telling the same story: Your designer has drawn nice backgrounds in a 320x240 resolution like the one with the colored circles in picture 1

picture 1

During the development you test the application on the emulator and you are happy seeing that everything goes fine. Suddenly you transfer your application on the real device and instead of nice backgrounds you see a white rectangle 320x240.

What happened???

OpenGL ES binds as textures only images where the width and the height are both power of 2 (POT). This means that only 32×16, 128×64, 8×256 etc images are supported. It does not sound flexible, huh? It is a certain restriction for your designer (I bet it is you!).

Newer GPU`s that support OpenGL version 2.0 or above can load any arbitrary dimension but why to take such a huge risk for the marketing of your application?

The main idea is very simple: OpenGL is stupid enough to load a texture where width & height are of power of two but since the texture is loaded and bound OpenGL accepts to scale it even using different scale factors for width and height.
What does it mean for our example?

After the picture is ready by your artist and well painted open it in your editor ( I use GIMP) and scale it by giving for new dimensions what you believe is the nearest values that are of power of two. For our example it could be 256x128. Then you have it a stretched image like in picture 2.

picture 1

This image is perfectly loaded and bound as an OpenGL-texture.
But you don’t want it to be 256x128. You want to see circles on the screen, not ellipses.

I am sure you know what the next step will be: You have to stretch it back to the original dimensions. For this there must be calculated the scale factors for width and height.

float fScaleWidth = 320/256 = 1.25f
float fScaleHeight = 240/128 = 1.875f

Q: What values do you need to have as fixed to make it full parametrically?

And then in the render function

if  ( mesh.isBackground == true )
{
     g.glScalef(fScaleFactor*fScaleWidth, fScaleFactor*fBgrScaleHeight, 1.0f);
}

where fScaleFactor is the global scale factor, assuming that you may have designed everything in your game initially for a resolution 320x240 but you want it to fill screens even with bigger resolutions.

Good luck.

(The hard way) OpenGL, Bypass the power of two (POT) restriction

Assuming you have decided to use OpenGL ES for your game and your designer drew all the backgrounds as 324×226 images like the one on the picture 1.

picture 1

During the development you load these backgrounds as textures in the OpenGL and you are happy watching nice graphic results on the emulator.

At some point of the timeline of your project you transfer the application on a real device and suddenly you realize than instead of a nice artwork you see a white square 324×226 (scaled at whatever scale-factor you have calculated according to the physical screen resolution)

What happened actually????

OpenGL ES binds only images where the width and the height are both power of 2 (POT).

This means, only 32×16, 128×64, 8×256 etc images are supported. It does not sound flexible, huh?. It is a certain restriction for your designer (I guess it is you!).

Newer GPUs that support OpenGL version 2.0 or above can load any arbitrary dimension but why to take such a huge risk?

In this tutorial I am showing to you a solution to this issue so to leave your talent free and wake up the hidden Van Gong who lives inside you and forget about any such kind of restrictions.

The main idea is very simple: You feed the engine with images of whatever dimension you want and the procedure that I am going to describe right now will split this image to the minimum amount of images with all their dimensions to be of POT.

In the example above, a background will be split in 12 images:

4 × 2
4 × 32
4 × 64
4 × 128
64 × 2
64 × 32
64 × 64
64 × 128
256 × 2
256 × 32
256 × 64
256 × 128

Like you can see on the picture 2

picture 2

Seeing this picture it is clear what steps has to be executed by an automated procedure:

1. Express the width and the height of the image as a sum of numbers of only powers of two.


2. Combine these numbers that sums the width with the numbers that sums the height and we have the dimensions of the new images.


3. Crop the initial image using these dimensions and get all the part-images as also the coordinates of them in relation of the (0,0) corner of the initial image.

Expressing any natural number k∈N as a sum of powers of two is the same as to represent this number into the binary numeral system. In fact this is the definition of the binary numeral system.

Apply this step in our example:

324 = (101000100)₂
= 1×2⁸ + 0×2⁷ + 1×2⁶ + 0×2⁵ +0×2⁴ +0×2³ + 1×2² + 0×2¹ +0×2⁰
= 256 + 64 + 4
= 4 + 64 + 256

similar for the height
226 = (11100010)₂
= 2⁷ + 2⁶ + 2⁵ + 2¹
= 128 + 64 + 32 + 2
= 2 + 32 + 64 + 128

It would be handy for the second step if we had an array for the width and another for the height to store these constants. For example it could be:

for 324, int w[] = {4, 64, 256 }
for 226, int h[] = {2, 32, 64, 128 }

And since the speech is about arrays it raises automatically the need to allocate memory for them before making any operation on them. What we exactly seek is the appearances of ‘1’s in the binary representation of the number. Let’s introduce our first function

int bitCount ( int number)
{
     int ones = 0;
     for ( int i = 0; i < 16; i++ )
     {
          if ( (number&1) == 1 )
               ones++;
      number >>= 1;
     }
     return ones;
}

Nothing special has been used than just a few boring bitwise operations.
(...or you can simply use the Integer.bitCount(int i) static method of Java!!!!)

Now we can allocate memory for our arrays and play safely with them. According to your IDE environment you can use malloc (Ansi C) , NSMutableArray (iPhone) or the “new” operator (Android/Java/C++)

Using the same pattern we can fill the array with values.

void getPowersOfTwo ( int number, int[] array )
{
     int pos = 0;
     for ( int i = 0; i < 16; i++ )
     {
          if ( (number&1) == 1)
          {
               array[pos++] = (int) Math.pow((double) 2, (double) i);
          }
          number >>= 1;
     }
}

Be very careful about the precedence of the operators since pos++ here doesn't have the same effect as ++pos. (Why?)

After we have called this function on both w[] and h[] arrays we loop through their elements to build all pairs we need for the cropping.

There are (w.length)×(h.length) combinations. That means that for our example there will be 3×4=12 images.

For this purpose we introduce two nested “for” loops :

int fromX = 0;
int fromY = 0;
for ( int i = 0; i < w.length; i++ )
{
     for ( int j = 0; j < h.length; j++ )
     {
          System.out.printf("Crop %d x %d from (%d,%d\n", w[i],h[j],fromX,fromY);
          fromY += h[j];
     }
     fromY = 0;
     fromX += w[i];
} 

Inside the body of the second “for” it is where you have to call a special function of the standard graphics library (not the OpenGL) and get the part of the image that you can bind right after as an OpenGL-texture. The printf has everything we need: Where to crop from (and where in the OpenGL mesh to put) and what size to crop.

Of course you have to save also the values of fromX and fromY to a data structure and don't blast them into oblivion after this print-out.

Here are these functions for the main platforms that rule the galaxy nowadays:

Android:

Bitmap android.graphics.Bitmap.createBitmap(Bitmap source, int x, int y, int width, int height) 

iPhone:

CGImageRef image = CGImageCreateWithImageInRect(CGImage source, rect);
UIImage*   uiimage = [UIImage imageWithCGImage:image];

And here is the output of this function on the console.

Crop 4 × 2 from (0,0)
Crop 4 × 32 from (0,2)
Crop 4 × 64 from (0,34)
Crop 4 × 128 from (0,98)
Crop 64 × 2 from (4,0)
Crop 64 × 32 from (4,2)
Crop 64 × 64 from (4,34)
Crop 64 × 128 from (4,98)
Crop 256 × 2 from (68,0)
Crop 256 × 32 from (68,2)
Crop 256 × 64 from (68,34)
Crop 256 × 128 from (68,98)

Is this all what you need? No, but it is the 90%.

I leave the remaining ...90% as an excercise.

Good luck

How to draw your own buttons

In this tutorial I am presenting a way for the case where you don’t want to use the high level library to add buttons in a game (or whatever else application) and want to draw your own instead.

Suppose you are making a game for the iPhone using the OpenGL ES. Of course you can use UIKit buttons and simply lay them over your OpenGL view. Using UIKit buttons works fine and is probably the easiest way to add buttons to your game. However, if you are trying to achieve the best performance possible, you should avoid putting a UIView on top of your OpenGL view. This is especially true if you want to use the controls in the game, unless your game is a “Find The Differences”-like game.

And since everything in my engine is texture everything that you can imagine can be considered as a button. From graphics and single alphanumeric characters (this is very useful for the “write your name” menu) to words and entire phrases.

Three types of buttons are fully supported:

• Buttons that fire a single signal of the touch event even when the button is kept pressed


• Continuous sending of signals to the core mechanism of the game as long as the button is kept pressed


• One signle signal only if the button is released after it has been pressed.

We do need a procedure for this because the operating system (iOS or Dalvik) triggers one single event when we click on the screen, no matter if we keep our finger on the screen.

As a first step we have to introduce a new structure (or class, in java) where we are going to store whatever is needed for a clickable object or Option, to speak more general.

public class Option
{
     int x;
     int y;
     int width;
     int height;
     int type;
     int prevState;
}

Where x,y are the (x,y) coordinates of the upper left corner of the option in actual screen coordinates, calculated in the initialization procedure of the clickable object that is bound with this option.
‘width’ and’ height’ is the width and the height of the object , again in screen coordinates.

The field ‘type’ stores the information of the type (what else?) of the option according to the three different cases as I described above. I have defined them as follow:

     final static int    OPTION_TYPE_INSTANT          = 0;
     final static int    OPTION_TYPE_CONTINUOUS       = 1;
     final static int    OPTION_TYPE_PRESSED          = 2;

The ‘type’ property of the option can be changed on runtime to achieve other effect for the same button in different game situations.
In the field ‘prevState’ is stored the previous state of the clickable object. You don’t have to deal with it since it is calculated automatically from the procedure that I am going to attach here. This state is defined as 0 for previously not pressed and 1 for previously pressed.

     final static int    PREVIOUSLY_NOT_PRESSED      = 0;
     final static int    PREVIOUSLY_PRESSED          = 1;

So,I am ready to reveal how our function will look like

boolean hasTouchedOnOption ( Option option )

The function returns a ‘boolean’ (BOOL for iOS). This means that in the current iteration of the game loop an option is either active or not active.

Do we need anything else? As you can guess we need a ‘touch_x’ and a ‘touch_y’ variable that represent the coordinates of the point where the click has taken place. We need also a ‘pointerStates’ variable that will do exactly what it says.

In my engine there are two states for the pointer. A finger is either on the screen or it is not on the screen.

     final static int POINTER_RELEASED   =  0;
     final static int POINTER_PRESSED    =  1;
 
     int  pointerStates    =  POINTER_RELEASED;

I chose to declare all these three variables as global variables. They are initialized in the function that catches the touch events directly from the underlying hardware.

iPhone: touchesBegan, touchesMoved, touchesEnded
Android: public boolean onTouchEvent

I am pasting here my implementation for Android

@Override 
public boolean onTouchEvent(MotionEvent event)
{ 
     int action = event.getAction();
     if ( action == MotionEvent.ACTION_OUTSIDE  || 
          action == MotionEvent.ACTION_UP       )
     {
          touch_x = -1;
          touch_y = -1;
          pointerStates = POINTER_RELEASED;
     }
     else if ( action == MotionEvent.ACTION_DOWN || 
               action == MotionEvent.ACTION_MOVE )
     {
          touch_x = (int) event.getX();
          touch_y = (int) event.getY();
          pointerStates = POINTER_PRESSED;
     }
     return super.onTouchEvent(event);
}

Now it is time to open the curtain and reveal the body of the hasTouchedOnOption function

protected static boolean hasTouchedOnOption ( Option option )
{
     if (pointerStates == POINTER_RELEASED )
     {
          if ( option.type == OPTION_TYPE_PRESSED )
          {
               if ( option.prevState == PREVIOUSLY_PRESSED)
               {
                    option.prevState = PREVIOUSLY_NOT_PRESSED;
                    return true;
               }
          }
          option.prevState = PREVIOUSLY_NOT_PRESSED;
          return false;
     }

     if ( option.type == OPTION_TYPE_INSTANT )
     {
          if ( option.prevState == PREVIOUSLY_PRESSED ) 
          {
               return false;
          }
     }

     // [OPTION] [TOUCH]
     if ( touch_x > option.x + option.width )
     {
          option.prevState = PREVIOUSLY_NOT_PRESSED;
          return false;
     }

     // [TOUCH] [OPTION]
     if ( touch_x < option.x )
     {
          option.prevState = PREVIOUSLY_NOT_PRESSED;
          return false;
     }

     // [ OPTION]
     //
     // [TOUCH]
     if ( touch_y > option.y + option.height )
     {
          option.prevState = PREVIOUSLY_NOT_PRESSED;
          return false;
     }

     // [TOUCH]
     //
     // [OPTION]
     if ( touch_y < option.y )
     {
          option.prevState = PREVIOUSLY_NOT_PRESSED;
          return false;
     }

     option.prevState = PREVIOUSLY_PRESSED;
     if ( option.type != OPTION_TYPE_PRESSED )
          return true;

     return false;
} 

I think there is not a lot of stuff that needs detailed explanation. [OPTION] and [TOUCH] is the relative position of the touch and the option. The function is extremely quick and it needs from 2 to 10(in the worst case) operations to return a result.

But where is the best place to call this function?

It depends on the nature of your application. Either directly inside the functions that transfer the touches from the OS(see above) or inside the main game loop.

Predefined FPS (Frames Per Second) value for your game loop

In the last decades tons of inks have been spent in articles about how to achieve a constant value for FPS in a game loop.

But why add another headache in the game development process? Why to time it? Why not just leave things run as quick as the CPU can and forget about on-purpose delays and timing?

The main reason is that you have to make sure that the game has the same tempo independent of the power of the CPU and if possible to synchronize the game loop with the refresh rate of the display. Imagine that your hero is at the leftmost bound of the scene and as you hit the right arrow key then he is at the rightmost edge in no time.

Another reason it that once we know the FPS then this is the key for defining the step for x, y direction (and even z in a 3D environment). You know the width of your scene, you know in how much time your hero has to walk all this distance(completely up to you) as if his way was free of obstacles, and if you also know how many frames he walks in a second, then you are a simple division away from setting a correct step (…not exactly …but I will discuss it in another article)

Particularly nowadays where mobile gaming rules the galaxy it is most important to find a way to stabilize on-the-fly the FPS value because you don’t know in the creation time of the game in what hardware configuration the game is going to run. Of course if you write games for an a priori known hardware (as example, if you are an iPhone-developer) then you can experiment in the development time and find the correct values so to put them hardcoded in your source code.

Of course if the game logic is implemented in a terrible way then you have to take other medicine and return later in this tutorial.

Please read first the wrong way for achieving a constant FPS value: It says that...
...if you want to have in your game, let’s say, 25 frames per second (FPS) then you have to add a delay of 1000/25 = 40 milliseconds at the end of every game cycle.

This approach is absolutely wrong because it doesn’t take into consideration:
1) the execution time of one cycle of your game loop.
2) the time that the delay() or sleep() function needs to execute itself.

And, you may ask, what if alone the execution time covers completely the optimal value for the delay? Can you in this case ignore the delay(X milliseconds) function? No! A delay() or sleep() function must be there even with a minimum value in its argument so that the CPU can give time and resources to other threads as well(Input, Display, System threads, etc).

So, a first conclusion for what will follow is that the delay time in unknown in the initialization process and thus we have to keep a variable for this:

int       iGameThreadDelay   = 1;

and change this value on-the-fly according to the everytime calculated FPS value. You will decide for a new value every 1 second.
So, we introduce a variable called lTimer, initialized before going into the while(gameRunning) loop and in every cycle we check if the difference with the current time is greater or equal(the best) than 1000 milliseconds (= 1 second).
And this “1-second-has-passed” moment is the best opportunity to get the cycles performed in this interval (then, FPS=cycles). The variable lGameCycles is increase by 1 in every iteration of the game loop and we can compare this value with the desired one to decide if the delay time has to be increased or decreased. Of course, there must a check for this delay time not to take values less than 1.

Here is a game loop in pseudo language. You can easily find the libraries of the language you use to get the current time in milliseconds and for letting a thread go to sleep mode for some milliseconds.

final static int FPS = 30;
Timer = GetCurrentTimeInMillis();
// better, if you initialize it from a precalculated value
iGameThreadDelay = 1;

// will be set to zero every (almost) 1 sec
lGameCycles = 0;
while ( gameRunning == true )
{   
   lGameCycles++;        
   // ....   
   // Game logic here   
   // ....        
   if ( GetCurrentTimeInMillis() - lTimer >= 1000 )   
   {      
      if ( lGameCycles > FPS )      
      {         
         // if too many FPS, then increase the delay         
         iGameThreadDelay++;      
      }      
      else // ...decrease the delay ...      
      {         
          // ... making sure that the minumum value is 1
          if ( iGameThreadDelay > 1 )              
          {            
                iGameThreadDelay--;         
          }      
      }      
      lGameCycles = 0;      
      lTimer = GetCurrentTimeInMillis();   
   }   
   delay ( iGameThreadDelay );
}

Inaccurate can occur when the difference of the current time and the saved one (in the previous ‘second’) is > 1000 milliseconds. This can be happened while in the k iteration of the loop the difference is let’s say 998 milliseconds and of course in this case the flow doesn’t enter the if (CurrentTimeMillis() - lTimer >= 1000 ) section and right after this in the k+1 iteration(the next) have already been spent 80ms for the execution of the game logic then the calculated difference will be 998 + 80 = 1078 milliseconds.


This value can be stored somewhere and be used in the next game session because – and I have to admit it – using this approach and starting the iGameThreadDelay from 1, it may take a few seconds for the game mechanism to calculate the best value and some players may experience bizarre movements in these few seconds. Thus, by storing it somewhere, it will happened only for the very first time the game is start.

Exactly the same logic can be applied on platforms where a time scheduler executes periodically a callback function (like iPhone & Android).

Collision detection by detecting ...no-collision

What can destroy your game? A bad collision detection algorithm that either returns error results or it is slow or both of them. What if you have hundreds of objects in a scene that have to be checked for collisions using an algorithm hungry for CPU resources?

In this tutorial I am presenting a way that I believe covers the needs of the 90% of the game developers. I am showing you how to perform very quick collision detection in 2D assuming that every object that carry collision dynamics in your game universe can be consider either as a rectangle or as a circle.

If there are special reasons to perform collision detection between objects that are of any kind of shape then you can approach them by splitting them in rectangles/circles or ...re-thing if you really need all this geometry. And if you finally decide to proceed with this then after you have prayed and sacrificed to Zeus...

... you have to befriended with trigonometry but remember: Never call trigonometric functions (sin(x), cos(x), tan(x), etc). Create instead (use this excel spreadsheet) an array (or more) with all possible angles that your game uses and get from there whatever you need.

Checking if two rectangles DO intersect can lead to a complex system of inequalities that has to be checked one-by-one, no escape, no 'break's, no 'return's, for each pair of objects, in each cycle of the game loop.

I don't even want to reproduce here the nightmare of such an inequalities system. Just take a pencil and a (large) piece of paper and draw all possible relative positions of two objects to understand the underlying complexity.

Instead of doing this it is much simpler to find whether two objects DO NOT collide at all. See the sketches bellow. There are only four cases:

To understand the simplicity, I want you to forget for one moment that there are programming languages in this world. Staring at these four pictures it makes sense that if you detect that you belong to one of these cases, then there is absolute no reason to check the remaining cases and you simply return with a result like COLLISION_NO. But if you end up by realizing that you are not in any case of them then only one result remains for you to accept: COLLISION_YES

And exactly this is the logic that I am going to implement. So, assume we have two rectangles A and B and call (x, y) the coordinates of the upper left corner. By knowing also the width and the height of each rectangle we can easily detect all other sides of it. It is very easy to get width & height in the loading procedure of the (image-)resources since almost every graphics library offers functions like getWidth() and getHeight() for its supported images.

So, I am repeating the sketch above by adding in each case the algebraic condition

Picture 1
A.x + A.width < B.x

Picture 2
A.x > B.x + B.width

Picture 3
A.y + A.height < B.y

Picture 4
A.y > B.y + B.height

Now, pack these conclusions in a function, let's call it “getCollisionResult”, that takes two rectangles as arguments and returns COLLISION_NO or COLLISION_YES that can be (#)defined as integers(0 or 1) , booleans(false or true) or whatever other primitive type you like.

result getCollisionResult ( rectangle A, rectangle B)
{   
   // picture 1   
   if ( A.x + A.width < B.x ) // 1 math operation (addition), 1 comparison
      return COLLISION_NO;      
   // picture 2   
   if ( A.x > B.x + B.width )      
      return COLLISION_NO;      
   // picture 3   
   if ( A.y + A.height < B.y )      
      return COLLISION_NO;      
   // picture 4   
   if ( A.y > B.y + B.height )      
      return COLLISION_NO;      

   // reaching at this point means that the rectangles overlap
      return COLLISION_YES;
}

As you see with a little luck you can end up a cycle of the game loop by doing very few CPU-operations for performing collision detection between two rectangles, 4 at the worst case plus 4 comparisons. There is another implementation of this function to reduce the operations to 2 but I leave it as an exercise for you.

This is not the main function that is going to realize your wishes when a collision is detected, but it is a helper function instead. The main function would look like this

result_type HandleCollision( )
{   
   for ( i = 0; i < objectsInGame; i++ )   
   {      
      for ( j = i+1; j < objectsInGame; j++ )//why j=i+1 ???      
      {         
         // before proceeding with checking for a collision,
         // see if these objects don't even need to be checked.
         if  ( checkObjects(obj[i],obj[j] ) == true)
         {            
            if (getCollisionResult(obj[i].rect,obj[j].rect)
                                         == COLLISION_YES)            
            {               
               // ...do whatever you want.            
            }         
         }       
      }  // END for ( j = ... )   
   } // END for ( i = ... )
}

What happens now if your have circles?Then also in this case you can use the function getCollisionResult by passing to it the rectangles that contain these circles. But it may be not accurate enough since it is possible to fall in this case:

The solution for this is to add another argument in the getCollisionResult function so that also the kind of the shapes is known now to the function. So, if the four “if”s are passed without returning NO, then the rectangles collide and only from now on is the best time to check the circles themselves by applying in our calculations the following lemma from the Euclidean geometry:Two circles collide only if the distance of their centers is less or equal to the sum of their radius as it can be seen in the following picture:

But given the centers (cx1,cy1) and (cx2,cy2) of two circles with radius r1 and r2 respectively the distance d between the centers is

And to check if our circles are far away from each other then it has to be check if

To strike the CPU with a square root is not the most gently you can do to it. It is a heavy operation and could lead to unnecessary delays. To avoid this take the square of the above relationship and you finally have to check this inequality:

where there is no square root. After all these, dive into coding and extend the function getCollisionResult like this:

...
radius_A = (A.width)/2;
radius_B = (B.width)/2;
...

result getCollisionResult ( rectangle A, rectangle B,
                            int shape )
{   
   // picture 1   
   if ( A.x + A.width < B.x ) 
      return COLLISION_NO;      
   // picture 2   
   if ( A.x > B.x + B.width )
      return COLLISION_NO;
   // picture 3
   if ( A.y + A.height < B.y )
      return COLLISION_NO;
   // picture 4
   if ( A.y > B.y + B.height )
      return COLLISION_NO;

   // reaching at this point means that the rectangles overlap
   if ( shape == CIRCLE )
   {      
      centerA_x = A.x + radius_A;
      centerA_Y = A.Y + radius_A;
      centerB_x = B.x + radius_B;
      centerB_y = B.y + radius_B;   
   }      
   distance_square = (centerA_x - centerB_x)^2 +
                     (centerA_y - centerB_y)^2;
   if ( distance_square > (radius_A + radius_B)^2 )
      return COLLISION_NO;

   return COLLISION_YES;
}

As it is clear when looking into the if ( ...CIRCLE ) section it would be very painful for the CPU to consider from the beginning the two circle-objects as circles and proceed directly with the if ( shape == CIRCLE ) section. At least do it once the container-rectangles collide which is extremely lighter to find it out.Of course you can optimize this new variation of the function getCollisionResult but I leave it as an exercise.