Squanderlings

This weekend I helped kick off a new podcast called...

Mon, 07 Nov 2011 10:48:58 -0800

This weekend I helped kick off a new podcast called Thu’umcast, a gameplay diary about our adventures in Skyrim, which is released on 11/11/11. Since the game isn’t out yet, I quizzed the other cohosts on The Elder Scrolls.. for points.

The main website is at http://www.jarober.com/thuumcast/

There you can find links to the iTunes subscription, facebook, twitter and send us feedback via email.

Why I hate glOrtho and all its offspring

Fri, 30 Sep 2011 18:30:00 -0700

In case you’re not familiar with the glOrtho function from OpenGL, it constructs and stores in to the active matrix a “parallel” projection matrix that is orthogonal to the screen. The function looks harmless enough:

glOrtho(left, right, bottom, top, near, far);

But the devil is in the details. The details are right here by the way, oh and also over at Microsoft’s version.. we’ll come back to Microsoft’s version shortly.

A typical call to this function might look like this:

glOrtho(0, 640, 0, 480, -1, 1);

Usually, the values 640 and 480 are replaced with the actual size of your window or widget. Let’s take a side step for a moment and upgrade to OpenGL 3.2 and ditch glOrtho and instead of glm:ortho<float>. This is an identical function and the matrix is still the same. In case you didn’t follow the link to the documentation to see the matrix, here it is:

(*image belongs to Microsoft)

So my gripe with this function is the way in which near and far are treated. Imagine we have just set up our ortho matrix and we have a near of -1 and a far of 1. Theoretically, if you wanted to put something close to the viewer on the screen, you’d want to put it nearer the near value, right? so you’d put it at -1. Oh my, have I expected near to mean near and failed miserably? Why yes, yes I have.

You see, the matrix described here actually flips the signedness of the near and far values. You can see it in the matrix above with the -2 instead of a 2. Why? Heaven knows, you’d have to dredge up the history of 3d rendering and go back to the teapot designers to find out why it was done this way. The downshot is that if you want to put something near the viewer, you have to give it a value near the far value.

Confused? You should be. It gets worse. If, for some reason, you went to the Microsoft webpage on glOrtho you would be still scratching your head. You see, the two pages differ ever so slightly in one crucial sentence:

Microsoft: “The far parameter specifies the location of the far clipping plane.”

Khronos.org: “-far specifies the location of the far clipping plane.”

Microsoft makes the rookie mistake I made years back when I first encountered this function, that far means far and near means near. Only the authors of the opengl spec get this right. Someone at Microsoft didn’t copy and paste, or perhaps thought that pesky little ‘-’ was a typo. Either way, it’s not unreasonable for someone new to opengl to rage a little on this particular matrix.

So why rant about it now? Because I fell for it -again-. AGAIN.. after all these years and knowing full well how stupid this little function is, I fell for it again when I dumbly assumed it would behave more sanely in glm::ortho. I found a curious bit of code in my renderer that had near and far back to front and I couldn’t figure out why. After toying with it a while I finally figured it out and that is what sent me straight to the blog to write some abusive words about this matrix.

Hey ortho matrix, go back to negative space where you belong!

Code coverage for Xtreams using StasisField to detect what has...

Wed, 14 Sep 2011 13:45:24 -0700

Code coverage for Xtreams using StasisField to detect what has and hasn’t been called in the image. StasisField is an experimental code-coverage technique that unloads code from the image and dynamically reloads it back in to the image when a method is called. It requires no changes to the VM and once a method has been resumed, there is no further cost to the code-coverage mechanism, making it one of the most efficient techniques for reducing runtime memory and for measure code-coverage.

C++ references are not good members

Fri, 19 Aug 2011 09:30:33 -0700

As a Smalltalk programmer, I tend to like things to be uniform. The idea of sometimes using . and sometimes using -> irritates me, so I tend to prefer using . as much as possible. As such, I just learnt a valuable lesson in the C++ world about when not to inflict my own biases on the code.

