If you have to refer to the documentation every time you use a module, find or build a new module

I recently checked out this slide deck called "Python For Humans" by Kenneth Reitz  which takes Python's Http library and rewrites it in a much more intuitive way. (I've used the Python http lib - it's not particularly straight forward). The deck is not really about Python, it's more about good API design. One of the slides says:

If you have to refer to the documentation every time you use a module, find or build a new module

Which I think can be generalised for API designers to 

If you have to refer to the documentation every time you use an API, change the API

This is excellent advice and something I could immediately apply to my own code. Even if you're using an API (rather than writing one), it's worth building an abstraction layer on top of the API you're using if it sucks - Win32 I'm looking at you :) I seem to vaguely remember in Win32 to move a window you have to call a function named ResizeWindow or something equally obscure. Anyway I looked at my own code and made a few changes. In Dancing Squid (my small game engine) my scripting API text alignment functions are called:

Renderer.SetFontAlignmentHorz and Renderer.SetFontAlignmentVert

I could never remember these function names, never - I always had to look them up! Also do you really align a font? Surely it's the text you're aligning?

It just seems a bad name all over. After reading the Kenneth's slides I decided at least this one part of the codebase needed a rename and I went for

Renederer.AlignTextX and Renderer.AlignTextY

Which I find far easier to remember - even as I was coding just now, and came to do some text alignment, I had a brief moment of syntax joy as I knew I'd be able to type out the functions without having to go to the docs or search my code. Good advice, that deep down we all know, but occasionally need reminding about!

Emedding Binary data in an executable

I have a fast little game engine that I've written called Dancing Squid. Recently I thought it would be nice to make it a little more user-friendly and print debug text to the screen of the render window. This way the user wouldn't have to keep looking at the console to see what's gone wrong. It'd also be useful for instrumentation type things like FPS and memory used.

If I 'm going to be rendering out error messages - I need a font but those error messages might include "Font file missing!", what's a programmer to do?

Well the way that immediately springs to mind for me is to embed the binary data in the .exe file directly. Can't lose the font then! (I decided to use silkscreen which has a permissive license and looks nice and minimal)

Here's how it's done using the standard gcc toolset.

ld -r -b binary -o [output_name].o [binary_file_to_embed]

This outputs an object file which can be linked into the exe at compile time. But then how do you reference the data? Well you need to get a special reference keyword and this can be done with another tool.

objdump -x [output_name].o

Which in my case outputs something like:

SYMBOL TABLE:
[  0](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 _binary_[data_id]_start
[  1](sec -1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000480c _binary_[data_id]_size
[  2](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000480c _binary_[data_id]_end

[data_id] is a name generated from the file being embedded. You can then use these names to get your data.

//embed_test.c
#include
#include

extern char binary_[data_id]_start[];

int main(int argc, char* argv[])
{
    char* p = binary_[data_id]_start;
    return 0;
}

Then to compile this:

gcc -o embed_test.exe embed_test.c [output_name].o

And that's fine, I managed to add that into my makefile and everything worked fine.

But I also compile to Android and I'd like this to work there too. Android make file's for C/C++ projects are some non-standard script and you can't add object data :( Somewhere hidden in a maze of different makefile and bashscripts Android uses the same tools, it uses gcc or g++ so it's possible but I didn't feel like trying to untangle all that so I looked for a different approach.

(I did get as far as making the object file for android - this is pretty simple and just requires you to use the arm version of ld that comes with android-ndk)

Second Approach to embedding data in a executable

If that fails - how about whacking the binary data into a header file as an array of bytes (unsigned chars). It's not a hard tool to write but I suspected someone had already written it - and they had; jetro

I ended up using that to generate my header file.

size_t data_len = 18444;
unsigned char data[18444]=
{
    0x00,0x01,0x00,0x00,0x00,0x0F,0x00,0x30,0x00,0x03,0x00,

And there we go - embedded data that works on both windows, android and any other platform that I think to add in the future.

Getting paid as a UK company from America

To get paid by an American company, if you're in the UK, you need an EIN number. If you don't have an EIN number then 30% of your payment gets withheld as a tax in America! You don't want that. I got this number a while back for my company and recently a friend was asking about how to go about getting one. I thought it'd be a good piece of information to share more widely!

In order to get the EIN number you need to get form W-8.  I didn't have to send the form in, I just phoned this number (00)1-267-941-1099 the woman asked me the questions that were on the form, then gave me the EIN number. While on the phone I made it clear the I could speak on behalf of the business. A week or two later they sent confirmation out to my business address. I was able to use the EIN number immediately.

The guys on the end of the phone obviously deal with people from the UK phoning up about this number all the time - so they can easily guide you through it all.

When filling the form in, there's a PDF of instructions for filling it in here: http://www.irs.gov/pub/irs-pdf/iss4.pdf which I missed initially! The W8 form itself is available here: http://www.irs.gov/pub/irs-pdf/fw8ben.pdf

I found this thread quite helpful when I was researching how everything worked:  https://www.createspace.com/en/community/thread/17723

C# for Game Development

I recently had an email asking how C# stands up as a game development language these days. I thought that was quite an interesting question; I'm very optimistic for the future of C# as a game dev language. Here's a cleaned-up version of my full reply.

Since I wrote the book C# Game Programming; the the landscape has changed; Tao has been renamed http://www.opentk.com/ now and XNA support has been dropped by Microsoft (just like they dropped the original C# bindings for DirectX, I can imagine it being deeply frustrating for people who have spent time learning the API. There's a story here: http://www.wpcentral.com/xna-dead-long-live-xna . Though, of course, XNA games will still work for sometime yet, just there will be no updates.)

On the growth side; game engines like Unity use C# and have become really prominent in the games industry. Sony has recently released the PlayStation Mobile Suite for indies to develop on Vita (and other mobile devices), that's also C#. It's great to see that C# has now become quite a viable language for console and mobile development. 

Unity games are released on all sorts of platforms - the games can definitely be competitive with handcrafted C engines ( http://www.interstellarmarines.com/media-section/ ). It has excellent support and resources but it's a closed platform, it too could go the way of XNA one day (though I don't think that's particularly likely anytime soon). There's monogame, an opensource version of XNA, as well but I haven't looked at it. Overall since a year ago C# has become a more popular language for game development.

C# is very fast, enough for a blockbuster type game. The code that really needs - down to the hardware fast - has slowly been migrating from the CPU to the GPU and is all handled through shaders. The language used for the gameplay code is becoming less about speed and more about ease of expression for the developer. A lot of big name games use scripting languages to run the game logic - Lua is popular and that's much slower than C# (but far easier to embed in C programs and very portable) 

If I was starting a new game project today - I'd use Unity, unless it was 2d, then I might have a look around and see if there's anything more suitable - moai? The general way 2d games are made in Unity involves setting everything up in 3d space and it seems a bit of a faff to me, though it can allow for some nice effects.

My main issue with C# and Tao/OpenTK is deployment - it's fine if you write an installer but if you just want to throw someone an exe to try it out - then you need to make sure they have the correct version of C# installed and send them all the relevant dlls. It wasn't particularly easy for a non-technical user to get everything running.  In my current projects deployment is something I try and make as smooth as possible. Unity does this very well because of it's webplayer - there's no barrier to overcome for the player, they just have to click a link and they're in the game!

Overall I think the future is looking quite bright for C#, it's not the perfect language but it's pretty good. I think it suffers the same disease as C++, each release adds some more features, more keywords and it makes the language less elegant, clean and easier to intuit. Despite growing in complexity I think it has quite a good future in games until multicores CPU's become more and more prevalent and we need something that can handle parallel programming better.