Also, if you like Lua, the LOVE library is excellent for writing games, and someone has recently started porting it to the browser - pretty impressive I think:
Oh, wow, that's very cool! How did you deal with the 3rd party dependencies? Is that open-source anywhere? I would love to see what you had to do in order to get that working.
I'm the author of the above-mentioned punchdrunk, by the way. There were three reasons that I decided to do the port by hand: 1) I wanted to preserve mobile support by falling back to 2d-canvas when necessary. 2) I wanted to really cut my teeth on some graphics programming because I'd never really had the chance before. 3) I just couldn't get the damn thing to compile with emscripten (which I why I'd be very interested in your process).
Third party dependencies are all statically linked and compiled by emscripten too, so the moaijs.js includes box2d, lua, libpng, libjpg, tinyxml all compiled in from their sources.
This repo needs some TLC and the Visual Studio stuff removed. The concept is interesting, but it doesn't give any real reason to use it over things that are firmly planted in the JS consciousness (i.e. Phaser)
Hey It's Shmueli, the creator. I've since removed the VS stuff and have been trying to give it more of the TLC it needs. I fully admit that if you're in the JS world it might not be the best (haven't personally used other JS game frameworks) but as CmonDev it's more for those coming from C# and XNA or those looking to port an XNA game.
«JavaScript game libary that is based on the XNA/MonoGame API
The only ""dependancies" on modern browsers the API takes is the HTML canvas object and the addEventListener function. Otherwise the code is valid ECMAScript 3 code and should work if those two are pollyfilled.»
1. That's JSIL not il2js (separate projects, similar goals)
2. That's using JSIL's custom JS xna reimplementation - not necessarily comparable. If you want to compare with real monogame, you want http://hildr.luminance.org/MonoGame/Platformer2D/ which is Actual MonoGame compiled to JS. (Not that it's fast - MonoGame does things that are fast in desktop GL but very bad ideas in WebGL)
3. JSIL output is currently slower than hand-written JS in most cases because VMs are really bad at optimizing .NET-style static types. A future version of the ASM.js spec will enable using it for managed languages like C#, at which point a compiler like JSIL will be much faster than hand-written JS.
P.S. Unity's IL2CPP compiler provides asm.js-level performance for a subset of C# right now; they use it for the HTML5 version of Unity. It's pretty awesome and well-engineered, so I'm hoping they open-source it. (I worked on it in the past, albeit briefly.)
Having written numerous large .js files in my time, a contributing factor is that it's an enormous pain in the ass to split javascript up into smaller files. You have to update a bunch of <script> tags everywhere, or depend on a specific module loader (which means all the libraries and existing code have to be updated to support that module loader, in some cases including third party code), or...
I eventually wrote a stripped-down loader for JSIL to address this problem (so I wouldn't have to force end-users to adopt something specific like require.js or something), but there are still real usability issues for maintaining a codebase full of small .js files (like the near-fixed overhead per-request for javascript). Ideally ES6 module loading will address some of this, and for the rest, I guess everyone will have to adopt a build process for javascript (ICK) and give up on instant reloads after file changes.
kevingadd pretty much sums up why I did one file. I do agree that such large files to get hard to maintain. To help with that I used regions, though I admit since it's a VS only feature it's of limited use.
"An attempt to replicate the LÖVE API in the browser using moonshine." https://github.com/TannerRogalsky/punchdrunk