pk fire!

I’ve been feeling pretty guilty lately of not having any running system of backups so I am getting started. I’m doing just a flat full mirror of this site on multiple machines and using rsync to do it — standard stuff. A lot of links are probably broken since I deleted a few things that were old and no longer significant. I’ll do what I can to fix things as they come up.

Otherwise, please don’t hate me if you came here for something and you couldn’t find it.

I also had an idea for a new web site design. To make it would be a rather bold endeavor, though it would be interesting to try!

I signed up to take part in the first-ever Reddit Secret Santa gift exchange program. It was a lot of fun! My gift recipient was neadha which didn’t leave very much clue what to get him, so I sent him a photo tour of Tuscaloosa guided by a character I made up called “Sarcastic Boy” since he simply said he liked satirical, ironic things. I mailed this off a long time ago and it should have been received by now. I don’t have any word of it and I’m thinking I probably won’t!

Oh, and mine came in! I received a hand-carved Reddit stamp of approval and a 3D dinosaur puzzle. Neat!

I received a Dinosaur 3D Puzzle and a handmade stamp!

Thanks a lot!

Thank-you card I sent to my Secret Santa

A few weeks ago I sent off my Android Dev Phone to be replaced due to my touch screen failing. I found that this makes the phone… well… rather useless. It was also doing funny things such as when receiving a call, the ringtone would playing incessantly on loop which can be pretty annoying too.

Dev Phones are handled by Brightstar Corporation. I’m not exactly sure what their role is for all this since they seem to backorder from HTC, but nonetheless they handled my support. It was a pretty straightforward process. I emailed a person and in a few days I got a number assigned to my case and I mailed them my phone. Not too bad.

Although, there is one thing about Brightstar’s return process:

We aim to process and provide a new or refurbished device to your address within 1-2 weeks of receipt.

*Gulp* That’s a long time. Especially when one of my classes depends on me developing on this particular phone. It was a hugely inconvenient time for the phone to fail but I stuck with it. Here’s the breakdown of the process:

9/22/2009 - I leave the packed phone at the UPS Store near my apartment. It departs the same day at 8:42 PM.
9/25/2009 - UPS shows confirmation of delivery at 11 AM.

That was fast! I was satisfied. I waited and waited and never received an email about the replacement being shipped. So I inquired Brightstar what was up. Brightstar tells me that the phone was received into their system on October 5 and that they would provide me a tracking number when it shipped.

Seemed a little odd to me but I didn’t make a big fuss. My new phone was coming soon.

10/5/2009 - Brightstar received my phone.

I waited around but didn’t hear anything about a tracking number

I later received a call from UPS telling me that the package would be delivered the next day. Oh boy!

10/16/2009 - The first delivery attempt is made, but nobody is available to sign for it.

Nuts. This is why classes should revolve around my schedule… and why UPS should have a narrower delivery range than “… between 8 AM and 7 PM”.

10/19/2009 - I pick the phone up at the shipment facility.

So the whole thing took about a month. There’s a lot of grey areas where I don’t know what was really going on, but I was hoping for the phone to be gone for less time than it was.

I’m now the proud owner of an Android 1.0 phone again. Now I gotta upgrade to 1.6 again. Grr…

It’s a lazy Sunday afternoon so I broke out the shortwave radio to see what all the international spies are up to again. Today I heard something broadcasting Morse code over the amateur and marine band on 8.1 MHz. It was going on around 12:45 P.M. CDT and has since stopped. Here’s a clip I recorded and isolated:

Link

I decoded it and this is what it yielded:

“RTIRA MUUDI IGMRI DGURG IUTMN RMURN”

Who knows what it means. I thought it must be a different substitution for some other language or it could be a cipher.

That is all.

Physics-based games are getting more and more popular, and at the idea of my brother, I found myself working on one for the Android simply called “Grenade.” I guess you can infer what it is like.

The game itself utilizes the accelerometer, but that was the easy part. I found myself more impressed with the basic 2D physics of the game. Getting grenades to bounce down a slope in just the right way is quite a chore.

