应该提供一个通用的C++层，在此基础上在接入cocos2D-x binding.
Closed this issue · 5 comments
现在这个C++版本依赖于cocos2d-x编译，如果不依赖于cocos2d-x就没法用了。
而大部分游戏引擎底层都是C++开发的，界面库的通行做法是把输入，batch提交等代码抽象成一个虚基类，对于每个引擎，例如cocos2dX，CryEngine，UE4的RHI，OGRE，Urho3D 等，都各自写一个这个类的实现。更应该写一个独立的OGL，和DX实现各写一个。
其他语言：C#和lua可以生成相应的binding，JavaScript可以用Emscripten过的C++，你们的核心代码只用写他一遍，这样解耦以后便于维护，只需要维护核心代码就行了。
其他UI库：什么CEGUI，MyGUI，还有现在非常流行的dear ImGUI，都是这样做的。
期待你们的新版本。
嗯，Unity的话，记得有这个：https://github.com/jacksondunstan/UnityNativeScripting，可以用来从C++代码直接调用UnityAPI。
我业余也在开发一个开源3D引擎，以后Fairy能够把输入输出层抽象出来这个API，我就很容易接入FairyGUI了。
你可以去做这个事情，反正是开源的，但我是不会做的，因为这是吃力不讨好的事，对于技术研究或许有好处，但对于一个UI产品来说，用户并不在乎你底层是什么架构，或者说他选择这个UI产品时他只希望这个架构越简单越直接越好，这无论对于决策层来说，还是基层JS、C#、Lua程序员来说都这样。
我觉得做好一个UI或许是比做一个开源3d引擎更有趣而且也能更快收获用户的事情，如果你对FairyGUI有兴趣，欢迎加我QQ联系我，我们可以更详细的讨论和合作。
完全不是技术研究的问题，问题在于：你现在的方案，核心代码要维护N多种，同样的代码要开发多遍啊，这不是更加吃力不讨好吗？
我刚才已经说明白了。我是做产品的，不是搞技术研究的。用户用的方便就是最大的，他们不吃力就行，作为开发商我吃力无所谓，有钱赚就行。
哎，好吧，回头我来弄一个好了。