As usual, I am jumping around from one side project to the next, always looking for the next shiny object. A repeat of a
Broadcom networking bug
on my new HTC One, lead me to want to be able to dig into the underlying network packets. There are a number of pieces to this project that are completely new to me, including building native code libraries (libpcap) and executing code as a root user on-device to allow libpcap to access the low-level networking stack.
Read more…
Wow… three months since my
last post
about my
Android Clock Widget Project
. While I’ve failed to bring stability to the clock selector during that time, I have figured out that the problem is not actually due to a deadlock. Instead, it appears that my project is tickling a bug in the Dalvik VM’s garbage collector.
Inertia is the resistance of any physical object to a change in its state of motion or rest, or the tendency of an object to resist any change in its motion.
For me, this also describes my tendencies toward side projects like my
Pingus project
. When I last worked on Pingus a couple of months ago, I updated the underlying
AndEngine
libraries and found a ton of breaking changes. I put Pingus on the shelf until I had more time to look at the breakage and how to solve it. The AndEngine changes are pretty significant and I’m going to need to rethink portions of Pingus in order to get things running correctly again.
In my last
Android Pingus post
I mentioned that I was interested in getting Pingus running full screen on my Motorola Xoom. It was clear from Android Market applications that it was possible to run applications across a wide range of Android versions with full screen support for extra large screens, but it was not entirely obvious to me how to actually accomplish that.
In reading the
Android
supports-screen
documentation
, it is clear that it is necessary to set the
xlargeScreens
attribute to
true
. However, the
xlargeScreens
attribute is not supported below API level 9. Trying to shoehorn that attribute into my project that was attempting to support back to API level 5, resulted in the following error.
Read more…
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.
I’m cheap. I like geek toys, but tend to go cheap whenever possible. I still like my cheap Sandisk Fuze (V2) for working out, particularly with the
Rockbox
player loaded. Recently, I changed up the music on the device and the music database functionality in Rockbox started hanging while building the database. While still usable, the player just isn’t quite as good without the database functionality.
When I
hit the wall with Android Pingus
I decided to tackle a Rockbox database generator, based on the
documentation in the Rockbox wiki
. Using that documentation along with looking at the Rockbox source code and lots of binary comparisons, I managed to get a Java-based tool built for generating a Rockbox database on the PC that can be loaded onto my Fuze. I’ve released the first release of the
Rockbox Tagcache Database Generator
. This not necessarily a tool for the feint of heart, as it is a command-line tool driven by a configuration file. With that said, I do think it is pretty easy to use for its purpose and I’m happily using the results from the tool every day when I go to the gym.
As with many of my projects, this tool comes with zero warranty or support. “It works for me” is the best I can say for this tool at this point. The source is available on the page as well for those that may want to tinker or offer patches. At the moment, I have no need or interest in adding new features to this tool, since it is getting the job done for me. With that said, patches to the source would be something I would consider creating a new version to track.
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…
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
.