Why HTML5, and the future of exporters

I am completly agree with 0plus1.

I don't say that html 5 is not the future for the WEB games (yes it is I think html 5 will have more features than flash) but for "games only" I don't think that the native exe will disappear or will be replace by a "simple" embeded html 5 game.

I'm sure of one thing : When Scirra said a sentence like "after the html 5 will be ok, we were be able to see for other export possibilities" at the beginning of C2, I wanted to help them and support so I adopt the earlier licence. (we have to be honest, C2 is a great product)

But if I was be able to see the future, and read before what I read in this topic (to resume exe is not the plan either), I would not have bought the earlier licence and stay with the free version.

Kyatric In fact I said "in theory" because in hte future it may be, but in practice have you seen my benchmark? html5 is not compiled, and it will probably never be and intepreted vs compiled will never be the same.

There will be room for improvement but we will never see bf3 on html5, at least not for a long time. This is to say that html5 will never be a viable solution for desktop gaming as games are moving towards incredibly complex (and optimized) engines that are not in the same league as anything that is made or ever will be made in html5. Example? Bastion has been made in nacl not in html5.

Pode Everything can be made in theory, but with what performances? There are effects that are hardware accelareted at driver level and webGL will probably never get them as driver manufacturers will have to code for too many cases. It's the same thing as directX vs openGL. DirectX is incredibly optimized right out of the box while with openGL there's a lot more work to do (in exchange of cross platform compatibility).

0plus1 : a shader is executed by the graphic card, so it's hardware accelerated.

And, by the way, interpreted can be faster than native, because the JIT has access to what the compiler don't : the execution context <img src="smileys/smiley2.gif" border="0" align="middle" />.

Pode are you seriously saying that an interpreted language can be faster than bytecode?!?

Do you have sources to support your claim? I'm always open to learn something new..

OK, I guess we shouldn't say "nearly as fast", since our own benchmark shows that at best HTML5 comes in at 25% the performance of native. What I think I really meant is that if you render on a GPU then it's always the same speed, since it doesn't matter whether the "draw sprite" command comes from a C++ DirectX app or a HTML5 WebGL app, it renders on the same GPU. The logic in HTML5 apps is indeed slower, but the important thing is to get hardware-accelerated rendering so the CPU is not weighed down with rendering, and can spend its time on the logic instead. When hardware accelerated rendering is in use, benchmarks then just show up the CPU difference between HTML5 and native, since as our blog post notes the GPU can render faster than you can send commands to it, so the benchmark is just measuring how fast the CPU can send draw commands to the GPU, which obviously native does better at.

For all intents and purposes WebGL and OpenGL are equivalent to DirectX in terms of features and GPU performance. We are planning to add pixel shaders and distortion meshes etc. to Construct 2 with WebGL, the only reason we haven't is we have long todo lists.

Also I think it's worth keeping benchmarks in perspective:

• compare Flash to native and you'll see Flash also comes in slower than native for the same reasons. So why did anyone ever use Flash instead of native? Because it's write once, run everywhere (or used to be until mobile came along), and this benefit largely outweighs the performance difference. I think this is an important comparison, since for a long time Flash was software rendered and wasn't even as fast as JS + WebGL - and yet it still conquered web gaming for many years!
• does your game have over 1000 sprites on-screen at once? If not, you will not see much performance difference between HTML5 and native - they should both manage 60fps just fine. So since many games are simpler and use low object counts, it could actually be said that the performance the user sees is equivalent.

Also, Javascript and WebGL can probably be sped up even faster than they are now.

So yeah we could make a bunch of native runtimes, but remember if your game already runs at 60 fps, using a native runtime will not bring you any observable performance increase.

The fact is webgl is not supported by all browsers.

And some chipset do not support webgl too and I am a great example with my laptop. But a native exe that uses directX or OpenGL works perfectly on my same laptop (but my home PC support it).

That's why my example with 250 sprites on the screen is very very slooooow in html 5 and almost perfect in native exe.

It is not (for me) a technologic performances problem.

I didn't say that webGL hasn't features or same features than directx and opengl, I just said that webgl is not the most compatible for now.

Your alpha test (exe wrapper) is unplayable on my laptop too. That's just a question of compatibility.

For now, WebGL is not 100 % compatible with all chips and browsers...

And if I take me again for example, if I want to develop a game wth a lot of effects with C2, I can't on my laptop, at the same as I'm not at home to use my home PC, just because of webgl ^^

I'm conscient that my laptop is not over great mega powerful (mouarf) but it has the capabilities to launch a unity 3D Game, a directX / OpenGL 2D games, an AGK games, a game maker exe games, a monkey games etc.. but C2 games, if the games is a little complicated (for the display) => nada.

Well, it can't launch Call Of Duty game lol (don't want to exagerate either), but "voila".

And I'm sure I'm not the only one that have a laptop that doesn't support webgl, they are dev, or they are gamers.

I don't want to be boring, I give just my opinion. I'm frustrated with C2 on my laptop like a probably gamer could be if he wants to test a game he can't because of compatibility issue with webgl.

In fine, you said "web game for many years" but if we want to make a game and not a "web" game, with C2 we have to use html 5 too with the webgl etc...etc.. that (and this is in my opinion) is not the best thing for now because of things I explained above.

But, be sure I follow future updates and look at C2 with attention. And I wait for the exe wrapper (with Awewsomium) witch is a good idea to permit user share their creation in a exe browserless distribuable format.

0plus1 : I'm not claiming anything spectacular. If your javascript engine is using a JIT, then for code properly coded, you can have the same perfs as a native binary, because a jit'ted code page in memory is *directly* executable.

