Phantom Lapboard – still alive

It’s been as while since I reported on Phantom Entertainment (nee Infinium Labs) and I though I’d check up on them as I haven’t seen the Lapboard reported on it a while. It’s seems they are still alive, though barely. After an initial rush of somewhat positive reviews in the media, the Lapboard seems well received by those it is targeting – online gamers who sit withing 10 ft of the TV. Definitely not a data-entry design, but apparently suitable for the target audience. Personally I’d like to see a few improvements to make it a bit more general purpose – say for those of us who’d use it for HTPC’s and big-screen web-surfing. YMMV. You can check it out yourself here.

Update: It’s always nice to get a response, and I got one from the Phantom CEO, John Landino (see comment below). I’ve edited the article to reflect some corrections he was gracious enough to share with me. The original subtitle was “still barely alive”, but after a year on Amazon they have over a dozen reviews, so being in business 4+ years and getting sold on Amazon amongst other places they are doing better than I thought.

Posted in Infinium | 2 Comments

Working with C++0X: Lambdas – part 2 – Scope Capture

Since a lambda is a local function defined with a scope (i.e. inside another function) it can have access to the same variables that are in that scope. This is where the capture-mode comes in. (Perversely, this prevents lambdas from working with templates, since templates have to be defined in a global scope.) The takeaway idea here is this;

Variables that are specified in the capture-clause are specified when the lambda is created. Think of these like values passed into the constructor of a functor.

Variables that are specified in the parameter-list are passed in as an argument – that is – when the lambda is called. Think of these as the parameters passed in with operator() of a functor. Thus you have the options of capturing state when the lambda is created (unique to lambdas) or when it is called (just like any other C++ function).

In addition to that, you have the option of passing parameters in by value or by reference, and either at declaration time (lambdas only) or invocation time (like any other C++ function). This is the power of lambdas, something that a lot of other languages don’t have – the ability for C++ lambdas to have effects on an outside scope.

This not only allows you to use lambdas as local functions, but also to create lambdas that encapsulate state. This is useful for creating closures – where a function accesses a variable outside it’s scope – something I’ll talk about in the next installment. For now, let’s cover the capture syntax and how it works.

Let’s go over some scope access samples

// inside some function...
   int n = 5, m = 6; // we have some variables
   // let's define some lambdas
   []{ n; }; // error - no capture mode defined, can't access "n";
   [=]{ n; m; }; // OK - n & m are accessible by value
   [n](){ n; m; }; // error - n is accessible, m is not
   [=]{ n++; }; // error - n is const
   [&n]{ n++; }; // OK - n is passed by reference
   [=]() mutable { n++; }; // OK - parameters are mutable

Before we examine this in more detail, we first need to be able to execute the lambda. Remember a lambda is like a local function, so we have defined lambdas, but we need a way to invoke them whenever we want. You can invoke them in place by adding an parameter list after defining them, or you can get a function pointer to them and invoke them later on. Let’s do the latter;

auto myLambda = []() throw() -> void {}(); 

So here we’re defining a pointer to our lambda function and we’re using the auto declaration since we don’t know or care what the exact declaration is. “myLambda” is the pointer to the function.

So let’s look at the last lambda statement from the previous sample in more detail and let’s give it a name, then we’ll call it a few times and see how the scoped variables behave.

  int n = 5, m=6
  auto myLambda = // capture it's address - we're getting a function pointer here
  // define the lambda
  [n,&m] // we capture n by value, m by reference
  () mutable  // no parameters are passed in & can modify non-ref variables locally
  {
	 n++; // post-increment
	 m++; // post-increment
}; 

// at this point n=5, m=6;
myLambda(); // inside the lambda, both get incremented
// at this point n=5, m=7;
myLambda(); // inside the lambda, both get incremented
// at this point n=5, m=8;

By default, the parameters passed in are const and can’t be modified in the lambda body. Thus the use of the mutable modifier. You can see how the capture-by-value & capture-by-reference syntax let us modify the local value or the scoped-one. While it’s nice to be able to create local function right where they are needed, I think the real power in lambdas lies in using them as closures, encapsulating (i.e. capturing and hiding) some bit of state for use later – using them this way is called a closure and will the the topic of my next C++0x blog.

Posted in C++0X, Code, Uncategorized | Leave a comment

Working with C++0x: Lambdas – part 1- Syntax