References; they’re great. They let me stay consistently dotted, rather than arrowed. Instead of writing a function like:
myFunction(const someclass* somevariable) { somevariable->doStuff(); }

I can write the function like this:
myFunction(const someclass& somevariable) { somevariable.doStuff(); }

Now, technically this is not what references are about. The two methods are in fact equivalent. However, the details are in the nuts and bolts here. That reference to somevariable is a hard-link back to the original variable. Changing its state or calling functions on it are the same in both versions, but -assigning- to the variable is different in each version.

Assigning to the argument of a function is rare, so when does this matter? Well, it matters when you start trying to use references as members of a class. Consider the following class:
class newclass {
someclass& somemember;
newclass(const someclass& somemember_) : somemember(somemember_) {}
};

The somemember variable must be initialized, because it is a reference. But now that we have it initialized, any attempt to assign to this member will not set what somemember is, but instead copy-replace its contents with the contents of the new object. Wherever somemember came from, we’re not changing its state - breaking encapsulation in one of the most wildest and dangerous ways.

So in this case, you have no choice but to either declare it inline (in which case newclass contains it entirely which might not be possible) or to declare it as a pointer. If you declare it as a pointer, which is the right thing to do, now you can no longer use . and instead have to use ->

Any and all methods you have previously written using . will have to be re-written using -> …this is incredibly annoying. An object you talk to with . in one place is talked to with -> in another place, which is inconsistent and infuriating. But, that’s the C++ language for you.

So, why is it that the dot operator doesn’t do what -> does? After all, there are -no- messages you can send to a pointer. Oh wait, yes there are.. operators. [] and + and - and a few others can all act on pointers; which means that if . worked like -> then . would be inconsistent with the other operators. However, I think, IMHO, that that is irrelevant; because no named member or function can exist on a pointer, only on the instance itself.

Oh well, may be in another 10 years C++ will have this sorted out. Somehow I doubt it. Until then, we must continue playing the . -> dancing game.

Hijack window events

Mon, 08 Aug 2011 10:25:46 -0700

Today I was fiddling around with events on Windows and I wanted to see if it would be possible to steal any and all events from a window, without having to define a new class. This is something that is relatively easy to do in a windowing system with DOM-Event like objects, where you can listen for an event and tell it to stop propagating right at the top of the tree. However, VisualWorks events don’t work like that; they’ve always been very object-message-centric, not “announcement”-centric.

So, typically, you would define a new controller and implement the methods on it that you wanted to handle the different events and set that controller on a window. But, what if you didn’t want to make a new class just for that? What if you wanted to just -script- it?

I came up with this little ploy today. In it, I take the focused window, grab mouse events and then capture the events in that window so that I can handle them in a block. I like blocks.

