A wicker soldier

Orel keeps on amazing us with new modifications. I can't wait to see this guy hacking and slashing. I wish I could model and texture like this...!

Parallel Profiling

Did some profiling during my lunch break, since I was curious to see how a one-day implementation of a parallel library would perform against a super rival like Microsoft's TPL. This simple console app has been run in release mode, so no debug stuff lying around. My work laptop's a Fujitsu-Siemens Amilo Pro, Intel Core Duo 1.86 GHz, 1.75 GB RAM.

Rainweaver.Parallel Tester

100000 iterations Bessel function.
Comparison mode.
Parallel (RNW): 21076 msecs elapsed.
Parallel (TPL): 15877 msecs elapsed.
Sequential: 44302 msecs elapsed.
Ratio: Parallel RNW is 2,1020117669387 times faster.
Ratio: Parallel TPL is 2,79032562826731 times faster.

The results are pretty self explanatory, considering noise and everything. While this makes me a bit sad, I'm still happy to see that the difference is not that humiliating - at least, that's how I see it, and it's granted it could be oh so much better. All in all, my implementation is not optimized nor has been given that much forethought, so I can consider this a small step towards Nirvana and a great first-hand experience in parallel coding, which is invaluable.

I'd like to congratulate the TPL team on an awesome job. Can't wait for the release of this great library.

Coming next...

I've been dealing with a few interesting issues and finalized a good part of my base libraries. The time has come for me to start working on Darkmana. I've been messing around with my codebase to find out I was misusing a bunch of objects, resulting in a few annoying exceptions while using TV3D. Hopefully the problem has been understood; the lessons is, when dealing with multithreading, don't assume to follow the same sequential logic you'd use normally. This might be a given, but it's usually not. One enters in this focused state of mind in which everything clicks perfectly, just to find out an important thing has been left out at the very base of the structure.

Enough intro. In the next days, I'll commit some time to work on these subjects:

• Parallel library: why, yes, even if there's one available for download over at Microsoft, I needed to roll my own. I can't rely on their release date (which is unknown at the moment) and on code in beta stage (adding to my own). Luckily a superb Channel 9 video with a throrugh explanation helped me disentangle a few doubts (link for the interested).
• Using the above library to create a proper loading screen. Loading screens are cool, but only if I'm the one making them, otherwise they're annoying as hell. I'd love to let the player move the main character around until the world fades in around him upon load completion. Wouldn't it be cool? I think so.
• Programmatic animations and AI. This is going to become a big matter, there are so many things I need to finalize first.
• User interface: that will be one of my last concerns. I'd rather have a simple guy running around and jumping than a working user interface at the moment. I have learned a lot from my past experiments with user interfaces, and this time I'm sure it won't be as painful as the first time (I'm not even considering the actual first time, since it was a mess :P).

The people who subscribed in our forums for the beta version will receive the link to download the various tests I'll be uploading (when there's something juicy for them to test of course).

Of Cyclical Rewriting

Sometimes I wonder why I even bother. It all started because there was a bug in the NTL compiler apparently not recognizing handler tokens. I could have sat down and probably fixed it in a bunch of hours. But no. I had to put the whole NTL language idea aside (as I said to Zak, it was mainly a "programming masturbation", but a cool one ;( ) and fall back to XML.

Well, I think it's eventually a good choice since XML is widespread, can be read by almost anything, espresso machines included, and is an accepted standard.

Luckily I didn't have to rewrite all the code that actually creates CLR assemblies out of the entity system definitions you spam in, or it would have been serious pain. Much pain.

Anyway. While I was at it, I also removed a feature which I didn't like. When the entities were processed and turned to IL, they were added a field named Prototype, which contained an EntityPrototype object basically describing the objects referenced by the entity; this means components, handlers and handled messages. All of this just to speed up entity creation at runtime.

However, I had forgotten once again about Attributes, and why they're in the CLR. So, armed with loads of patience but handicapped by lack of proper sleep, I set to remove this prototype stuff and go on with attributes. Now I'm in the middle of realizing what's the next step.

The most annoying part is that I am storing Types via their TypeHandles (actually their RuntimeTypeHandle.Values ToInt32()ed); this basically means creating a type storage via indices; this so reminds me of the database stuff I have going on at work - though, when I started to ramble about entity systems, I kind of expected it.

I had a nice demo going on but it's no more. Raaargh. Here's hoping it won't be long until I have something actually doing its job again.

I'm out.

07 Sept. Edit: Well, it wasn't as bad as I initially thought. I managed to get things up and running again, now including some things like proper component installation and uninstallation. Since my programming life is full of happy gummybears again, I can commit some time to the actual entity system editor. I'll keep you posted.

Entity System and Lua

Lately the Entity System code has been getting more and more complex, to the point that I had to read what I was writing very carefully (and sometimes reading aloud too... go figure).
I have some news about it... about time!

The good news is that it is almost complete! It's a joyful day for me. Object pooling, message dispatching... stuff that works! I still have to finish adding and removing components dynamically (right now we just get the components we defined per entity in an NTL file).

The bad news is that Lua hates me, and it's giving me all kind of exceptions. I think I know what's going on and the relative fix, but if said fix did not work, I'd be in serious troubles. Basically, Lua needs to know what types you're working with, otherwise it would just sit and cry pitifully, making you feel guilty for such carelessness. And it makes sense, of course. LuaInterface is a mysterious world, I still have to figure out thoroughly how the .NET bridging works - luckily the source code is freely available.

At some point of yesterday evening, while bashing my head on the desk for the umpteenth exception, I even felt like writing a Lua compiler / interpreter from scratch in order to get rid of problems when interfacing with the CLR. Sadly, it's a task beyond my available time and most likely experience as well. It would be a great challenge, though.

I still haven't performed any performance tests, but I know in advance I will have to make sure a) the object pool isn't raping the heap b) entity creation is quick and painless, and so is its disposal.

I know it's all a bit vague, but I'll be sure to release the NTL environment as soon as I have something worth attention.

Have a good and productive .NET day! (...rolololflol.)

Shameless plug here

Aloha to everyone reading this blog (hi granma!), I'm now back from holidays and ready for a quick recap about my latest endeavours (whoa).

As if the Entity System weren't enough to keep me entertained and make my fellow team mates doubt about my commitment, I've restarted the long-forgotten UI project. This time it's been redesigned the good way. The good thing of the stuff I'm writing lately is that is it 3d engine-independant, I'm just providing managed Truevision3D implementations since this is what we're using at the moment.

The UI includes / will include the following features:

• Full scripting support
• Multiple views (UI on meshes and on screen, for instance)
• Markup compiler (a la WoW interface)
• Event driven design (in combo with the Input Manager contained in the Rainweaver.Core library)
• Layout Customization, allowing your artists to do their job and snap pieces together

I meant to add Add-on support by default but it's very implementation specific and I'm not sure everyone would use it. It'll be very easy to plug stuff into the interface, though.

I decided to restart the interface project since it's the best environment where to test my libraries (engine, input, scripting, console, data structures etc...).

Stay tuned-zorz.

Away Notice

To everybody who sent me an email in these last days: I'm on holiday, I'll be sure to reply as soon as I come back.

Wien (Vienna) and Budapest are awesome :)

PS: If you plan on going abroad with your trusty laptop, be sure to bring a power adapter.

PPS: I'm away for another week and I won't have an internet connection... take good care everyone and see you soon!