I've been thinking on doing some work on this, even tho there is base for JSIL I would like to think of other options as well. Current options on getting C# on Web are:
- JSIL (may translate C# badly in some cases, but it does produce files runnable even from android)
- NaCl (requires browser plugin, but will be more precise in running C# than JSIL)
- PNaCl (Chrome only, no plugin required)
@tomspilman @KonajuGames @dellis1972 What are your thoughts on this?
harry-cpp
All 70 comments
I've done a little research into JSIL, and found something that I think you guys will find very interesting.
http://hildr.luminance.org/MonoGame/Platformer2D/
It looks like somebody (looks like a contributer to JSIL, actually) decided to do this already. His code can be found at https://github.com/kg/MonoGame/tree/JSIL. The fact that this produces something that we can run on android is also really fantastic.
EDIT:
Apparently we have tried to do this before, and that code never got merged because we were merging another JSIL implementation? What ever happened to that?
WardBenjamin
on 30 May 2015
@kg is the creator of JSIL....
Also in the main JSIL repo there is some code dedicated to porting MonoGame to web(https://github.com/sq/JSIL/tree/master/Libraries/MonoGame), but the way MonoGame planned to do it is a bit different(create a solution for MonoGame, and use that instead of WindowsGL dlls).
Also @WardBenjamin do "Protobuild.exe --generate Web" I think, it will generate JSIL web stuff MonoGame already has.
harry-cpp
on 30 May 2015
@kg is the creator of JSIL....
I didn't know that :)
I'm going to check that out, thanks!
WardBenjamin
on 30 May 2015
A client sponsored some recent work on MonoGame & SDL2 (via p/invoke and emscripten) integration for JSIL that is almost ready to merge. I'll try to remember to mention that here when it's available.
On May 30, 2015 8:59:01 AM PDT, Harry [email protected] wrote:
@kg is the creator of JSIL....
Also in the main JSIL repo there is some code dedicated to porting
MonoGame to
web(https://github.com/sq/JSIL/tree/master/Libraries/MonoGame), but the
way MonoGame planned to do it is a bit different(create a solution for
MonoGame).Also @WardBenjamin do Protobuild.exe --generate Web I think, it will
generate JSIL web stuff MonoGame already has.
Reply to this email directly or view it on GitHub:
https://github.com/mono/MonoGame/issues/3895#issuecomment-107056912
- kg (mobile)
kg
on 30 May 2015
A client sponsored some recent work on MonoGame & SDL2 (via p/invoke and emscripten) integration for JSIL that is almost ready to merge. I'll try to remember to mention that here when it's available.
@kg Sweet!!!
harry-cpp
on 30 May 2015
NaCl
PNaCl
I don't think either of these are good solutions as they are specific to just one or two browsers. The only path I see that works on all browsers and will be fairly fast on most of them is cross-compiling to JavaScript.
This is why we decided on JSIL in the first place.
tomspilman
on 31 May 2015
Ok, I'm going to wait up to a month to see what's going to happen with what @kg talked about. After that I'll start working on this using JSIL.
harry-cpp
on 31 May 2015
harry-cpp
on 22 Jun 2015
It will be interesting to see when WebAssembly becomes usable... maybe a year or two if we're lucky. Until then JSIL is still a good path for us.
tomspilman
on 22 Jun 2015
At some point you'll be able to use WebAssembly with compilers like JSIL and GWT, hopefully. It's on the long-term agenda.
kg
on 22 Jun 2015
The initial monogame work is almost complete (been doing it in my spare time and paying out of pocket since the sponsor bailed), so I'll have a demo & some associated documentation on the JSIL wiki out soon for people to use as a starting point. It's the MonoGame version of the platformer2d sample, running against a fork and using emscripten'd SDL2. Gamepad input, audio, opengl, etc all work. Getting something like this working in trunk monogame will be a challenge but once this is polished up it will be a good proof-of-concept for how to do it.
kg
on 4 Jul 2015
Here's the working demo.
http://hildr.luminance.org/SampleFNA/
https://github.com/sq/SampleFNA
It's using FNA instead of trunk MonoGame, because FNA's use of SDL2 as its single backend made the initial port easier. The general approach should be viable for MG, since it lets you keep all of your PInvoke-based code (that talks to GL or whatever). It's an approach that's also compatible with writing a separate web backend that reuses a subset of the existing native code, instead of reusing all of it and patching up specific spots with JS.
There are a handful of issues left to fix but it's a pretty good proof-of-concept for something like this.
kg
on 5 Jul 2015
Crashes in IE11 on Win 8.1
Unhandled exception at http://hildr.luminance.org/SampleFNA/bin/JSIL/FNA,%20Version=0.0.0.1,%20Culture=neutral,%20PublicKeyToken=null.js line 11486:
Unable to get property 'bufferSubData' of undefined or null reference
SamuelEnglard
on 6 Jul 2015
Last time I tested it, IE's OpenGL support was too old, check the error console. If it's something other than GL support I can fix it.
FWIW, that is a major downside to the approach of using emscripten-compiled SDL2 or otherwise: Existing graphics stacks are still pretty heavily dependent on a full GL feature set, and WebGL is more of a stripped-down, crippled GLES.
kg
on 6 Jul 2015
Guessing WebGL 0.94 is too old. Aww :(
SamuelEnglard
on 7 Jul 2015
@kg Just FYI about:
For Song playback to work, you'll need to convert Music.wma into an ogg vorbis file called Music.ogg, next to the Music.xnb file created by the content builder above. Sadly, the content builder cannot do this for us. (JSILc may acquire the ability to do this in the future.)
Is not correct, the newest develop branch Pipeline Tool will convert song files to .ogg files as long as platform is set to DesktopGL / WindowsGL / Linux and processor is set to Song.
harry-cpp
on 4 Aug 2015
While setting up content manager with JSIL I found that: https://github.com/mono/MonoGame/blob/develop/MonoGame.Framework/Content/ContentManager.cs#L200 causes a crash.
It's not that big of a deal since I was not gonna use that part of the code anyway, but I thought it would be useful to mention it.
@kg For Xna/Fna are you loading xnb or raw(png, ogg, etc)? I started setting up raw loading of stuff.
harry-cpp
on 3 Dec 2015
Fna loads raw xnbs and we kept that intact, with the exception of streaming music - I used the browser's audio decoder for that. You could call out to libvorbis I suppose but you'd need to do the emscripten port of that thing yourself.
My hand-written xna stubs used the browser's image decoders (jpeg/png etc) but that's a really bad idea as browsers tend to have really buggy/inconsistent ones.
FYI, please file JSIL bug reports about crashes that only occur in JS builds.
kg
on 3 Dec 2015
Wow you are fast.
FYI, please file JSIL bug reports about crashes that only occur in JS builds.
I will, first I need to figure out a small code that can reproduce it.
harry-cpp
on 3 Dec 2015
Is this still supported?
@kg your demo link crashes under the latest Chrome:
Unhandled exception at http://hildr.luminance.org/SampleFNA/SDL2.js line 4:
Uncaught TypeError: Cannot read property 'getParameter' of undefined
That being said, the RPG demo from the JSIL page runs fine.
ashes999
on 30 May 2016
@ashes999 Works here, just tried it. Browser vendors love to break HTML5 games, so maybe file a bug report against Chrome. SDL2.js is an emscripten-compiled version of SDL2.
kg
on 30 May 2016
@kg I'm running Chrome 50.0.2661.102. How about you?
This doesn't exactly inspire me with confidence. I can imagine a fragmented user base complaining about my game crashing and/or not working, and being stuck without the ability to easily troubleshoot it.
Is there a well-defined subset that this should work with? Can I say something like "always works with the latest browser(s)"?
ashes999
on 30 May 2016
It probably requires WebGL and you don't have it. SDL2.js isn't something I wrote, so it's not under my control.
This doesn't exactly inspire me with confidence. I can imagine a fragmented user base complaining about my game crashing and/or not working, and being stuck without the ability to easily troubleshoot it.
Welcome to HTML5. It's not great.
kg
on 30 May 2016
Just gonna mention that MonoGame has shifted to using SDL instead of OpenTK so emscripten-compiled version may be an option for MonoGame as well.
harry-cpp
on 30 May 2016
@kg I worked directly on JS games in the past and experienced something similar. Thanks for clarifying. I think this is a pretty viable approach for now.
ashes999
on 30 May 2016
Bump.
Hi all, someone on Twitter was asking about the current status of MG's Browser support. Anything I can share publically? PM me if it is not public :)
Hope everyone is well!!
D.
CartBlanche
on 21 Oct 2016
@CartBlanche maybe it's not obvious, but JSIL works (with some caveats) with MonoGame. There are some good examples on the JSIL website that you can use. Whether this is stable/reliable enough for you or not, I can't say.
ashes999
on 21 Oct 2016
Only input is implemented, graphics/audio/loading content is not.
harry-cpp
on 21 Oct 2016
In theory they could give my MonoGameJs a try?
SamuelEnglard
on 21 Oct 2016
Any news about c#, monogame and web?
I would like to run my monogame projects in a browser and i do not know how.
RiuSalvi
on 4 Jan 2017
I would be interested in any updates too
bencrossman
on 25 Sep 2017
@bencrossman You have some psychic powers my friend :), yesterday I started working on MG Bridge.net implementation, most of the things aren't yet implemented, but I did get it to compile and run at least:
PS. I know about web assembly, I just have my personal reasons for wanting to do it this way.
harry-cpp
on 26 Sep 2017
That's awesome. Well done
bencrossman
on 26 Sep 2017
PS. I know about web assembly
WebAssembly for C# to JS still seems to be in development and not ready for our use, but i expect we will eventually support it.
tomspilman
on 26 Sep 2017
Status update: Mouse, Keyboard and Song implemented.
harry-cpp
on 27 Sep 2017
@cra0zy Any update on your Bridge.net implementation? It looks really exciting! :smile:
TheSpydog
on 6 Apr 2018
Nah, waiting for webassembly to mature. I could get Bridge.Net version working, but it requires a lot of work and I don't have any incentive to do so.
harry-cpp
on 6 Apr 2018
@cra0zy - Did you look at Blazor?
tomspilman
on 7 Apr 2018
@cra0zy - Did you look at Blazor?
Its meant more for writing html applications so to speak, it does not offer any good way of invoking a lot of stuff we need (like webgl for example).
harry-cpp
on 7 Apr 2018
it does not offer any good way of invoking a lot of stuff we need (like webgl for example).
What would be a "good way"? They say it has support for invoking Javascript from C#.
tomspilman
on 7 Apr 2018
A good way is something like https://github.com/rustwasm/wasm-bindgen for .Net. Also note that Mono's WASM support is just the Mono interpreter emscripten'd. Your C# is not AOT compiled to WASM as might be expected (though that's a goal for them).
cretz
on 7 Apr 2018
What would be a "good way"? They say it has support for invoking Javascript from C#.
Doing that per each call gives slow performance.
Workaroubd could be to write part of the framework on the JS side which is not efficient either (time spent wise plus the code would still not be that fast).
harry-cpp
on 7 Apr 2018
Yeah I was playing around with Blazor. In my opinion until web assembly can access things like the dom/js api without javascript. best solution is using bridge - c# to JavaScript.
But I did see a issue posted in Blazor : https://github.com/aspnet/Blazor/issues/1212
they were talking about maybe inlining js using bridge/ retyped.
samuelGrahame
on 8 Aug 2018
harry-cpp
on 19 Aug 2018
@cra0zy will be there new updates about your progress?
YogurtTheHorse
on 23 Sep 2018
harry-cpp
on 23 Sep 2018
Hello @cra0zy,
I've been interested in your thread and the idea of running MonoGame inside the browser, what do you think of Web Assembly and Blazor?
I think Web Assembly would be really ideal for MonoGame, DLLs can be loaded rather than having to generate JS.
I am also interested in Web VR and I think MonoGame could be used for that in the future.
What do ya think?
LukeTOBrien
on 12 Jan 2019
I've been interested in your thread and the idea of running MonoGame inside the browser, what do you think of Web Assembly and Blazor?
WebAssembly is way too experimental for C#, Blazor is slower than Bridge.NET.
I think Web Assembly would be really ideal for MonoGame, DLLs can be loaded rather than having to generate JS.
That would be a horrible way to compile a C# game for web, TLDR. is you want to convert C# to WebAssembly, not make the C# runtime available on web, ie. Unity for example uses IL2CPP + Emscripten.
harry-cpp
on 12 Jan 2019
WebAssembly needs a GC -> Access to DOM -> Access to -> WebGL
samuelGrahame
on 14 Jan 2019
@cra0zy : It seems you have benchmarked Blazor vs Bridge.Net regarding speed execution. Would you mind sharing it please?
Also, why packaging MonoGame as compiled assemblies, instead of truly "native" wasm modules, would be horrible? The later would probably be faster to load (no need for the Mono VM to be sent) and faster to execute (truly wasm, so less indirection). But besides this, are there more drawbacks to this approach?
codec-abc
on 14 Jan 2019
To answer both your questions, I have not benchmarked it as it would be redundant to do so considering you would have to make a mandatory copy of each vertex/index array you pass to webgl + you would have to call javascript code multiple times just to get access to WebGL/Input/Audio/etc.
harry-cpp
on 14 Jan 2019
There's more nuance to this than vertex copies I think. Would be neat if anyone got MG running on Blazor for comparing perf.
Jjagg
on 14 Jan 2019
At the moment I believe wasm was released as a MVP at version one, so it
doesn't have a lot of the features needed.
I have also heard that wasm is slower, at the moment, than JavaScript, and
the Blazor startup project is slower than I would expect from a pure
JavaScript one,
As wasm is still version 1 and doesn't have the supported features, a
benchmark would be misleading at this time.
But I do think it's something to keep an eye on, I think wasm will develop
more the the feature needed and probably will become a better option than
JavaScript in the future.
On Mon, Jan 14, 2019 at 6:04 PM Harry notifications@github.com wrote:
To answer both your questions, I have not benchmarked it as it would be
redundant to do so considering you would have to make a mandatory copy of
each vertex/index array you pass to webgl + you would have to call
javascript code multiple times just to get access to WebGL/Input/Audio/etc.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MonoGame/MonoGame/issues/3895#issuecomment-454102189,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APamFRhvoBB0oqguAyoO4J8Y4PWkyb8cks5vDMargaJpZM4Ewl_n
.
LukeTOBrien
on 14 Jan 2019
There's more nuance to this than vertex copies I think.
You need to invoke JS to access WebGL/Audio/Input :/
harry-cpp
on 14 Jan 2019
How slow is Blazor compared to JS? if this something like 2x or even 3x times slower it can still be useful and would probably improve over time. Also, at least in Firefox wasm <-> Js calls are now quite fast.
So a first version of MG running with blazor isn't gonna beat JS right now in term of speed and app size, but it doesn't mean it would be bad. Actually, I would be surprised if performance is so terrible that it would be unusable.
codec-abc
on 14 Jan 2019
I think also we need MonoGame that is targeted toward .Net Standard -
Perhaps the 3.8 release?.
Blazor is a ASP.NET project and uses .Net Core, at the moment it uses Mono
to compile to wasm but in the future that could switch to CoreRT.
On Mon, Jan 14, 2019 at 6:48 PM codec-abc notifications@github.com wrote:
How slow is Blazor compared to JS? if this something like 2x or even 3x
times slower it can still be useful and would probably improve over time.
Also, at least in Firefox wasm <-> Js calls are now quite fast
https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/
.
So a first version of MG running with blazor isn't gonna beat JS right now
in term of speed and app size, but it doesn't mean it would be bad.
Actually, I would be surprised if performance is so terrible that it would
be unusable.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MonoGame/MonoGame/issues/3895#issuecomment-454116750,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APamFd5b2atTx76YLLVvJAfG8FnhLNZwks5vDNEWgaJpZM4Ewl_n
.
LukeTOBrien
on 14 Jan 2019
This is not a 1 to 1 example of how mono would perform in Blazor.
But i have created a project that would allow for winforms in the browser (still alpha)
Blazor is pretty slow for a simple winforms application - could you imagine a game running 60 frames a second
I have made a port to blazor and bridge.
Blazor Rep:
https://github.com/samuelGrahame/ClassicFormsBlazor
Classicforms with bridge and Blazor DLL
https://github.com/samuelGrahame/ClassicForms
I have made a gif recording as how much the js invoking overhead.
Blazor Version
Bridge JS
samuelGrahame
on 14 Jan 2019
Cool!
Interesting result. I ran the Blazor project and had the same result. Interestingly enough the major performance hit seems to happen only in wasm code. Not even when going from Js to wasm nor GC.
So I am wondering what kind of code could result in so long operations.
codec-abc
on 15 Jan 2019
I am going to covert to the latest version of blazor - currently running 0.4. they have 0.7
samuelGrahame
on 15 Jan 2019
I have done it for a even simpler page where I have a div that take the full page and update a line of text on each onmousemove event. I expected the processing to be near 0 for the wasm operation and only have repaint operations (and maybe layout). It turns out that my CPU is not idle most of the time but only ~30% of the time. Repaint take around ~6%. Wasm account for ~35% of the time which is huge! I didn't expected Blazor to perform so poorly performance wise. I wonder what is responsible for such low performance.
codec-abc
on 15 Jan 2019
This seems confirmed by this Reddit thread As such MonoGame would probably run terribly except for some toy applications. On the other hand, the day C# can be compiled directly to wasm (without needing the mono VM) performance could be nice enough to be used.
codec-abc
on 15 Jan 2019
Mono wasm is compiling C# to wasm, you're not losing time there unless you fall back to the interpreter (this should only happen in rare cases). That reddit thread is from 8 months ago so results that old should be treated as meaningless for a runtime in early development like this.
If you're seeing bad performance the only way to truly understand it is profiling, but in general some info:
- Cross-language inlining (wasm <-> js) is a thing in Firefox now and might also be available in V8 soon (I'm not certain there). I expect JSC will have it eventually too. So calling between environments is not implicitly a problem, as long as the JS bridging functions are cheap.
- The biggest interop hurdle you need to worry about is things being copied into and out of the wasm heap. It's not possible to avoid copies to/from the heap for JS strings, because JS strings have a bad API. For things like vertex and index buffers this should not be a problem - you can create ArrayViews that point into the wasm heap and then pass those to WebGL APIs when performing uploads. If you're manually copying in/out you're simply not bridging to WebGL correctly. If you want to marshal structs in/out of wasm you will eat a cost there too (either copying into JS objects or indirecting with properties).
- Some of these interop hurdles apply to Bridge (and JSIL, back before I stopped maintaining it) just like Wasm. If your vertex buffer is filled with structs you need some marshaling logic to actually turn it into something you can upload into WebGL. I don't know how Bridge solves that but JSIL solved it by using marshaling wrappers that treated the typed array as permanent storage for struct properties, which is complicated - and copying struct objects into a buffer manually once per vertex is also a slow, awful approach. Wasm-compiled C# will not have this problem, memory is memory.
- Passing JS objects around (and across the JS<->wasm boundary, in particular) is expensive and will be until host objects (anyref) are shipping in every wasm runtime. This is because you have to maintain an id<->object table on the JS side so that you can pass numeric object handles into/out of wasm. In many cases though you don't need that many host objects - MonoGame isn't going to be using a ton of them. Test cases like 'render a bunch of dynamic HTML' are the opposite of a good benchmark here because they rely heavily on both host objects and calls into non-JS APIs.
- In both cases (bridge and wasm) you need to actually profile your test case and see why it's slow. It's often a result of making a silly mistake or of a bug in one of the libraries you're using, and not a problem with the compiler or runtime. Using something like react or jquery from wasm is likely to perform very badly because react isn't designed for a runtime environment where strings and objects have high interop cost, but it would be possible to design a virtual DOM API for wasm that would be high-performance by making use of the wasm heap directly.
Anyway, in conclusion I think it is possible for both Bridge and WASM versions of MonoGame to perform okay right now, and in the long term WASM will wipe the floor with Bridge because you are never going to get native-level computational performance out of JS for things like vertex buffers and stuff. JS runtimes simply aren't smart or consistent enough to optimize that code for you (which is one of the reasons JSIL ended up being a dead end).
Context: I was one of the original designers of WebAssembly and I review some of the pull requests for mono's wasm support.
kg
on 15 Jan 2019
Thanks for the detailed answer. In case you want to take a look I created a repository for a analyzing performances. for the case I talked earlier: moving the mouse over an area and showing the move position by updating text inside a div. On both Firefox and Chrome the CPU usage is very high for a simple application like this. In the last commit I even removed the DOM update (so basically I just subscribe to an event and do nothing when it is fired) and the CPU usage is still quite high. I agree with you on profiling but analyzing time spent inside wasm code isn't easy. This is what I got:
and this isn't giving much hint about what is wrong (assuming there is something wrong).
codec-abc
on 15 Jan 2019
Thanks so much for that explanation @kg.
Jjagg
on 15 Jan 2019
- , but it would be possible to design a virtual DOM API for wasm that would be high-performance by making use of the wasm heap directly.
@kg If you don't mind, can you give me a simple example of calling a DOM related function in the most effective manner?
I know about: https://learn-blazor.com/architecture/interop/
harry-cpp
on 15 Jan 2019
@kg: I found a more up to date benchmark (September 2018) and an issue from the blazor repo where member of the Blazor team say that saying a 100x time slower code (comparatively to desktop) is pretty standard at this point. Also, it doesn't seems the team focused on performance lately, because it is working well enough for their uses cases. Also, the ongoing work to get full AoD wasm compilation with Mono will certainly improve the situation. So my point is is that MonoGame would probably run terribly today and probably won't be usable for much things. On the other hand, getting something that work with mono-wasm today would allow developer to take advantage has it as soon as the mono-wasm AoT wasm compilation will land.
codec-abc
on 15 Jan 2019
harry-cpp
on 10 Mar 2020
@harry-cpp : Nice! Is MonoGame close to be WASM compatible?
codec-abc
on 10 Mar 2020
Yes, yes it is.
harry-cpp
on 10 Mar 2020
Would be incredible to see a MonoGame instance as a component for Blazor.
May even be made to run on a "separate thread" by running in an Iframe, or running logic in a WebWorker.
skyne98
on 11 Oct 2020
Related issues
rds1983
·
5Comments
monsieurmax
·
5Comments
harry-cpp
·
5Comments
MichaelDePiazzi
·
4Comments
bjornenalfa
·
5Comments
Most helpful comment
Yes, yes it is.