Monthly Archives: December 2011

I'd like to encourage everyone to take a moment to sign this petition on blocking the National Defense Authorization Act.  The act itself is not malicious, but there are pieces which are horribly insidious.  The largest discontent stems from the clause which authorizes the indefinite detention of US citizens without trial or right to legal representation.  This is a subtle landmine of a footnote on a budget bill.  It's also the best use of WeThePeople I've seen recently -- it invokes powers directly available to the president and does so in an immediate and observable way.

I've tried to put in words my contempt for Perforce a few times.  I believe now that were I to manifest fully the immensity of my hatred for this piece of software it would blanket the earth in a sea of ash and decay.  It would start with the sound of weeping and lamentation, like a child crying against the ambient noise of a playground.  The plague wind of silence would spread, lifting the hopeful and animated spirits from their frames and casting them into the darkness. Joy now ended, the screaming would grow from this deathly silence, filling the skeletal void with a boiling noise of apocalypse.  Tumultuous and unending, the world would burn and the fields would turn to salt in the wake of this horror incarnate.

With that said, here are some of my real gripes with Perforce:

  1. Setting the active client in the command line is troublesome.  I struggled today to realize that `p4 set P4CLIENT=myclient_engbuild` was not working because P4CLIENT should not be capitalized.  It is printed as P4CLIENT in all the documentation, but you have to use p4client if you want it to accept changes.
  2. If you leave out the equals on `p4 set client myclient_engbuild`, you will set an environment variable called 'client', then wonder why all your commits and changes are not happening where you expected.
  3. If you need to edit your changelist in the GUI client on Windows 7, good luck.  You can add files and remove them, but not add a description.  It's faster to just completely delete your change list and redo all your changes.
  4. You cannot delete your changelist until you delete all of the changes on it.  The option doesn't even appear until the changelist is empty.  It is not made obvious why one cannot delete a changelist, or it is possible.  However, one can search Google and find the required information.
  5. Once you get to a few million files across different projects, UI latency becomes intolerable.  On my Q6600 desktop with 4 gigs of ram, I need to wait between four and ten minutes (std dev 2 min) after EVERY MOUSE CLICK.  In defense of Perforce, I suspect it's the case that their software is fine, but my organization has a terrible codebase structure.  Is it reasonable for a lot of code to bog down a subversion server?

Having vented that, I'm sure there are reasonable solutions to all of these problems.  Unfortunately, the solutions are not obvious, and the problems are recurring.  I'd like to think I've given Perforce a fair shot, but it still falls terribly short when compared to every other piece of source control software I've used.

A while back I wrote a tool called TED, the tileset editor.  It was a companion for the marvelous TileD.  Aside from Pixothello, there really weren't any good tileset editors.  One can work in Photoshop, absolutely, but it's designed for a more general purpose.  It might be time to dust off the code and start fiddling again to make it more usable and, of importance, easier for someone else to step in and diddle with the code.

Here is a link to the source as it stands:

Things to be done:

  1. A decent color palette.
  2. Fix an annoying bug where the preview of the pointer tool doesn't line up with the target.
  3. Add a big preview of the tile in use.  I think this is handle by the zoom feature, but there's a problem:
  4. Zoom and pan are buggy.  Moving around the tileset is unpleasant and can cause certain tools to misbehave.

Reddit has been kind enough to provide feedback and recommend changes.  The thread is here:

Finally, here's a preview of an older revision.  I made some changes and, not realizing it, broke some things.  The next release will probably be 99% bugfixes.  I'll suspend work on DRMan until this is in a decent state.

Uploaded a time lapse video of the work on DRMan.

Some things I learned:

You can replace the audio in a movie using the following FFMPEG command:

ffmpeg -i source.mkv -i new_audio.mp3 -vcodec copy -acodec copy destination.mkv -newaudio
You can record a time lapse video of your endeavors with the following:
while true; do scrot -q 100 $(date +%Y%m%d%H%M%S).png; sleep 1; done
mencoder -ovc x264 -mf w=1280:h=1024:fps=30:type=png 'mf://@files.txt' -o devtime.avi

I'm going to cheat and get started early on next year's resolution.  The first game idea is an arcade-like top-down superhero game.  It's motivated by a Saturday Morning Breakfast Cereal Comic:

One controls Disproportionate Response Man (hereafter, DRMan), ambling through a procedurally generated city and punishing evildoers in ways which are spectacularly fatal.  Someone littering?  Throw them into a power transformer?  Double parked?  Time to get hit by your own car!  Spitting?  I will slap your face off of your face!  The crime rate drops as a function of both visibility and the horrificness of the punishment.  That is, beating a criminal with another criminal will drop the crime rate faster in full view of the public.  Crushing someone with a dumpster in the privacy of an alley will do less to deter crime than crushing someone with a building in the middle of a crowded intersection.

Build Order:

  1. Running build environment
  2. Window drawing
  3. Drawing, update loop, input, main menu, and game states
  4. Single controllable character on screen
  5. Multiple stupid NPCs on screen with instancing support
  6. Scrolling map in background
  7. NPC/NPC collisions and damage
  8. NPC/World collisions and pathfinding
  9. Gameplay tweaks and finish criteria

I'm aiming for 1 through 5 this weekend, possibly reaching as far as 8.  9 will be the longest running item, and will require the most tweaking.  A public beta will be made available at that time, I'm debating whether or not to open source the whole thing.  At the least, I'll keep an active dev log and pseudocode to describe the interesting bits.