Lambdas are new to C++0x and if you are familiar with functors then you already have a good idea of how lambdas can be used. Where lambdas really become useful (in my opinion) are allowing you to encapsulate behavior (as a local function) and encapsulate state (as closures). Once you get used to these ideas it gets easier and easier to see instances where you can simplify your code by using lambdas. But we need to crawl before we can walk so let’s start off with some basics. Lambdas in C++ add a lot of power over other language’s versions (Java and C#) because they allow you to not only capture state but to affect state as well. So let’s jump in. The simplest valid lambda expression is the following;

[]{}; // in some scope, not global. Valid C++0x code

The [] is the lambda-introducer, which tells the compiler that a lambda expression is beginning. It’s also where you can specify the capture-clause, which is the kind of scope-capture you want to use as the default for the lambda. Here it’s empty, so there is no default scope. The {} is the compound-statement, which is the actual local function that you are defining, which uses the variables at the scope that the introducer defined or the parameters passed into the lambda. In this case it’s just an empty function.

There are a lot of modifiers for a lambda, and if you wanted to have all the bells and whistles specified you could write something like this;

// the simplest lambda with all the parts exposed, also valid C++0x code
[=]() mutable throw() -> void {}(); 

The [=] specifies that the default capture mode is by value. The default [] is to capture nothing. [&] means the default is capture by reference.
The first ( ) specifies the parameter-declaration-list, which are the const pass-by-value variable and/or by-reference declarations.
Since parameters that are pass-by-value are const, there’s an “mutable” keyword that undoes the const-ness of those parameters.
The second ( ) following the throw is the type of exception that this lambda can throw – the default is none.
The -> is the return-type-clause, the default return is of type void. This is only necessary if the return type isn’t obvious.
The { } defines an lambda body – in this case it’s an empty function.
The last parenthesis at the end are the actual parameters if you wanted to create an instance of the lambda and call it with those parameters. In other words this actually creates a lambda and calls it with those parameters. I just include it for completeness and to totally weird you out with the syntax. It’s legal but usually you’d see that in some stl container iterator implementation where you’re declaring and invoking the lambda in one go.

There are three basic parts to a lambda – the block that describes the scope of the various parameters, the block that describes the return signature of the lambda, and finally the actual compound statement that makes of the lambda body.

In actual use it’s a bit cleaner. Usually there will be the introducer with a capture clause and the compound statement, which is just the lambda (i.e. function) body. The capture scope is where you get a lot of the power of lambdas – plus a lot of opportunity to mess things up if you don’t understand scope capture. That’s what I’ll cover next time.

Posted in C++0X, Code | Leave a comment

Seamus Blackley to leave Creative Artists Agency

Seamus Blackley is leaving Creative Artists Agency after eight years. He’s reported to be planning to launch his own production company to develop games. Seamus was one of the original creators of the Xbox. While he was at CAA they negotiated deals for famous names like BioShock creative lead Ken Levine and Flower devs thatgamecompany, and helped ex-Infinity Ward heads Vince Zampella and Jason West get new gigs. Reuters recently ran an article about how CAA is thinking of opening a Silicon Valley office in order to be closer to some of the major tech firms.

Posted in Ex-Microsoft, Game Industry | Leave a comment

Working with C++0x: nullptr and nullptr_t

One my pet peeves with C/C++ are null pointers – specifically not having a good way of specifying a special pointer value that means “invalid pointer”. C (and C++) have a preprocessor macro NULL, which in C expands to either (void*)0 or 0. C++ is different has NULL defined to 0. Zero is a fine representation of an invalid pointer value, but it has nothing inherently invalid it, it can still be used as an address. What nullptr as a keyword brings to the table is the ability to unambiguously inform the compiler and the running code that this pointer isn’t valid.

But another interesting thing is that nullptr is a keyword, and not a type. It’s a what, a keyword? If this doesn’t seem like a great thing, look at it this way; If you have a bool, and want to check its value it will be either true of false. true and false are keywords. And now we have a keyword for “invalid pointer”. Get it now? If a pointer value is nullptr it’s null and pointing at something invalid. It’s also strongly typed so that will aid in disambiguating from non-null pointers in addition to other types. What’s nullptr’s type? It’s of type nullptr_t. Looking back to our bool example, the keywords “true” and “false” are of type bool, and the keyword “nullptr” is of type nullptr_t. This also allows you to use it (for example) in a function definition to catch those instances when a nullptr instead of something else a pointer could be converted to is passed in.

So if you have various function prototypes…

void Foo(long a) { cout << "Foo(long)" << endl; }
void Foo(int a) { cout << "Foo(int)" << endl; }
void Foo(char *a) { cout << "Foo(char*)" << endl; }
void Foo(void* a) { cout << "Foo(void*)" << endl; }
void Foo(nullptr_t a) { cout << "Foo(nullptr_t)" << endl; }

Foo((void*)0); // Foo(void*)
Foo(0); // Foo(int)
Foo(5.5f); // Foo(float) if it’s defined else Foo(int)
//    but usually you’ll get a conversion warning
Foo(NULL); // Foo(int) or Foo(long) on some machines – depends on how NULL is defined
Foo(nullptr); // Foo(nullptr_t) if it’s defined, else Foo(char*)

In some instances you’ll get a compiler warning about an ambiguous overloaded call. nullptr isn’t yet in all C++ compilers, but it will be soon. nullptr’s are a great addition to C++ that made pointer handling much easier.

Posted in C++0X, Code | Leave a comment

Working with C++0x: static_assert and decltype

I have been writing a lot of code the last few months, and I’ve had a chance to play with some of the new C++0x features. It’s really the first time in many years that there’s been a significant improvement to the language. I thought I’d take a few blog entries and work through some of the new features, because unless you’ve already had experience with some of them in other languages you might not fully understand the power that is behind some of the features.

The first one I’m going to talk about is called static assertions. I assume you are familiar with the assert macro in debug mode. There’s also the #error preprocessor command. Static assertions on the other hand are compile time tests. They give you the ability to essentially make compile time assertions in your code. One nice feature is that it works with templated expressions as well. If the conditional can be evaluated at compile time then the compiler will immediately evaluate the conditional For a template assertion, the test is performed when a template is instantiated, just like the assert macro, if the condition evaluates to true, nothing is done. If however the condition is false then the compiler will raise an error and post the error message that is part of the static assert. For example;

static_assert ( 1+1 == 3 , "one plus one does not equal three");

For example, you might have code compiles for both 32-bit and 64-bit and you might need to make assertions;

static_assert(8 == sizeof(void*),  "Not valid for 32-bit code");
static_assert(4 == sizeof(void*),  "64-bit code generation has not been tested");

Or, as I recently have been doing, you’re writing out binary files that have to run on a variety of operating systems and architectures, and you don’t want any nasty surprises when you start running on different systems.

static_assert(4 == sizeof(int) ,   "ints aren’t 32 bits in size");

A recent post in AltDevBlogADay by Michael Tedder <Trivial Constructors and Destructors in C++> talked about creating POD data (Plain old data – i.e. data that has no virtual function tables, exceptions, etc. that is, data that is just that – data and no dangling functionality hanging off it) If you are creating an allocator for POD objects, it’s possible to check for this at compile time.


#include <type_traits> 

template <class TYPE >
class Allocator{
    static_assert(std::is_pod>TYPE&rt;::value, "Template argument must be a POD");
};

class pod
{
};

class not_pod
{
virtual ~not_pod(){} ; //  the offending non-POD part
};
...
Allocator<int>  v1; // works
Allocator<pod> v2; // works
Allocator<not_pod>  v3; // static asserts
...

It just takes some creativity to figure out how to assert that what you want, and then it’s in your code forever, tested every time you compile. As you can see, I am a firm believer in letting computers do as much of the work as possible. In this case, it’s possible to let the compiler check my assertions for me. With the rapidly changing pace of both target architecture and operating system that we have today in the games industry an ounce of prevention is worth a whole lot more than a pound of cure.

Posted in C++0X, Code | Leave a comment

Otto Berkes – the last Xbox founder – leaves Microsoft

Way back when I was writing my OpenGL Book, I had the good fortune to run across some stupendous folks at Microsoft who were forthright and open and very very helpful to me, answering questions, implementation details, and generally reviewing a lot of my work. One of these guys was Otto Berkes. Later the API wars would put him and most of the other OpenGL team onto the DirectX team (which is one reason it suddenly jumped in quality between releases),  and eventually he went on with Seamus Blackley, Kevin Bachus, and Ted Hase to be the core Xbox team. He’s the last one to leave Microsoft, and I wish him all the best.

Posted in DirectX, Ex-Microsoft, OpenGL, PC Graphics | Leave a comment

Blog – take 2

So, a few months after updating my website to be more of a blog format ( since that’s what it was anyway), I managed to enter setting in WordPress confuse it utterly and leave it unusable. Much to my surprise, my web provider does not backup content, just e-mail, at my subscription level. Fortunately, I was able to recover most of the content, and I finally sat down, re-created my blog format in WordPress, and am re-posting all of the content from before the unfortunate event. What a pain in the ass. I hope you guys enjoy it!

Posted in Miscellaneous | Leave a comment