Cross-Platform Support

[AdamsLair]

• Since Duality is using OpenTK, it should in theory be possible to run it with Mono / on different platforms than Windows
• Some dependencies might be problematic indeed and need to be removed or replaced. OggVorbis might be an example
• While making the engine itself multiplatform-ready seems like an achievable goal, the editor will probably need a lot more work.
• Will need a testing environment / system and someone with Mono experience

[AdamsLair]

• The OggVorbis dependency has been replaced with one entirely written in managed code. So this particular problem is solved.

[Andrea]

This would be amazing. The priority at least for us, would be that the game runs on Linux and Mac. I don't think people have a problem developing on windows
It might be worthwhile talking to @dellis1972 :D

[AdamsLair]

If he's experienced with Mono and / or cross-platform OpenTK, that'd probably be a great help.

I wonder if he gets notified, now that you've referred his nickname.

[Andrea]

He was part of the monogame team and he is a genius and also incredibly experienced. I hope he gets my nudge

[dellis1972]

I did get your nudge.. :) genius is over stating it a bit I think :P

[Andrea]

:) not at all dude
If you had some guidelines / tips it would be so very helpful
For me the focus is mono mac, PS 4 and vita

[dellis1972]

I'd have a review of the code when I get a moment. Mono Mac will probably be the easiest port since it has a compatible opentk layer. PS 4/vita will be more problematic since vita has its own API as does the PS4. Unless duality has its own abstraction layer for graphics/input/content etc which would make things easier.

[Andrea]

Thanks Dean,
yes, of course ( about PS4 and Vita)
Looking forward to your thoughts
Hope all is well

[AdamsLair]

I'd have a review of the code when I get a moment.

That sounds great :) Looking forward to your thoughts!

Unless duality has its own abstraction layer for graphics/input/content etc which would make things easier.

Duality provides an abstraction layer to the user, so he doesn't need to talk to OpenTK API bindings directly, but it doesn't have an additional, internal layer of abstraction as you're probably referring to.

Directly invoking API commands (OpenGL, OpenAL, etc.) happens only in some designated spots, though - Resource classes (Texture, Sound, ShaderProgram, ...), Rendering classes (DrawDevice, VertexFormat, ...) and a few utility methods (CheckOpenGLerrors, ...) should account for most of the direct OpenTK interaction.

If you need anything, just let me know.

(I'll be unavailable from 30/4 until 6/5 though.)

[dellis1972]

OK I had a quick look, I think it will be possible to port the runtime port to mac/linux as its using basic opentk. the editor however is a different issue, its using WinForms and what looks like some custom Windows components for Docking etc. So the editor will probably need a bit of a rewrite to get that working.

I'm wondering if the runtime could have its 'OpenGL/AL/Resources' part moved to a plugin, so the core of Duality is totally independent of platform, and the platform specific bits are in a plugin (a monogame plugin perhaps…. :P ) . You already have a bunch of interfaces in place by the looks of things so it should be possible.

For the editor the core and the presentation would need to be separated out so windows and mac could have their own front ends. You could move to a XWT type UI layer which handles the platform abstraction for you, or go totally native for each platform. Either way it will be a lot of work, but it would be well worth it in the end.

For now for cross platform I would suggest looking at the runtime first, then the editor later. I might have a few cycles to help in a few months (got a few projects of my own I need to finish first).

[Andrea]

Thanks a mill for the feedback Dean :)
You are coming to MonkeySpace right :D

[AdamsLair]

Thanks for the feedback so far :)

I'm wondering if the runtime could have its 'OpenGL/AL/Resources' part moved to a plugin

That should be possible using the existing plugin infrastructure, but not in the way that would move Resources themselves into a plugin, because there should be a fixed basis of core functionality (Textures, Sounds, ...) that is always available, independently of available plugins.

However, moving the "internal API" into a distinct plugin sounds like a good start. I'm thinking of something like an IGraphicsDriver / IAudioDriver abstraction layer that will be used by all Resources, but the implementation of it will be loaded from a plugin. That way, there would be no direct API calls in Duality at all.

