This seems to happen a lot for me. I’m testing/playing around with some code thing, and I set up some cheeseball compiling in a shell script. Then I get to a point and it’s just not enough, the compiling is taking too long, or so one. My major projects often have a nice makefile setup going, but my experiments, not so much. That’s because writing a makefile, despite being the same thing again and again for me, is tricky to get right....
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 Unity’s “JavaScript” isn’t JavaScript, it’s better named UnityScript. UnityScript is kinda terrible, essentially being just a different syntaxed less featured C#. But var is allowed, so uhhh… *shrug*....
So last year, Derek and I created a little game called Nook. Nook was an interesting game that was half JavaScript and half C++, running in the browser (as 100% JavaScript). Things were still new with Emscripten. At the time it had only recently reached the point where it could work with standard C++ libraries without issue. Performance claims were about 6x slower than native. Everything worked out great, so I did little writeup on it:...
EDIT: For reference I’m leaving this post as-is (except for the new ending), but it seems AppJS is a lot more painful to use after all. Ugh. Long story short, I need to write a tool with a UI. I want it to be portable, just in case. And because JavaScript is “fine”, I’m investigating what packaging options there are. I’m not doing a very scientific test. All I’m doing is throwing TOOM, an adventure game Derek Laufman and I made for Ludum Dare 26 at it. If it works, I’m happy. If it fails, I’m not. TOOM uses SoundJS and PreloadJS. PreloadJS wont work if the browser is reading from the local file system (i.e. file:///blah.html). So developing TOOM, I’ve had to use a tiny webserver running locally (currently Mongoose, was MiniWeb). Chrome Packaged Apps http://developer.chrome.com/apps/about_apps.html Despite the name, despite the wording, this doesn’t create standalone apps. It creates content for distribution by Google’s Chrome App Store only. It’s also not officially live yet. You can make apps, test them, but can’t Publish. Beh. Node-Webkit https://github.com/rogerwang/node-webkit A good simple solution, based on NodeJS and Chromium, regularly updated (Intel Sponsored), but fails the TOOM test. It starts loading, but dies at an unusual place (complaining about one of my source files missing… which is definitely there if it can start loading at all). Adds about 54 MB to the total size (~23 MB zipped). AppJS http://appjs.org/ A fantastic solution, also based on NodeJS and Chromium, and so far the only thing to pass the TOOM test (no audio and slower, so clearly using an older version of Chromium). The very very saddening part however is that there’s only 1 guy on the project, and he’s too busy. Also adds about 54 MB to the total size (~22 MB zipped). Visual Studio 2012 http://www.microsoft.com/visualstudio/eng#downloads Untested, but this option is Windows only, and there may be other caveats. Any code written for DiskIO and file manipulation will only work on Windows. No WebGL support. That said, the JS code may compile down to CLI bytecodes (dot net), so performance might be better. Also how an app is structured may not mirror how a web project is created (index.html and all files). Untested though. Adobe Air http://www.adobe.com/devnet/air/air-sdk-download.html Nope. Created my descriptor file, modified it to use the HTML file, then ran it with adl (adl D:\Toom\application.xml). After fixing the one bug it reported, it just sits there… waiting. Running I assume, but there’s no action. NOTE: Instructions for running and packaging I found inside “AIR SDK Readme.txt” in AirSDK. TideSDK http://www.tidesdk.org/ Formerly known as Appcelerator Titanium for Desktop. Finally, another one that passes the TOOM test. TideSDK is based on Webkit, but a seemingly an older version of webkit. CSS Fonts did not work, the framerate was even slower than AppJS, and no audio. Still, it was interesting. Downside is they seem to be short on funds too; Their blog reminds me of PBS. More choices, no good ones http://stackoverflow.com/questions/11015811/html5-desktop-wrapper-framework Conclusion There’s no safe/good/active choice, but AppJS impressed me the most. As far as portability goes, I think what I want to be using is something that combines Chrome and NodeJS, but not Webkit. Plus it gives me a reason to learn NodeJS too. My Browser performance and debugging experience is just so much better with Chrome, even though I don’t use it as a primary browser (I use Firefox instead). Regrettably AppJS right now today is a bit of a gamble, since it’s just one dude behind it, and he’s made it clear he doesn’t have the time. But it does exactly what I want, so *shrug*. There’s talk of a Kickstarter, and I hope this sees the light of day. Totally a worthwhile project. PLOT TWIST! Not a good one though. Something I hadn’t really realized before was how AppJS is actually working. From what I can tell, it’s actually running a small web server, i.e. the NodeJS part. Your main JS script file is standalone and disconnected from what runs in the browser context… YET, you control maximizing/minimizing windows, the contents of menus, task bar appearance from the NodeJS side. Your app is standalaone, caged inside the browser context. Now, there may be a way to pass data between the NodeJS side and Chromium side, similar to making web requests in general. It’s not documented though, so *sigh* not sure where to start. Node-Webkit might actually be more of what I want, since it’s about introducing the Node features in to Webkit. That said, it failed the TOOM test. Ah well, enough of this for now. ...
More notes. This article contains a longer more comprehensive list of differences, but I want a more concise list for both my own reference, and for when I’m teaching. Squirrel 3 documentation. ...
So I’m typically a native C/C++ programmer, and I seem to surprise people when I say I like JavaScript yet dislike C# and Java. What I like about JavaScript is that it does things C and C++ don’t, as opposed to C# and Java that take C++ and as a base and enforce new constraints to “simplify” code. Both C# and Java do improve on C++, but I find the new strictness they impose to be a detriment or intermediary fix....
The following is some rambling. I have a point I’m trying to make, but I’m certain I don’t make it. My fingers kept moving, and this is what resulted. You can kinda get an idea what sort of madness is bouncing around in the ‘ol noodle right now though. Good luck. *Big Sigh* I’m typically a “from scratch”, “native code is best”, “c++ FTW” type of developer. The thing is, developers with my skillset and experience really are at a big disadvantage in today’s game market....
Here are my notes on Squirrel and JavaScript. JS: Number, String, Array, Object (Table), Function, Null (object named null), Undefined SQ: Integer, Float, String, Array, Table (Object), Function, Null (null), Class, ClassInstance, Generator, Thread, Weak Reference, UserData, UserPointer JS: false, undefined, null, 0, NaN, “” SQ: false, null, 0, 0.0 (“” untested) JS: var MyVariable = Value; /*Global*/ SQ: MyVariable <- Value; /*Root Table*/...
I’ve been evaluating some new libraries lately and as usual, I decided to take some notes. POCO POCO seems to be a nice complete C++ library filled with things that other languages like Python and Java have. It’s very feature filled, but it’s unfortunately obvious that the development team doesn’t spend much time working or testing on Windows (and when they do, it’s with MSVC). There is a MinGW build, but as of POCO 1.4.5 it’s designed for Cygwin MinGW, which is a variation of MinGW that you invoke with “-mno-cygwin” to remove dependence on the Cygwin libraries. No good for a pure MinGW+MSys user like myself. So, I had to make the following changes to build/config/MinGW: ...
DrMinGW is a fancy crash detection program for MinGW programs. Details can be found here: http://code.google.com/p/jrfonseca/wiki/DrMingw One of the really cool features of DrMinGW is you can alternatively invoke a DLL from your program to catch your crashes, instead of requiring you or your testers to install DrMinGW. The problem is the library and DLL aren’t available for download, and building it from sources requires SCONS, which I can’t seem to get to work with it. So, my solution is to build it manually. Unfortunately, building it requires knowledge of some of the secret defines set by SCONS. ...