Recently in Games Development Category

This is a crosspost from (

Recently, a university undergraduate asked me on twitter for advice on becoming a graphics programmer within the games industry. I wrote a fairly detailed email response and thought the information was good enough to make an article for AltDevBlogADay. This is all my personal opinion of course.

If you’re at university, you should research whether there’s a programme to do a summer or year long internship at a games studio. There was nothing like that when I was at the University of Liverpool ’97-’00 (or I wasn’t aware of it), but I’ve seen people come through that kind of programme with much greater practical game development knowledge and it goes a long way towards persuading an employer to take you on. EA, Lionhead and other large companies tend to run this sort of programme so look on their job pages too. Beware that sometimes companies don’t respond to intern applications for various reasons (team is deep in crunch, budget spent elsewhere, etc) and places are extremely limited.

Your best bet is to make a graphics demo, either on your own or with a small group of people. You learn more by doing than by just reading. Pick a modern graphics technique that interests you and implement it. Even better, do more than one. This is also great training for motivating yourself to get a project finished which is often the hardest part of games development, for all disciplines. Make sure you’re prepared to talk in detail about the choices you made, performance (in milliseconds, not frames per second!), quality, alternatives and trade offs in a job interview.

When I was in university I did a straight computer science course - there were barely any games courses available back then, but I still think that employers still value computer science graduates above games graduates as there’s a perception that you learn a greater range of software engineering skills. This could be a misconception though, as games courses are a lot better than they used to be, but you may have to fight your corner in an interview and prove you know your stuff (and not just the curriculum you were taught).

Computer science courses also tend to be quite maths heavy (I would hope games courses are similar), which is vital for graphics programming. Make sure you understand homogeneous coordinates, matrix maths, dot products, cross products, quaternions, normal vectors, tangent bases, etc and how these things (and countless others) are useful for transforming and lighting geometry. Learn big O notation for algorithmic execution time, understand colour spaces, gamma correction, what high dynamic range means and so on. Learn some basic lighting models - Lambert, Phong, Blinn, etc.


In my experience, Visual Studio is pretty much universal as a code IDE (except for Apple, Linux, Android and Nintendo games), though you can of course use your favourite editor if you really want to, as long as you know Visual Studio. There is a free Express edition available from Microsoft (, so it won’t cost you any money to learn. The PS3 is a little different as there is a separate hardware specific debugger, but you should be able to learn that on the job.

You should be familiar with a source control system. Perforce ( is a good choice as a lot of game studios use it and it’s free for single users. Try to learn it on a project with other people as merging, branching and integration are good skills to have. With all source control systems, similar concepts apply so it’s essential knowledge to have. Shockingly, my university course never mentioned source control and I was naive enough to believe that people just shared code over the network or on floppy disks.

As you’re unlikely to have access to devkits at home or in university, you’ll most likely be learning your skills on PC. In what may come as a surprise from someone with a decade’s game development experience, I don’t know much OpenGL as there’s never been a pressing need for me to learn it. Most PC games use DirectX, though if you learn DirectX 11, make sure you also learn DirectX 9 as it’s still current for Xbox 360 and many PC games still use it to support the dwindling, but still large Windows XP market. DirectX 10 is completely superseded by DirectX 11, so it is not worth learning (you can write DirectX 11 games for DirectX 10 hardware, and even DirectX 9 hardware).

It’s also definitely worth learning a graphical debugger. PIX for Windows isn’t as good as the Xbox 360 version, but there are fantastic free alternatives (Intel GPA -, Nvidia Parallel Nsight - These tools are not just for performance tuning on the GPU - they’re also for debugging your draw calls, working out why something doesn’t draw, why it looks wrong, and so on. You can also learn about how a GPU works as you can see all the renderstates, shaders, meshes, textures, etc for any draw call in a frame and really understand what the GPU is actually doing with the data you give it.

Other Duties

As a graphics coder you’ll probably have to do some tools work too, working with mesh compilers, animation compilers, plugins for Maya/3DS Max or in-house editors for the artists to use. Remember that your job is to provide technology to support the artists in their daily work, so it needs to be presented in a friendly manner. If you give your art team a tool that lets them tweak some coefficients of a fancy rendering algorithm and they have no idea what the numbers mean, they probably won’t use it. Also, technical artists are your friends - they’re the best people to talk about requirements for artists and to work out the best workflow for the content creators.

It’s also good to learn general performance and optimisation techniques as this often falls to the graphics/engine team to do. You probably won’t have to write any (or very little) raw assembler, but you ought to be familiar with what the C/C++ compiler is doing to your code, how to spot problems and what to do about them. For example, one of the biggest performance problem will be L2 cache misses (you lose hundreds of cycles per miss on all modern hardware), so learn techniques to reduce them (almost always changing the data, not the code is the fix).

Online Learning Resources

Online resources are a goldmine, and there’s much better stuff out there than there was when I was at university as a lot of companies publish papers on their techniques which are pretty useful stuff. A few examples…

Also there are a few good blogs posting regularly about graphics. A few good examples… - Lost in the Triangles. Aras Pranckevičius’s blog (a lead programmer for Unity). - Real Time Rendering has good information (also the book is a worthwhile read!) - Another good graphics programming blog.

Make sure you read the relevant presentations from GDC (very useful) and SIGGRAPH (slightly less useful as a lot of it is for non-realtime graphics, but useful as a crystal ball for future techniques).

My last handy tip is that if you live near a big dev studio, find out which pub they go drinking at after work and join in on a Friday night. You’ll learn a lot just chatting with developers. You can also join twitter and talk to many games developers there who are willing to share their experience.

Keyboard Question MarkAs I said at the end of my last post, I was going to write an article listing all the little handy utilities/settings that make my life easier as a programmer, but in a change in schedule I've decided to postpone that and write about something I've been coding this week instead whilst it's still fresh in my mind.

As I'm writing my own engine, one of the first things that needs to be done is input processing. In the latest DirectX SDK, there are two options listed for input, namely DirectInput8 and XInput. DirectInput8 is long in the tooth, being over a decade old and has localisation issues as I'll discuss below. XInput is newer and is a cleaner API, but seems to exist entirely for using Xbox 360 controllers (presumably as an aid to porting) and supports nothing else. Neither seemed to be an ideal solution to me.

Twitter to the Rescue

I asked about this on Twitter and got a few replies suggesting I use the Raw Input API which I wasn't previously aware of. Richard Sim pointed me to this MSDN articlecomparing the APIs (in this case the example is reading mouse input). As you can see, the code for using Raw Input is a lot cleaner and simpler than DirectInput8. The article also says that DirectInput8 is built on top of the Raw Input API and uses a separate thread to capture the WM_INPUT messages, adding overhead in the process. It felt to me that using Raw Input directly was the better solution.

Using Raw Input

The MSDN documentation for the Raw Input API is missing a few things which I've had to dig around and find out for myself, so I'll explain what I've found out here. The basic process is that in your initialisation code you register the devices you'd like input from using RegisterRawInputDevices(), and then you receive WM_INPUT messages from the device in the Windows message loop from which you extract the actual keys/mouse input/etc. If you want to register for input from the keyboard, you would use the following code.

RAWINPUTDEVICE keyboard_device;
keyboard_device.usUsagePage = 0x01;
keyboard_device.usUsage = 0x06;
keyboard_device.hwndTarget = hWnd;
keyboard_device.dwFlags = 0;

BOOL ret = RegisterRawInputDevices(&keyboard_device, 1, sizeof(RAWINPUTDEVICE));

The question is - where on Earth do those UsagePage and Usage numbers come from? The MSDN documentation doesn't explain, but after a bit of digging I found out that they're part of the USB HID standard (pdf). On page 26 is table 1 for generic desktop devices, and the keyboard is device number 6, hence the numbers passed to the code above. For the mouse you would use page 1, usage 2. In fact, the Raw Input API lets you register multiple device at once as shown here.

RAWINPUTDEVICE keyboard_and_mouse_devices[2];
keyboard_and_mouse_devices[0].usUsagePage = 0x01; // Generic desktop page
keyboard_and_mouse_devices[0].usUsage = 0x06;     // Keyboard
keyboard_and_mouse_devices[0].hwndTarget = hWnd;
keyboard_and_mouse_devices[0].dwFlags = 0;
keyboard_and_mouse_devices[1].usUsagePage = 0x01; // Generic desktop page
keyboard_and_mouse_devices[1].usUsage = 0x02;     // Mouse
keyboard_and_mouse_devices[1].hwndTarget = hWnd;
keyboard_and_mouse_devices[1].dwFlags = 0;

BOOL ret = RegisterRawInputDevices(keyboard_and_mouse_devices, 2, sizeof(RAWINPUTDEVICE));

I have no idea why the API insists you pass the size of the RAWINPUTDEVICE struct as the final parameter, though it seems to be a common trait for Win32 API functions.

I think the MSDN docs explain actually getting the data well enough, so I won't repeat that here.

Once your application is registered to recieve WM_INPUT messages, it will also receive WM_INPUT_DEVICE_CHANGE messages whenever a device is added/removed from the system so you can print up "Controller Removed" messages, or switch to an alternate controller as your game requires.

Wrapping Up

I mentioned above that DirectInput8 has localisation issues. What I mean by this is that often in games you need to show the name of the key on screen in control select screens or tutorials. To do this you would use GetKeyNameText() which will return a string from a scan code. Unfortunately, DirectInput8 uses its own DIK_ enums for the keys, which don't exactly map onto scan codes. On previous games I've worked on, we've ended up with a large remapping table, with a few exceptions for various locales. The Raw Input API gives you the scan code directly as well as the virtual VK_ enum, so in theory this problem disappears (I still need to confirm this).

This is a crosspost from AltDevBlogADay - 

This is a crosspost from AltDevBlogADay -

Greetings all! For my first post I thought I'd start with something I've been thinking about lately. As I'm preparing to leave "AAA" games development and become a fledgling indie, I need to set up my home office for maximum productivity and comfort. I don't have a facilities department to handle all of this for me, so here's my tips for comfort based on my experiences. I'll leave out the actual PC/Mac hardware itself and focus more on the ergonomic aspect of things. This article isn't meant to be authoritative (how could it be without reams of ergonomic data?) so I've avoided recommending specific products, but the general point is that you should try out a few things until you find what works best for you.

Chair - First and foremost, you need a good chair. I can't stress this enough after having lower back pain from working on a bad office chair a few years ago. If you can afford it (and have space in your home office), get an Aeron or whatever your favourite type of chair is. A really good chair may cost a lot at first, but you'll be sitting, slouching and wheeling around on it for a long time so it's a worthwhile investment. It's not something to skimp on. Make sure you take the type of chair for a test run (test sit?) if possible. A few seconds sat on one in a shop really isn't enough. If you know someone who has the chair you're thinking of buying, ask if you can spend an hour or so working on it to see how it works for you (although you may irritate them if you change the settings too much!). Last of all, make sure you're really happy with your choice before handing over your money.

I'm typing this article sat on a solid wooden Ikea Ivar borrowed from the dining room which is far from ideal, so I need to sort out a proper chair sooner rather than later!

Desk - A desk is easier to sort out. It just needs to be the right height (or adjustable) and big enough to put everything you want on it. Also it needs no obstructions underneath for your knees to accidentally bash against. I'm using an Ikea Galant which is a nice corner desk that fits nicely in the room I'm using, has adjustable height legs, is pretty strong (it is no problem for me to sit on it) and it is easily big enough for all the desktop equipment I need. Make sure you have measurements of the room you're going to use before buying so you can eliminate anything that won't fit quickly.

Monitor(s) and Light - A monitor should be big, bright, comfortable to read, well calibrated and more than one if possible. Make sure the height is set up so you don't strain your neck as you look at it. I'm counting light as part of this category as I think it is intrinsically linked to how well your monitor works for you. I like there to be a good level of ambient light in the room to avoid eye-strain from the monitors, but make sure the light is out of your field of vision or it will irritate you in your peripheral zone. Other people I've worked with (mostly artists and older coders), seem to have a preference for working in the dark - though I find that odd as it hurts my eyes after a while. I can (sort of) understand that way of working in the bad old days of curved, highly reflective CRT monitors as darkness would minimise reflections, but these days I think that is minimal. However, it is of course up to you how you light your room - whatever works best for you is most important.

Keyboard - You're going to need something you can type on for hours without causing pain to your wrists. Ideally you want your hands and forearms fairly flat on the desk and not bent upwards so your wrists aren't strained. Ergonomic, straight - it's up to you, but find something that works for you and doesn't cause pain after extended use. Also, you need to find a keyboard that has a key feel you like (how much travel, how "clicky" it is), sounds right (not too loud, not too quiet). Some keyboards also have extra buttons mimicking browser navigation, application shortcuts, volume control, etc. How useful these features are is debatable (I quite like having volume/mute buttons), but once again what works for you is best.

Mouse - Likewise, find something that fits your hand well, has all the buttons you need (mine is right hand shaped with two handy thumb buttons) and slides about the desk smoothly. Optical mice are all very good these days in terms of ability to read surfaces accurately so unless your desk is made of glass, you shouldn't need a mouse mat. Alternatively, you might be someone who prefers a pad, trackball or other pointing device - I only have limited experience with these so comments below welcome! I've recently bought a Wacom Bamboo pad and am getting used to using a pen as a pointing device (as well as for drawing lines and curves).

Headphones - As I'll be working in a house with two young children around, I'll need a way to block out the distraction of their noise whilst they are playing, so a good, comfortable set of headphones is important to me. Find some that don't hurt your ears and have good sound quality (I find cheap tinny sound tends to irritate after a while). Noise cancelling is an option, though on the ones I've tried, sound quality seems flatter (perhaps that's just me though).

Space - An odd thing to include, but I find that when I'm stuck on a problem, I like to pace back on forth whilst my brain is working on a solution. It's something I've deliberately refrained from at big companies as being watched by an office full of people stops my thought processes, but I do it at home (to the chagrin of my wife). Having an area you can do this without driving the people who live with you insane is probably a good idea!

I'd love comments on this article from people with suggestions of your own. For my next article, I plan to look at the software side of things - those little utilities that make my life as a programmer easier and more productive.

About this Archive

This page is an archive of recent entries in the Games Development category.

Games is the previous category.

Guildford is the next category.

Find recent content on the main index or look in the archives to find all content.