Did I mention that I really hate the term "html5 OS" (hence I said "HTML5 compliant") ?

I mean, I love HTML5. I really do. But "html5 OS" sounds like it was something that only ran in a browser. A sort of emulated OS, if you will.

Anyways. I'm already working on some new specifications, especially concerning the proper use of client side decorations. Currently, I'm working feverishly to get some bootup scripts ported to zsh since it will replace GNU/bash as the default root shell. Design wise, I already got rid of all virtual consoles as I really don't think they belong into a user oriented OS. The system should boot right into the graphical user environment.

After going through a number of spec changes and basically defaulting on a couple of key choices, I have made quite some progress on my OS.

There are now two development frameworks.

Junior, the one I'm currently concentrating development on, caters to the modern web developer and combines ease of use with a modern language supporting a number of native services and powerful graphical features. Natura, on the other hand, tries to provide a low level toolset for those who need every last bit of performance, reliability and security.

Here's a screenshot of Anima's login manager (WIP. Don't mind the debug console to the left). The frontend was entirely created in Junior whereas the backend relies on features that I'm going to add to Natura. Combining a Junior based application with code from Natura (or any other low-level framework, for that matter) required a single wrapper class of less than 20 lines.

Was looking into ideas on how to add some sort of simple scripting system to my engine and stumbled upon the data driven solution outlined here:

https://bitbucket.org/gabomdq/ignifuga- ... at=default

Anyone got an idea on how to implement this? Ideally, there would be a way to have a string that says "Room: <roomname>" and is compared against a global variable that contains the current roomname. The Construct 2 specific code would then only parse the keys belonging to the same roomname.

Unfortunately, I'm not good with multidimensional JSON documents or I would've implemented this by now.

What you use to "compile" your game can also have a tremendous impact on overall performance.

In some rare cases, you may have to use external tools since the plugins implemented in Construct 2 just aren't good for the particular job.

If there's any interest, I can also offer a custom wrapper based on Mozilla's Gecko.

While I'm still having some issues with the GNU/Linux version (specifically fglrx, aka the official AMD Catalyst driver blob), Mac OS X and Windows games utilizing WebGL are generally a fair bit faster under it than under Node Webkit.

GPU blacklisting is also less of/no issue.

The game really seems to hit Webkit's limits. Either that, or Chromium has become a really lousy codebase.

Anyways. Replacing Node Webkit with a hand rolled solution based on Gecko and Azure, I was able to raise the average and low FPS considerably. Whereas the game (build from the .capx Ldk provided here before) would previously run at a mind numbing, stuttery 45-53 FPS (sometimes dropping below fourty/into the lower thirties), it now runs at a constant 55-60 FPS. And that's on a Macbook Air 2013. My Mac Pro runs circles around it.

Any reason you use oversized sprites, Ldk? The Rhino is 559 × 289, even though in game it's only like 21 x 16 or something like that.

I know. Sad part is im no longer using any webgl effects on layers.

Time will tell.

Stop stalling and give us the .capx already

Seriously. You had me at performance issue. It may sound weird, but I love figuring out reasons for performance issues.

Well. Most AAA games/engines are written in C/C++, so there's that.

As for companies not talking about what engines they use. Nothing could be further from the truth. There's actually plenty info online. No matter whether a dev uses UE3/U4, Crytech 3, Unity3D or rolls it's own, there's usually info/tech videos around.

The offer still stands.

I can also help optimizing for performance/file size and testing the game on multiple hardware platforms. I own several Macs (equipped with AMD, Intel and NVIDIA GPUs) and half a dozen Linux boxes, so I'm in the position to test the game for all kinds of graphics drivers.

Was really looking forward to this (especially as Ldk contacted me, asking for help/insights with the Mac/Linux versions).

Oh well. I'm sure the game will be nice, even without being Construct 2 based.

Thanks.

I'm hard at work fixing regressions and refactoring the codebase for both games.

After that, I might open source my cleaned up Wobbly-Blocks source tree and start implementing those additional features.