Perhaps the best known open source hardware is Arduino, who make a number of small development boards based on the AVR microcontrollers (and have just announced last week new boards based on the more powerful AVR32 and ARM Cortex M3 microcontrollers), and a complete development environment for them – all free of course. The Arduino’s are aimed at people with little to no experience in electronics (or even programming); designers, artists, and anyone else who wants to tinker. Under the hood their development environment compiles C/C++ code, but the specifics of the language are hidden from users; but there’s nothing stopping advanced users going right to the compiler.
There’s nothing in itself extraordinary about the Arduino, but what sets it apart from the competition is the hardware that others have made available to interface with it, both open and closed source. Arduino boards have standardized footprints, that allow for daughter boards (‘shields’ in Arduino terminology) to connect up easily. What this means for the user is they can get an Arduino board, a few shields for things like Bluetooth connectivity, motor control, or even the ability to make or receive phone calls through a cellular network. Of course you are also free to develop your own shields, or anything else – it doesn’t have to fit the standard footprints at all, just have the ability to connect to the Arduino board’s exposed headers (connectors).
Open source hardware isn’t limited to the Arduino and the shields that go with it, and you can pretty much find any kind of sensor available on an open source interface board for ease of use and prototyping. This is very useful since the vast majority of modern sensors and other devices that you may be interested in trying out are very, very small and hard to work with without proper equipment. While it’s not impossible, it’s definitely a barrier that a lot of beginners find daunting, so having something easier to get started with is a big help in getting stuff done.

The Arduino is so well received that Google even chose it as the base for its reference design for the Android Open Accessory Development Kit. This opens the Android system up to being able to interface with nearly any kind of sensor or feedback mechanism around, so the possibilities for what can be done with input (or output) from an Android game are endless! There are two gotcha’s with the Accessory Development Kit however; unfortunately it’s limited to Android 2.3.4+, and the accessory must be a USB host. The last point especially limits the portability of any potential accessories due to the requirement of all USB hosts to provide 5V and 500mA. While this isn’t impossible to do in a portable accessory, it will add considerable bulk to any device for the battery capacity required to get any kind of acceptable battery life. The former point has a solution at least, not to use the ADK! SparkFun make a board called the IOIO, which similarly to the ADK works via acting as a USB host device, that will work with Android devices running Android 1.5 or above (though they admit it could be incompatible with some devices, since they haven’t tested it with a huge variety).

So, the Arduino is what you need – now what? The great thing about experimenting with hardware is that it can be really simple, and fun! The very first hardware I remember making as a kid (I can’t have been more than 10, and was probably a lot younger) was a pressure pad – and all it consisted of was a couple of bits of cardboard with aluminium foil on, separated by a ring of foam core. You pressed on the top and the two pieces of aluminium foil made contact inside to close the circuit (i.e. the switch was ‘turned on’). Of course, this was long before you could order cool arcade buttons and joysticks over the Internet, so you may want to forgo the cardboard and glue and go straight for real buttons these days. While not as fun, you sure can’t beat their reliability!

If this all sounds cool but you’re not sure where to start, Instructables can be a great source for inspiration, ideas, and plans. How about Hooking up a treadmill to a PC game, a Mega DPDT tank-style switch, a Mobile dance stage, Hacking EEG toys, Laser tag, Making your own SNES controller, or an Android-controlled ball maze? And those don’t even touch on applications of some of the cool sensors you can get. What fun can you have with a game based around an alcohol sensor at your next party?

Here are a few of my favourite suppliers to get you started:

• SparkFun
• Adafruit
• Seeed Studio
• Maker SHED

This was originally posted on Technofumbles, which may have better formatting for the tables; if the layout is too messed up here, try the original post.

I haven’t been able to test every algorithm I wanted to get to yet (new and old), and only have PC results to show so far – but am releasing the source so it can be extended as people desire. See the end of the post for a download link. Future algorithms on my list to add to the test suite are ZLib, lzham, LZMA, and a few variants there of.

UPDATE April 24, 2011: LZ4 has been open-sourced, so I’ve added it to the test suite and updated the results. Charts have also been added to make comparison easier.

