Device removal on Windows
In response to:
which Sofie shared from a Digg post. I'd reply with a Reader comment, but they
Raymond Chen (MS genius) writes that users inadvertently get presented with the
"advanced" device removal menu when right-clicking on the device
removal notification icon, when all they should've done is left-click, which
brings up the simpler menu. The simple menu presents one menu item for each
device, alongside the drive letter, making it relatively easy to find the usb
stick you're trying to remove. The advanced menu shows a device/bus tree that
makes it near-impossible to find the device you're after.
What's amazing is that first Raymond, then all the commentators, blame the user
for choosing the wrong menu ("oh, silly me, I didn't realise there was a
left-click menu"). No-one points out that nowhere else in Windows does a
left-click activate a menu. (There is also a half-second delay in bringing up
the simple menu, compared to the advanced menu, causing many to try both and end
up with just the advanced one after the simple one doesn't appear to do
Secondly, no-one points out that the "advanced" menu is pointless. It
has no more functionality than the simple menu, because you are still removing
the same devices, they're just listed in a different format (one that is
Finally, the whole interface is completely insane. Internal hard drives are
listed alongside USB sticks, it asks for confirmation before ejecting the disk
(something which is easily undoable and has no consequence), and everything in
the menu is a "Mass Storage Device".
But the real kicker -- why doesn't Windows flush data to USB devices as soon as
there's an idle IO period (say, after 1 second); and show a warning icon only
when the device is in use? That way, it's always safe to remove the device,
except for the few seconds (at most) after writing to it, which would be
indicated by a red warning symbol or some such, telling you to hold off for a
Hell, they could've put that light on the stick itself. "Don't pull the
stick out while the light is on". Sounds like floppy disk technology.
I had some free time because my thumbs were sore from playing Wipeout HD, so I
wrote another vector/matrix module for Python.
This one has a better design than euclid
* The API is almost identical to the GLSL API, supporting all the same vector
and matrix types and functions (but not the scalar or component-wise functions).
* There are no methods on vectors or matrices, so we don't get confused by
writing imperative code and thinking it's functional, or vice-versa.
* There's a big test suite.
Because of the arrangement of matrix data (as a list of column vectors), it's
probably less efficient in both time and space than euclid. On the other hand,
it's more likely to give the right answer, and doesn't have the Point/Vector
distinction^H^H^H^H^H^Hconfusion that euclid does.
I wrote a small templating engine to generate the code. I think it's quite
neat. It needs no explanation; just run the makefile and look at the generated
files, you'll see how it works.
Watched constants, in Python
Games need lots of magic constant value to set creature spawn rates, movement
speeds, acceleration, rates of fire, random chance, etc etc. Finding values for
all these numbers that work well is usually a lot of guesswork and good luck.
And, unless you have some very sophisticated value-tweaking engine built into
your game, a lot of recompilation and restarting as well.
I stumbled upon this neat trick on Molly Rocket
for automatically updating
hard-coded constants in source code as the game is running.
Here's my quick hacked-up version for Python:
# Name of this function
stack = traceback.extract_stack()
func_name = stack[-1]
# Pattern to locate the new value
pattern = re.compile('.*[^a-zA-Z0-9]%s\(([^\)]+)\).*' % func_name)
# Filename and line number where this function was called
filename, lineno = stack[-2][:2]
# See what that line looks like at the moment
line = list(open(filename))[lineno - 1]
match = pattern.match(line)
Import this into your code, then whenever you have some constant you're not sure
of, instead of writing:
self.x += 0.5
self.x += TWEAK(0.5)
Then run your game. The change is reflected in the game as it runs, as soon as
you save the source file. As is it won't work for values that are used to
intialise, say, a particle emitter; it can probably be improved with some clever
use of __getattribute__ and small changes to the way you write your code like
that. Another improvement that wouldn't be impossible is supporting multiple
TWEAK values on one line.
When did this become the hip new word for "conclusion"? It irks me.
"Our opponent is an alien starship packed with atomic bombs," I said.
"We have a protractor."