Squirrel Stack Tracking

Squirrel native dev lives and dies by the stack, so here are some notes on the effect each function has on the stack. NOTE: SQUserPointer’s are noted as void*’s (since that’s what they really are). Virtual Machine Stack 0 Stack ?? (depends on args: 0, -1, +1, or both) Stack +1 Stack -1 Pops a value and sets it to the value found on the stack. Compiler If (successful) Stack +1 else Stack 0 Use sq_gettop(vm) to check if it was a success....

Revised thoughts on Squirrel Math

Been thinking a bunch about the vector math classes mentioned in the previous post (vec2, vec3, etc). I was ready to try proposing “something” to let you add .anything to a class to access members hidden in (say) userdata. As it turns out, that already works. The _get and _set metamethods talk about indexes in the documentation, so I mistakenly assumed they were for creating array-like syntax (maybe they are too), but in actuality they do exactly what I want: let you handle ....

Squirrel Class Notes

Squirrel features both Delegates and Classes for creating types and providing default values and actions. They are mutually exclusive, meaning you either use a class or a delegate (attached to a table/array). The following is a collection of notes on Classes. Sample Class The class below features a constructor, metamethods (like operator overloading), and a few additional functions. Create instances with function syntax Creating an instance is a lot like JavaScript....

Qk's Squirrel “Reloading Scope” Guide

This is a preliminary document. A first pass, a draft, talking through implementation notes from a piece of a project with the working name “Qk”. It might be something cool. I’m not telling. ;D The programming language seen below is squirrel, but this specific nuance is something in my engine. Reloading Scope “Reloading Scope” is another name for the Global Scope of a script file. Take the follow code:...

SquirrelyJS – Squirrel Programming Language in the browser

Phew! Okay, my little science experiment from today (i.e. why I needed a makefile): SquirrelyJS. SquirrelyJS is a Squirrel Programming Language compiler and VM running in the browser. So it’s a bunch of JavaScript code, a bunch of C/C++ code compiled using Emscripten, all wired up to a shittyweb page. It’s barebones at the moment. You can edit/change/replace the code in the left side, and hit the Compile buttons to recompile it....

Barebones Useful Generic Makefile

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....

State of the Investigation

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*....

Emscripten 2: The Emscripting (or setting it up again, a year later)

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:...

Evaluating JavaScript to Native-App Packagers

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. ...

Squirrely things about Squirrel

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. ...