partiallydisassembled.net

Device removal on Windows

2009-05-04 08:19:04

In response to: http://blogs.msdn.com/oldnewthing/archive/2009/05/01/9581563.aspx which Sofie shared from a Digg post. I'd reply with a Reader comment, but they really suck. 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 anything). 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 opaque). 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 second. 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. Genius!

vectypes

2009-04-09 23:19:51

I had some free time because my thumbs were sore from playing Wipeout HD, so I wrote another vector/matrix module for Python. http://vectypes.googlecode.com/ 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

2009-03-28 19:50:24

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: def TWEAK(initial_value): import traceback import re # Name of this function stack = traceback.extract_stack() func_name = stack[-1][2] # 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 try: line = list(open(filename))[lineno - 1] match = pattern.match(line) return eval(match.group(1)) except: return initial_value Import this into your code, then whenever you have some constant you're not sure of, instead of writing: self.x += 0.5 use: 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.

Richard writes:

I guess it's a little more programmer-friendly than using a configuration file, but it gives me the willies :)

The takeaway

2009-02-20 10:26:21

When did this become the hip new word for "conclusion"? It irks me.

Anathem

2008-10-11 20:36:51

"Our opponent is an alien starship packed with atomic bombs," I said. "We have a protractor."

Alan Green writes:

Ooh, ooh. I know. We wait until they reach out to press the "fire" button, then we stab them in the hand, right?

Jesse Archer writes:

Perhaps there's another angle we could approach this problem from.