I wish this brief overview had been available when I first got my TX2, for how to rebuild a kernel and flash it.
Adafruit has some cool, bendable LED strips. You can buy up to 4 meters of them in a continuous strip, with 30, 60, or 144 LEDs per meter. You send the color to each of the LEDs as 24-bit RGB, using a serial bus (single-ended SPI) and a simple protocol.
The protocol for these DotStar LEDs wasn't documented, so I had to figure it out from the sample code. It's pretty easy:
The kind folks at DFRobot sent me a sample of their "Nova Basic Kit" to test out.
When building code you port from Linux (or other GCC based systems) to Visual Studio, you may run into the Microsoft standard C library not containing a definition for strtoll(), which converts from a C string to a long long, 64-bit integer value.
error C3861: 'strtoll': identifier not found
A joystick is a nice input device for certain kinds of games, like flight simulators, space games, etc. A mini-version of the joystick is the gamepad, ubiquitous in console games.
Orignal post 2011-06-10:
In various web APIs, there is some confusion between the representation of a hash value.
There exists APIs where a password is validated as, say, MD5(challenge + MD5(salt + password)).
Let's leave aside the fact that MD5 is not a secure algorithm anymore (you can procedurally generate an input that generates any MD5 hash value you want in cheap-to-compute time).
I used to do serialization using all kinds of fancy templates and macros. You can create pretty elegant systems that way. However, at some point, simplicity should win out. Here's a system that might work just fine for you:
A simple packet class, which really is all you need:
class packet { public: packet() : pos_(0) {} void append(void const *data, size_t size) {
I recently have answered several questions about how to structure a networking library such that it can be easy to use for users of the library and/or when expanding the game you're writing. Here are some thoughts on that. (Code examples in C++)
Networking generally ends up needing to do three things:
1) Mirror state updates from one object to another.
2) Request remote services ("RPC").
#include "etwork/etwork.h" #include "etwork/buffer.h" #include "etwork/errors.h" #include "etwork/notify.h" #include "etwork/marshal.h" #include <assert.h> #include <stdio.h> #include <string> #include <math.h> #if defined( NDEBUG ) #pragma warning( disable: 4101 ) // unreferenced local variable #endif void TestEtworkCreate() { EtworkSettings es;
A simple command-line program that exercises parts of the Etwork API and asserts if something fails. Think of it as an API acceptance test.