Jump to content

Postbug Technical Overview: Compiling C# to Javascript


HemingwayGames
 Share

Recommended Posts

My new blog post is an overview of some interesting aspects of the technology I used to create Postbug. The game was developed in C# and compiled to Javascript using Erik Källén's Saltarelle Compiler. This allows for the game to be developed with a statically typed language and run in the browser on a wide range of platforms. The game uses the Pixi.js library to render GPU accelerated graphics with WebGL.

 

You can find the blog post here: http://hemingwaygames.com/blog/postbug-compiling-csharp-to-javascript

Link to comment
Share on other sites

I think you may want to fix the link which at the moment links to this same page - very nice and meta but probably not what you wanted? :)

Anyway, I had not heard of Saltarelle before. I thought it's an interesting idea, albeit one that I would never use (why would you want to use a more verbose language when you could do it directly in JavaScript or TypeScript if static type checks are your concern). Anyway, I can see it appealing to lots of Unity programmers out there and all the other people that still use C#.

 

So I went to their home page to check it out, and stopped reading after the very first sentence: "you can leverage all the advantages of C#, such as static type checking, IntelliSense (the kind that works) and lambda expressions when writing code for the browser."

 

Seriously, that makes you wonder how much this person knows about JavaScript and whether the software can be trusted at all. Did you find the performance was acceptable? I assume most common commands (such as Array.sort) would have to go through some kind of emulated .NET library, and would be really slow? What was your experience in terms of speed of the resulting JavaScript and did you do any test comparing it to raw JavaScript?

Link to comment
Share on other sites

Hi Gio, thanks for pointing out the issue with the link. It's now fixed :-)

 

TypeScript is a prime example of source-to-source compiling and in the blog I referenced CoffeeScript's wiki page which provides an extensive list of languages that compile to JS. I don't see a reason why a language (whether it's Javascript, C#, c++, java etc) should be bound to a particular platform and this list highlights the demand for source-to-source compiling.

 

In regards to Unity, the next version is using a different technology to compile the engine to JS. They're using the LLVM and Emscripten toolchain which compiles c++ to asm.js. One of the aims of asm.js is to provide static typing hints to the JS engine which it can then perform additional optimisations by mapping the instructions to machine code during JIT. Unity actually have their own c#/IL to JS compiler for the scripting side.

 

In regards to Saltarelle, Erik Kallen has done an exceptional job and the tool is very stable. Most of my C# 4.0 code compiles to JS without any problems. In order to achieve such a complex task, I would assume his understanding of Javascript is sound. There's also other C# to JS compilers to choose from if this was a problem.

 

Regarding performance, I've found it lightning fast on desktop computers. It's amazing how fast Javascript engines are now with JIT compiling. My biggest concern with Javascript performance would be the garbage collector. 

 

I have the same concerns with you regarding performance and these are a number of things I would do when optimising:

 

1. Think about how the code would convert the code to machine code (which I'd also do if writing Javascript code)

2. Avoid creating large numbers of objects (eg creating temporary 2d vectors in a loop) to lighten the load on the garbage collector (btw this is not a Saltarelle problem)

3. Regarding .net libraries, I'd may consider wrapping a Javascript library instead. 

4. Avoid certain C# features which don't translate awkwardly such as yield

 

I think the important thing here is to tackle performance from a programing angle. eg how can we reduce load on the garbage collector and what time and space complexity are my algorithms. 

 

I haven't yet started analysing the performance on mobile devices, however I'll keep you posted on this. There's quite a bit to investigate in this space..

Link to comment
Share on other sites

Yeah, I just thought it was odd that he'd mention things such as lambda expressions as an example of the advantages of C# over languages targeted at browsers because, well, anonymous first-class functions are essentially lambda expressions and have been a feature of JavaScript since forever (moreover ES6 even provides the exact same syntax as C# for lambda expressions). Similar things can be said about IntelliSense-like tools, etc.

Anyway, I totally agree with you, making languages portable is a very good thing, and doing so addresses one of C# biggest problems.

But with all the Emscripten and "Unity to web" demos I have seen, size and performance were very noticeable problems. As impressive as these demos looked on powerful PC's, on other devices it became apparent that they could have been much more performing if they were made with raw JS (for which there is admittedly a lack of dedicated tools, and that may be another reason for some people to choose another language to start with).

If you could point me to a Saltarelle game or demo that works on a low-specced device, I'd be very curious to check it out. And I'm certainly interested in reading more about your experience porting your game to mobiles and tablets, I'll keep an eye on your blog.
 

Link to comment
Share on other sites

I agree with your performance concerns with Unity exporting to web. I think it's an ambitious project and I'll be keeping an eye on how it turns out. I'm guessing though the export would only be used for desktops and iOS and Android would use their respective native exports.

 

I initially looked at Unity, however the licensing for iOS, Android and Flash (at the time flash was supported) was too expensive for my needs. The non pro version also did not remove unused code from the engine so a vanilla iOS/Android install was 15-30MB. Back then I didn't want iOS/Android users to have to use a wireless network to install. 

 

Maybe there's a place for my small game library. A lightweight C# game library which compiles to JS and renders with WebGL. A solution for writing small arcade games :D. This is something I plan on working on for some game jams next year (if time permits).

 

Thanks for your interest, btw. I'll keep you posted on my progress with mobile/tablets.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...