It will be a requirement to identify some kind of "shared basis" of API functionality on all platforms that will be exposed by the interfaces. It will also be necessary to decide whether this interface will have a low-level or a high-level tendency and which of both makes more sense. I'm lacking practical experience here, so some feedback on this would be great :)

For now for cross platform I would suggest looking at the runtime first, then the editor later.

Yep, that sounds good. I'm not sure whether it will pay off to port the editor at all, though - since I expect it to be a lot more work than porting the core, while only providing a relatively "small" benefit. Will need to re-evaluate that when the community has grown a little more.

[AdamsLair]

(Prerequisite Step) Evaluate whether Duality runs using Mono on Windows: Done. It works.

ToDo: Acquire Virtual Machine and see what happens when trying that on Linux.

[Kethku]

A related issue is the ability to port the game to windows phone/mono touch and mono droid. The editor and system is very cool, but is gated from me because I would like to post my game on those market places. Of course this would also require having an ifdef like functionality so its probably beyond the scope of this bug...

It would also require a diretx backend as the windows phones don't allow opengl. If a directx plugin were created, it would let us post to windows store too which would increase reach even further.

[AdamsLair]

Without OpenGL / OpenAL support on these platforms, it will be either introducing another abstraction layer or porting to something like MonoGame. Both options aren't really great in my opinion:

• MonoGame feels kind of bloated and brings along a lot of stuff that Duality doesn't need or replaces with its own solution anyway. Porting to MonoGame makes me cringe, as I'm kind of a minimalism fan and this appears to be the complete opposite.
• Introducing another abstraction layer for Audio, Video and Input feels kind of bad, because that's what OpenTK is already supposed to be. So it would be wrapping a wrapper. On the other hand, MonoGame pretty much does the same on its OpenGL backend side... so doing the same with Duality would probably still be a better solution.

Another option would be to ditch non-OpenGL platforms in the first iteration and stick to making it run directly with OpenTK on all platforms that support it, preferably the Win / Linux / Mac trio. Since multi-platform is quite a big topic on its own, I'd kind of go with this third option and see how far it leads first.

[HeadClot]

Hey Adam - My advice would be to port it using mono. You would in theory be able to port it to Android as well. My advice would be to use Android TV as a test bed for duality on mobile hardware.

If you are having difficulties porting your engine to Android ask some of the Devs over on the XDA Developers forum.

Here is a link - http://forum.xda-developers.com/

As for Mac and Linux - I am not sure about who to ask for help in the Mac area.

Maybe some of the folks over on TIGsource.com could help you out as well as promoting your own engine. Maybe the Gaming on Linux forums could help - http://www.gamingonlinux.com/forum/

Just thought I would Offer my support.

• HeadClot

[AdamsLair]

Thanks for the hint! :) Will definitely check it out.

[ala53]

Perhaps retargeting to OpenTK's OpenGLES 2.0 would solve some of the graphics issues? It allows a standard API to be used internally that in theory will work with all of the platforms. If anyone's graphics card doesn't support it (just about everything newer than the GMA950 does), they probably couldn't play the game anyways

[AdamsLair]

I've also thought about that, yet I'm not sure whether this is the best way to approach the task of platform-independent graphics, mainly due to one reason: It is possible that certain projects use OpenGL features that may not be available in OpenGL ES. I think this is a rather obscure case and would probably dismiss it that way, but right now, I do not know enough about OpenGL ES to say for sure.

But then again, abstracting away all the graphics would leave those cases with some extra work as well, so it might not be any worse than moving the actual graphics code to a plugin.

[AdamsLair]

This issue has been superseded by the OpenTK Abstraction Layer and making Duality a PCL. When both of them are in place, it should be possible to port Duality by simply creating a new platform backend plugin and, depending on the platform, a new launcher.

With the entire platform backend in a plugin and Duality and its plugins being PCLs, it would in theory be possible to reach just about any platform that is supported by the PCL profile - all Desktop ones (DotNet and Mono), as well as some of the Xamarin ones - as long as someone creates the platform backend plugin and potentially launcher.

Closing this, moving discussion to the v2.0 milestone.