The Omnigeek

I’ve been trying to think of something good to write on.  Being a geek blog, it needs to be geeky and with my focus on mobile apps, my posts have all been on that topic lately, I don’t want to overwhelm the blog with those posts.  So I decided to venture into a dangerous ground.

Today we celebrate the birth of Jesus.  Well, “we” meaning Christianity.   “We” is a dangerous term given that only 1/3 of the people on the planet are Christian.  It is, however; the dominate religion in the United States, which many of you are from, so I’ll brave the term and go with “we”.

Take the Rick Perry “I’m a Christian and therefore Gay’s are Evil” ad that he’s running to try and become President as an example.  He’s targeting a group to blame for all the country’s problems and encouraging you to hate them because its the Christian thing to do.  “The Christian thing to do…..”

Jesus taught us to love not hate, yet it seems that message gets lost today.  “We” are anti-gay marriage (well anti-gay everything it seems.)  “We” are against a mosque being built down the street.  “We” are against the growing culture of Spanish speakers.  “We” are against socialists and communists.  “We” are against anything that isn’t like us.

Where does that come from?  It seems to me that we’ve forsaken Jesus’s message of love and tolerance and forgiveness to one of hate those that don’t believe in God.  Hate those who violate 4 verses in the Bible, 3 in the Old Testament and of which two are in the same writing as hurl rocks at your kids until they die for back talking you.  You know, the verses you cherry pick that gives you permission to hate the GLBT community.

Frequently this hate comes from a lack of familiarity with the people you are hating on.  Its a distrust formed because “they” are different and “we” are not comfortable with them or their culture.  Its easy for people to group together in common circles to protect your status quo.  But when that need to protect only stems from not knowing those outside your group, that’s when problems start.  War’s have started because of this.

For those who are Star Wars fans (obligatory geekism), you know that hate leads to the dark side.  The dark side is evil, therefor hate is evil.

Hate and distrust leads to bullying.  Many of us think of bullies as big kids beating up on weaklings.  That’s true, but its also people saying hurtful things about others.  Its about excluding people because they are different.  Its making fun of a kid because he prefers art over football.  Because she wears glasses.  Why is different wrong?  Why  must “we” do things to hurt people who are different?

Since this is a season of Love, Family, Giving, Sharing and as we move to the new year, one of resolve….   Lets not worry about how we got to a state of hate, but instead focus on love and tolerance.

I challenge each and every one of you as we move into 2012 to work to find some group/culture/faith that you “hate” or uncomfortable with  and try to learn something about them.  Maybe its learning a little bit about Chinese culture.   Perhaps its reading a few verses of the Koran.   Learn a little bit of Spanish.  Read about the origins of Kwanzaa.

Take this time and make it your New Years resolution.  Make it one you will keep.  It doesn’t take much.

If we all take a few steps towards love and tolerance then perhaps the world will be a better place.  A more peaceful place and one were different is a good quality not a bad one.

A frequent question that comes up in the Corona SDK forums is how to detect when two images on a screen hit each other. This is known as a “Collision”. The ability to determine when two things have bumped into each other is called “Collision Detection”.

Within Corona SDK, being that its an event driven system, we like the idea that we can have the system tell us when things hit each other and we just have to write the code to handle the interaction of the two. This is a cool concept and it works, but . . .

It requires using the Physics engine to do so.

Corona SDK uses a wonderful 2D Box model for physics and that model supports this event driven model and it works well. But if you’re game does not need physics and many apps don’t, like a card game where you move a card to a stack, its kind of silly and wasteful to include the overhead of the physics engine. You don’t need all of those angular momentum floating point mathematics going on in your game.

So how do I detect collisions? I don’t see any API calls to do that?

We really can’t use an event driven model like the physics engine, but there is a very simple method (well there are two) that use other features of Corona SDK, in particular using an “enterFrame” event on the Runtime listener.

Basically we have to write the code that the physics engine is doing for us and it’s not all that complex.