| window eventDispatcher eventHandler |
window := Screen default focusedWindow.
eventDispatcher := window eventDispatcher.
eventHandler := PushButton new.
eventHandler eventReactions initialize.
(eventHandler eventReactions reactionFor: #Button1Up)
addDefaultAction: [:event |
Transcript cr; nextPutAll: ‘ungrabbing mouse’.
eventDispatcher ungrabMouseEventFor: eventHandler].
(eventHandler eventReactions reactionFor: #MouseMoved)
addDefaultAction: [:event |
Transcript cr; nextPutAll: ‘mouse moved: ‘; print: event point].
Transcript cr; nextPutAll: ‘grabbing mouse’.
eventDispatcher grabMouseEventFor: eventHandler.

This is made possible because of the ongoing work to implement Skinny in VisualWorks 7.9. The eventReactions is part of an effort to modernize the widgets; in this case by implementing nice state machines. Here, we create a push button and hijack its state machine with #initialize to reset it, then set up our button and movement callbacks.

Unfortunately we can only do this for mouse events so far. The EventDispatcher has special code to “reroute” mouse events if the window is “grabbed”. Keyboard events head to the KeyboardProcessor, not to a currentKeyboardConsumer. The same goes for events like window resizing, etc.

May be in the future…

C++11 on OSX is a Mess!

Mon, 25 Jul 2011 12:21:25 -0700

GCC 4.6 cannot compile Objective C programs on OSX if you’re linking to Cocoa, because you end up trying to compile NSTask which uses Apple’s “Blocks” syntax, (return type)(^block name)(arguments…).

Apple GCC 4.2.1 cannot compile C++11 programs on OSX because it doesn’t support C++11.

Clang++ can compile -some- C++11 programs on OSX, and can compile Apple’s “Blocks” syntax, but does not currently have support for C++ Lambdas. Luckily they have implemented auto, which is probably the biggest win in C++11 out of all the new syntax features.

You can of course statically link GCC 4.6 libstdc++ and libgcc in to your program and make a self contained distributable program, but you’re then unable to dynamically link to anything at all, because the ABI is different.

I’m not sure what the deal is with distributing clang compiled programs yet; is libc++ standard on Lion? If it’s not, then you’re stuck with the same distribution program as GCC 4.6.

In case you didn’t know, you should give up on hoping for a newer version of GCC on OSX; everything after 4.2.2 is GPLv3 and Apple won’t touch it with a ten foot pole. That’s why they’ve been investing in LLVM and Clang.

Welcome to episode 20 of “That Podcast: An FNV...

Tue, 19 Jul 2011 22:33:00 -0700

Welcome to episode 20 of “That Podcast: An FNV Diary” - a podcast where Michael Lucas-Smith and James Robertson document our trials and tribulations in Fallout: New Vegas.

On today’s podcast, Michael and James give their first impressions of “Old World Blues” - the latest DLC for Fallout: New Vegas. So far - it’s a big thumbs up!.

(read more)

Time to play with C++11

Mon, 18 Jul 2011 19:04:08 -0700

This is possibly the worst time to experiment with gcc 4.6 on OSX. Lion is about to be released any day now, so I’ll have to completely redo the gcc install via macports once I’ve upgraded. Oh well.

But, curiosity was getting the better of me. After all, we’re talking about Closures here, in C++.. hell froze over or something because this just shouldn’t happen. Will Apple fix change their closure syntax to match? make grand central compatible with std::bind and std::function? Only time will tell.

So here is my prelim. report on using C++11 on Snow Leopard. I used macports to install gcc46 and that went very smoothly, although it took quite a while to compile. One of the neat things about this version of gcc is the automatic vectorizing of arrays where it can figure out how to do that. Neat. I wonder if I’ll ever notice.

My test program utilized two of the three features I’m most interested in with C++11. Lambda and Auto. The third is the for(:) range syntax, I’m sure I’ll get to it eventually.

#include <functional>

int main(void) {
auto f = [] (unsigned char b) { return b - 1; };
return f(1);
}

Some things to note here. Auto really does do its job, the actual type of the lambda is this: std::function<unsigned char (unsigned char)> which is yet another templated mouthful which would otherwise make C++11 a miserable failure. But, auto to the rescue — this may actually make programming in C++ …nice?

The next thing of note here is how I didn’t specify a return type for the lambda, but it worked anyway. It appears that the return type of the lambda is automatically inferred; I assume if it cannot infer it it’ll throw some obscure unintelligible error.

The compilation line I used was this:
g++-mp-4.6 -std=c++0x test.cpp -o test

There are a few things to note here. Make sure you remember to use g++ instead of gcc, or it’ll try and compile it without the C++ libraries present and all heck will break loose.

Another important point here is that gcc 4.6 does not compile with C++11 activated by default; so you must specify which standard you’re using via the -std=c++0x parameter. If you fail to do either of these two steps, you will get the usual gibberish template error messages from gcc that only google can understand.

By the way, thanks google and stack overflow for eventually pointing me in the right directions to compile this ridiculously simple program correctly.

They claim that C++11 feels like a whole new language. I have to agree; apart from having closures, this auto type is miraculous for C++, especially with templates. It’s practically civilized.. may be that’s going a little too far. But, at least C++ gets a taste of functional and dynamic programming for a change. It’s been far too long without it.

Finally, I find it interesting that gcc hasn’t shipped with std::thread yet; which is probably one of the biggest wins of the C++11 standard library and therefore equally as notable that it’s missing.

Polycephaly finds new home in Xtreams-Grid

Mon, 11 Jul 2011 16:40:00 -0700

When I first proposed Polycephaly to Arden Thomas, the product manager, and wrangled Martin Kobetic in to help me; I was unsure if we were really going to help our customers solve real world problems with it or not. Polycephaly, meaning “Many Heads” is a framework like Squeak’s Hydra. It lets you run multiple Smalltalk Images simultaneously, with one image controlling the “drones”. Ironically, the drones run headless, so despite it being called Many Heads it really should have been called Many Headlesses.

To our delight, customers started emailing in with reports of its usefulness in their development and production environments. We also got a lot of feedback too. Polycephaly used stdin/stdout to communicate over pipes between the master and drone. Any customer code that just so happened to write out to Stdout or read from Stdin would break Polycephaly.

Customers found it very useful to spawn 3-5 extra images and give them work to better utilize their multi-core machines. But they also wanted to do the same over the network. And so, Polycephaly-NetworkVirtualMachine was published by Holger Kleinsorgen.

Another criticism was how VirtualMachines worked; specifically it was not useful as a load balancer. So Runar Jordahl blogged about his solution, which round-robin’d “jobs” to different VirtualMachine instances.

Meanwhile, I was somewhat unimpressed with the inability for a drone to respond in a streaming fashion back to the master; or for the master to supply job objects in a stream either. This meant that as soon as a drone had completed its job, it would typically lock up in communication with the master through BOSS.

So, the technical debt on Polycephaly finally reached a turning point when a review was written on the VWNC mailing list and I was resolved to fix the problems. And what luck, I had an engineering trip planned to travel to Ottawa where two of my colleagues live, and then to Victoria (Vancouver Isle.) where another one of my colleagues live. It just so happens that these colleagues could help me and face to face time is invaluable.

I present to you Xtreams-Grid, a VisualWorks and ObjectStudio solution for working with multiple images on your local machine and across a network. Here is the features list when compared with Polycephaly:

Remove drones and remote masters. Drones can be activated via inetd style, or be pre-configured. Drones can connect to a pre-determined master, or be listening for a master(s) to connect.
Sockets instead of Pipes, no more Stdin/Stdout breaking the system.
Streaming results and arguments to-and-fro. The stream is now multiplexed too, with high through-put using the Xtreams-Multiplexer protocol.
VirtualMachines now acts as a load balancer with a “job” style API and can easily be used with #promise.
When starting a VirtualMachine locally, you can specify a different image to use and/or a different virtual machine executable.
Xtreams-Grid has actual documentation, where Polycephaly was still a work-in-progress and had none.
If you have the Xtreams parcels available (they will be updated in VisualWorks 7.9 at some point in the nearish future); an image no longer has to be saved, the Xtreams drone script will auto-load Xtreams-Grid and its prerequisites on start up.

It also has a much more sensible name. Every one knows what grid computing is and typically looks up ‘grid’ when trying to find it. Polycephaly, while having a very unique name that is highly recognizable, was always a bit of a tongue in cheek job. You can consider it as a past-tense code name at this point.

The API of Xtreams-Grid is very similar to Polycephaly, though not 100% the same. There’s no #timeout:do: method any more, since you can use [] onTimeout: aDuration do: aBlock. VirtualMachines is a complete rewrite and the #do:environment: API is gone completely.

There are new tricks up its sleeve though. Consider, for a moment, this peculiar little example:

evens := machine do: [ :odds | odds collecting: [ :e | e + 1 ] ] with: (1 to: 9) reading.

In this case, we are streaming in odd numbers to the drone and the drone will increment each element in the stream by one, then stream the results back out to the master. The master can leisurely read results, only taxing the drone as required.

As well as this, the drone can consume multiple streams as arguments from the master. It does not need to consume each argument stream in full; since underneath the hood is the Xtreams-Multiplexer protocol, which works similarly to the SSH2 multiplexing protocol.

There is lots to explore here. There are tests which demonstrate some of these capabilities, as well as updated documentation at http://code.google.com/p/xtreams. Or, more specifically: http://code.google.com/p/xtreams/wiki/Grid

The latest version of XtreamsDevelopment as of this writing is 526.

Generators for Xtreams

Tue, 05 Jul 2011 12:49:00 -0700

While at Smalltalk Solutions 2011 in Las Vegas, a question was raised about Generators. Martin and I had no idea what Generators were, so we filed that one away for “later pontification”. Well, that later came this week when Nicolas Cellier posted about using generators and Xtreams to compute primes.

One criticism Nicolas raised was the lack of Generators in Xtreams. We wanted to understand what Generators were and why they needed to manipulate the stack to work. In the end, we decided it’s actually faster and easier to implement them using a second process and a couple of semaphores. Also, more portable.

So what do generators do? Well, possibly the simplest example is this:

1 to: 10 do: [:i | …do something…]

In this case, you cannot easily transform it in to a stream using [] reading, because you get stuck inside the iteration block, controlled by the #to:do: method. A generator allows you to push out elements piece-meal regardless of the nature of the code you’re running, eg:

readStream := [:out | 1 to: 10 do: [:i | out put: i ] ] reading

The block will begin running immediately, but as soon as it tries to write out a value on to the @out variable, it will halt execution until you attempt to read from @readStream. This makes it possible for Nicolas to re-write his example as:

primes := [:out | Integer primesUpTo: 100 do: [:prime | out put: prime ] ] reading.

Note that @out is actually a write stream, so you can use all the regular streaming API on it too, such as #write: instead of a single element #put:.

The last part of this story isn’t to do with generators at all, but about using buffers to make non-positionable information positionable. In the case of Nicolas’s primes, he wanted the last element on the stream. You can’t “skip to end, rewind one, read last element” on a non-positionable stream. But you can on a positionable stream.

The default buffer of a positionable stream is endless though, so it will record everything, allowing you to rewind right back to the start. In this case, that’s a complete waste. We also only produce one element at a time, because it’s coming from a generator. So, we can use a RingBuffer of size 1 as the buffer for positioning.

(primes positioning buffer: (RingBuffer new: 1 class: Array))
-= 1;
get

This is where the positioning API of Xtreams really becomes handy. We use #-= which means “From the end of the stream, rewind ‘n’ elements”. Now that we have a positioning buffer that always remembers the last element, we can skip to the end and rewind by one element and then call #get to fetch it.

The [:out | ] reading generator terminal is available in XtreamsDevelopment 508.

Maki and I take you on an update tour of our fortress in...

Sun, 03 Jul 2011 21:43:39 -0700

Maki and I take you on an update tour of our fortress in Minecraft, now updated to 1.7.2 with pistons. We’re in the process of automating much our farming now that it is possible.

Xtreams 492 Update: Marshaling and Multiplexing

Sun, 19 Jun 2011 12:20:00 -0700

It’s not often I get to write a change log for an “add-on” library. Usually things move incrementally toward the original goals. But with Xtreams, sometimes we add new things, or improve old things.

Xtreams changes from v472 to v492:

#write:from:at: and #insert:from:at: now consistently return an Integer. This mirrors #read:into:at: which already returned an Integer consistently.
Added #buffering: to WriteStream, which buffers up all writes in to it, until it hits the buffer size, at which point it flushes the contents down to its destination. You can send #flush to force the contents out immediately, if you’re working with a particular protocol. This is useful when dealing with protocols that don’t internally buffer (which is most of Xtreams).
Included Xtreams-IRC in XtreamsDevelopment. The XtreamsDevelopment bundle is not something you should ever prerequisite. But it is a convenient way to pull everything in. We’ve decided to include applications of Xtreams in to the XtreamsDevelopment bundle. Yes, I have my eye on you StoMP.
Hub is removed from Xtreams-Xperiments.
#multiplexing is removed from Xtreams-Xperiments
Stitch(Read/Write)Stream can be instantiated from the class side with a semi-private API of #on:contentsSpecies: which avoids the default behavior of stitch streams, which always pre-fetch the very first substream to stitch.
Added #monitoring:every: to (Read/Write)Stream, which allows you to measure the through-put on a stream. This is particularly useful when transferring files and other large data across a network.
ObjectMarshaler will now marshal/unmarshal/analyse very large integers. Previously this was a #notYetImplemented method. The format is inefficient, but integers that large are by their very nature inefficient.
ObjectMarshaler will now create light-weight shadow classes for classes that do not exist when unmarshaling objects. The classes are full subclasses of Object with getters/setters created on them for their instance variable names.
Xtreams-Multiplexer package added, which contains the previously implemented #multiplexing and Hub behavior. It now has a sliding ChannelWindow to avoid stream saturation for unread data. As well as being promoted from Xperiments, it now has tests.

* Items in bold represent new behavior / API.

It's a travel day...

Tue, 14 Jun 2011 18:15:00 -0700

Ha ha Canada. I get it, Michael is on his way so well stage a strike in the one random airport he has a connection in. Calgary, of all places. If I get my luggage I will be amazed, but now I’ll be getting in to Ottawa at 1am. Oh and let’s not forget the aircraft I was on required an airstart - that happens when the engine can’t start itself anymore! That flight was delayed I’m arriving and so is my next flight. I’ll get there eventually.

Quantities in VisualWorks

Tue, 07 Jun 2011 07:32:45 -0700

In VisualWorks we’ve had a few arbitrary limits in Timestamp and Duration. Timestamp stops at milliseconds and there’s a need to go down to nanoseconds there for interfaces to Oracle and other databases. Duration is fixed to nanoseconds as of VW7.8 which covers the majority of short time period computations. But ultimately, we’d rather not have to go through a 10^-9 -> 10^-12 migration sometime next release.

So instead, we’re making Duration and Timestamp hold on to seconds at an arbitrary scale. Now, that’s not actually what this post is about; but it’s tangential. As part of the effort to “get this right” I wanted to understand the right way to internally represent Duration; as whatever we do there we’ll be replicating in Timestamp. I’d rather not get two classes wrong in VisualWorks 7.9.

To understand it better, I took a step back to look at the entire problem of representing quantities or measurements in Smalltalk and other programming languages. So let’s start with the best of breed for static languages: Boost.Units — now, I know some of you will jump out of your seats in fury and rage at this point because I’m not talking about your favourite functional language. Trust me when I say I understand and I’m sorry you just broke your favourite chair.

Boost.Units is a C++ library that provides a zero-runtime overhead for representing units in your C++ program. This is, honestly, a fantastic addition to the C++ language and should be in the base. If only they could get their compilation errors to make sense I’m sure we’d all be using it. After all, if a developer starts programming with inches in mind and accidentally collaborates with anyone outside of the USA, they’ll be combining centimetres with inches and bam, you crash your Mars satellite.

It’ll slow down your compilation time, but at least your program will be correct! This is one of the few times where types do not get in your way and save you a lot of time and (especially in the case of NASA) money.

On to the next best of breed — Measurements in the Cincom Public Repository. This library comes from two people, the first is Travis Griggs who is my colleague here at Cincom. The second is Ken Greene. Now I’m mentioning their names, particularly Ken, here because they came up with a way of representing units at runtime that has very low overhead on arithmetic operations. We’ll come back to what this is later in the post.

So with these two great examples of units and quantities to go off of, I set about trying different variations for describing quantities in VisualWorks generically. I wanted to allow it to blend with the existing (and future) implementation of Duration. I *really* wanted to know if there is any design impact on Duration that I need to know about now before I go and change its implementation in VisualWorks 7.9.

After going through many iterations, I ended up with a design using the same trick as Measurements, but with more capabilities, such as instantiating Duration when dealing with the Time dimension. Or instantiating an Angle when you’re dealing with radians, degrees and gradians. There is of course the Temperature class too - but I won’t bore you with the details of that one.

Because we’re creating and destroying objects constantly if we’re doing tight loop arithmetics on quantities, we need to make sure the implementation is only being dragged down by a lack of stack-allocation in an otherwise very smart virtual machine.

This is where Ken Greene comes in to the picture. When you multiply two quantities together, you also need to multiply the units together, eg: 5 seconds * 5 metres = 25 metres.seconds — to do this, each base unit is given a prime number. Derived units, such as metres.seconds are an integer that is composed of primes. This means you can decompose the integer and find out which base units make it up. You compute the name of a newly derived unit but you can also quickly look up previously computed units using the same integer quickly.

We have a class called Fraction in Smalltalk, which has two numbers (numerator and denominator) which can be used to describe the unit too, for example 5 seconds / 5 metres will create a fraction unit of seconds/metres.

The whole implementation ended up being two classes: Unit, ArithmeticQuantity (to mirror ArithmeticValue) and one exception: Incompatible. The package contains two specializations of ArithmeticQuantity: Angle and Temperature; but strictly speaking those domains could be removed from the library and it’d be just fine. The rest of the dimensions from SI units end up being generic. The library re-uses Duration to represent the Time dimension though.

You can find the library in the Cincom Public Store under the name Quantities and Quantities-Tests. I’ll be updating the library once the new Duration is integrated in to VisualWorks 7.9; so if you’re in the vw-dev program you’ll want to use the 7.9 version instead of the 7.8 version. The package contains a bunch of documentation, but only time will tell if the documentation is sufficient. It almost goes without saying that you can also use this package in ObjectStudio too (and WebVelocity!).

The first Minecraft world I built, starting in Infdev and...

Mon, 06 Jun 2011 22:40:03 -0700

The first Minecraft world I built, starting in Infdev and through a few alpha builds, before Maki joined me and we started to customize it further until we finally moved on to the next world. This is a short tour of this world and the things we made. We were novices at this point.

Battle Flag (feat. Pigeonhead) by Lo Fidelity Allstars. The...

Mon, 06 Jun 2011 16:13:00 -0700

Battle Flag (feat. Pigeonhead) by Lo Fidelity Allstars. The album is called How to operate with a blown mind.

This song has been used in the Duke Nukem Forever trailer. This game is going to be short and crude and I’m going to love every minute of it.

This is a tour of a castle that I and Makahlua have been...

Fri, 03 Jun 2011 11:47:00 -0700

This is a tour of a castle that I and Makahlua have been building in Minecraft 1.5 and now 1.6.6 — it’s not that amazing and the world is still very new, so we’re low on resources like wool and diamond, but it’s coming along nicely.

Portal 3 hints? (warning: portal 2 spoilers)

Thu, 28 Apr 2011 11:16:24 -0700

I think enough time has passed since Portal 2 came out that most people, rabid fans, will have completed the game. So here are some things that hint at a Portal 3, or at least some serious DLC.

First off, there is a whole period of Aperture Science’s history that is completely missing from the game. The 90s. We know that Chell appears to have been the daughter of one of the scientists who worked at Aperture because Chell’s potato experiment is down in the offices.

We also know that there is another person in cold storage with the same last name as Chell. Now, if you read the Rat man’s comic you’d know that her last name is [redacted]. Why would there be another test subject with a redacted last name? It may have been a reference to the original co-op idea of having Chell and another person run around the mazes; but they changed that to two androids instead - which is cuter.

Next up, Cave talks about an experiment involving Time Travel once or twice, to great comedic effect. You may have noticed in the 70s control rooms a warning for employees to report any federal inspectors, etc. In the 80s control rooms there was a similar warning, except it was a picture of someone in an orange jump suit. This suggests to me that if there is a Portal 3, it’ll involve time travel back to Aperture Science’s hayday, when people actually worked there. This could just as easily be DLC using some of the people who were cryo’d in “Saving Science”.

Finally, a game mechanic was completely left out of the game, the Pneumatic Diversity Tubes. These babies have a supersuck and once you’ve hit the end of the game you can easily see why they left them out of the game. Having super suck as a normal game power would have dampened the space vacuum ending. So any DLC or Portal 3 is likely to include this game mechanic now that Aperture Science has easy access to a super vacuum.

So, possible settings for the game - Aperture’s past, the moon. Valve has hinted that Chell may interact with characters from the Half-Life universe, so may be she brings them back to Aperture to get access to the technology in there to help fight the good fight. I guess time will tell - DLC is coming up. I’d like to see them do a Left 4 Dead 2 and make the DLC be full on story involving these sorts of plot lines; instead of just generic/difficult test chambers and dozens of obscure achievements.

Me, with a beard. I should probably shave.

Sun, 24 Apr 2011 23:44:59 -0700

Me, with a beard. I should probably shave.

C++ template aliasing

Tue, 14 Sep 2010 00:00:00 -0700

Recently I have been working on some C++ classes which make heavy use of templates. In particular there are two classes Vector, T, N and Matrix<T, M, N=M> where you specify the type of the elements and the number of elements for both. Examples of how you would use these are:

Vector<double, 3> myVector(1, 2, 3);

Matrix<float, 3> myIdentityMatrix;

As you can imagine, typing out that full declaration everywhere gets a little tiresome after a while. What I really wanted was a way to alias Vector3 to mean Vector<double, 3> yet at the same time be able to easily do Vector3<float>.

The most logical thing you might try and do is to template the typedef, eg:

template <typename T=double> typedef Vector<T, 3> Vector3;

However, you’ll quickly discover that this is an unimplemented feature of C++0x. So what can you do instead? The simplest thing that came to mind at first was to make a subclass:

template <typename T=double> class Vector2 : public Vector<T, 2> {

Vector2 (void) : Vector () {}

Vector2 (T x, T y) : Vector (x, y) {}

};

The obvious problem here is that you have to re-implement the constructors and destructors each time you do this and if new constructors are added, they have to be added to the subclasses as well.

A thread on stack overflow had a different solution to the problem. While C++ doesn’t let you template typedefs, it does let you template structs, which can contain typedefs:

template <typename T=double> struct Vector2 {

typedef Vector<T, 2> type;

};

This approach is a true alias, however it requires you to declare your variables like this:

Vector2<>::type myVector;

That’s almost as much typing as you would be doing before - albeit without having to redeclare the types and dimensions every time. As I discussed this problem with a friend, he suggested that I template a namespace and then import the types with using, but it turns out that the following is invalid:

using LinearMath::Vectors<>;

You cannot have a template-id in a using-declaration. It introduces ambiguities in to the namespace. But this got me thinking about importing stuff in to your namespace and I realized I could actually do it using subclassing. Since all my code was generally in classes already, it was a simple matter of creating a class that I could inherit from.

template <typename T=double> class Vectors {

public:

typedef Vector<T, 2> Vector2;

};

class MyClass : Vectors<> {

Vector2 myVector;

};

What’s particularly neat about this is that all the code in my class gets to uniformly use the same vector types and matrix types where appropriate - and they are true aliases, so two compatible types blend together without issue.

This goes to demonstrate the already well known fact that C++ is a very unpolished language with lots of rough edges. Templates exist, but they are not uniform across the language and there are many holes you can easily fall in to. Without namespace templates, typedef templates, using templates.. I was luckily able to find a solution using multiple inheritance.