box2dweb, Refactored for Flexibility and Enterprisiness

I wanted to try my hand at making a physics-based HTML 5 game, so I thought I would start by refactoring the box2dweb demo (not working at the moment) into a set of loosely coupled compoenents as a springboard for a custom game engine architecture.  For various reasons, not all of which involve having a working game sooner, I'm gradually removing any dependency on box2dweb from the majority of the code.  Eventually, only adapters will interact with 3rd party software, except for requireJS.

What I have created so far is a refactored version of the demo (with a couple minor behavior changes that have to do with the first game I want to create with it) with a broken Maven build.  :)  The components so far are:
-main - entry point for loading modules.
-Input - takes input from the user and translates it into actions for other components to act on.
-renderingService - displays the state of the game to the user (i.e., does graphics), and also the inverse (translates x,y coordinates on the screen into x,y coordinates in the game world--more on why another day).  The implementation uses box2dweb's Debug view thingy, but the interface is implementation-agnostic.
-physicsService - does the physics.  The implementation uses box2dweb  but provides enough of an interface that other components should be able to use it without knowledge of box2dweb.
-EntityFactory - creates the entities--anything with location in space.  Entities are comprised of a physicsComponent that is a box2dweb entity, plus whatever extra data they need.  Later, they will probably have a graphicsComponent as well.  The box2dweb entity itself is exposed as-is, even though that means the app-at-large is dependent on box2dweb.
-game - runs the show.  Specifically, it does project setup, the game loop, and the master update routine.

I'm using requireJS to wire components together.  The Maven build is backed by the Javascript Maven Plugin.  I have had a lot of trouble getting this to work.  My current problem is that mvn install deletes require.js for some reason, making subsequent builds fail.

I hope to add a unit test or two later, then get serious about making a game with this.  It should be fun.

"In Practice" is just a theory too.

In the software development industry in particular, the phrase in practice is used to mean true, in contrast to in theory, which is a patronizing way of saying false, but well-intentioned.

The phrase in practice precedes a theory just as much as the prhase in theory.  In the best cases, it is a theory based on the experiences of many people, and maybe even empirical studies, and is likely true.  But in the worst cases, it preconceived notion from someone lacking real knowledge of the "practical" theory and the more "theoretical" theory.

Don't use in practice or in theory as spin words to assert your idea as right or belittle the opinions of others.  Share what you think and back up your position with facts and sound reasoning as much as possible.  What you say works in practice is a theory, too.

Ok, enough italics for one day.  :)

Just Use a Saw

I discovered something profoundly usesless today: When you combine a square wave at amplitude 2x, pitch y with a sawtooth at amplitude x, pitch 2y, the result is a sawtooth at amplitude 2x, pitch y, when the two waves are in phase with each other.

square(2a,p) + saw(a,2p) = saw(2a,p)

I can prove it using the harmonic series, but first I should warn that I am not a good mathematician, and there may be errors here, and the above proposition may be false. Please let me know if you see any errors; children will starve if any flaws go unnoticed.

