Today’s title may be weird to see, after all, it’s about a mistake I made in programming. However, people made mistakes all the time, so they can learn from mistakes.

So, What happened?

What should happen:

It went like this:

I’ve been working on a project that resembles a pac-man game for quite some time, and all these time, I’m trying to work out a way of effectively doing collision detection. Now, what I initially thought how to do it, is to read the colors of the pixels that made the borders of the walls, and if the border of the sprite of pac-man intersected a pixel with such color, then it can be said that the main character has collided with the wall and will cease moving. (If the main character didn’t collide with a wall it will definitely keep moving towards that direction except further action is assigned).

Below is the “map” I made for this project, in other words, this is the pacman board.

The walls all uses the color (99,15,164), and the wall border is also specifically set as (5,3,67). Technically, I could set up so if the border of the pacman sprite intersects with a later color, then consider them collided and stop the movement of the sprite.

The similar way of collision detection has been already used in the Pacman eat pellet part, but it’s done traditionally since it’s easy to just erase the pellet when pacman’s sprite went through it. And technically, what I thought would work because there is a call in 2LoC engine that did get the properties of a pixel for me:

• GetPixel() : tloc::graphics::media::Image_T< T_ColorType, T_StorageType >

This call should get me the pixel-in-question’s color, and storage type.

So, I hook my if statements up with that, and compiled the program.

What really went down and why

And it turns out to be a disaster, none of the collision detection is there, when I pressed the direction button, the main character just turned and ate through those walls.

While I admit this turned out to be very funny, it’s not pac-man at all. So obviously, this should be fixed.

I looked through the code, and find out that the above call deals with images, basically it’s handled by the part that loads the images. So the results that came from the calls used in those if statements are not reflecting the color that the engine really reads, since there the engine let OpenGL to handle those buffers and everything should went there.

So I went through the code again, this time starting from another direction, and then fixed the calls so it came from tloc::graphics::gl instead of tloc::graphics::media.

Then, I rewrote the if statements to match the new changes, and run it. The result? Less a disaster, but still is:

Now the pacman character will stop when I hit a direction button when it cannot turn. However, the sprite turns, the pacman sprite actually went down some pixels before it got blocked with the collision kicked in.

So basically, the character is still turnable when it shouldn’t.

The problem this time, I suppose, lies in pixels. After a closer inspection made in Photoshop, it seems the sizing of the initial picture caused the pixels that has the color (5,3,67) to changed color – PS has a way of handling resizing of non-vector pictures, one of the ways is to change the colors of the border pixels in order to conduct the anti-aliasing. It uses a lot of pixels that look the same but has the different contrast and hue around the jagged parts – whatever – come to think of it, I even blogged about this last year in this very blog! How did I fail to see that coming?

So here I am, remaking that board, and writing this blog.

Then what about the “more” in this title?

Oh, it’s about my other project. See, I’m supposed to do a non-trivial cutscene, right? By a cutscene, that means with animated stuff, right? So last week I’ve been working on implementing rigged animation in 2LoC engine, and complaining the lack of presets in the engine to boot. Then I found out that the only thing that need to move is the keyframed camera. Heck, I worked on a week for nearly nothing, at least I put the ideas of that youtube video featured last week into practice, so something came out from that. But that aside, I still think I wasted some time so I don’t really want to talk about it. Now, back to making the new boards, or until I came up with a new and effective way to do these collision detection.

Until next time.