Despite traveling soccer season heating up, I have managed to make some real progress on destroyable terrain since hitting a wall in my last post. Ground tiles are now implemented and working quite well. In this first video, you can see the individual tiles being marked as the digger works its way through the ground.
When we
last met
I had begun working on the ability for the Pingus character to destroy the terrain. At that point, I had managed to get the images updated for the sprites that made up the image, but since those images were shared all of the sprites that shared the image were being affected.
Read more…
They say that slow and steady wins the race. In the case of this project, the only thing I have going for me is the slow part. Nicolas Gramlich, author of the AndEngine library on which this is based, referred to this part of the project as “destroyable terrain”. I really like that phrase, so I think I will continue to use it here.
In Early Digger Support I covered the initial digger support. At that point I had managed to update the in-memory collision map , but updating the actual textures driving AndEngine was proving to be a bit more difficult. I’m still not there, but I think I’m moving in a positive direction. The following video shows the current state of things. The textures are being updated with a full red fill to make it clear that they have been hit.
So, why is everything turning red? Well, that turns out to be the next item that will need to be dealt with… shared textures. To save memory, many of the sprites share common textures and texture regions. Thus, in the current implementation, changing the underlying texture information affects all sprites that share that information. This is something I knew would have to be dealt with eventually, so it appears that eventually is now .
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.
It is a good thing that I’m not trying to make my living with this little project, given the slow forward progress. However, there is continued progress on the collision detection compared to my last update Pingus On Android – Early Collision Detection .
In
Part 2 of this series
I had finally managed to get the primary scene ground objects into place. Since then, I’ve made some reasonable progress on the game. The following demo shows some of the initial collision detection working.
Read more…
In my first entry ( Pingus on Android ), I talked about my initial efforts to port the free game called Pingus to run on top of Android using AndEngine . At that point, I was struggling to properly place sprite images when the sprite is rotated 90 degrees (and presumably 270). All of the work being done was at a zoom level that allowed the complete scene to be displayed on the device. Because of the extreme zoom, it was impossible to see the details and therefore to notice when things weren’t properly aligned. It seemed like I was getting close with this alignment, but the numbers were not something that could be calculated based on available information:
As I’ve continued hiring at
mFoundry
(if you live in the Bay Area,
check us out
), I’ve been very busy non-coding. As usual, that implies the need for a non-work programming project. As I mentioned
in my last post
, I’ve started digging into Android programming. I decided it would be interesting to try to do a game of some sort. Given that I have zero skill with graphics, I had to cheat a bit. I’m attempting to build an Android version of the
Pingus
game using the graphics and levels from their source code and the very cool Android game engine
AndEngine
.
Read more…
In my previous entries , I’ve discussed a few things that caught me off guard while learning iPhone development. In the last couple of weeks, I’ve picked up an Android device to dig into that platform a bit and probably will spend less time playing with iPhone development. Before I move too far away from iPhone, I wanted to wrap up the remaining differences I found interesting between the iPhone and Java platforms.