The test data I chose came mainly from the DirectX SDK samples, with a few files that were kicking around my hard drive for good measure. Highly scientific! I hope to do more realistic tests soon!

Tests were performed on a low-end Core2 Duo laptop. Without further delays, here’s the numbers.

Summary Results:

Compression Ratio (click to enlarge):

Compression Time (click to enlarge):

Compression Time, Zoomed (click to enlarge):

Decompression Time (click to enlarge):

Decompression Time, Zoomed (click to enlarge):

Summary Results:

Compression Details:

Decompression Details:

Current source can be grabbed here (mostly platform-agnostic test suite library with a C# GUI and C++/CLI for interop):
GitHub: https://github.com/richard-sim/Compression-Test-Suite
Zipped: http://technofumbles.com/files/CompressionTest.zip

Pixel Quads and Pixie Dust

A few days ago an artist asked me for information on specular behaviour for materials, to which I sent him a link to the post Everything is Shiny over on the excellent Filmic Games blog. While browsing the site, he came across the post Where are my sub-pixel triangles???, which discusses performance issues arising from small triangles in meshes. Amazed that he’d never heard of such issues he came back and asked me if it really was true – and it is. It’s just never really discussed beyond the programming tracks at GDC, Gamefest, and so on. By the time it gets to artists it probably has been reduced to "make sure there are LODs", with not further details on what this means or why they need to exist. After all, LODs just reduce the vertex count – that couldn’t possibly affect the pixel shading performance! Right? It turns out that this is absolutely incorrect, and LODs have in fact a dramatic affect on pixel shading performance.

What. The. Hell. Yeah, it sounds odd. Your LOD is half the vertex count of the full-resolution mesh but still takes up exactly the same number of pixels on screen as the full mesh at the same distance from the camera, however the pixel shading performance of the full mesh is much lower than that of the LOD?! This is because there is a trade-off in the hardware between the size of triangles and pixel shader performance. The trade-off varies between hardware, and in some cases can be very extreme, but it never doesn’t exist.

Being a hardware trade-off this does mean that I have to explain a bit about how the hardware works when a triangle is rendered.

The process of rendering a mesh goes something like this:

Vertex processing (vertex shader) -> MAGIC –> Pixel processing (pixel shader)

What is the MAGIC step? That depends on the platform, but the general formula is that each triangle is broken into 2×2 blocks of pixels called quads, and then some (potentially large) number of quads are run through the pixel shader at once. As the X360 has a lot of great documentation on this publicly available from Gamefest, let’s take that as an example (the PS3 isn’t all that different anyway).

Putting this together, we get:

Vertex processing –> Triangles –> Quads -> 16-Quads –> Pixel processing

This might start to ring alarm bells as to why small triangles are expensive. To take the worst-case that you have a single 1 pixel triangle, for that single pixel you might as well be executing the pixel shader 64 (2*2*16) times! If you have 64 single-pixel triangles so there are enough quads generated to fill a full pixel vector, you will still at best have 25% pixel shading efficiency due to the 2×2 quads. To put this another way, the lighting, texture filtering, and all-round shiny-awesomeness of the pixels could be FOUR times as complex if we avoid these cases. There’s nothing that anybody but the artist creating the mesh can do about this either (other than a programmer running some ugly automatic decimation algorithm on the mesh in the pipeline, which I’ve never seen any artist happy about – for good reason). You won’t be able to make a perfect mesh, but it’s important to make a good one.

This can be distilled down to a simple ratio for easy comparison: vertex to pixel quad density. Ask a rendering programmer to show you how to figure this out for your art, or see the presentations listed in the References section at the end of this post.

A few other random stats pulled from various Gamefest presentations:

• Triangles that cover 2×2 pixels waste 60% or more of the pixel shading performance
• Going from 2×2 pixel triangles to 4×4 can increase the pixel shading performance by 33%

Overdraw Overload

The cost of overdraw is proportional to the speed at which memory can be written to of the platform and the size of the screen. It may come as a surprise to many, but the PS2 actually performed better in this area than the X360 and PS3 (or even most modern PC graphics cards). As such, overdraw is actually quite significantly more expensive for this generation of consoles than it was for the previous (at least, on the PS2). We are saved somewhat by more flexible hardware with optimizations to fight the cost of overdraw, but those unfortunately don’t help when the overdraw consists of alpha-blended geometry (particles are obviously the worst for this).

So uh… that’s about it – overdraw is still a terrible problem for alpha-blended geometry, so try to reduce the number of layers of overdraw as much as possible.

Light, Shadow and Their Dark Interactions

Low-angle light directions are the enemy of efficient shadows, as they require far more objects to be classified as casting shadows for a frame than otherwise. The easiest way to look at this is that the length of the shadow that an object casts directly relates to how expensive it will be to be shadowed. This isn’t about the actual cost of calculating the shadow for the particular object, but about the cost to include it in the shadow calculations because the longer a shadow than an object can cast, the further outside of the current cameras view it must still be evaluated since it could be casting a shadow over something that is visible to the camera.

It doesn’t help that these low-angle light directions make for the most interesting lighting environments of course, so a compromise will probably have to be reached between the art and programming teams.

Death by Draw Calls

Everyone hates unnecessary bookkeeping; it’s red tape in the way of getting things done, and pulls you away from what you really want to be doing. Generally speaking, if you have different materials (shaders, textures, lighting values, etc.) applied to different parts of a mesh, it will have to be split up by the engine and each piece rendered individually. When you have multiple meshes on multiple objects split into multiple parts, you’re cutting down the amount of useful work that the GPU and engine can do as it’s having to do a lot of bookkeeping instead.

Try to use texture pages wherever possible, UV some parts of a mesh to a black part of the specular texture rather than a separate material with no specular, and weld together any meshes that can be.

Summary

This is about half of the items that I wanted to cover in this post, so it’ll definitely be covered further in my next blog post. But for now that should be plenty to chew on, and certainly covers a lot of the bigger issues affecting performance of art.

References

Technical Art Reviews: Getting the Most Out of your Content, Cameron Egbert, Gamefest 2010
PIX for Artists, Alan Murphy, Gamefest 2010
Xbox Textures – Formats, Conversion, Fetching, and Performance, David Cook and Jason Gould, Gamefest 2008
Xbox 360 Shaders and Performance: How Not to Upset the GPU, Cody Pritchard, Gamefest 2010
Building an Über-Fast Crowd Renderer for Your Next Xbox 360 Engine, Tomas Vykruta, Gamefest 2010
Past Gamefest Presentations

This was originally posted on my blog, Technofumbles.

This is the reason I ask about hobbies and personal projects of those who I interview and those for whom I interview with (interviews go both ways remember!). It’s not something I ask because I want to know if you’ll be my buddy, even though that is very important factor in selecting coworkers in my opinion, but because it is one of the most clear indicators of a curious and active mind – and that trait is very important. An engineering team with curious and active minds is the cornerstone of a solid development process. They are the ones who will be the most forward-looking, identifying the potential pitfalls ahead and working to avoid them now, because they’re thinking. They will be versatile, because they’re used to it. They will actively improve the codebase, systems and procedures, because they want to work somewhere that they enjoy what they work with.
Great work is not achieved by punching a clock, and someone who is curious will work on the problem because they want to solve it. This isn’t to say that I like curious coworkers because they do lots of overtime – my opinion on overtime is not positive at all – quite the opposite in fact. I don’t really care the hours you do if you’re doing a great job in that time and not slacking off. The unfortunate reality of the games industry is that you will be doing overtime, and that overtime will make up for any short days taken. If you’re making no progress on a problem I’d much rather see my team take off early and relax than sit around bored and frustrated – then when the solution finally comes you’ll be fresh and happy to work hard on doing a great job rather than burnt out and doing just a good job.

Of course that isn’t to say that if you don’t have any personal projects on the go that you don’t have a curious and active mind, only that it’s an a clear indicator in an interview; I know plenty of great engineers who don’t fit this profile, and there’s nothing wrong with that. There will be things that you’ll miss out on though, because often there isn’t time in the schedule to bring someone up to speed on a new area, meaning that if you don’t already know it, you won’t get the opportunity to learn. This isn’t for any malicious reason; it’s simply the reality of schedules.

There’s no reason that a personal project has to be directly related to your daily work. If it was, that’d be little more than homework. Not much fun there if that’s all you do. For instance, my personal projects are usually a mix of embedded (electronics and low-level programming), Android (mobile programming and OpenGL), and the occasional work-related R&D. What counts is that you’re pushing yourself to learn, and having fun doing it.

Originally posted to Technofumbles.

Ok, now that you know you’re in for a lot of monotonous text, let’s get on with it!

Gamma correct rendering may sound like a simple enough concept at first, but to do it correctly can be very challenging – especially once you throw hardware variations into the mix. Possibly worse yet is that it is something you must keep in mind throughout development, and educate your teammates about. Or you ignore the issue completely and live with the consequences, but it will come around to bite you down the road. Repeatedly.

First some definitions:

• <Gamma/sRGB/Linear> space
  The curve of raw data values to represented values for the data that you’re working with (could by bytes, floats, or rgb triple). Linear is easy as it’s an exact match. Gamma and sRGB on the other hand are not identical, and instead define a curve that gives more raw data values to the lower ranges of the represented values compared to the higher ranges. For the purpose of this post, we’ll call gamma and sRGB the same thing (though they aren’t necessarily this way, as sRGB refers to a very specific curve, while gamma can be anything).
• To gamma a texture/value
  To convert from linear space to gamma space. This will result in raw linear values (the same as their represented values) of 0.2 going to raw gamma values of ~0.5 (but still representing 0.2). The exact values depend on the curve of the gamma space that you convert to of course.
• To degamma a texture/value
  The opposite of the above; to convert from gamma space to linear space by applying the inverse of the gamma curve. So, with the above example you would get back the original linear raw value of 0.2 from the gamma value ~0.5.

So what does it really take to be gamma correct? There are 3 primary areas of concern: the pipeline, the shader, and the render target.

The Pipeline and Tools

• Some of the source data that you’re given will be in gamma space, and other source data will be in linear space. The pipeline has to know what it has, and what it should do with it. Easier said than done, as this requires meta data to be present – either artist-set or automatically-set based on usage. Having artists specify what everything should be interpreted as is obviously the easiest choice when faced with having to shoehorn gamma correct behaviour into an existing pipeline without the backend architecture to support it, but does carry with it the consequence that user-errors will be abundant.
• If you’re going to perform any processing on textures in the pipeline (resizing, mipmap generation, blending the edges of cubemap faces, etc), the operations must be done in linear space. The gotcha with this is that you must operate with as much precision as possible throughout this process to avoid issues with quantization due to the conversion to linear space and back again. This usually means converting to a floating point texture immediately, and only converting back as the very last step. Yes, and you’ll probably have issues achieving this with some of the external libraries you use. So go and modify them too (and diverge from what’s in SVN, making taking updates all that much harder). Fun stuff.
• The final conversion to gamma space after you’ve done your processing may also bite you due to hardware variations. If you’re lucky you’ll only be targeting platforms that have proper support for sRGB – but many are not so lucky and as such will be in for a world of fiddly pain thanks to . But at least it’s documented now, which has only happened in the last couple of years. Extremely fun stuff.

The Shader

• Everything you do in a shader should be in linear space. Simple.
• There are states that you can set on the various platforms to automatically convert textures when sampled from gamma space to linear space, but these states do live in different places for different platforms.

The Render Target

• The joys of hardware variations will strike you severely here, and throw a spanner (wrench for those of North American heritage) in the works.
• Frame buffers are usually stored in gamma space and you output linear space values from the pixel shader. Thus, blending the output of the pixel shader with the frame buffer can be done in linear space (correct) or gamma space (incorrect) depending on the platform. DX9 and the PS3 will do it incorrectly, but DX10+ and the X360 will do it correctly.

Here’s a spoiler: not everything should be gamma corrected at every step. But what does that mean? Why is that? Well, that’s exactly what this post is about!

Continued at Intuition for Gamma Correct Rendering at TechnoFumbles…