Monthly Archives: December 2003

Yoga

I went to a yoga meditation today. One word: Ow. Pain in the muscles. But I’m definitely going back. My body doesn’t get much physical exercise outside my fingers (which may be the strongest fingers in the world :-p), and although painful, it felt so good. It also made me realize how utterly out of my control my body is.

Bearing weight is supposed to be good for bone mass, which you start losing when you’re 25. So I ought start bearing some weight before I turn 25 and my bones realize they didn’t have any mass in the first place…

And I don’t think my eventual geek-loving lover would mind so much if I had a muscle here or there. Or Karlin, for that matter, who’s BACK IN TOWN AS OF TONIGHT. I am so happy! (For the unaware but misplacedly interested, she was my girlfriend for two and a half years, and we get along fantastically. Forget whomsoever I might be with at the moment, we’ll still cuddle and have a brilliant connection. The fact that I’m not with anybody at the moment only brightens the situation :-)

Return of the King

I saw the 12:01 Return of The King last night. This was after watching the extended versions of the first two movies throughout the week. It was pretty good.

There was this overall sinister feel to it, even after it was All Over. And tension, massive tension, “claw your own skin” tension. I haven’t read the books (yet), so that made the movies significantly better (Namaste has read the books, and he was at a loss for feeling everything I did, because he knew everything that was going to happen).

My complaint is that it got very cliché by the end. A classic shockwave follows a standard explosion. I was remembering The Wall, right after The Trial, the sound of the wall crashing down. I wanted the end to be like that, but it wasn’t. It had to be all glorious and instant-climax like the rest of Hollywood.

But it was good. Definitely see it in the theaters.

Perl macros for GLIC

Speaking of templates, here’s their all-powerful replacement (or complement, probably) in GLIC:

    macro class PrintName {
        # Transition to Perl code (should probably be more clearly marked)
        sub GENERATE {
            my ($class, @params) = @_;
            my $template = join(', ', map { $_->name } @params);
            <<CODE;
                void print() { cout << "My name is $class<$template>\n" }
CODE
        }
    };
    PrintName<int> p;
    p.print();       // "My name is PrintName<int>"

Do you have any idea how powerful that is!? And the best part: Do you have any idea how damn easy that is to implement!? So, yay.

Facet

I knew facet was a bad name for them. But here’s an explanation:

It’s a way of making one object contain another with a weak reference, specified from the containee’s side. So we have:

    class Drawer
    does Facetable
    {
        void draw() { for i in facets { i.draw(); } }
    };
    Drawer drawer = Drawer.new;

    class Ball
    does Drawable
    {
        facet void drawer.draw() { /* Draw a circle */ }
    };

    drawer.draw();   // Draws nothing
    Ball ball1 = Ball.new;
    drawer.draw();   // Draws a ball
    ball1 = 0;
    drawer.draw();   // Draws nothing again

few details I need to flesh out, like what if you want to specifiy a different “drawer” in the constructor, or something? But it seems like a powerful construct so far.

Maybe I should call them task, except that seems to have a relation to threads. Maybe favor; that might be too cutesy, though.

In related news, I’m already about half way done with the parser for this language, and the code generator should be pretty easy (considering most of what it outputs is just what it was given). I have yet to do classes and templates. I’m inclined to punt on templates because they’re a pain to implement, but I really want to be able to use existing template classes in GLIC code.

GLIC design notes

Here are some initial design notes I put together for GLIC, the game language I was brainstorming about. It’s written in the present tense, but don’t be fooled, it doesn’t exist yet.

There are certainly things I’m missing, and I might throw out a couple things, but most of the features are there. Those familiar with Perl 6 will feel at home :-). Much as I love designing a flexible, beautiful language, I’m emphasizing simple implementation and focused design here. Thanks to Parse::RecDescent, I can screw with the syntax as much as I want. And you know how I love syntax…

I think it needs to be closer to the domain in a few areas, but much of that can manifest itself in the library, which can be continually extended and improved. A huge leap I made was adding what I’m calling facets (for now), which I’m seeing all over game programming idioms. Hmm, can you say Class::Facet? (I just released
Class::Role, along similar lines).

Embedded List

This is a container that removes a level of indirection from the standard implementation of a linked list, and sticks the next pointers inside the contained object itself. It has some advantages if you have an appropriate situation, such as it does not allocate any memory, and is thus very fast and safe.

An appropriate situation is: partitioning the entire set (or most of it) of instances of some class into disjoint sets. Say, for example, I don’t know, a collision detection algorithm implemented with a quad-tree. :-)

Collision Detection

So I’ve been thinking some more about the Worms-like game contest for gamedev next time. I’ve got a damn sweet model for deformable terrain up my sleve, which I think could make a very strategic ballistics game. Not to mention, it’s deformable terrain, which is cool in its own right.

There are two problems I’m facing at the moment. The first is that the deformable terrain model is a very stiff differential system, making for computationally intense integration. As an example, do a simple Euler integration on x’ = -Kx, with K = 10,000 and x0 = 1. You’ll note that if you use a step-size any greater than 10-4, things start looking very different from the correct e-Kx.

Another is collision detection, as usual. The Game Language I spoke of earlier is going to need a solid generic collision detection algorithm built-in (and it needs to be overridable), so it’s time I gave this some thought. I was thinking of using the OpenGL stencil buffer in combination with selection to do the detection for me, but it has a couple serious problems, the main one being that it only works for objects that are on-screen. So that basically rules that one out.

So I might fall back on a quad-tree implementation, using the embedded list pattern (I’ll post on that in a minute), so I don’t have to allocate any memory in the process. Doing lines is a bit of a challenge in the tree environment, but I might be able to come up with an efficient and elegant recursive algorithm. Actually, I can think of it right now. Cool. I think I’ll do another demo and see how it measures up in terms of speed.