
The case against native engines - AshleysBrain
https://www.scirra.com/blog/ashley/28/the-case-against-native-engines
======
AshleysBrain
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.

~~~
versteegen
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...](https://www.scirra.com/blog/ashley/26/run-your-
construct-2-games-as-xbox-one-apps)

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

------
rdw
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.

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

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

------
Millennium
>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?

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

------
mwcampbell
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-...](https://chadaustin.me/2014/09/web-platform-limitations-part-2-web-
audio-api-is-a-mess/)

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

------
bluejekyll
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?

------
milesvp
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?

------
kelukelugames
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.

