It took some time until I finally could get back to my little Android game and I must admit that this wasn’t really a “day” I worked on it. Instead, it were multiple, scattered and short sessions where I worked on the collision testing and response code, some effects and UI stuff. It’s simply too hot currently… so bear with me that there’s no cool video this time. Keep reading below if you’re interested in the recent progress. Comments are welcome! In case you missed it, also don’t forget to read the earlier reports on my steps in Android game development: Steps 1-3, Step 4, Step 5.
Day #5, Sunday, June 27th. Here’s the rough concept for timed events I already mentioned in my last posting. It’s working for now, but I’ll do some more tweaks to abstract this even further and make it more flexible. Keep reading below if you’re interested in today’s progress. Comments are welcome! In case you missed it, also don’t forget to read the reports on my steps in Android game development: Steps 1-3 and Step 4.
Day #4, Saturday, June 26th. Keep reading below if you’re interested in today’s progress. Comments are welcome! In case you missed it, also don’t forget to read the report on my first three steps in Android game development.
I’m building rather boring enterprise applications at work and I love creating more appealing things in my spare time, so I do a bit of game development whenever I can. The main problem for a programmer is to get some graphics, but fortunately I have some nice renderings from my old Project E tutorial and the even older Project D game by sechsta sinn on my harddisk that I could put into use (all done by my friend and favorite artist Martin Ernst, btw.). This is what I managed to do in three after work sessions so far, if you’re interested in the details, continue reading after the video.
This is mainly a note to self because I screw up every time I need to write something like that, so here’s an example for myself in the future. Reference: java.sun.com, Tadtech
Last year’s success story continues. If you consider to do GWT 1.7.x development on a 10.5.8 Leopard, you better spare the 4.0.5 update too and stick to Safari 4.0.3; it keeps crashing even though the bug was reported to be fixed in 4.0.5. I am displeased.
I was searching for that today and thought I could write a short wrap-up of what I ended up with. Particularly helpful was the Android TranslucentGLSurface sample code and a thread in the Android Beginners group. Keep reading below for the fully commented source code.
I installed the Safari 4.0.4 update yesterday on my OS X 10.5.8 (Leopard) and got GWT 1.7.x crashes ever since then. That’s a pitty since I’m involved in a larger GWT project (featuring GWT Canvas). There’s already a ticket and a simple workaround available but that’s no choice for production environments. So if you have a Google account, please vote for it so it gets resolved soon. Apparently it’s a Webkit bug which will be fixed in Safari 4.0.5. Update: I could downgrade back to Safari 4.0.3 using Pacifist and the Safari 4.0.3 installation package. I opened the package with Pacifist and chose “Replace” as the option for all files. Trying to apply the package alone won’t help because it detects that a later version was installed, even if you try to remove Safari competely using AppZapper. Safari’s “About” screen shows version 4.0.3 again, OS X asks me to update to 4.0.4 again and my GWT application is back running. Not sure whether there are any other side effects, though, so handle with care. Another …
…it just works! (Source)
Google has announced the second Android Developer Challenge and I’m seriously considering taking part. They have ten different categories with three attractive prizes each and one overall category with three even more attractive prizes. Given the facts that there were only 1788 submissions last year, that I have already gathered some experience in mobile device development and that I do work with several Google APIs for my freelancing job I consider my chances not too bad. Idea, anyone? 😉