In my personal model, I typically have a table/array of all of my on screen objects and then I have my player’s avatar object.

 Lua | 
 copy code |
?
 
1
2
local objects = {}
3
for i=1, 20, do
4
    objects[i] = spawnEnemy() -- spawnEnemy creates on display objects and returns it.
5
end
6
 
7
local player = display.newImageRect("avatar.png", 64, 64) -- create me.
8

At this point we have a table of enemies in the “objects” table and my player object.

For the Runtime enterFrame event, you need a function to process the collision detection.

 Lua | 
 copy code |
?
 
01
02
local function testCollisions()
03
    for i=1, #objects do
04
         if hasCollided(objects[i], player) then
05
             -- do what you need to do if they hit each other
06
         end
07
    end
08
end
09
 
10
Runtime:addEventListener("enterFrame", testCollisions)
11

So we simply iterate over the list of objects and see if any have hit the player object using a function called hasCollided.

This is a function that you also have to write.

There are two main methods for doing this, one is based on rectangles overlapping each other. The other involves circle testing.

 Lua | 
 copy code |
?
 
01
02
-- rectangle based
03
local function hasCollided(obj1, obj2)
04
    if obj1 == nil then
05
        return false
06
    end
07
    if obj2 == nil then
08
        return false
09
    end
10
    local left = obj1.contentBounds.xMin <= obj2.contentBounds.xMin and obj1.contentBounds.xMax >= obj2.contentBounds.xMin
11
    local right = obj1.contentBounds.xMin >= obj2.contentBounds.xMin and obj1.contentBounds.xMin <= obj2.contentBounds.xMax
12
    local up = obj1.contentBounds.yMin <= obj2.contentBounds.yMin and obj1.contentBounds.yMax >= obj2.contentBounds.yMin
13
    local down = obj1.contentBounds.yMin >= obj2.contentBounds.yMin and obj1.contentBounds.yMin <= obj2.contentBounds.yMax
14
    return (left or right) and (up or down)
15
end
16
 
17
-- circle based
18
local function hasCollidedCircle(obj1, obj2)
19
    if obj1 == nil then
20
        return false
21
    end
22
    if obj2 == nil then
23
        return false
24
    end
25
    local sqrt = math.sqrt
26
 
27
    local dx =  obj1.x - obj2.x;
28
    local dy =  obj1.y - obj2.y;
29
 
30
    local distance = sqrt(dx*dx + dy*dy);
31
    local objectSize = (obj2.contentWidth/2) + (obj1.contentWidth/2)
32
    if distance < objectSize then
33
        return true
34
    end
35
    return false
36
end
37

Depending on the shape of your player and objects, you may find that circles work better or rectangles work better. In my game Omniblaster I used both methods depending on the objects. My space ship has rounded shields and my rocks were basically round, and my enemies were basically round, so using the hasCollidedCircle made more sense to use.

When I say rounded, the images have transparency that when using rectangles would cause the objects to hit before they looked like it.

Yet, when I fired my phasers or torpedoes, those graphics fit nicely into rectangles, so using the rectangle hasCollided method was a better choice.

One gotcha that you need to be aware of is that if your processing takes too long, (longer than 1/30th of a second or 1/60th depending on frame rate) then your collision detection will fire again before you finish, so I usually change my collision handler to something like this:

 Lua | 
 copy code |
?
 
01
02
local isCheckingCollisions = false
03
local function testCollisions
04
    if isCheckingCollisions then 
05
        return true 
06
    end
07
    isCheckingCollisions = true
08
    for i=1, #objects do
09
         if hasCollided(objects[i], player) then
10
             -- do what you need to do if they hit each other
11
         end
12
    end
13
    isCheckingCollisions = false
14
    return true
15
end
16

This should be a lighter weight collision detection system than the overhead of the physics engine. Though you don’t get filters, being able to define polygon shapes unless you roll you’re own!

Happy coding!