A square wave (http://en.wikipedia.org/wiki/Square_wave) contains every odd-integer harmonic n at amplitude a/n where a is the amplitude of the fundamental (the first harmonic). (Please pardon the infinitely recursive definition... the fundamental is at volume a.)

A sawtooth wave (http://en.wikipedia.org/wiki/Sawtooth_wave) contains every integer harmonic n at amplitude a/n where a is the amplitude of the fundamental.

Now, to sum the amplitudes of the harmonics of the 2 waves, we can express one wave's harmonics in terms of the other wave. Since the square wave in this proposition is lower in frequency and double the amplitude of the sawtooth, I will call its frequency the fundamental (first harmonic) for this example. (After all, it _is_ the fundamental if both are played together anyway, but that's irrelevant to this proof.)

Since the frequency of the sawtooth wave is double that of the square wave, its nth harmonic is the (2n)th harmonic of the square wave. Therefore, it will provide all the even-numbered harmonics. Since its amplitude is half that of the square wave, its fundamental (the 2nd harmonic of the square wave) will sound at 1/2 the amplitude of the square wave, its 2nd harmonic (the 4th harmonic of the quare wave) will sound at 1/2 _that_ amplitude, its 3rd harmonic (the 6th harmonic of the square wave) will sound at 1/3 its amplitude (1/6 that of the square wave), etc.

So, the square wave provides all odd-numbered harmonics n at amplitude 1/n, and the sawtooth provides all even-numbered harmonics _of our resulting wave_ at 1/n. Therefore, by combining a square wave and a sawtooth at twice the frequency and half the amplitude, we have all integer harmonics at volume 1/n, which is a sawtooth at the pitch and amplitude of the contributing square wave.

I guess there is one application to this: On a synthesizer, using a sawtooth oscillator combined with a square oscillator one octave lower at the same volume is useless. One octave lower because that's half the frequency, and the same volume because that's twice the ampltidue and frequency times amplitdue equals volume. So the moral of the story: Just use a saw!

Windows Command Prompt Keeps Up with One Current Directory Per Drive

Or so it seems. This is copied from a console window on a machine running Windows Server 2003:

C:\Documents and Settings\jyoung>cd E:\InetPub\web sites

C:\Documents and Settings\jyoung>cd "E:\InetPub\web sites"

C:\Documents and Settings\jyoung>cd e:
E:\InetPub\web sites

C:\Documents and Settings\jyoung>e:

E:\InetPub\web sites>

Very strange. It seems that the command prompt keeps up with the “current directory” on a per-drive basis, so that when you cd to some drive that you’re not on, it changes the “current” directory for that drive rather than _the_ current directory. Then when you change drives, it remembers what drive you changed it to previously. I did not know that.

Oddly, using the /d flag is required to change directories across drives [reference].

Do your work, or throw an exception - example

The last post gave an illustration of a employee telling his manager if he cannot do his work as usual instead of requiring his manager to ask him if he will start doing what is expected of him every time she asks him to.

Below is a code example of this idea that I posted on StackOverflow:

class GoodEmployee {
void DoWork() {
if (CarIsInTheShop)
throw new CantDoWorkException();
else
_DoWork();
}
}

class BadEmployee {
bool DoWork() {
if (CarIsInTheShop)
return false;
else
{
_DoWork();
return true;
}
}
}

Imagine using each of these. Using GoodEmployee means that client code can operate as normal. Wherever appropriate, _if_ appropriate, a try/catch _may_ be used to properly handle the exception, if that is even possible. The most appropriate try/catch may be in place already in a form something like this:

// main loop:
while(!timeToQuit) {
try {
REPL(); // read eval print loop, for example
}
catch (TransientException e) {
TellUserHeCantDoThatRightNow(e);
}
}

Meanwhile, client code of GoodEmployee may look like this:

myGoodEmployee.DoWork();

Contrast this with proper usage of BadEmployee:

if (!myBadEmployee.DoWork) {
return false;
}
...
return true;

Not _so_ bad. But what if we call DoWork in lots of places? What if there are not 1 but many different methods like DoWork that have to be called? Worst of all, what if we want to have N layers of indirection that must exit when the employee cannot do his work? What if we apply this same pattern (return error codes instead of throwing an exception) to those methods? Then we have something like this:

A() {
if (!B())
return false;
// do some other work;
return true;
}

B() {
if (!C())
return false;
// do some other work;
return true;
}

C() {
if (!myEmployee.DoWork1())
return false;
if (!myEmployee.DoWork2())
return false;
if (!myEmployee.DoWork3())
return false;
// do some other stuff
return true;
}

YUCK!

I have worked on an application like this. Making any minor little changes to it is an absolute pain because it employs the above pattern throughout. Contrast that with otherwise comparable apps that throws exceptions and allows exceptions to be thrown--the latter group of apps not only have less code, cleaner code, and fewer bugs, they also have _more robust_ exception handling.

I hope these clearly examples show how exception-phobia and speculative catch blocks are destructive and literally multiply the amount of code you have to maintain, as well as hide and even introduce bugs.