Silicon Dust HD Homerun, CableCard, and Mac

One point twenty-one jiggawatts!

So, the good news is that Time Warner’s 50Mb/s internet access is really, truly 50Mb/s. I’m impressed. (Let’s assume no outages.) On the other hand there’s the whole digital cable situation. Now, as you may recall, I don’t care for broadcast TV but, hey, I wouldn’t mind being able to watch major sporting events live. Also, I’ve discovered that, at least where Comcast is concerned, if you don’t actually have a digital tuner in your house then you can’t access HBO GO even if you pay for HBO. So my goal was to (a) get access to TV when I wanted it (i.e. rarely), and (b) minimize the amount of cable TV bundling tax I pay on top of my true need which is high speed internet.

My plan was to get a stupidly fast internet connection with the cheapest TV package that included the station that Game of Thrones is on. I also wanted to pay as little as possible for set top boxes and other crap. The result is I bought a new modem from Amazon (based on recommendations from both Time Warner and The Wirecutter) to avoid paying $8/month for a crappy modem and trying to figure out which wall wart goes with my old Comcast modem (which probably doesn’t support DOCSYS 3 anyway) and I bought a mysterious device called the HD Homerun which purports to allow anyone on your LAN to watch Cable TV by using a CableCard. I picked this option after discovering that a CableCard is by far the cheapest “tuner” option I can rent from Time Warner if I want to be able to “watch” HBO.

The HD Homerun's software is minimalist and borderline useless

First off, the HD Homerun basically doesn’t support Macs. It has a godawful (and pretty useless) “application” that lets you discover your device on the network (which works quite well) and then point its tuners at different stations in a ludicrously primitive and unhelpful way. Some stations “work” (i.e. when you tune to one and click “view” you see something) while others don’t (i.e. if they’re encrypted or some other magic property is not in evidence). To get that far, however, is a bit of an epic journey.

The HD Homerun's embedded web app is truly awful.

To begin with, such documentation as you get (which is virtually nothing) assumes you’re using Windows 7 (or maybe 8). Although, judging by the forums, it’s not like everything “just works” in Windows. But in particular Windows will actually display the HOST ID and DATA strings you need to get the device working with your provider. On a Mac you need to go into terminal and type hdhomerun_config discover to find out the IP address of your gadget. (Getting this information involved extensive googling and then eventually realizing that Mac users are best off reading the MythTV documentation and trying to glean meaning from it.) You then type the resulting IP address into a web browser to get to a spectacularly bad web app (as in, worse than ten year old routers) which displays the information you need. And with that I was able to see perhaps one in ten stations (not even all the free to air stations I am supposed to get).

So, the one positive side of this is that despite the fact I can’t watch any HBO stations (they’re all encrypted and the device doesn’t support decrypting them — I’m not sure why) I have been able to log into HBO GO and I’m only paying $2.50 per month (plus taxes to pay for the Spanish-American War, etc.) for a useless CableCard instead of $8/month for a useless set-top box or $23/month for a useless DVR.

Verdict: I’m not positive that Time Warner Cable is as incompetent as Comcast, so it’s possible that I don’t need the CableCard at all, in which case the HD Homerun is a complete waste of money, On the assumption that TWC is exactly as incompetent as Comcast, and that without some kind of tuner that theoretically could receive HBO in my house I couldn’t use HBO GO, the HD Homerun is the cheapest device I could find that lets me use (and theoretically activate) a CableCard. As such, it pays for itself in about six months. Just don’t expect it to do anything useful.

Daikon Forge

Daikon Forge lets you edit your UI live in the scene editor and preview it in the game view.
Daikon Forge lets you edit your UI live in the scene editor and preview it in the game view.

Progress continues on Project Weasel, and last weekend I bought a license for Daikon Forge ($90 in the Unity Asset Store) after mulling over the Unity GUI situation for over two years (basically since Unity announced its new GUI system in San Francisco in 2011). Like many Unity developers, I’ve been waiting for Unity to fix its execrable GUI library for some time, and had avoided investing in nGUI, Daikon Forge, or Coherent because something better — and free — was coming out real soon now.

