back
13 comments
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:

"An attempt to replicate the LÖVE API in the browser using moonshine." https://github.com/TannerRogalsky/punchdrunk

Looks like a big effort. It is interesting that they are trying to port by hand instead of using emscripten.

I used emscripten to port the MOAI engine (lua 2.5d engine) to HTML/JS, and it runs pretty smoothly (needs webGL).

you can see an older version of the player working here: http://moaijs.moaiforge.com/progrocket/index.html

I also created a jsfiddle style interface for it so you can play with it in the browser. http://moaifiddle.com

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

We are considering emscripten for other modules like love.physics: https://github.com/TannerRogalsky/punchdrunk/issues/38

Moai is opensource and the html host has been merged. http://github.com/moai/moai-dev , (moaifiddle is also opensource but doesn't actually build the moaijs.js file (it just uses a prebuilt one. http://github.com/halfnelson/moaifiddle)

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.

Best of luck!

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.
Less things to learn when coming from XNA/MonoGame background. Especially when JavaScript will start reminding a real language with the 6.0 release.
From the repo:

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

would be interesting to know how it performs compared to the code generated by il2js which is seen here running an xna 3.1 platformer exampler in html5 http://hildr.luminance.org/Platformer/Platformer.html

I know that the asmjs box2d outperforms the hand coded port, wondering if this holds true here

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

Why do people write their libraries in ONE single unmaintainable file?! I don't get it.
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.