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
make
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 rerun
And Then I have got error
use of undeclared identifier āglDeleteBuffersā; in directory /cocos
/2d/CCCameraBackgroundBrush.cpp
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.
Same here. Iāve an app iām consider porting to emscripten, because managing a double code base is a nonsenseā¦ while googlin a bit, iāve found this: https://uncovergame.com/2015/01/21/porting-a-complete-c-game-engine-to-html5-through-emscripten/
Anyway i guess porting cocos wonāt be easy, if not possible at all. Iām left with trying something strange or switch to another engineā¦
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.
Anyway,
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.
Unity supports itās own flavor of JavaScript, and it has first-class support.
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?
JavaScript has much better tooling. Maybe not for Cocos by default (because you still have to deal with C++ anyway and JSB seems shaky, undocumented, and somewhat broken), but in general, definitely. This isnāt too debatable. Node, browserify, ES6 (with transpilers like Babel), gulp (for build systems, much better than bash).
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?
,
