
Working on The Witness, Part 2: Finding and fixing a five-second stall - danso
http://mollyrocket.com/casey/stream_0007.html
======
JoeAltmaier
Strangely, Windows is one of the easier platforms to debug. Because mostly
there are so many programming for it, thus lots of online experience to mine.

I've tried to write correct CoreAudio software for instance (part of writing
audio code for a portable app). It turns out to be pretty much impossible. The
libraries are immature; they post events to non-existant code long after the
audio device is stopped and closed. Pretty much it only works if you write the
same app everybody else is writing (which I am not). SO you add timeouts and
use handles instead of pointers everywhere and vet all the callbacks to weed
out the stale ones.

And there's nowhere to look to figure these things out, because everything you
try in any deep library, you're the 1st one to try it. Because there's 1% the
dev going on on that platform.

~~~
fit2rule
>>Strangely, Windows is one of the easier platforms to debug. Because mostly
there are so many programming for it, thus lots of online experience to mine.

I don't know about that, I find Linux to be absolutely the easiest platform to
debug, personally .. so I haven't been much of a Windows 'person', but I _do_
recognize that all platforms/architectures have their strengths.

Its just that, for me, I see the solution to the whole twisted mess of it all
is to simply define another platform. Windows serves as a great host
environment for a Lua VM .. wrap this in such a way that the same basic code
runs on all major platforms, and oila: no more dependency on outside
frameworks/libs/etc. You own the platform in the 21st century, or it owns you.
Simple as that; from the pepsiPhone to throwaway computing, we're all riding a
slippery slope of use/dont-use because of, factually, fads.

The new platform is the platform, as in the entire platform. If you have to
subscribe, your toolset is broken.

~~~
JoeAltmaier
Here's the chance to insert the inevitable xkcd comic. Anybody remember which
one? About trying to combine 13 versions of Unix into one - result - 14
versions of Unix.

------
mdwrigh2
> Better yet, way back when they first started catering to games with Windows
> 95, they could have introduce a call like BeginFullScreenGame(), and that
> could have done literally everything for you:

In general, APIs like this are pretty undesirable. They're rigid and not
really orthogonal to any other API, so they're difficult to combine with
existing or new APIs. They can't ever really change behavior either, because
people are going to rely on specific implementation details. If you're a game,
you might be able to use them (assuming you don't want to do anything out of
the norm), and you can't if you aren't. Problem is, the platform isn't just a
gaming platform, it's a platform for pretty much everything, and the platform
developer probably isn't a game developer either. This means he or she
probably doesn't have the expertise to write the exact APIs game developers
want, that will be flexible in just the right ways, etc, and whatever API they
did write would only be for a subset of the platforms "customers".

The real problem here is that the APIs that do exist sound like they are
poorly documented and not necessarily thought-out with respect to the rest of
the system. Ideally, all of the options needed for a full screen game should
be well-documented and orthogonal, so they can be combined to achieve what
each of the various apps wants without having to write a
"BeginFullScreen$APPTYPE" function. Then, if there truly is a common setup
games want, it can be built as a separate library on top of these APIs, either
by the platform maker or by a 3rd party.

> They might try to hire and cultivate good API designers, and have real,
> talented developers who do nothing but work on the APIs to the internal
> systems.

There _are_ teams at these companies that do this. This is exactly what the
Android Frameworks team does at Google, which includes people like Dianne
Hackborn and Romain Guy (until a few months ago), to name a couple of the
better known members. They're in charge of designing and implementing a lot of
APIs exposed to third party developers, but also spend time each release
reviewing all of the APIs that are being made public.

------
badman_ting
I like how this piece describes the tedium and pointless work involved in
being a software developer, wasting time doing things to compensate for other
people's mistakes and carelessness. You can be a developer without worrying
about this stuff, but you can't be a good developer without worrying about
this stuff.

------
jimbobimbo
That reminded me. I actually developed and sold a software [1] that would
disable Win key for full-screen games that would not do the workaround. I
developed it after seeing frustration of my friends booted to desktop in the
middle of their Counter Strike battle.

First it was a freebie, then I added blocking for Caps, Num and power keys and
made it a shareware. It was even featured on TechTV by Leo Laporte (great for
the bank account!).

Fun times...

[1]
[http://www.bytegems.com/ihatethiskeydeluxe.shtml](http://www.bytegems.com/ihatethiskeydeluxe.shtml)

------
aboodman
I wonder if the incorrectly documented flag behaves the same way in all of the
versions of Windows that the game is meant to run on.

~~~
to3m
DirectInput has long supported the DISCL_NOWINKEY flag, which blocks the
Windows key and other shortcuts. At one point DirectInput was its own thing,
so who knows what that flag did internally; but since Windows XP, DirectInput
has been a wrapper round the raw input system, so that flag presumably maps to
RIDEV_NOHOTKEYS.

Since DISCL_NOWINKEY has always proven reliable for me on Windows XP and
later, I'd imagine (unless proven otherwise...) RIDEV_NOHOTKEYS will be
reliable too.

EDIT: Just to prove me utterly wrong, see here:
[https://twitter.com/cmuratori/status/470647266995224576](https://twitter.com/cmuratori/status/470647266995224576).
Obviously it was some kind of a problem that this flag did pretty much the
right thing.

------
lnanek2
Fun sort of boy scout's motto for programming mentioned in the article: > My
version of the static discipline, adapted for software, is that whenever you
are making a modification to a piece of code, you should always leave it in a
state of stability equal to or better than how you found it

------
slazaro
Casey's posts on the development of The Witness are all really good reads, I
recommend reading them all.

------
ipsin
Given the domain name and the title, I was really hoping for an article on how
to recover from a five-second loss of control in rocketry.

