The case against native engines | Hacker News Reader

The case against native engines

scirra.com

39 pointsAshleysBrain15 comments

Author/submitter here - just some context for HN, we make consumer software aimed at non-programmers, so the post is written to that audience. I think there's still interesting insight for other developers there though.

How do you cope with the amount of assets games of today want to ship?

Thanks, this post is also very useful to me as a hobbist working on a FLOSS game (RPG) construction engine. I hadn't heard of Cordova or of the ability to run Win 10 universal apps on XBox One and web apps on Wii U. Sounds like it might be a good idea to port from native desktop to HTML5/JS using emscripten, and then port that to these non-desktop platforms. Was there much work involved in porting to XBone or Wii U?

In [1] you wrote

  It's not clear whether this UWP app support is actually
  intended for games publishing, whether game UWP apps will
  be accepted for the Xbox, or if you're meant to use some
  other publishing option.

Do you know any more about that now?

[1] https://www.scirra.com/blog/ashley/26/run-your-construct-2-g...

The "it's not clear" quote was just excessive caution when Microsoft announced Xbox One support. It's turned out fine!

I've done a bit of game development for the Web. Unless things have changed very recently, a major performance bottleneck is draw calls. It feels a lot more like a mobile platform (< 100 draw calls) than a desktop platform (1000 draw calls). Unfortunately, it's quite an effort to reduce draw calls without making graphics compromises, curious how well Construct 2 does there.

If you have the data, I'm curious to know what proportion of games are fillrate bound vs draw call bound vs cpu bound.

In most cases, draw calls aren't a problem for us - the OpenGL API (and WebGL inherits this) is designed to be able to batch a lot of work with few draw calls, and the Construct 2 WebGL renderer uses a batching system accordingly. (Note we have a 2D game engine so it's a bit less demanding.) Of course you can make worst-case scenarios which issue lots of separate draw calls, but most cases work nicely. For example if you create 1000 of the same sprite in Construct 2, it can issue a single drawElements call to render them all in one go.

For 2D games where you can batch heavily (Textures in atlas, single material) WebGL is fine. And for games like that it indeed does not make sense to go native if it works fine on all target platforms. Except if you care about power consumption.

For modern 3D game, even in mobile, you do need way more than that and 100 draw calls is very limiting.

>asm.js is progressing in to WebAssembly, a more mature technology (still in development) with enthusiasm from all major browser makers.

If it's still in development, then in what way is it "more mature" than asm.js?

WebAssembly solves problems like growing the heap, as well as being a proper binary format that is smaller and quicker to parse. The design is definitely ahead of asm.js, which is really smart but still a bit of a backwards-compatibility hack.

Has the Web Audio API improved dramatically in just the past two years? From what I had previously read [1], it seemed like a disaster.

[1]: https://chadaustin.me/2014/09/web-platform-limitations-part-...

I've been working quite a bit with the Web Audio API recently (building a modular soft-synth), and I can confirm that it is a bit wonky, but ultimately more powerful than one might expect.

There are lots of little oddities that I had to research or discover to get the API to do what I want. For example, dynamic sound generation nodes will not run in certain circumstances where the system believes they are unattached from the audio output. These nodes also have a bad habit of garbage collecting their event listener functions.

Performance is definitely an issue as well, and I still get some audio tearing type pops and clicks despite quite a bit of optimization.

I think some of these issues are due to that fact that the Web Audio API spec is still being worked out (https://webaudio.github.io/web-audio-api/)! Some API components are deprecated in the newer versions of the spec, but have not been replaced in current browsers. Which leaves the API in a weird limbo state.

BUT! All that said. I've been pushing the API pretty hard to build this modular synth and it is working admirably. I think a game engine would have an easier time getting it to do what is needed. I'm always amazed at what you can do in the browser these days, Web Audio API included.

the article is too old. Web Audio API is mature platform now in 2016. See http://molgav.nn.ru/rtfm/index.html for example. Molgav uses hundreds of instruments from guitar to piano, library of thousans of songs, it works on desktop and mobile.

People have been saying this for a while, but this question is only going to get to continue to lean more and more in the direction of html5 clients in general.

It's the easiest method to develop cross platform applications. Things like Electron make it possible to bundle apps to make them look and act like native apps.

This post is mostly about performance, and secondarly about a team's ability to focus. Which this allows them to do and deliver to many different platforms. With the rise of webassembly this will only get better.

Is native finally something of the past? Or will this end up just being a rehash of the Java JWT?

So this probably just shows my ignorance, but I was under the impression that modern browsers isolated running js to running on a single processor? The only part of the article to touch on this was the part talking about the operating system possibly running on another core. It seems like the elephant in the room.

Is it just not true any more that browsers isolate js to a single thread?

I love Construct 2 because it is easy to use. I made my first game on it and it was the only one that launched. However, Construct games have notable performance issues and as a programmer, we can make things in other engines just as easily.

Reply on news.ycombinator.com