[Question] Cocos2d-x Implementation Status

GDevelop general
1

Hi.

After some time using GDevelop It’s come to my attention that there is currently a cocos2dx render target in experimental mode.

I also found this in the GDevelop roadmap

(Please vote :stuck_out_tongue:)

As some of you know cocos2dx has been used for many mobile (e.g FEH and others) and desktop games and since it’s programmed in c++ it has near native performance in most platforms. It would also open the window for Hardware accelerated games in said platforms and the cocos2dx team is also considering Vulkan support in the future.


Because of this, I wanted to ask what’s the state of this feature and if it’s going to be continued in the near future?

If it’s not going to be continued, I’d like to know what can we do to help it become a reality or to spark interest once more so development can be resumed?

I’ll be completely honest. Regardless of the advances in computer science wrappers can only get so far, Cordova, Electron, and similar technologies, while impressive are not yet ideal. Even the most advanced JS games have to be ported (rewritten) for consoles and depending on the required performance for mobile devices too.

As users or developers, we shouldn’t rely on having a “faster” computer or processor to run a simple game, but you can be sure that you need to optimize it when doing a complex game. Even if your Desktop can handle it, Mobiles have a worse time dealing with these kind of virtualized applications.

Having an optional “native” target as the original GDevelop (4.x and below) would make GDevelop even more appealing to experienced game developers.

Of course, I know right now the priority is to stabilize the game engine and make it as accessible and usable as possible so i’m sure this feature won’t be worked soon, but even then please consider it! :smile: Don’t drop it unless there’s a better alternative.

While this will surely take time, I really would like GDevelop to become very widespread, as I enjoy using it a whole more than Unity or Gamemaker since it allows me to focus on creating the games.

Either way thanks as always for all the hard work! :muscle::100:

p.s. I’d like 4ian to comment so we can have a better overview of this, if possible :bowing_man:

4 Likes
2

A few clarifications on performance itself:

  • Cocos2d-JS is based on a native rendering engine (OpenGL) and the JavaScript source code of the game (including GDevelop game engine) is ran in a JS engine embedded in the game (SpiderMonkey at least on version of Cocos2d-JS). I’m unsure about if this is still the case for Cocos Creator game engine (it is based on Cocos2d-JS), in particular I’m unsure if they changed to another JS engine on Android/iOS. The issue with SpiderMonkey is that it was a very old version in Cocos2d-JS and was not benefiting of JIT (Just in time compilation) from recent JS engines.
  • Speaking of JIT, most recent browser engines (V8 for Chrome, WebKit for Safari) are doing Just In Time compilation of JavaScript functions that are considered “hot”, compiling them to native code bringing really good performance.
  • WebAssembly being now a thing, it’s also a good target for the future to use to power small or large parts of the game engines (collision, etc…) with unmatched performance (almost native).

All of this discussion is about raw computing performance itself. Then there is the performance for the rendering engine. OpenGL ES (running on mobile phones) and WebGL are very very similar, basically WebGL is opengl es roughly speaking.

So you can see that the word “native” itself is a broad spectrum :slight_smile:

To answer the question about implementation status: Cocos2d-JS having the issue mentioned before about JIT, it is not actively developed - as performances are not better than with a classical JavaScript engine + WebGL rendering.

There is also a question of codebase and development. Cocos2D-JS current implementation differs from the Pixi.js implementation only on the renderers that make calls to display things on screen.
It’s still a lot of things to maintain, every object needs two renderers. So for now, priority is first to get a renderer for Pixi.js as it’s the stable game engine, and Cocos2D-JS if possible and not too long to implement.

Having a separate “native” game engine is a lot of work. It’s double the time of development, double the number of bugs basically. That’s a strong incentive to keep a single codebase unless we have massively more contributors. Development agility is key.

For now, I plan to experiment with WebAssembly more. It might be a good way to have native like computing speeds in browsers (without praying for JIT to do the right thing for the JS code) and, if written in C++/rust or another language like this, it could even be reused to make “native” games (without WebAssembly, but still keeping a single codebase). At least not having two separate game engines which is really a recipe for failure.

2 Likes
3

Thank you for the reply @4ian ! I understand what you’re saying, however for native mobile and desktop targets (not semantically native, but actual machine code AOT compilation) they are using Cocos2d-x, that is, the C++ framework implementation with newly developed JS bindings, which i’m not sure if are closed-source, but were developed from scratch, apart from the original Spidermonkey VM from Cocos2D-JS so they could handle the C++ engine under the hood. This is what I was originally asking about.

From your reply I noticed, that Gdevelop was supporting Cocos2d-js instead of Cocos2d-x, which I didn’t understand until your comment, my apologies for any confusion.

But either way it is exactly as you say, that they based Cocos Creator off Cocos2D-js /html5 and they use that specific framework to output for both desktop and mobile browsers only and Cocos2d-x for the other native targets (at least according to their framework workflow diagrams).

With all of this I completely understand that supporting either cocos2d-x or cocos2d-js would require extra development investment for the GDevelop team, so I suppose this will not happen in the end :pensive:

So, If you’re taking the path of Webassembly I hope you have a fruitful experience with it :smile: I personally think WASM might only be truly production ready in the following 10 years once browser vendor adoption becomes more widespread (along WebGL2 :pray: ), and as more companies continue to invest in web-based technologies I suppose there will be a crossroads at some point where wrapper based webview applications will become as fast as so called native applications, but I don’t think some of us have the luxury to wait 10+ years to be honest.

Anyway thanks again for your time and your informative post, I’d like to keep this topic open at least to have an update in a few months / years on your work with WebAssembly, if that’s ok :slightly_smiling_face:

1 Like