Monogame: JSIL Based Implementation

[SamuelEnglard]

I saw the NaCl implementation to run in a browser but the flaw in that is that it only works in Chrome. JSIL is a program that converts CIL into JavaScript that will run in the browser. It includes XNA support (using Canvas to draw). I was thinking that using this for browser support may make more sense than using NaCl since this would be cross browser.

https://github.com/kevingadd/JSIL

[tomspilman]

If someone wants to work on that... it would be a fantastic project.

Most of MonoGame is not platform specific... my guess is over 70%. That would all port via JSIL no problem.

It would just be the core platform specific stuff... GameWindow, GraphicsDevice, Shader, Texture2D, etc. that would need to be almost completely re-written in JavaScript to call WebGL APIs.

[KonajuGames]

There are pros and cons to both approaches. With JS your entire source
code is readable as plain text. NaCl is compiled to native. JS is
available on more browsers (in this case the ones with available WebGL
support), and NaCl is only available on Chrome.

It would be interesting to see how it goes.

[SamuelEnglard]

In theory little would actually need to be done since he's written a lot of XNA specific code. Just take a look in https://github.com/kevingadd/JSIL/tree/master/Libraries

[SamuelEnglard]

(also wow you guys respond fast, wasn't expecting anything till tomorrow!)

[chaosnhatred]

maybe it would be good to inquire how supergiant ported bastion over.

[tomspilman]

I don't know what you are asking here then. If he has implemented XNA then there is nothing for MonoGame to do.

[SamuelEnglard]

A) He doesn't have everything done (no 3D for example which in theory could be done in WebGL)
B) Was more to alert you guys about its existence as well as work with him in cases where things don't work.

[tomspilman]

We are aware. Until someone wants to write the 3D support it is of limited value to most I think.

[SamuelEnglard]

I disagree but then again all my work is in 2D so...

[KonajuGames]

maybe it would be good to inquire how supergiant ported bastion over.

Supergiant Games ported MonoGame to NaCl, Google's native client for Chrome.

[kg]

I'd be glad to help anyone who's interested in doing this. I suspect large portions of the JSIL code written to interface with XNA could just be replaced by cross-compiled versions of MonoGame's substitutes. Most of JSIL's current XNA feature set is there specifically because a game being ported needed it.

One of the big obstacles to 3D is the lack of a solution for porting HLSL shaders. Does MonoGame have a solution for this (perhaps based on mojoshader or something)?

[tomspilman]

@kevingadd

Hey Kevin. It would be great for both projects to collaborate on this to make it happen.

replaced by cross-compiled versions of MonoGame's substitutes

That is what I expect as well.

I figure the only parts that need to be hand crafted are the very low level classes which talk to WebGL, input devices, sound system, etc.

One of the big obstacles to 3D is the lack of a solution for porting
HLSL shaders

We have a solution for that.

We currently convert the effect during content processing to GLSL format that MonoGame can use. As long as we cross-compile the right parts of the MonoGame Effect system then it should be able to read the XNB effect and work.

[kg]

Great! Maybe it would be worth thinking about involving a third party as well - I tend to love having projects be motivated by games since it keeps the engineering efforts focused.

The biggest mechanical obstacle for 3D is that filling an array of vertex structures is nearly impossible to express in idiomatic JS. Right now every struct instance in JSIL output is a JS heap object, which implies all sorts of awful performance consequences, in addition to the obvious fact that you can't put those in a WebGL buffer. For games with mostly static buffers, though, this might not be a problem in the short term - and in the long term I think there are ways to solve that. For things like input and audio, we'll probably be able to leverage the existing JSIL implementations as a starting point - they tend to conform to the XNA interfaces where possible anyway.

Reading XNB files is something I already support in cases where the proper reader machinery is available on the other end - off the top of my head I use XNBs for SpriteFont already (since why not) and a couple games with custom content processors work too. So reading shaders out of XNBs seems like it should totally be feasible.

[tomspilman]

I tend to love having projects be motivated by games

That would be great. Maybe @CartBlanche can tweet about it and find some existing MonoGame user that would be interesting in doing that sort of bleeding edge port?

filling an array of vertex structures is nearly impossible to express in idiomatic JS

Interesting.

So does that mean we cannot cross-compile our SpriteBatch implementation which internally packs arrays then feeds them thru GraphicsDevice.DrawUserPrimitive()?

you can't put those in a WebGL buffer

I know nothing about WebGL... how would you dynamically feed data into a buffer?

Reading XNB files is something I already support in cases
where the proper reader machinery is available on the other

We have all the readers in MonoGame. Could we just cross-compile them all with JSIL?

[kg]

You could instantiate an array of structs in SpriteBatch and fill it, but copying it into a WebGL buffer would require an additional pass to read all the attributes out of the structs and then pack them into an actual buffer full of floats/bytes. I think the Typed Array specification also has alignment requirements that don't match those of traditional OpenGL/Direct3D (for example you can't do unaligned reads of 32-bit or 64-bit values).