I reached the point where not having a functional UI library was blocking progress, so I decided I was going to buy a better UI library — the question was which one? nGUI has been the market leader, but from what I’ve seen the API is pretty terrible (and the fact that the nGUI dev is the guy building the new Unity GUI does not fill me with enthusiasm). Coherent — based on HTML5 — seems like a great idea, but according to reviews I’ve read it consumes quite a bit of CPU on mobile devices (and you’d expect it to, given that web browsers can tax mobile devices). From what I could see, Daikon Forge was the least expensive option and possibly the best (if not as widely supported as nGUI). It’s very well reviewed, including by quite a few nGUI refugees. It also struck me that the Unity GUI would probably be, in effect, an improved nGUI, so I’ll have the best of both worlds once it actually ships.

Anyway, so far I’ve found Daikon Forge is pretty nice but not without issues. But it’s worth noting that all of the weaknesses I’ve seen so far affect the developer and not the delivered product.

(Mostly) Good Stuff

I whipped up a 3d pinned information panel in less than an hour
I whipped up a 3d pinned information panel in less than an hour

To create a user interface with Daikon Forge you use a wizard to set up a “manager”. On the plus side, it works! On the minus side it’s a “wizard” — automatic fail. I’d prefer you to be able to drag a prefab into the scene, or drag a script onto a GameObject, or select a GameObject and pick a menu item. The sad thing is that there’s no reason it can’t work that way. Functionality A. Usability C.

Next, you need to assign a default skin and a default font to the UI gadget. In my opinion it should Just Work without this. (How? Easy — stick a default skin and a default font in a Resources folder and load them on the fly if needed.) This particular bit initially stymied me (the picker didn’t “see” the relevant assets), and I needed to find the relevant components manually and drag them into place. Functionality B. Usability F.

Daikon Forge makes creating and maintaining a UI atlas very easy
Daikon Forge makes creating and maintaining a UI atlas very easy
Using Sketch (this is the old version) you can whip up a UI skin in a matter of minutes
Using a tool like Sketch (this is the old version) you can whip up a UI skin in a matter of minutes

The tools for creating your own skins and fonts are almost brilliant. (Select the assets and pull a menu item — and you can easily add items to and remove items from your UI atlas any time you need to.) Functionality A. Usability B.

Next, you can right-click the UI “gizmo” in the scene editor and add controls to it directly. This also stymied me because the context menu does not work when your inspector panel is in debug mode, which mine happened to be in at the time. (Who knew?) Again, on the plus side it works, on the down side many controls come with idiotic defaults (e.g. huge or dimensionless). Functionality B. Usability C.

So I finally managed to get my Galaxy working so that I could click on a star and have a little information display pin itself to the star and show information like the name and spectral class of the star and how many planets it has orbiting it (and the display is not scaled, renders in a minimum of draw calls, and is pixel perfect, but is pinned to the projected 3d position of the star — very cool). On the downside, I found the documentation for binding values to controls to be incomprehensible, and did it all by brute force. Functionality C (so far). Usability F.

Bad Stuff

Every widget has a lot of properties, and they're not given sensible defaults
Every widget has a lot of properties, and they’re not given sensible defaults

First of all, there’s a big workflow problem. When I first imported Daikon Forge into my project it didn’t work properly (e.g. when I tried to assign a skin to one of Daikon Forge’s UI managers it wouldn’t find the relevant assets). This problem eventually “went away” (no idea why) but it was a sign of things to come.

Second, I keep my project in Dropbox and would work on it from my laptop and desktop at different times. When I switch machines, the other machine would load changed files and Just Work. But after I installed Daikon Forge this process became completely broken. Daikon Forge would become completely broken and need to be reimported whenever I switched machines. Worse, every script component assignment would become detached from its relevant script (only for Daikon Forge scripts) and have to be manually repaired. I don’t have a fix for this except to stop using DropBox, which might not be a Bad Thing.

Third, the documentation is good as a class reference, but bad as a guide/overview/cookbook. The tutorials are good but video only and somewhat lengthy. The examples are good but no substitute for actual documentation. Then there’s the website. To post on the website you need to register, and when I try to register it tells me my username or email address flags me as a spammer and that if I want to fix this I need to reply (how?) or use the contact form (where?). I tried my usual handle (podperson) and my usual email address, and my real name and my gmail address — all spammers apparently.

The WYSIWYG editing of your interface is great as far as it goes, but that’s not far. E.g. there are guides, but nothing snaps to them. There’s a grid but nothing snaps to it. There’s a tool to distribute multiple controls horizontally or vertically, but it doesn’t work properly. Worst of all, simply moving and editing things is very finicky. You can easily get into a state where the transform widget is overlapping some other control (e.g. a sizing handle) so that whenever you try to move a control you actually resize it. I ended up resorting to the keyboard for moving controls, and directly entering values for sizing them most of the time.

