.NETAsm

You HAVE to check this out. Sounds bloody amazing to me.

Entity System (Part 3)

Well, the compiler looks almost done; a ntl file in, a .net assembly out. I'm sure there will be a few bugs to iron out, but it conforts me to just think I'm not too far from its release.

The next step will be releasing an editor for the language; for now, I think I'm going to use Roger Alsing's Syntaxbox and some other stuff found in the net.

Another aspect worth discussing is that the Entity System will work on its own thread, and it will communicate with the main thread via the so-called "action gateway". Every action sent to the ES is queued and executed serially; the inverse is alike, however the main thread has to take care of serializing the actions the ES has sent and execute them after whatever comes first (usually rendering and physics update).

Now, in my mind this looks like a good plan, but I know it's bound to change somehow. I can't wait to have some working results to show.

Good weekend, Raine out (nerdish goodbye).

Part 4 is here.

Tree awesomeness

When you have an artist doing stuff like this...


Awesomeness rating: 100%

Well, check out our website if you're interested in how the tools are coming along. :)

Async Resource Loader

A few months ago I had the map loading stuff done, and wanted to try some landscape paging. I thought a worker thread would save my day but, as it turned out, loading stuff from HD was still blocking the rendering. I took a look around and found out that synchronous calls (even in a different thread) wouldn't act any better than if they were in the main (rendering) thread.

Real life then set in, and I couldn't get much done. Some weeks ago I rewrote the async loader, and this time it'd include asynchronous calls. So, a worker thread + asynchronous calls (Begin... / End... methods). I soon realized a bad design mistake and I wiped the folder (lesson learned: don't code anything until you've filled at least a page of a good old paper notebook).

I'm going to write it again before implementing anything else since I want all loads to be performed without rendering hiccups (or at least, as few as possible, since the OS has the final say on everything). So, since it's to be rewritten, I'll take more time to design it carefully.

The ARL (async resource loader, blah blah blah) allows you to use custom loaders (since all it does, on its own, is to load a stream of bytes asynchronously from somewhere). Once you have added at least a loader, you start the "service" and call the Load(ResourceInfo) method wherever you like (provided it's in the main thread). Once it's ready, you get a Resource object back (from a callback, I guess). That's about it.

There are details to consider, however; load requests have to be queued, can be aborted, the object which does the final loading (that is, converting the stream of bytes into an useable resource) must be locked (both inside the custom loader and outside), and last but not least, it really has to be threadsafe and performing, otherwise it's useless.

That's all for the moment, ran out of inspiration....