Lumbering Dream Interactive

I chose not to choose blog.
I chose something else.

In the past week, I've seen the total Eclipse of Dev-C++: I've swapped the latter IDE to the former. I've found my way across the mysteries of setting up Eclipse and getting it to work with SDL, OpenGL and XRhodes (two amazing tutorials helped quite a bit). There were a good couple of restarts, and project opens/closes (I can't believe this), but now everything is a-work, so as soon as my laptop arrives (due today), I'll transfer my work to practice and optimize my speed for the Berlin Indie Game Jam.

It's worth pointing out for the span of an additional paragraph, that XRhodes' Windows version took not just a little bashing before it was working perfectly with OpenGL 2.0 / GLSL. As the ever-helpful people of stackoverflow.com pointed out, all OpenGL functionality beyond v1.2 needs to be loaded dynamically.

When that was done, I've refactored XR::Font and XR::TexCoordRect to comply with XRSF. XR::TexCoordRect helps a lot it you want to implement a frame-based Animation class or maybe a SpriteSheet class etc. And it's nice to be object-oriented.

I've started working on Cornerstone's level editor too, complete with tools resembling any graphic editor. It's going to be fun, and it isn't long before level serialization is complete.

And just when I was ready to get down to create documentation for XRhodes (in what time I can spare from my spare time), the start of the Adult / Educational Compo has been announced at TIGSource. Priorities tip a bit, systems collapse, but my new game is in the pipeline, and I'm just about to complete the object hierarchy. Anyhow, since there'll be two weeks to finish it after BIGJam, I'll try to keep my focus on XRhodes and Cornerstone.

This time would be as good as any to quit my day job -- too bad none of these projects pay just yet.

XR::SF::Processor is complete, the little neato. I've refactored XR::Font based on it, and the first tests have finished without a single logical error. Wonder how is it going to be, when I start hurling crazy documents at it.

Anyhow, the Processor works as follows: you instantiate it for a type (it's a template), Set() up the tag (String) - process pairs (pointers to member functions of the class you've instantiated it for, which will process the data) and Run() it on a given object of the type you've initiated the template for, and a given Reader; it will return false if invalid XRSF was found and true otherwise. The processing will finish at the end of the current aggregate. You can also check the number of different tags found passing a tag to GetCount() (i.e. expecting tags to be present, warning about duplicates, etc).

Sadly enough, yesterday I was too tired to see that XR::SF::Tree can't be refactored based on XR::SF::Processor, not at its current level of genericness: it won't branch based on the type of the elements type (value/aggregate), rather than based on their names. On the upside, I'm completely able to live with it, and so are you.

Read more »

I've been a bit disoriented with joy (and else) these days. Managed to find a sleek and optimal way to handle collisions with surfaces meeting at an acute edge: no lists, no sorting; yeah -- it screwed up collisions with surfaces meeting at > 270 degrees. The ideas to tackle this didn't work out so far, so I'll have a crack at it tomorrow.

That's not all that's going on, though. I have rewritten the XR::Font loader to use XRSF instead of XR::Script. Having worked with the XRSF implementation provided valuable insight in the practicalities of processing of real-life XRSF documents/elements.

Read more »

I've got the hang of the problem with collisions with multiple surfaces intersecting at acute angles. The key is occlusion check, which involves recording cases of non-penetration and checking collision candidate surfaces' relative orientation (yes, Dot Product is my new best friend). Now, the new implementation is still not perfect -- it fails with the dreaded Spiral. There is a work-around for it, using smaller surfaces (see screenshot). Although this is something that helps with optimization, I prefer imperfections like this one ironed out.

On the optimization note, there'll be quite a bit to do. XR::LayerServer is given more than a little work in the engine, and there are a few dot products and loops in the narrow phase. I'll see if there are collision candidates that can be discarded before the occlusion check. Plus I've got some more ideas to cut the amount of collision checks to be done, but I'll come back to that later.

It's been high time for a new post. Things keep happening in bunches: there's the Berlin Indie Game Jam to come, for one. It's such a great excuse to wrap up XRhodes (which now exists in a static library form -- yay!). I've also made some progress with the vector platformer engine that will power Cornerstone. Here's the first screenshot.

The chunkiness is not obligatory, of course: in the demo there are grid helpers in place at 16 x 16 pixels. (The projector, the particles, the motion blur and circle rendering (at adjustable detail - adjusted to a low value) are done by XRhodes.)

Read more »

I've just finished XR::SF::Tree which aims to improve the accessibility of XRSF, enabling DOM-style parsing. It is compatible with the XR::Resource::Manager/Indexer templates should you need to store an array of processed XRSF data. It has two CreateFrom() methods: one accepts a String filename (the resource index in its manager class) and attempts to process the file it refers to. The other accepts a reference to an XR::SF::Reader, which means that you can create an XR::SF::Tree from a part (an element) or a whole of an XRSF document.

Read more »