So in one of the logging articles, boost::thread_specific_ptr was mentioned. In my opinion, it is a very cool little thing. It's basically just a pointer which can have a different value in each thread. Why would you want one? Well, I used to have a bit of a problem. Angel script, the scripting language I use, requires a thing called a context when calling script functions. Contexts cannot be shared between threads and I wanted to cache the context between calls to the scripting language, since creating them is relatively expensive. Calls are made by a couple of different threads, so caching the context required a bit of hackery. A thread specific pointer, however, is a perfect fit. For each call to script I check if the context for the thread is null (unlike a normal pointer it is initialised to null by default) and if it is I create the context. Otherwise I just use the one already cached for this thread.

Also, this is what my log files look like now:

They're quite colourful. Completely overkill, too. But the really great thing is that I'm now happy to look at log files. I want the program to go up in flames just so I have an excuse to read their christmasy goodness! Though I suppose the novelty will wear off.

So I've just been writing a contender for the most overkill logging system known to man. You see, with my "spare time" projects, I have a tendency to not do anything that doesn't stretch my programming muscles a bit. It's great to do something tricky after watching your skills atrophy for an entire semester. So, when I decide it's time to replace all my cout logging with something a bit tidier, it's not enough to just write them to a file. That would be boring. The task has to become complicated enough to retain my interest.

With that in mind, I based my solution on two articles: Using XML Technologies For Enhancing Log Files and Simple STL Logging System (which is basically about boost streams). By combining these, I end up with an xml logging system which is written to like a standard stream. It's a macro, admittedly, but there's nothing you can do about that while keeping file/function/line information. I have yet to do the xslt part, but most of it is in place, in a rough form.

Along the way, I came up with the idea of a logged exception. A logged exception is basically just a shortcut for logging an error, then throwing an exception, and using the same message for both. This allows the calling code to catch and handle the exception if it wants, but if it is not handled or handled badly then you still have a handy message in the log so you know where things went wrong.

Greetings. Much time has passed but I'm back. Today's item is a mini physics engine with point masses, constraints and damage. It uses verlet integration, basically as described in this article: Advanced Character Physics by Thomas Jakobsen but gradually deviating from it. Main difference so far is that I don't just resolve each constraint in turn, I get the amount each constraint wants the point to move first and then sort of mix them. I basically just wrote this thing to avoid going insane, but I am going somewhere with it. Whether I get there is another matter entirely. Currently the issues I have are that friction depends on how many iterations I run through the solver (since it's not represented as a force) and my constraint breaking feature is, er, broken (deformation is fine).

I was going to put up a video but line graphics really don't compress well, so here are a few screenshots instead.

I've had another attempt at sparse volumes for my voxel-like renderer. A bit late though, I've been thoroughly beaten to it. Not that surprising, considering how many years I've been chipping away at it (and, lately, just plain neglecting it).

This sparse volume is much simpler than previous attempts, and as such, works quite a bit better. I've got a 2048^3 volume working, with floating point radii, and it's taking around a gig of ram. And let me say this: You have no idea how big a 2048^3 volume is. Here's a picture:

You see each of the little squares on the left? They're 8 grid points across. Each 8^3 bunch of radii is coloured like a colour cube. There are artifacts, but I don't care at the moment. I'm tired.

So I've been thinking (boom). Not about the exam on Monday, no way that would happen. I've been thinking about how quite a few people live out of a USB memory stick/drive/key/dongle/whatever, especially at uni. Some people do it because they don't have a laptop and use a combination of lab and home computers. Some people do it even though they do have a laptop. For example me. To the point where I want to get a fancy shmancy memory card thingy that can still be used with USB, so I don't have an 8gb stick hanging off the side of my laptop all the time.

Money sinks aside, I see this sort of portable storage playing a big role in the near future of computing. It already is, you say? Yes, well, that's what tipped me off. But seriously, it's pretty limited at the moment. Most people don't put that many programs on their USB whatchamacallits. The reason for this, from what I've seen, is that a lot of programs just don't handle it very well. E.g. they use the registry (eww) or store stuff in your user or system directories that don't move when the program does. There's been some effort to sort this out, and half-assed operating system support for this kind of thing, but I ignored it all because it would take per-program effort. It seems to me the problem is being solved at the wrong level entirely.