In a nut

Daikon Forge delivers on its promises in terms of functionality and performance. It renders user interfaces efficiently and attractively. It’s very easy to create and maintain texture atlases. And it supports scalable fonts. Furthermore, its design leverages idiomatic Unity development (e.g. you can make and reuse prefab controls in the obvious manner.) But it is far from perfect: ironically for a UI building tool, its own UI is spotty to put it charitably. Thus far I’ve found the website to be borderline useless and the documentation weak. I’m not sure if the video tutorials and examples really fill the gap (I haven’t had the time or inclination to watch all the tutorials).

C#’s Belt and Suspenders

In discussing my (fairly minor) annoyances with C# with a colleague, I finally figured out the nub of the problem. C# tries to protect you from certain bugs (overflowing bounds and buffers in particular) in so many different ways that the relevant warnings and fixes become irritations and noise, probably making code less reliable rather than more

E.g. why does assigning a double precision value to a float stop code from compiling? What’s the problem this solves?

Another example, why does moving values from unsigned to signed integer types stop compiles? The main reasons for worrying about integer overflows or getting a negative number when you expect a non-negative number is array bounds checking, but C# has array bounds checking, so why do this at all?

It seems to me that C# ought to treat all numbers with periods or exponents as double precision by default and allow assignment to float with implicit casting. This emphasizes correctness (precision) over performance by default, which is as it should be. Similarly, assigning an int to a uint should simply be allowed. (The compiler can insert code to throw an error if the value is negative if so desired.)

Now, I should say I’m using Unity’s (i.e. Mono’s) C# compiler here, so perhaps Microsoft deals with these annoyances at IDE level (e.g. by offering to automatically fix the relevant problems) in much the same way as Apple has leveraged compiler technology to provide automatic fixes, optimizations, and suggested improvements in XCode.

C# Part II

Galaxy Generated and Rendered in Unity 3D
Galaxy Generated and Rendered in Unity 3D

In the end, it took me four evenings to replicate the functionality in my Javascript prototype. I’d have to point out that I was able to do some really nice UI stuff (e.g. drag to rotate, mousewheel to zoom) in Unity that I hesitated to mess with in Javascript (the galaxy was rendered to a canvas in Javascript).

On the whole, I have some impressions.

First, C# is very strict about types, and while I can see some benefits, I think a lot of it is utterly wasted. E.g. having to constantly cast from one numeric type to another is simply a pain in the butt (I routinely expect to have to tease apart a bunch of cryptic type-related errors every time I compile a few lines of new code).

// given an array of weights, pick an index with corresponding weighted probability,
// e.g. [1,2,3] -> 1/6 chance of 0, 2/6 chance of 2, 3/6 chance of 3
public uint Pick( uint[] weights ){
    int s = 0;
    uint idx;
    foreach( uint w in weights ){
        s += (int)w;
    }
    s = Range (1, s); // returns a random int from 1 to s, inclusive
    for( idx = 0; idx < weights.Length; idx++ ){
        s -= (int)weights[idx];
        if(s <= 0){
            break;
        }
    }
    return idx;
}

