Wondering how the engine runs in Arm instructions so far? iPhone, Android and possibly something like Switch.
There is no support for mobile as of yet.
Ok, any idea how much work would be involved in getting it running? What would be the biggest challenges that come to mind.
It wouldn’t be a trivial task. These are the biggest points, in order from biggest to smallest:
- Render backend would probably be the most work. Either OpenGL ES, or Vulkan for Android and Metal for iOS.
- OpenGL is already supported but some stuff is done differently on OpenGL ES, adjustments would need to be made accordingly.
- Another option is to use Vulkan on Android, which is already implemented (but not tested on Android), and Metal on iOS. Metal is not supported at all right now, but would be handy for macOS as well as iOS.
- Renderer would need to be adjusted for mobile. Not all features that desktop PCs have are supported on mobile and adjustments to certain shaders and rendering techniques might need to be made.
- There is already a lower-end version of the renderer for macOS, which should be a good starting point, but it’s likely some things won’t run. Much of the advanced effects can also be disabled, as a first step.
- Various platform specific stuff, like ‘window’ creation and file system. Potentially some compiler or ARM specific bits of code as well, but probably not too much.
Thanks for the reply.
I’m really considering using Bs:framework for our next title in about 6 months and I’m a proud Patreon of it too. We’re definitely planning to support Switch for our next title. I know it supports a full desktop class GPU features and Vulcan. Do you have any thoughts on that? I’m not convinced on UE4 yet and definitely will not want to use Unity3D again compared to in house engines I’ve used before and engines I’ve built myself. Trying to find a good middle ground and it seems Bs:framework can be that.
I started bs::framework because I was unhappy with Unity and Unreal, both of which we use for projects at work. And bsf is what I’m using for my personal projects, so I’m definitely a proponent of using in-house engines you can tweak for your exact needs.
It’s more modern than other similar libraries such as Ogre or Urho 3D, more performant due to its multi-threaded and data-driven nature, built so it’s easier to customize, better documented, focuses on more modern technologies and has systems that provide features similar to commercial engines (many OS libraries will tend to focus on a basic feature set).
On the other hand those other libraries have been out for longer, have broader platform support (you obviously need to add Switch support to bsf), are better tested (although I resolve all issues fairly quickly) and generally have a wider set of available systems (bsf still lacks systems such as networking, pathfinding, terrain and others).
Regarding the renderer, it is desktop focused but a lot of its effects can be disabled, and macOS provides a lower-end path that might be suitable for mobiles. It’s also pretty extensible. That said, you will definitely need to do some work to get it working on Switch.
Thanks man. As expected. Still would seem like I get a better leg up on the project using BSF compared to building anything of my own. Of course that would beg the question how many weeks or months it’ll take to get things in working order. Kinda damn if I do, damn if I don’t. I’m particularly interested in writing/modifying shaders for the renderer and ensure my gameplay logic can be multi threaded where applicable.
I’ll be looking into BSF sometime closer to the end of the year or beginning of next year. I actually rather adopt the game concept and gameplay to BSFs working features (which seem to be enough besides object occlusion). So no need to worry about pathfinding or terrain/open world system for now. I just need a renderer that I can actually scale for Switch ( cough UE4 ) and a game architecture that isn’t bananas (U3D).
Anyways, keep up the good work. Thanks for giving us another option to use.