I have created new project ( I have followed instructions on github too), build it for linux and run, it work good.
Next step I have tried to build for web using emscripten in directory of project i have entered in console:
cmake -DCMAKE_CXX_COMPILER=em++ -DCMAKE_CC_COMPILER=emcc
Firstly, I have got error with CC_DLL in tinyxml2.h, I removed CC_DLL, And rerun. Then I have got error on unknown include in directory “unzip” ( I have copied zlib.h and zconf.h to directory) and rerun.
Then I have got error with GLubyte -use of undeclared identifier, I have added
#include <SDL/SDL.h #include <GL/gl.h #include <GL/glu.h
(I am sorry but I can not put symbol of close (">") If I put the symbol, name file become invisible)
And Then I have got error
use of undeclared identifier ‘glDeleteBuffers’; in directory /cocos
and many same errors, and I do not know what to do…
Could You help me please how to fix it?
Thank you for any help!
Emscripten used to work on cocos2d-x, but I don’t think it has been supported for some time. In fact, I’m pretty sure support for it was deprecated a few release ago.
On cocos2d-x 3.13.1, I had tried for a while to get a C++ game ported to a web version using emscripten, but realized that with the 3rd party libs I was using that there was really no hope. So I am porting my game to JS manually by starting a new JS project and translating most of the code to JS. It works, but now I have two code bases to manage
Thank you for your attention and for sharing your experience!
I have found on github project with support emscripten It seems very interesting, but there is old version cocos2dx framework.
I am sorry but I do not understand why it very hard to port c++ code to the web using emscripten, As I understand : We have source code framework (cocos2d) and source code different libraries (for example box2d) But If compile all library using emscritpen, and compile internal cocos2d library using emscripten and then we can get project working in browser using emscripten, Or is it not right?
I didn’t want to be fatalistic about the ‘no hope’ thing! ,
From my earlier look into emscripten, I can see how a cocos2d-x C++ conversion to JS should be possible. For myself, however, with some networking code I was using and some 3rd party libraries I was using I realized that it would be better for me to maintain a separate JS port of the game rather then hope for an emscripten solution.
I do think it would be a great feature for cocos2d-x to support emscripen again, though! I’m curious why it was deprecated.
I think the best path forward is either a fork, or a modularized v4 version that strips out some of the mostly unused features. Then others can add them back in.
So if one could get literally only the core classes (Director, Renderer Commands, etc), along with a limited set of classes like Scene, Ref, Node, and maybe one or two dependent classes. It may be possible to show a working build fairly quickly. Render the nodes position using a render command. It may also be possible that cocos2d-x v3.x is too coupled internally which means it would be too much work to bother trying to simplify to get working quickly (hence why i mentioned a modularized v4). There is also the cocosCreator’s cocos2d-x-lite fork that might be one for initial work.
One could also look at the Fiber2D project and port/rewrite all the Swift code written for that “fork” of the cocos2d family and use the c99 base code (along with the core BGFX rendering engine) to get it working through the emscripten compiler.
A lot of the code should just compile fine. Most if not all the libraries should compile fine. The usual issues will likely reside in the file handling (which is also somewhat supported at least with the boost emscripten fork) and other areas where the browser differs in capability/functionality from the win/linux/mac OS.
Edit: oh and of course anything that is literally platform dependent even today in the code base.
It’s probably a lot of work, regardless, so that’s why it hasn’t been worked on again since the initial 3.0 port that was working a while back as you’ve mentioned.
Emscripten works fine with SDL2 because their team deeply integrated it into the tool. Almost every gaming engine supporting emscripten now also uses sdl2 because of this. It’s a de facto standard now, like it or not. Porting cocos to emscripten would probably mean substituting the relevant engine parts for sdl2… and this accounts for more and more of a rewriting. Scratch it.
Absolutely agree on bgfx / swift / fiber2d chain, looks very promising.
Why not obsolete lots of your old C++ code with your new JS scripts (taking advantage of JSB)? You can keep the C++ for the performance related code or platform-specific stuff. In general, JS is easier to read and write, has more built in functionality, better tooling, better community support, and runs fast enough.
about performances: almost on par, but not the same
about obsolescence: must be a very good reason to do that, otherwise it’s just losing time. missing libraries, double codebase…
better community support: possibly, but why unity/unreal/almost all others engines chose that way? there must be a reason
about control: debuggin c++ ultra-mangled code full of jsb–something which i don’t know what is doing… really is that possible?
about strategy: native comes first, a browser it’s just an app like any other on a mobile. yes, you can do a full web game with a portal and all the bells and whistles, but that’s another thing, and requires a whole different strategy, not just banging js sprites up’n’down.
about being easier: sure js is, but you pay a price for it. can’t tweak anything when you use scripting. you are forced to use given components. Can i do a procedural noise landscape generator in js? maybe there’s a library out there…
better tool: hope so. Does someone tried if chipmunk support works in creator? I’ve a heavily using chipmunk porting to do too…
@MikeCocos2dX - but yeah similar to Jgod’s response if running in a web browser is a requirement definitely look at Creator (or cocos2d-js, no C++) or another WebGL supported engine. If it’s not a requirement then your question was probably more of a hopeful one, and instead you should just focus on the platforms that matter for selling your game (Android, iOS, Steam, Windows), heh.
It’s not a far cry to suggest scripting, many (most?) AAA games use them. WoW has LUA, Civ 4 has Python for logic, etc.
Simple logic between game objects should probably be contained in scripts, you get the benefits of hot reloading and insanely fast iteration time, as opposed to recompiling, launching simulator or deploying to device etc, which is slow as hell in comparison.
Most games are “business logic” between components which can easily be held in a script.
These are all some of the reasons the Cocos team has been pushing scripting, like through their Cocos Creator, etc.
Most games made with cocos are simple games, nothing cutting edge or crazy. People use “real” game engines for those (it helps that they’re better-documented with big communities, too).
Is reducing most of the codebase a good reason? I guarantee most cocos games are 75% business logic which can be thrown in scripts and run in any environment, with the benefits of hot-reloading etc. etc. with no huge performance hit. You could then share that huge amount of common code between the web “port” and the old version you’re porting from.
Again, Unity and Unreal are also designed for heavier games than Cocos.
You’re not making Gears of War with Cocos. I say this as someone who’s used Cocos since 2012 and love it, despite its harsh learning curve and clunkyness.
Right now I’m writing a native-only game (iOS, Android) that uses packages from Node, bundles them up for the “browser” (Cocos), and transpiles my ES6 (much better than ES5 - the stock JS) to ES5. If I can add functions/scripting/object attributes in the browser live, and modify it on the spot, I have much more flexibility and a magnitudes faster feedback loop.
I’ve spent years in Xcode with Cocos2d-x using only C++ and it’s a bad setup for rapidly tweaking things. Adding scripting is something I’d recommend to anyone.
Even if I abandon such a heavy-JS approach, I’ll still add some amount of JS in the end probably.
What do you mean you can’t tweak anything? You can write any components you want. You can write your own native stuff still, why not? That’s how the Cocos team implemented JSB in the first place.
I’d agree that systems should be kept native because you can actually argue for a performance hit there. But again, how many performance-intensive systems does an endless runner or match-3 clone (vast majority of cocos games) have?
With the rise of React etc. there has been magnitudes more developer-hours poured into JS than C++.
You can use shared JS end-to-end from device, to browser, to server, in packages like lodash.
If you want static typing, you can add it with TypeScript, Flow, etc. NPM is an incredible achievement in software and community and there’s nothing like that at all for C++.
Don’t get me wrong, I am an insanely big C++11+ fanboy and good at at it, and have been jamming it in most things I make for the last few years but I still think pick the right tools for the job, etc. etc.
I don’t make such intensive games where I’d lose much by taking a performance hit for increased productivity and faster iteration.
I can always drop down to C++ when I need to speed it up.
Hello, A c++ game, judging from the posts, seems hard enough to convert to java. Is this still the case, or in the two years since this topic, have things become easier? If a Nakama user wants to put his 3.17 c++ game online must he take further steps too?