That's why, in various benchmarks, you can have Java code beating C/C++ code, or Python faster than C, for example. A codetree that has just been evaluated by a JIT can be more efficient than compiled-ahead code, with the compiler having no information of the context.

That's also why, on iOS, webapps can't use the various acceleration in Nitro. JITting means that you are flagging some memory page as "executable". That could be a potential security flaw for Apple (not if they properly designed their browser, but they are �ber strict about that kind of things...)

Pode I see your point, but JIT is an implementation where code gets translated to bytecode at runtime (same as what JVM does) which is sort-of compiling it.

I would like to see the benchmark you are talking about, and while they are more than possible for certain tasks, we are talking about gaming and I still see .exe files in my steam directory with small exceptions for flash and JAVA.

The problem as I said and as is pointing — is the compatibility issues. I'm a web developer and still in 2012 I have to waste time for cross browser compatibility because there is too much fragmentation and I'm not speaking of internet explorer, but also about the differences between firefox and Chrome.

HTML5 is not yet a standard and everybody is basically doing what they want. Without going too far in c2 the audio is still an issue across browsers (especially mobile).

And that is the problem right now, fragmentation, not all browsers supports webGL and when they do each one of them is doing it differently as well as not every browser supports webcams/gamepads and so on.

HTML5 will be the future for application development because everything is moving toward the web for games I'm not completely sold. Flash is becoming geared toward gaming as they lost the race for audio/video and as much as I hate him, flash has the advantage of being the same everywhere, regardless of system/browser, there is also unity3d that has the webplugin that powers game that have graphics light years ahead of html5.

In the end are the developers that steers the market and I've yet to see someone able to monetize html5 games.

It's still an open match, only time will tell who will come out as winner, that is the reason why other "game makers" allow exporting to several different platforms, because they now that they may be betting on the wrong horse..

0plus1 : I completely agree with you on the fact "use the tool that fits the job". I use C2 and produce HTML5 games and app for client, in controlled environment, where I know what I do works. For the moment, it's doing what I want it to do, cheaper and faster (for my client) than other solutions, so for me, it's a win <img src="smileys/smiley1.gif" border="0" align="middle" />.

Anyway, I also do code in OpenCV and C/C++, and for the moment, nothing can beat that in pure speed...

This thread has been a very interesting read. I can see everyone has their opinion, usually supported by relevant facts. As someone else said, I think it boils down to what your intentions are for making games.

I am in the position of having some pretty specific projects in mind that are not very graphically intensive, and which I want to be fully web-based. I am also not looking to make any (or much) money from making games.

I can see how, if your position is different, that the pace and lack of platform coverage could be frustrating. It is a very interesting and dynamic time to be making indie games, but that doesn't mean it's easy.

—: the reason WebGL is not always supported is browsers blacklist certain drivers for security reasons.

In our EXE wrapper, we can turn off the blacklist, so WebGL is always on and enabled regardless of the user's computer. That should help ensure the EXE is always fast.

Ashley : I wonder if this is not my laptop graphic card (intel gma 3150) that is not compatible with webgl. I tried to find some information about it and this chipset but I didn't find anything.

For the exe wrapper that could be a good idea to be able to avoid blacklisting.

Pode <img src="smileys/smiley1.gif" border="0" align="middle" />

I have also coded games in several languages, and surprise, the only one I actually finished has been made in c2.

This is what makes me really angry, I tried all game makers on the market and construct is a masterpiece, easy, intuitive and fast, and I can't accept that such a marvellous tools will be relegated only to prototyping for the opinable (at least in my opinion) choice to support just html5.

I understand that this is a two man operation, but you are really sitting on a goldmine, you could charge 150$ a year for a iOS and the same for an android exporter like your competition is doing and you would sell it like bread. Now is the time where everybody wants to be on the appstore and not on kongregate and I think you should really consider riding the wave..

If we compare with competitors, it's certain that C2 is the only one that support ONLY Html 5 ^^

Pode <img src="smileys/smiley1.gif" border="0" align="middle" />

I have also coded games in several languages, and surprise, the only one I actually finished has been made in c2.

This is what makes me really angry, I tried all game makers on the market and construct is a masterpiece, easy, intuitive and fast, and I can't accept that such a marvellous tools will be relegated only to prototyping for the opinable (at least in my opinion) choice to support just html5.

I understand that this is a two man operation, but you are really sitting on a goldmine, you could charge 150$ a year for a iOS and the same for an android exporter like your competition is doing and you would sell it like bread. Now is the time where everybody wants to be on the appstore and not on kongregate and I think you should really consider riding the wave..

^^ +1

HTML5 definitely have it's place and in a few years might become where Flash games are now. Still...Flash games are a fraction of the monetizing possibilities.

Why just support HTML5 when you can support HTML5, Flash, Android, iOS ?

I understand that this is a big task, but Stencyl is also only 1 or 2 people team. I would seriously prefer to use Construct 2 but I cannot if i can't get my game properly to iOS and Android as well as HTML5.

This is the only thing that keeps me from embracing Construct 2 as a end to end solution. Using different tools to get this done negates the ease of use of Construct and the value for money proposition. I too wont mind paying an extra fee per exporter "plugin" - MMF2 and Stencyl has followed the route.

I also don't want to sound like an $$, but I think it's better to say it and might hopefully get this features than just keep quiet and go away. I really do love Construct 2 - it's fantastic as an editor. Just a bit limited in export option.

Anyway at the risk of flogging a dying horse...

I also respect Scirra's right NOT to do this and ride bet on HTML5 only.