As far as filling buffers go, WebGL exposes the same general set of primitives as GLES - you make bindings, etc. and then pass it a pointer to your source data in order to copy it into a buffer. In the case of WebGL, that pointer comes in the form of a 'typed array', which is basically a fixed-size memory allocation from the JS heap that has a single type (though you can do some magic to make multiple arrays of differing types share the same underlying buffer - this is what Emscripten does to simulate a native heap.)

Pretty much anything that doesn't rely on p/invoke or unsafe code should be possible to cross-compile, though I expect we may find edge cases involving convoluted generics/reflection that I don't implement correctly. Even unsafe code would be possible to support if we need it, at least for constrained scenarios (like pinning a float[] that you just allocated).

I'd be glad to help in the hunt for an interested developer. I try to reach out on a regular basis and if it helps I can describe for them in detail the process for previous ports (Bytown Lumberjack, Soulcaster, Escape Goat, and a couple others that aren't public).

These slides from my GDC online talk (co-presented with the author of Emscripten - maybe worth checking out his slides too :) ) may help clarify how things work: https://dl.dropbox.com/u/1643240/GDC%20Online%20Slides.zip

[thefaker]

I think if there was a browser version of MonoGame it would seal the deal on some projects I am working on.

[SamuelEnglard]

@thefaker depending on what you need JSIL can work as it is

[thefaker]

Thanks @SamuelEnglard ...
A key project is a 3D app ... we currently have an XNA4 prototype ... we are aiming to target as many platforms as we can easily achieve... MacOSx, WinRT, iPad, Android .... If we could get it running in a browser too, that could really help.

[kg]

Just an update for anyone interested: Tom and I are actively looking into this (nothing concrete to report yet, unfortunately).

Alongside that, partial support has landed in JSIL for pointers, pinning, and writing/reading structs through pointers. Given this, an interested party could start experimenting with WebGL right now alongside JSIL's existing XNA support; if anyone is interested in this, feel free to contact me and I can provide guidance and address bugs you encounter.

Otherwise, patience is appreciated, and if you can provide links to games that you are interested in porting (given an eventual MonoGame JSIL port) that will be helpful in guiding our planning and discussions here.

[tomspilman]

Very cool stuff!

[xanather]

If you guys manage to pull this off that will be incredible!

[profK]

Part of the issue with a WebGL based port is that Microsoft does not yet and is not likely to ever support WebGL.

OTOH a Canvas based port of the 2D would be possible on pretty much every browser right now.

I don't know how well that would work with your codebase though, which I would gather probably implements your 2D as a layer over your 3D (thats what I would have done...)

Edit: Well Ill be damned, Microsoft caved for IE 11. Thats a real blink for them. They HATE OGL and see ti as The Enemy.

http://techcrunch.com/2013/06/26/microsoft-confirms-webgl-support-for-internet-explorer-11/

[nightst4r]

I'm sure their implementation will just route it right into DirectX =)

[profK]

Oh certainly... but putting any kind of OGL API around theirs must hurt.

On Sat, Jul 13, 2013 at 2:59 AM, Mark [email protected] wrote:

I'm sure their implementation will just route it right into DirectX =)

—
Reply to this email directly or view it on GitHubhttps://github.com/mono/MonoGame/issues/1422#issuecomment-20915813
.

It's always darkest just before you are eaten by a grue.

[kg]

A brief status update:

Your patience is appreciated. :)

[tomspilman]

@kg - Very cool!

Your persistence is even more appreciated! :+1:

[CartBlanche]

Saw this on twitter and retweeted it immediately.

Amazing work Kevin! Thanks for keeping us informed.

D.

On 29 July 2013 00:03, Tom Spilman [email protected] wrote:

@kg https://github.com/kg - Very cool!

Your persistence is even more appreciated! [image: :+1:]

—
Reply to this email directly or view it on GitHubhttps://github.com/mono/MonoGame/issues/1422#issuecomment-21693090
.

Regards,

D.

[SamuelEnglard]

Kevin, your work is amazing!

[profK]

When you think you're ready, Ill try porting TwoDEngine over to it.

Very exciting!

On Sun, Jul 28, 2013 at 7:00 PM, K. Gadd [email protected] wrote:

A brief status update:
[image: opentk_05]https://f.cloud.github.com/assets/198130/868998/5826c664-f7d9-11e2-9ce8-efa8c12a584d.png
Your patience is appreciated. :)

—
Reply to this email directly or view it on GitHubhttps://github.com/mono/MonoGame/issues/1422#issuecomment-21693021
.

It's always darkest just before you are eaten by a grue.

[lujunq]

are there any updates on this?

[kg]

Funding dried up. Might still happen eventually.

[CartBlanche]

@kg What sort of funding is required?

[kg]

The funding was being used to pay a contractor (hourly) to do a lot of the heavy lifting because I have other stuff eating my time. We got as far as a simple proof-of-concept using emscripten SDL2 and FNA (because FNA talks directly to SDL2):

http://hildr.luminance.org/SampleFNA/

But there's a lot of additional work that would have to happen for the broad set of released MonoGame titles to work. Even something as simple as that sample game hit some html5 rough edges (like music playback...)

[RiuSalvi]

Is there any updates on this monogame to web situation? I want to now more and to help if i can.