I’m listing a few things that I find inconvenient when using cocos2dx. This only came from a few days of using it. So I might as well be mistaken with some of those issues. If so, I’d really appreciate a few pointers.
Vector math is made annoying. ccSub, ccAdd and stuff are hard to use. Operator overloads are perfect for this scenario. I wish libgfx could replace the native C style math library. It’s simple libgfx header only lib that supports vectors, matrices, quaternions and even packed integer vectors.
No sensible camera abstraction. Any reasonable game engine should have a decent camera abstraction. It’s even easier to do in 2D engines since all you do is panning cameras. Unfortunately the native camera class uses OpenGL style look-at function, and it invalidate frame sizes when used.
Callbacks use objects instead of lambdas. This is almost unavoidable in C*+ pre-0x. But if you programmed for Android it’s immediately obvious that closures are just awesome as callbacks and simplify code a lot even for a language like Java.
Reference counting is annoying in a mixed environment. It’s made even more so by autorelease pool. It’s annoying to keep in mind autorelease pools and all that objective specifics in an almost pure C*+ environment.
Documentation is still lacking. Often I run into functions that I wish could have more description than what its name says.
My overall feeling is that cocos2dx is awesome in terms of portability, despite the difficulty of setting stuff to cross compile without having a conflicting folder structure. It’d be better if made header only and linked statically though. There is a lot of space for improvement and I’m really looking forward to a better commercial 2D engine. Startup idea, make a a unity3D style 2D engine.
Thanks for your suggestion. I’m not sure if you’re the person who at me on weibo.com. I just reply on weibo to the same questions a few minutes ago.
Use the integrated kazmath library since 2.0
Only a few users asked for changing camera in their 2D games.
lambdas is still too new for some old systems. We are also avoid using too much c*+ features, just like overload operators, overload new/deleate, templates, which will make beginners easier to learn this framework. Callbacks can be more elegant in script binding layer, instead of improving it in C*+
Almost all large projects of c*+ are using reference count or smart pointer. We chose the ref count coz it’s easier to be managed. Smart pointer is usually made with c*+ templates, which is we avoid to use. If you annoy with autorelease pool, you can call new/delete/init directly, and passby the CCAutoreleasePool, that’s an important part of our design.
The edit/create permission of wiki.cocos2d-x.org is open to every registered developers on this website. Besides this, a full-time writer will probably join in us in the coming month.
Yes I’m the same guy :D. Just lost my reply to GFW. Now in short:
Still think vector classes with common overloads for *, -, *, / are quite intuitive. Those without prior experiences should still be able to pick it up quickly.
It’s not difficult to implement the camera behavior I described but it’s a lot cleaner to do inside cocos2dx with direct access to OpenGL matrices. Surprised to hear there is no strong demand. Nice to have it than reinventing the wheel every time and it definitely makes making games easier. At least I can think in terms of “moving a camera” than “moving background layer in reverse”.
How much a rewrite is cocos2dx from cocos2d? I like most of cocos2d but if the language is C*+ it’s a little disappointing that deep down there are a lot objc patterns. Main reason I’m using cocos2dx is because I don’t like objc patterns. I know that’s more of a personal taste though.
Main reason I’m using cocos2dx is because I don’t like objc patterns.
Main problem here is cocos2dx is written using the same objc patterns
I find cocos2dx ugly in some aspects (geometry classes, callbacks, collections, autorelease pool etc). Main reason I see is cocos2d-x avoiding many C*+ native features. I think these features won’t make cocos2dx too complex. Cocos2dx could be easier and cleaner even for beginners if it was written in C*+ style.
hoho hmm wrote:
> Main reason I’m using cocos2dx is because I don’t like objc patterns.
Main problem here is cocos2dx is written using the same objc patterns
>
I find cocos2dx ugly in some aspects (geometry classes, callbacks, collections, autorelease pool etc). Main reason I see is cocos2d-x avoiding many C*+ native features. I think these features won’t make cocos2dx too complex. Cocos2dx could be easier and cleaner even for beginners if it was written in C*+ style.
That’s exactly my point :D. Throwing in too many objc patterns in a pure C*+ set up is counter-intuitive and may scare or even turn away many C*+ programmers. So far I find no alternative that matches the portability cocos2dx provides so that’s the killer feature here. So far I haven’t met anyone (in real life) who likes objc and its derivative mess other than iOS is stuck with it.
I’m curious how the portability is achieved. If someone could take that and make a pure C++ style engine I’ll crack fireworks for him.