I found myself returning to an old friend of mine. A while back, I wrote a “for-fun” app called JPhysics, which was just a physics sandbox written in Java. It consisted of a bunch of bouncing balls which would bounce off of each other. Really when we’re dealing with bouncing a rigid body (modeled as a circle) bouncing off of a planar surface, it’s a subcase of two circles bouncing off of each other.

A lesson in bouncy things

Let’s consult my old friend, 2D collisions without trigonometry (original link to Geocities now dead). This is a great resource for any game/simulation programmer. This document overviews how to simulate two circles bouncing off of each other.

The idea behind this is we can turn a complex case (A) into a simple case (B):

We start with normal x-y axes and what we see is that our surface is not parallel to the x-axis. So, we convert it to a new axis: the normal-tangent axis. If you can find a unit vector that is either normal to the surface or tangent to the surface you can perform the bounce. In my case, I found it easier to first find the tangent vector since I was dealing with an array of integers indicating the height of a mountain at a given point. All you have to do is find the slope at the point of impact, convert that into a unit vector, and you are set.

So, if you have a unit tangent or unit normal vector, how do you find the other? Since by definition a tangent and its normal vector are at a right angle to each other, it’s quite easy.

ut = < -un_y, un_x >

From here, you find the object’s normal and tangential speed which is just a dot product of the corresponding unit normal and tangent vectors.

A general principle for the normal and tangential velocities is that the normal velocity will be mirrored across the normal axis after the bounce since the object will want to bounce away from the surface and the tangential velocity will remain intact. At this point, it is a good time to apply any friction (for the tangential speed) or elasticity (for the normal speed) since it is easiest to calculate at this step.

If we were bouncing balls at this point, we could also use the laws of momentum to calculate the real speed. However, we’re assuming that the terrain we’re bouncing off (the planet Earth) is really really massive, so I have ignored it for my game.

Now it is all a matter of changing back to our original axis. First turn the normal and tangential speeds into vectors. All this requires is multiplying the computed normal and tangential velocity by the unit normal and unit tangent vectors respectively.

Finally, you will find the resulting velocity by adding together the ball’s normal and tangential velocity you just solved for.

So, it might be handy to see that in an overview. Here is a step-by-step breakdown:

1. Find the unit tangent vector or the unit normal vector to form the new axes that we will deal with. If you are missing one, use the aforementioned identity to compute it.
2. Find the speed of the object on the new normal-tangent axis.
3. Manipulate the normal and tangential speeds as needed. In order to bounce the ball, the normal speed must be negated.
4. Convert the normal and tangential speeds into vectors.
5. Convert these newly found vectors back to the x-y axis.

In Java written as a function that accepts the x and y component of a tangent vector, it looks like this:


public void bounce(double tx, double ty) {
if(!mPhysics) return;

// Assign the new velocity vector
mVX = (float) (nvx + tvx);
mVY = (float) (nvy + tvy);
}


Other thoughts on this subject

Nearly every other type of engineer will have seen this type of problem before. I’m a student of computer science and physics and this type of things has come up in my introductory physics courses, but does not explain how to apply the laws of conservation of momentum in this situation.

That’s why I love the linked document so much.

If you’re a rising game/simulation programmer I would read this and keep it handy. I read it once many moons ago and never thought I’d need it again… heh.

I’ve spent the day figuring out the best way to install Debian from something other than CDs, and more specifically, flash drives. If you’re familiar with the unetbootin method, normally it would just be an issue of downloading the ISO and the program does the rest. However, unetbootin tends to miss a lot of things that would normally be on the ISO itself. When using the Debian net-install image with unetbootin, Debian would fail to scan for the CD because the CD isn’t there. Fair enough. Normally it would be good enough to copy an ISO image onto the USB drive and mount it at the BusyBox console, but alas, mounting loop devices just plain doesn’t work. This is getting frustrating.

Preparing the stick manually seems to be the best option. The nice thing from Debian is a handy installer image that’s ready to go on almost any media type. This web page does a good job of outlining the many ways you can install Linux on your toaster… or at least most systems. If you’re looking to do this quick and recklessly and you don’t give a damn about your USB stick, have a visit to:

ftp://ftp.debian.org/debian/dists/[preferred distro]/main/installer-i386/current/images/hd-media/

Where ‘[preferred distro]‘ is something like ‘lenny’ or ‘etch’. There is a file called ‘boot.img.gz’ that you will want. Download it and a simple

#> zcat boot.img.gz > /dev/sdb1

takes care of the rest. Afterwards, you will need to copy an installation ISO of some sort (net-install or Business card ISO) to the flash drive.

If you’ve read the developing on a device article in Android’s documentation you’ll see a little tidbit about how to get device debugging working on Ubuntu. What they offer is a little udev fix to get adb to play nice with Linux. They tell you to put the following in /etc/udev/rules.d/50-android.rules, dependent on which version of Ubuntu you use.

SUBSYSTEM==”usb_device”, SYSFS{idVendor}==”0bb4″, MODE=”0666″

What irks me is that the documentation seems to be confused on whether or not the file needs to be 50-android.rules or 51-android.rules. At that, the scale of the complexity of this problem is actually much larger than what the documentation makes it out to be. There are many different udev configurations. I know, there’s no way to cover everything. That’s why we have the community to help us out.

Anyway, if you’re using Fedora Core what you put in that file is actually going to be different for you. I read this android-developers thread to figure out that something was amiss.

This thread suggests that there’s a rule in udev called 50-udev.rules that will execute after 50-android.rules and undo the change that we are trying to make. It suggests you name the file 51-android.rules so that our changes will execute after the changes that would normally revert everything. I found this not to be true on Fedora Core 10. Or at the very least, I found that it does not matter whether the file is called 51-android.rules or 50-android.rules. I assumed this was because I didn’t have the rule that would normally matter.

The proper content of /etc/udev/rules.d/50-android.rules in Fedora Core 10 should be:

SUBSYSTEM==”usb”,SYSFS{idVendor}==”0bb4″,SYMLINK+=”android_adb”,MODE=”0666″

If someone wants to explain why that SYMLINK part makes a difference, I am all ears. A man from IRC who has a beard so long that it tells me he is much wiser than I says that the method is different in FC11, and even more different in FC12.

In short, put that in /etc/udev/rules.d/50-android.rules instead of what the docs say to do. When you get done, thrown away all your work and upgrade to FC11. Then to FC12. Then get fed up with Red Hat and change to Ubuntu.

I have returned from my reclusive state of coding Pong and released it for the public to laugh at my coding inability. I created a project page at Google code for it.

Also, I am in the process of moving into an apartment. And curtains suck. Balls.

I just published my first application to the Android Market. All I can find for real evidence is the entry on Cyrket.

Pong could definitely be a whole lot better than it is, but I’ve been pushing myself to release something at all. The reason I bought the Android Dev Phone is to make money back, after all, and I haven’t done a thing for commercial gain. $_$

It’s been fun making it though. It taught me a lot of what I will need to know for my next project. The Android platform is another exciting world for me.

Howdy. I’m taking a small break from studying for an exam to bring you some hopeful relief from MapView.

I had the pleasure of playing with MapViews for the first time the other day, and I’m trying to keep my pledge of writing about every minor problem I have and how to fix it.

This particular problem comes up when you run your MapView for the first time. While you might normally expect your MapView to contain, well, maps, it actually contains a bunch of grey squares.

There are two probable causes of this type of error.

Malformed/missing Google Android Maps API key

To get your map data, you actually need an API key. It’s right there in the tutorial in case you haven’t checked. You have to get the fingerprint of your APK signature and use it to request a key.

I spent a lot of time trying to fix my API key, when actually my problem was…

Not having the Internet permission defined

Again, this is right there in the tutorial. My problem was not that the permission was missing, but rather in the wrong place.

The following ought to be under your <MANIFEST> tag.
<uses-permission android:name="android.permission.INTERNET" />

That’s MANIFEST. Not APPLICATION.

With just that and following the tutorial, you can get a simple MapView up and running.