LibGDX on Flutter?

Anything libgdx related goes here!

Re: LibGDX on Flutter?

Postby yobowargames » Fri Jan 10, 2020 10:21 pm

I'm not entirely sure why you think the answers are stupid?

When I look at flutter its
A Framework (UI Library based on widgets): A collection of reusable UI elements (buttons, text inputs, sliders, and so on) that you can personalize for your own needs.

That's almost exactly what Scene2D is.
Posts: 15
Joined: Sat Oct 27, 2018 4:25 pm

Re: LibGDX on Flutter?

Postby evilentity » Fri Jan 10, 2020 11:28 pm

Last ive checked Flutter was in Dart not in Java. Doing custom widgets was massive pain in the ass. Trying to fit gdx in there would be even more. Attempting to do that would make little sense.

Amusing how often this story happen, 'scene 2d is hard! I know, ill use some unrelated thing that also does ui! What could go wrong?' :(
Looking for a freelancer? PM me!
Check out libgdx discord server!
Posts: 4867
Joined: Wed Aug 24, 2011 11:37 am

Re: LibGDX on Flutter?

Postby pedro » Fri Jan 10, 2020 11:37 pm

Some points/replies (edited):
  • I never said Scene2D is hard, I still dont know why some people started talking about Scene2D, I never even mentioned it on the original post, much less that I find it hard or that I dont like it
  • As I said, Im an experienced LibGDX developer, have released multiple successful commercial titles with it years ago, and I do like Scene2D, and my question is NOT about it
  • Flutter is in Dart, yes, that's why Im asking if there's any kind of effort/fork/etc to make (or remake) LibGDX on it
  • The widget part of Flutter is not something Im interested in, it would never work for game development, but you can draw on the "canvas" with Flutter, there are some crappy game engines in Flutter that dont use anything of the widget part (it creates an initial "canvas" widget, and then you draw everything in it). For example check Flame ( )
  • And, maybe most importantly, I never asked for suggestions/alternatives!! I specifically asked if there is a port to run LibGDX on Flutter, and/or if that's something the LibGDX community has previously discussed, or is interested. And I said I think it would be very valuable for LibGDX, since it would naturally run on both Android and iOS (and desktop) without the need for RoboVM or any other similar "hack" (yes, in my eyes RoboVM is not much more than a hack). Also I mentioned there's a gap on Flutter for decent game engines, and LibGDX could fill that gap. Still, almost every reply I got is off-topic (some are slightly off, some are light-years off)
Posts: 21
Joined: Mon Apr 27, 2015 10:08 pm

Re: LibGDX on Flutter?

Postby tintinger108 » Thu Jan 16, 2020 10:42 am

Basically, could we make flutter the cross-platform backend for libGDX?
Posts: 18
Joined: Fri Sep 13, 2019 3:44 pm

Re: LibGDX on Flutter?

Postby pedro » Tue Jan 21, 2020 1:26 pm

I started migrating LibGDX code to Dart to try to make a minimal test, but after about a week of code migration it seems I'm still a bit far from the goal, but in any case I have some lessons learned I want to make sure the knowledge is not lost.

OpenGL interface:
  • there is an OpenGL package (pubspec.yaml -> dependencies: -> opengl: ^0.3.0), not sure if will work out of the box
  • if it doesnt work, there is a C-interop package called FFI (dart:ffi) to make the bridge to OpenGL, this should work (in fact I think this opengl package above is exactly this)
  • I read somewhere that there is a thread limitation/difference in Dart that impacts OpenGL, during an OpenGL batch you cant have any kind of future/async op or it will change the thread and lose all OpenGL context
  • but this kind of delay/future during a batch of OpenGL calls make no sense, so there shouldnt be any impact of this

Method naming/overloading:
  • this is a massive pain/effort, I underestimated this initially
  • dart doesnt support method overloading, but it does support optional named parameters, so it's possible to migrate most of the methods to work with named parameters
  • but I think it would be a major work, and I dont know how much would it affect performance
  • so my suggestion would be establishing a naming convention and renaming all the methods
  • for example let's say there's 3 methods: void color (Color color), void color (float r, float g, float b, float a), and void color (float colorBits)
  • one possible naming convention (which is probably totally against Dart naming conventions, but oh well) would be to rename them according to the params, for ex: color_Color/color_RGBA/color_Bits, or maybe add the number of params to make it easier to find the correct method: color_1Color/color_4RGBA/color_1Bits
  • in any case, it would make our job much easier if we did all this renaming on the Java side to use the power of Eclipse/Android Studio to rename the methods and calls using Refactor tools

Data types:
  • floating point: Dart doesnt have FLOAT, only DOUBLE
  • integer: Dart's INT is 64 bit
  • I'm not really sure the consequences, I migrated all floats to double on the code, but certainly this would cause several issues I cant foresee
  • the most obvious issues are on the interfaces to external or lower level systems, for example when calling OpenGL, or when converting to/from Color
  • there is a way to convert/change the data types from 32bit to 64 and vice-versa: a class called ByteData. But on LibGDX internals it would need to work on 99% of case with 64 bit int and double, or else we would lose all the types (everything would be ByteData) and the code would be a mess. Working with 64bit vars instead of 32bit should/might impact performance.

Other (small?) differences:
  • I'm by no means Dart expert, Im in fact very very new to it, so I might have made some false assumptions or mistakes
  • there's no "private" keyword, to make a member private you have to name it starting with _, so I ended up making everything public on my test (removed the private keyword and didnt add the _)
  • I ended up removing all "final" keywords, it does exist in Dart but it works a bit differently it seems so I just ended up removing them altogether
  • there's no array in Dart, only List<type>, but you can create a fixed-size List by passing the size on the constructor. Dont know if there are performance issues.
  • there's no interface, I converted all interfaces to abstract classes and it seems to have worked (well, compiled) fine
  • you cant add methods/variables directly to enums, but you can make extension methods to enum, so it should work

Next steps (from my point of view):
  • I would suggest to try a really minimal test to solve these issues, before trying to effectivelly migrate anything LibGDX related
  • for example step 1 would be make a minimal OpenGL example (calling it in a similar manner LibGDX would do)
  • step 2 we could add some LibGDX utility classes that can work in an isolated manner without having to add all of LibGDX, for example classes such as Color, Matrix3/4, Quaternion, etc, then make some unit tests to check if everything is working fine (despite the differences of variable types/sizes such as int64 and double)
  • step 3 could be to add something minimal of LibGDX to test the OpenGL integration
  • step 4 could be effectively trying to draw something from Scene2D such as an Image, without all the backend still working (game loop etc)
  • and step 5 would basically be everything else, since if it reached this far it must work overall
  • obs: I kinda tried starting from Step 4, that's why it took a long time, and I dont have much knowledge of the inner workings of LibGDX to know what to cut out, what is important to migrate, etc
  • for migrating LibGDX Java code to Dart I would enormously suggest make something more automated instead of doing it manually as I mostly did. First it's mandatory to rename all the methods (avoiding overload) on Java side as I mentioned or you will lose maybe 80% of your time doing that on the Dart side. Then for the rest (float -> double, array to List, remove public, remove final, remove private, remove @Override etc) maybe a simple search/replace would work (but I would suggest doing that on all the classes at the same time, maybe put them all in a single dart file and then later split). Or another more robust solution would be to code something to parse/convert the code fro Java to Dart, shouldnt be too hard.
  • also I havent tested or mentioned the rest of LibGDX (eg sound, file loading, etc), but I believe all the rest can easily be adapted or remade, that's why I ignored that part

I will probably continue trying to hack, but I have to get back to some other tasks/games, that's why I stopped to write this so at least we have some information somewhere about LibGDX on Dart. Once I continue to work I will write again here.
Posts: 21
Joined: Mon Apr 27, 2015 10:08 pm

Re: LibGDX on Flutter?

Postby tintinger108 » Tue Jan 21, 2020 8:10 pm

Respect! Do you have a git repository?
Posts: 18
Joined: Fri Sep 13, 2019 3:44 pm


Return to Libgdx

Who is online

Users browsing this forum: Google [Bot], Majestic-12 [Bot] and 1 guest