
MonoGame.Js - dgellow
https://github.com/SamuelEnglard/MonoGame.Js
======
chuckup
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](https://github.com/TannerRogalsky/punchdrunk)

~~~
s369610
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](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](http://moaifiddle.com)

~~~
Tanner
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](https://github.com/TannerRogalsky/punchdrunk/issues/38)

~~~
s369610
Moai is opensource and the html host has been merged.
[http://github.com/moai/moai-dev](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](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!

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

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

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

------
s369610
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](http://hildr.luminance.org/Platformer/Platformer.html)

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

~~~
kevingadd
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/](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.)

------
sgehlich
Why do people write their libraries in ONE single unmaintainable file?! I
don't get it.

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

