Thanks. I really try to remain objective
I don’t understand why you saying that. I’m just asking about this because it’s very important for my team. It’s very sad, that it’s fun for you.
Sorry dont misinterpret my reply. I said I try and remain objective…meaning I treat every question the same because we have users from all languages and cultures and therefore someone might write something that some take offense to and some don’t. I look past this.
Or Kore … system and rendering API abstraction in one small super portable C++ library. Korecos … mmm
I just learned about Kore too!
I’ve been experimenting with it FWIW. The graphics API is simple and flexible, and as far as the same code (including shaders) running across iOS, macOS, Win32, UWP, HTML5 is concerned it just works. I used the Kore::Graphics4 API but I should really check out Graphics5 for multithreaded goodness. There’s implementations for everything from RPi to PS4/XB1/Switch.
Interesting. What about performances?
Best I’ve tested, though Kore is a very thin layer over the underlying back-end so the engine you put on top will be the primary factor in performance.
In my BunnyMark tests iPhone 6s gets 38000 with Kore, the batcher class from the linked repository and the OpenGL back end. Cocos2D-X gets 6800. Godot 3.0.2 gets 1100. Kore’s built in “Graphics2” simpler sprite API gets 29000.
More comparative figures are here.
There was a problem with the Kore Metal shader compiler at the time so I couldn’t test that.
I am still in researching. The reasons why not choose BGFX are:
- it is huge and complex
- if there is bug in BGFX, then it is hard to solve it
- it is not designed for next generation graphic API
The google’s WebGPU seems good.
Any thoughts about Kore ?
Sorry, i haven’t done any research of Kore, so i can not give any feedback now. What do you think about it? Do you have any experience of it?
No. I don’t have any experience. But i feel it might be a option for cocos. Just after looking their repo and @nivrig comments.
I’ve been experimenting on and off with Kore for some time. There’s a github repo of mine linked earlier with a full example.
Kore uses a custom node-based build system (koremake) that generates IDE project files, however, you can quite easily collect the correct sources and preprocessor defines together yourself. Shaders are written in GLSL 450. The shader cross compiler (kraffix) is run as part of a koremake build but it too can be run independently.
Kore handles window and graphics context creation, input events (mouse, touch, key, controller), sound and graphics. You start the Kore system and provide callback function pointers for frame, input events and so on.
For rendering, look at the Graphics4 or Graphics5 APIs in Kore. Both provide flexible control of pipeline state and geometry submission (also tesselation and compute shaders if the back end supports it). My repo is primarily a flexible “opportunistic batcher” implementation for Graphics4 supporting any geometry or shader setup and also provides convenience APIs for “normal” bitmap font and sprite rendering.
Finally, the author is very responsive on Twitter. I believe Kore has been used to ship commercial console games but he will be able to confirm and/or provide more detail.
How about using something like “The Forge” (https://github.com/ConfettiFX/The-Forge) ?
The news is we are working on Metal integration. We will update you all when we have something to show. Until then the engine developers will need to focus on their work.
That’s like no resources for that… using cocos is now risky, right? Let’s count since now and till Metal will be implemented and fully tested and fixed.
P.s. this is my last game using cocos, I understand devs, but they should have understand me… looking at bug fixes process and overall state of cocos it’s obvious.
Counting the days is not an accurate way to measure quality. Also, OpenGL isn’t going away so fast. Therefore we can implement Metal slowly to ensure quality and polish. We just need it done with time for you all to test with your games and provide feedback. Deprecation != removed.
Exploring other alternatives is a a great way to see what is out there. I encourage you to make the decisions that are best for you. Maybe try and implement one of your current games in another game engine and see how it goes. Educational none-the-less.
Thanks for the answer. This, I think, is the only thread about Metal, and I haven’t seen any news or progress on the past days. Since this is a VERY importan issue, I think you should be more communicative about how things are developing and what decisions you are making. I truly love cocos, I’ve been using it for the last 9 years and I don’t want to stop using it… but knowing that current version will stop working on iOS in 1 year and not knowing when and how you are planning to solve this, is killing me. I need to have a plan B (i.e., port all my code to some other engine) and I need to decide if/when I execute that plan.
I guess many other developers are in more or less the same situation, and I think being more communicative could help them/us to stick around rather than look for alternatives.
Our developers are not going to start a thread and update it each day with how many lines of code they wrote or what they did that day. It would be a mess and not worth the time. They need to understand the work, break it up, implement it, test it, qa it, ask for feedback and review, etc.
This is what you need to know: OpenGL is being deprecated by Apple. That means we need to implement Metal. Our engineering team discussed it in this thread and decided on Metal. Now, the engineering team will do the work and have results for everyone here to work with before Apple says OpenGL is gone.
If there are milestones worth mentioning we will start a thread at that time.
We aren;t dropping the ball here. We said we would implement Metal. We know the timeframe. We plan it to be a drop in replacement (except maybe shaders, I am not sure about that).