Et-Setera

Work and life have conspired to keep me from making a lot of progress on my Android on Pingus project. I had hoped to get further before posting here again, but instead decided to go ahead and post a minor update. In my last post I covered my early collision detection implementation.

The next step was to start implementing some behaviors for the Pingus. The digger behavior seemed a good place to start. In order to implement the digger, it is necessary to actually alter the collision map generated by the tool. In the end, this part was pretty easy to handle. The results are captured in the video capture.

While it was relatively easy to carve out a path through the in-memory collision map, updating the actual graphics is proving to be much more difficult. AndEngine implements 2D graphics using 3D/OpenGL. This implies that in order to update the graphics, the underlying texture images need to be updated. I’m in the process of building AndEngine support for altering the underlying texture images. At the moment, this appears to be slow and may need to be abandoned. Just like while I worked on the collision map, the lack of guarantee for clipping and Z buffer on Android devices further complicate the situation.

While there are times that I wonder if using AndEngine for this project is makes it more difficult, I’m not quite ready to give it up. More to come…

A quick “from the trenches” post. Recently I’ve been digging in to the Android camera a bit. The Android SDK samples have an example of how to wire up a live preview from the camera on the device directly to a Surface view. Unfortunately, this fails miserably on my Samsung Captivate with a repeating error similar to the following.

07-04 12:23:45.101: ERROR/copybit(2230): Error in VIDIOC_STREAMON
07-04 12:23:45.101: ERROR/copybit(2230): Fail : v4l2_stream_on()
07-04 12:23:45.106: ERROR/copybit(2230): stretch_copybit::sec_stretch fail : ret=-5

This had me stymied for a bit until I took a look at the awesome zxing (Zebra Crossing) project where I stumbled on to a solution for this problem. (All credit goes to their developers). The code in their CameraManager class and CameraConfigurationManager class goes through a number of gyrations to pick an appropriate preview size. Using that code allows the Captivate to properly render a live preview.

Thanks to the zxing crew for this little tidbit, as I’m not sure I would have figured this one out on my own.