And all of this rigor didn’t actually prevent or even help debug an error I ran into with overflowing a uint (I have a utility that picks weighted random numbers, but I overflowed the weights leading to an out-of-bounds error. (A simple fix is to change idx < weights.Length to idx < weights.Length – 1.) On the whole it would be nice if you could simply live in a world of “numbers” (as in Javascript) and only convert explicitly to a specific representation when doing something low level.

Second, there’s this weird restriction on naming classes within a namespace such that the namespace and class sometimes may not match and the class you want is often not in the namespace you expect. (E.g. I wanted to create the namespace LNM.PRNG and define the class PRNG in it, but this confuses the compiler, so I ended up calling the namespace LNM.Random — so code referring to this is “using LNM.Random” which mysteriously causes a class called PRNG to become available.) I don’t see why namespaces and class names can’t be the same.

Oddly enough in some cases I am allowed to name the class the same as the namespace, and I don’t know why. So LNM.Astrophysics implements the Astrophysics class, but I had to rename Badwords to BadwordFilter at some point because the compiler started complaining.

I’ve been using Monodevelop, which is an editor produced by the Mono folk and lightly customized to work with Unity. It’s a bit of a slug (if it’s developed using Mono, then it’s not a terrific advertisement for Mono). In particular, its autocomplete is great when it works, but utterly frustrating far more often. It fails to match obvious words (e.g. local variable names) and often makes it impossible to type something short (which matches something longer) on the first attempt. The autocomplete is darn useful, or I’d simply switch back to Sublime.

Flying my untextured spaceship around an undecorated, partially implemented solar system
Flying my untextured spaceship around an undecorated, partially implemented solar system

So the current reckoning is that I ended up producing the following:

  • Astrophysics.cs — defines the LNM.Astrophysics namespace and implements the Astrophysics utility class, some useful enumerations, and the Galaxy, Star, and Planet classes.
  • PRNG.cs — defines the LNM.Random namespace and implements the PRNG class which provides convenience functions for the Meisui.Random Mersenne Twister implementation I’m using.
  • Badwords.cs — defines the LNM.Badwords namespace and implements the BadwordFilter class which checks to see if any of a pretty comprehensive list of nasty words is present in a given string. (Used to prevent obscene star names from being generated.)
  • Billboard.cs — a Monobehavior that keeps a sprite facing the camera. It’s a little cute in that it tries to save CPU time by only updating a given star every 10 physics updates. There’s probably a better way.
  • FixedCamera.cs — a Monobehavior that implements a mouse/touch controlled camera that keeps a fixed view of a specified target unless explicitly moved. I’m planning on using this as my main view control throughout the game.
  • NewtonianScoutship.cs — a Monobehavior implementing an Asteroids-style player ship. I’ve also experimented with a “Delta Vee” style abstracted Newtonian ship controller but good old rotate and accelerate just feels better, and makes movement a pleasant challenge in and of itself. (It also makes becoming “stationary” in space almost impossible, which I think is a Good Thing.)
  • GalaxyGenerator.cs — a Monobehavior that instantiates a galaxy and renders it with sprites. (Right now every single star is a Draw Call, so I’m going to need to do some optimization at some point.)
  • Starsystem.cs — a Monobehavior that instantiates a Star (and its planets) and renders them, a navigation grid (to provide a sense of movement when passing through empty space) and orbits using a bunch of Prefabs.

So, while I continue to find C# quite tedious to develop with, I am making significant progress for the first time in over a year, and while C# feels much less productive than real Javascript, I do think it’s very competitive with Unityscript, and it’s been quite easy to get over the hump.

C#

Screen shot of my galaxy generator in action
Screen shot of my galaxy generator in action

I’ve been developing stuff with Unity in my spare time for something like eight years (I started at around v1.5). I was initially drawn in by its alleged Javascript support. Indeed, I like Unityscript so much, I defended it vocally against charges that using C# is better, and wrote this article to help others avoid some of my early stumbles. I also contributed significant improvements to JSONParse — although the fact that you need a JSON module for Unityscript tells you something about just how unlike Javascript it really is.

I’m a pretty hardcore Javascript coder these days. I’ve learned several frameworks, written ad unit code that runs pretty much flawlessly on billions of computers every day (or used to — I don’t know what’s going on with my former employers), created a simple framework from scratch, helped develop a second framework from scratch (sorry, can’t link to it yet), built services using node.js and phantom.js, built workflow automation tools in javascript for Adobe Creative Suite and Cheetah 3D, and even written a desktop application with node-webkit.

The problem with Unityscript is that it’s not really Javascript, and the more I use it, the more the differences irk me.

Anyway, one evening in 2012 I wrote a procedural galaxy generator using barebones Javascript. When I say barebones, I mean that I didn’t use any third-party libraries (I’d had a conversation with my esteemed colleague Josiah Ulfers about the awfulness of jQuery’s iterators some time earlier and so I went off on a tangent and implemented my own iteration library for fun that same evening).

Now, this isn’t about the content or knowledge that goes into the star system generator itself. It’s basic physics and astrophysics, a bit of googling for things like the mathematics of log spirals, and finding Knuth’s algorithm for generating gaussian random distributions. Bear in mind that some of this stuff I know by heart, some of it I had googled in an idle moment some time earlier, and some of it I simply looked up on the spot. I’m talking about the time it takes to turn an algorithm into working code.

So the benchmark is: coding the whole thing, from scratch, in one long evening, using Javascript.

Now, the time it took to port it into Unityscript — NaN. Abandoned after two evenings.

I’m about halfway through porting this stuff to C# (in Unity), and so far I’ve devoted part of an afternoon and part of an evening. Now bear in mind that with C# I am using the Mono project’s buggy auto-completing editor, which is probably a slight productivity win versus using a solid text editor with no autocomplete for Javascript (and Unityscript). Also note that I am far from fluent as a C# programmer.

So far here are my impressions of C# versus Javascript.

C#’s data structures and types are a huge pain. Consider this method in my PNRG class (which wraps a MersenneTwister implementation I found somewhere in a far more convenient API):

// return a value in [min,max]
public float RealRange( double min, double max ){
    return (float)(mt.genrand_real1 () * (max - min) + min);
}

I need to cast the double (that results from mt.genrand_real1 ()). What I’d really like to do is pick a floating point format and just use it everywhere, but it’s impossible. Some things talk floats, others talk double, and of course there are uints and ints, which must also be cast to and fro. Now I’m sure there are bugs caused by, for example, passing signed integers into code that expects unsigned, but seriously. It doesn’t help that the Mono compiler generates cryptic error messages (not even telling you, for example, what it is that’s not the right type).

How about some simple data declarations:

Javascript:

var stellarTypes = {
    "O": {
        luminosity: 5E+5,
        color = 'rgb(192,128,255)',
        planets = [0,3]
    },
    ...
};

C#:

public static Dictionary<string, StellarType> stellarTypes = new Dictionary<string, StellarType> {
    {"O", new StellarType(){
        luminosity = 50000F,
        color = new Color(0.75F,0.5F,1.0F),
        minPlanets = 0, 
        maxPlanets = 3
    }},
    ...
};

Off-topic, here’s a handy mnemonic — Oh Be A Fine Girl Kiss Me (Right Now Smack). Although I think that R and N are now referred to as C-R and C-N and have been joined by C-H and C-J so we probably need a replacement.

Note that the C# version requires the StellarType class to be defined appropriately (I could have simply used a dictionary of dictionaries or something, but the declaration gets uglier fast, and it’s pretty damn ugly as it is. I also need use the System.Collections.Generic namespace (that took me a while to figure out — I thought that by using System.Collections I would get System.Collections.Generic for free).

Now I don’t want to pile on C#. I actually like it a lot as a language (although I prefer Objective-C so far). It’s a shame it doesn’t have some obvious syntax sugar (e.g. public static auto or something to avoid typing the same damn type twice) and that its literal notation is so damn ugly.

Another especially annoying declaration pattern is public int foo { get; private set; } — note the lack of terminal semicolon, and the fact that it’s public/private. And note that this should probably be the single most common declaration pattern in C#, so it really should be the easiest one to write. Why not public int foo { get; }? (You shouldn’t need set at all — you have direct internal access to the member.)

I’m also a tad puzzled as to why I can’t declare static variables inside methods (I thought I might be doing it wrong, but this explanation argues it’s a design choice — but I don’t see how a static method variable would or should be different from an instance variable, only scoped to the method. So, instead I’m using private member variables which need to be carefully commented. How is this better?

So in a nutshell, I need to port the following code from Javascript to C#:

  • astrophysics.js — done
  • badwords.js — done; simple code to identify randomly generated names containing bad words and eliminate them
  • iter.js — C# has pretty good built-in iterators (and I don’t need most of the iterators I wrote) so I can likely skip this
  • mersenne_twister — done; replaced this with a different MT implementation in C#; tests written
  • planet.js — I’ve refactored part of this into the Astrophysics module; the rest will be in the Star System generator
  • pnrg.js — done; tests written; actually works better and simpler in C# than Javascript (aside from an hour spent banging my head against weird casting issues)
  • star.js — this is the galaxy generator (it’s actually quite simple) — it basically produces a random collection of stars offset from a log spiral using a gaussian distribution.
  • utils.js — random stuff like a string capitalizer, roman numeral generator, and object-to-HTML renderer; will probably go into Astrophysics or be skipped

Once I’ve gotten the darn thing working, I’ll package up a web demo. (When Unity 5 Pro ships I should be able to put up a pure HTML version, which will bring us full circle.) Eventually it will serve as the content foundation for Project Weasel and possibly a new version of Manta.