18 Jun 2015

Do Computers Dream?

If we apply the algorithm iteratively on its own outputs and apply some zooming after each iteration, we get an endless stream of new impressions, exploring the set of things the network knows about. We can even start this process from a random-noise image, so that the result becomes purely the result of the neural network, as seen in the following images:



13 Mar 2015

On the Complexities of Graphics Drivers (also how does software even work)

This forum post from an ex-NVIDIA driver engineer is full of goodies. Let me cherry pick some good ones for you:

"The driver is gigantic. Think 1-2 million lines of code dealing with the hardware abstraction layers, plus another million per API supported."

"...within the existing drivers and APIs it is impossible to get more than trivial gains out of any application side multithreading. If Futuremark can only get 5% in a trivial test case, the rest of us have no chance."

"Why are games broken? Because the APIs are complex, and validation varies from decent (D3D 11) to poor (D3D 9) to catastrophic (OpenGL)."

"Threading is just a catastrophe..."

10 Jan 2015

Cinder is Fun.

"Cinder is a community-developed, free and open source library for professional-quality creative coding in C++."

In short: it's like Processing except in a good better language with better hardware access in a better IDE (your choice!) with more opportunities for optimization.

Anyway, I made a webcam thing!

It's now one of my many Githubs! Check it out.

06 Jan 2015

Quick Trick: Generics as a Decorator

Unity Attributes

Unity likes to use Attributes. They use them all over the place in the Editor to allow you to statically link together Types: like a Type and a class that renders editor controls for that Type:

public class Vector5Editor : Editor

Unity can now look through the assemblies and pull out all classes with the CustomEditor decorator. Now, everytime Unity needs to render controls for a Vector5, it can use this custom implementation. C# is brilliant, right?

Eh, it's good, but it's not great because our custom Editor has to extend a class as well as pin on an Attribute. This is not only unnecessary code, it means that Editor has to pass around an Object, which means when you work with whatever API Editor exposes, you have to work with an Object.

private void OnGUI()
	var vector = (Vector5) target;

D'oh. Editor::target is a stupid Object, not a Vector5.

Instead of using this as a model, consider using generics to link your classes together.

Enter Generics

Say you are writing a custom editor to work with in game entities. You call these entities Actors, cause you want to be cool like Unreal. You also want to let anyone create subclasses of Actor so your Actor system can be, you know, useful.

Like the Unity Editor, you want your editor to be easily extendible, so you want to allow people to write custom editors for their Actor subclasses that will be drawn inside of your editor when necessary. One method is to just mimic Unity's method of attaching attributes. A better method, I would argue, is to use generics to associate the two classes.

public class StaticActorRenderer : ActorRenderer<StaticActor>
	public void OnGUI()
		// ActorRenderer<>:target is already a StaticActor!

Now your Actor editor can simply peruse the assemblies for any class that extends ActorRenderer and look at the generic parameter for the association. The generic parameter is your decorator, so you can ditch the Attribute.

In addition, your ActorRenderer base class can perform useful actions on a typed entity and can expose a typed API.

Yes please.

28 Dec 2014


There are trade schools for woodworking. Did you know that?

You don't go for four years, you don't get a diploma. Instead you can take specialized classes at a variety of skill levels for a few weeks at a time. You learn how to build a desk and a chair, and about different joints-- about cedar and maple and pine. As each day comes and goes, it's up to you to hone your craft. You make stuff. And you learn new techniques. You learn how to think in a certain way and how to visualize and how to plan and how to get what's in your head all the way down to your hands.

Then you make something beautiful, show it off, and hear all your friends say, "what a craftsman!"

It doesn't work that way with programming-- it should, but it doesn't.

Men and women who end up programmers usually go to a 4-year liberal arts college. They get a degree in something that's not science, called Computer Science. They learn about something that's not engineering, called Software Engineering.

Some of them suck at it, but get jobs anyway. Some of them are just lazy, but get jobs anyway.

Some of them, however, are like the woodworker. They see a bit of the behind the scenes and find that the have a feel for the grain. They decide to learn more. They pour over new ideas, new techniques. They look at their work and want to do better. They work on that link between brain and fingers.

Then they make something beautiful, show it off, and hear all their friends say, "uh... who cares?"

Sometimes, programming sucks.