Then, Electron arrived (basically it's a way to bundle your website in a package together with the Chrome browser and pretend you created a native app), and I thought:
"Woha! Why not make a real native app out of my WebGL game? I only put it into Electron and that's it!"
I did that, and Electron worked surprisingly well. Nice piece of software. But the result wasn't very convincing: Although I put a lot of effort into making the electron app feel like a native app instead of a HTML site, it had a lot of drawbacks like input lag, lack of hardware, 3D and fullscreen settings, bad working cursor locking and similar.
The port was done within a handful of weekends and the game is now a native Win32 C++ program. You can try it if you like.
For now, I'm developing my game further in C++. And hope to have it finished within the next months. You can follow its progress on its website, if you like.
26 comments, already:
It is important to be first.
First - 23 09 16 - 11:57
I am the second one First.
Second - 23 09 16 - 12:11
Am I first too?
1st - 23 09 16 - 12:17
valarionch () - 23 09 16 - 13:04
It will be interesting to review your entry in 5 years. :)
mark - 23 09 16 - 13:09
valarionch: Why would it?
disconnect3d (link) - 23 09 16 - 13:21
I’m curious if you captured any perf traces that might reveal the issue on the JS implementation. Are you planning on filing a Chrome bug with your repro that demonstrates the input lag?
Brandon - 23 09 16 - 14:14
There are multiple bug reports like this already in the tracker made by other devs, and all of them were closed, with the explanation that Google devs do not have the intention to fix this. When I read that I started the C++ port.
niko - 23 09 16 - 14:30
You could probably improve the feel of the game in the JS version by offloading the WebGL calls to a web worker. A preliminary web search leads me to believe that it’s only supported in Firefox, though.
Kyle - 23 09 16 - 14:52
@valarionch are you just saying node.js because buzzword? it’s the exact same engine as Chrome. it won’t be any faster.
crunchwrap - 23 09 16 - 15:43
sessamekesh - 23 09 16 - 16:00
EDIT to my last comment – it’s a valid question, but I think the answer is still “no, keep it browser and WebGL. A Node version would likely run into the same problems.”
sessamekesh - 23 09 16 - 16:03
I would be interested in seeing your analysis with a C++ version compiled into asm.js/WASM using Emscripten. I assume iirlicht supports Emscripten as a target?
Daniel - 23 09 16 - 17:36
@sessamekesh @valarionch Uhhhm, electron is nodejs with an API to run/control chromium. They both use v8 as the engine and all scripts running in the chromium instance created by the node process are executed in the same environment. So it node would not make the game faster. How would you do any rendering in node anyway?
@kyle you could use node.js web workers because electron is node compatible.
Very interesting read though. Would love to see how profiling with flamegraphs and stuff help with speeding up your game.
Glen Keane - 23 09 16 - 17:45
I eat butts
Connor - 23 09 16 - 18:48
Garbage collection. You can’t really make a fast reacting game like an FPS unless you can control it. If a GC hits right before you pull the trigger, the user will miss the shot, or get shot himself. Unfortunately, the GC problem affects some native games on Android too.
sundbry () (link) - 23 09 16 - 20:43
To those suggesting node.
Node is a server side scripting language. it doesn’t have any of the graphical libraries, canvas or webgl apis that modern browsers have. There might be some libraries that can add support for this but I don’t expect them to be well tested or reliable enough to produce an FPS game in them.
It’s a bit like suggesting OP use bash, perl or php.
Ian - 23 09 16 - 20:46
Did you tried to use a native lib or to develop one for inputs using electrons ?
Do you have more details about function that are slow in webgl and are not in ogl ?
Nuts - 23 09 16 - 22:28
Nice, the laggy is from browser, which soon or latter will fix, Like chrome book.
Abner (link) - 24 09 16 - 20:49
I was interested, did you try webassembly and emscripten to port you game for web?
Driver () - 25 09 16 - 01:16
Hi Niko, thanks for this interesting article. I must say i really admire all the work you have done over the years, it never ceases to amaze me what you are doing all by yourself! I wish i had the balls and persistence to go on such adventure myself
Lenx - 27 09 16 - 08:02
AFAIK, even when using emscripten or webassembly, you still need to go through that WebGL API.
niko - 29 09 16 - 01:49
I have no experience in game development but, have you tried – asm.js – setImmediate or a polyfill (as setTimeout / setInterval take at least 4 ms by spec, even if you set 0 ms)?
garaboncias - 29 09 16 - 22:12
As for the node.js suggestion, yes it runs on V8 just like Chome, but the input lag Nikolaus is describing comes from the browser, not the JS engine. Node is just a thing that runs JS code, entirely separate from the DOM, input event handling, etc. stuff that the browser provides on top.
Andy F () (link) - 30 09 16 - 08:32
The slowdowns can happen because of two reasons – either garbage collection or code deoptimization.
There was a good talk about it on Google I/O 2013 that’s about just that: https://www.youtube.com/watch?v=VhpdsjBUS3g
Darko - 01 10 16 - 09:50
Well, V8 has stop-the-world GC and browser event input contribute to lag. Latter probably more. But node.js idea isn’t crazy at all. It would be interesting to see OpenGL (now WebGL but they are similar) in js with OpenGL context and input event handling using native node.js addon like sdl or node-glfw or node-webgl but I don’t know state of those modules.
EdinM () - 06 10 16 - 23:29