Few hours ago I launched our demo on Android. Pure Swift that is build with Swift Package Manager under Linux VM. APK is created on Mac.
Currently we run Metal on iOS/tvOS/macOS, OpenGL (via SDL) on macOS/iOS/tvOS/Ubuntu. Platform specific is less then 10 lines, so you can say it is “code once, run everywhere”. Dreams come true, especially in Christmas/New Year period.
We have huge plans for this project, so stay tuned. Nobody will take the x-platformability from us like they did with Apportable anymore!
Great news! I’m definitely interested to see how fast this will progress, and likely helping out at least a bit.
Couple questions in case anyone is interested in using this or even helping out. Feel free to ignore these questions, but maybe they’re useful to think about?? Sorry if you’ve discussed any elsewhere. I don’t see much info beyond the read-me and reading through some of the code.
I see you’re going to wrap AudioEngine. That seems like a reasonable idea for the long term future only because I imagine all the issues will be ironed out over the next year since there’s more testing and more people using it, especially now that Creator does too. However, have you considered other options? OpenAL-soft? or SoLoud? It might be interesting to do something similar to these other sound engines and have Fiber2D implement the 80% API allowing for plug and play backends.
Are there one or two major features that you’d like some help with, or that you’re less interested in doing yourself? Maybe some of the SpriteSheet/Importer stuff? DirectX/Win32/Win10 builds? Tilemaps? Particle Systems? Editors?
Are you planning to dog food the engine more fully by maybe working on a medium-sized game (something that uses many of the features) either as open source example(s) (like Unity3D’s AngryBot)?
What’s the timeline on the BGFX support for GPU particle systems?
Do you have a target minimum spec? Or do you plan to rely on BGFX to continue supporting old devices through rendering/etc fallbacks?
Where is a good place for anyone interested to have further discussions? Github Issues? Twitter?
Do you have any thoughts around cocos2d-x v4 taking some of Fiber2D’s ideas?
How about composition over inheritance? Do you have any thoughts on whether the engine will lean toward ECS-style vs a Scene Graph? Maybe you’re goal is to provide a good foundation for modularity so that other’s can use and swap out various components of the engine?
Have you considered supporting hot-reloading of assets and other data as a foundational feature?
Any long-term plans on a 1st-party open source editor (scene, UI, particle design, animation design, state machine or behavior design, etc) similar to SpriteBuilder, Cocos Creator, or the SpriteKit/SceneKit Editor?
I just thought I’d ask since I’m interested in finding what my 5+ year goto game engine for personal (and possibly contract/work) projects. I’m sure I’m putting the cart before the horse a little.
There is nothing similar, other is just a crap next to SpriteBuilder. Also I believe that editor should be developed using Swift too, so it’s will be macOS editor only.
Writing your own thing from scratch is often a cool and fun idea, but I bet it will be hundred times easier to support AudioEngine wrapper than consistent audio library for 5-6 platforms.
This is definitely the font rendering. Both TTF and Bitmap. Tilemaps are good to help with too.
For sure. I was just busy doing some tech stuff instead. I think I will port some cocos2d demos as I don’t have any assets to use anyways.
Not sure I understand the question. For 2D we can’t use GPU particles anyway, but what I want to do is to compute particles vertices via compute shaders, which should decrease CPU time significantly.
F2D is designed to have bgfx in its core, so yeah we will depend on that for a while.
I already have a gitter (badge is in the repo), I wish I can start mainting trello soon and also slack would be cool.
Never heard of it. I don’t care about C++ though. Can you show me a link?
We will never be ECS, but we are CBS already. PhysicsBody is a components and PhysicsWorld is a system. And one the main goal is to save parent-child relationships because it is useful for 2D games.
Didn’t thought of it yet.
I don’t have both time and resources for that, but it is a must for sure.
It should be much easier than android port, and it can even be cross-compiled from Mac that is even cooler. The only problem is that I don’t have a windows machine, but that is only a matter of time.
Hello, I guess building for android takes running build.sh in Fiber2D/demo/platform/android, but I get an error:
error: unknown command: #
enter `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-build --help’ for usage information
build.sh: line 4: -Xswiftc: command not found
build.sh: line 8: -Xswiftc: command not found
build.sh: line 15: -Xswiftc: command not found
build.sh: line 19: -Xcc: command not found
build.sh: line 23: -Xlinker: command not found
build.sh: line 24: -Xlinker: command not found
build.sh: line 25: -Xlinker: command not found
You have build your own environemnt (Swift Compiler, Foundation and Dispatch) in order to build Fiber2D. This is not a trivial process, that is why I shipp precompiled binaries for those who just want to try it.
Thanks for the response. I’ll clarify a couple as I wrote that off-the-cuff and while on mobile.
I’m mostly trying to gauge the direction of this engine as well as an estimated timeline/roadmap that I can foresee myself through watching the progress rate and discussions.
Sorry, I didn’t mean writing from scratch or re-writing anything really (I was thinking API surface when I mentioned 80%, this was the “writing in haste” talking). Let me restate this one and question why not look at another prebuilt audio framework like OpenALSoft or SoLoud (or another one that’s ready to go).
You’ve written “GPU particles (once BGFX supports it)”. I was just curious if you knew when that support was going to be ready on the BGFX side of things. You idea sounds similar to geometry shader or instanced particles. GPU particle system in my mind is one where the entire particle simulation is done in the shaders (if physics/collisions required you would update infrequently where dynamic bodies have moved). Anyway I’ll go look at BGFX’s site and see where they’re discussing it.
Smart to ignore this one. I just meant that cocos2d-x and Fiber2D could take ideas from each other as they march toward 4.x(C2D) and 1.x (F2D). The 4.x (next c++ version) has been discussed and for example using BGFX as the low-level render was one and another was instancing and improved particle system and tile map rendering.
They’re pretty similar, and none are crap, but rather just ones you dislike or ones that don’t interest you. The editor must also be cross-platform or it’s dead on arrival, and if it’s Fiber2D’s editor then it will be written in Swift and I’d be surprised if it wasn’t also a Fiber2D app either using its UI controls or possibly bringing in a cross-platform one like ImGUI, Qt, or whatever else exists. One could also use a “3rd-party” open source editor like Overlap2D, just as example. I’m sure many editor loader/parser/renderers will be supported just like all other cocos2d engines, so I was mainly curious if the big picture idea for the engine was to be more like Unity (everything integrated) or more like Cocos2D-iPhone (external editors).
We can’t talk about the editor unless I finish data-driven side of API. I want to implement YAML based loading and then the editor will be just a matter of time. I thought about Overlap2D but it is not supported anymore. And I hope to maintain the ability to use Fiber2D as a code-only and with editor, but that should not sacrifice the functionality at both sides.
About the particles: for now, yes, I’m mostly about going compute (geometry) shaders, but pure GPU particles are a good thing to think of for sure.
About the ideas: Fiber2D took everything It could from cocos2d. Deep inside it is still a cocos2d
Sounds good. Thanks again, appreciate you taking time to discuss.
I am all for a code-first engine, It’s my preference.
Sad to hear about Overlap2D’s abandonment.
A question, why use swift to go cross-platform when you already have it with c++? or are there other benefits in the longer term like performance, better graphics support etc.
I tried Cocos Studio 2 many times and it’s worse thing in cocos2d-x. And I believe next creation is the same.
Thats interesting, why? You need macOS to build for the major platform - iOS, and maybe tvOS. So for development you definitely will be using Mac.
That’s probably only one “suitable” solution, but all it’s wouldn’t be native and with a lot of problems on all platforms, some same crap as cocos studio. Or use stable tools like Qt(but with “stable” coding hands), however - how to use Swift engine code with it? Or duplicate functionality for everything and doing deep tests every time?
Same bad thing. Editor should be working closely with the engine and have same codebase. All like SpriteBuilder.
Why make a wheel thinking about an editor, but just not copy ideology of SpriteBuilder?
All people who woking with unity likely try editor based engine, but not just blank code - it’s just waste of time.
Definitely all should be WYSIWYG and editor based.
The problem is in C++. This language is not the best for game development, it is an industry standard only due to its performance. And the good part is that Swift can be as fast as C++.
