So I’ve done a few scatterbrained posts lately that talk about things. Most of them had rather open ended conclusions, that were followed by wildly out-of-left field follow up posts. Here’s me making sense of that.
Evaluating Middlewares: Unity does good 3D, bad at JS
I still don’t care much for C#, but I think Unity’s 3D workflow is excellent. Fantastic even. I have 3D projects I want to do, and when the time comes, I’ve convinced myself I should do them in Unity.
That’s 3D only though.
Time was short during Ludum Dare, but we came up with some neat ideas, so we’re redoing the game. A “Director’s Cut” if you will. It’s still taking place in the one room, but we’re planning to make both the room and the interactions you have inside it way more interesting.
Packaged HTML5 Apps (Tool): Abandoned
In January 2012, I ported the unreleased Beneath Darkness prototype to some HTML5 packager. The company behind the packager was running a contest, and my intention was to enter the game in that contest. I wasn’t able to finish enough in time though, so I never submitted. That was fine though, as the winning games were definitely better and more complete.
The thing is, I can’t remember what that packager or the company was called.
It doesn’t really matter though. Like the Chrome Store, apps built for this packager were only for their proprietary HTML5 app store. I seem to remember a blue acorn, which may have been their logo. What disappoints me is that packager ran the game perfect. No issues with sound, no issues disabling linear filtering on image scaling, no issues loading files. Yet today, running the same prototype in both AppJS and Node-Webkit fails to load the map file. I’d be fine if Node-Webkit had no issues loading TOOM using PreloadJS, but it does. I might have been able to get NOOK working in Node-Webkit without any changes, but long story short I’m not happy.
Google’s Chrome App Packager stuff sounds like they solve the key issue (XMLHTTPRequest’s locally are okay), but it’s proprietary, and again only available to apps intended for distribution in the Chrome Store.
Even if it’s something that would be best fixed inside PreloadJS itself (support file://), that’s fine, but that’s not working 100% right now. I still have to do all my testing via a mini webserver running locally. My intent was to build a generic editor for a TOOM related project using HTML5, but I’ve decided against it. Building a Tool in HTML5 only saves me time if it works… right now… today.
I’m very unhappy with the state of packaging HTML5 apps as Desktop Apps.
Renstalled Empscripten, Embracing WebGL
But like the headline says, I’ve since reinstalled Emscripten. My post from earlier today details this process, which was notably different than from when I did it 1 year ago. Better… except for the build time (70 minutes to build LLVM+Clang… and I had to do it twice).
I’ve been sort-of against WebGL, ironically, being an OpenGL guy. Against is a harsh word. More like, ignoring it. After all, Microsoft will never add it to Internet Explorer… or will they? Yes if the leaked Windows Blue version of Internet Explorer is to be believed, WebGL support is there now, so therefor coming soon.
What WebGL also brings is some potential Canvas graphics performance improvements. Your render code will have to be ported over to WebGL (OpenGL ES2), but with a little bit of batching, things get nice and quick.
Oh and Unreal Engine 3 now runs in the browser, thanks to WebGL and Emscripten.
So alright. If Unreal Engine 3 can do it, surely a WebGL accelerated 2D engine can.
Now for the final piece.
Anyways, my mini-project of the day was to get Squirrel building in the browser (using Emscripten), and to build a very basic HTML interface for invoking the compiler and seeing the results. I’m betting that, since Unreal Engine 3 can run in the browser, it’s not unreasonable of me to expect instant execution of small Squirrel scripts. If that’s the case, then if paired WebGL, it may be reasonable to expect 30-60fps performance of a C++ game driven by Squirrel scripts. I’m not exactly interested in developing web games in Squirrel, but I’m investigating whether if I commit to Squirrel as a native game logic language, I can still generate playable web versions of games.
Regrettably, I haven’t yet finished this Squirrel building project yet. Getting Emscripten working again ate up most of my afternoon (long Clang compiles). Then there was the power outage, and this blog post, so I think I’ve done enough for today.
I may try just compiling Squirrel with Emscripten, then I’m calling it a night.
EDIT: Yep. So far working just fine with NodeJS.
emcc -O2 \
-I include/ \
// Usage: node sq.js [args]
// FYI: Emscripten compiled things can only access files inside their virtual file
// system, so passing a .nut file on the command line will only work if you
// added it during build. i.e. --embed-file myfile.blah
// NOTE: --preload-file wont work in the above example, because node.js lacks
// a window object and XMLHTTPRequests. Must be --embed-file.
C++11 Support Feature Complete in Clang and GCC soon!
Now this is some awesome news. Clang 3.3 and GCC 4.8.1 are expected to be fully compliant with C++11 in their upcoming next versions.
There’s still the problem of compiler vendors being slow to upgrade their GCC and Clang versions to newer ones, but this milestone should be a good kick-start.
Something also rather neat, Clang is adding C++1y (C++14?) features already. One that caught my eye, BINARY LITERALS! So just like you do 0x10 for the hexadecimal number 16, you’ll be able to do 0b11010011 to write binary. 😀
I have a header file, named Binary.h, that’s literally filled with every 8-bit combination of b0 to b11111111. Looks like I’ll be able to retire it some day. 🙂
End of Report
This post grew rather large ‘eh? Alright then, I’m done.