euphyy wrote:
It seems that fluddokt has been even busier than I have lately, which is why the Android version hasn't been getting as many updates. (I don't blame him, since porting my changes can't be very interesting...) But it's all open source, so really anyone can take over if they want to.
A technical issue is the way the Android version is written. To actually get the program running on Android, fluddokt had to switch the game engine from Slick2D (simple, dead, and desktop-only) to libGDX. But instead of porting the source code, which would've taken a very long time, he's "faking" the Slick2D API and replacing the implementation of all referenced methods with libGDX code. It works, as you can tell, but comes with these large problems:
- If someone updates the Slick2D code and calls Slick2D methods not yet "faked", all of those methods need to be rewritten as well (which isn't always easy, or even possible).
- If anyone continues developing the libGDX code with pure libGDX calls, the source code will be a mess of mixed Slick2D/libGDX and merging changes from the Slick2D code will get significantly harder.
- Some desktop code needs to be rewritten to work at all on Android, which makes things even more complicated.
The only two choices I can see are to rewrite the project completely in pure libGDX (which nobody wants to do) or continue developing in Slick2D and porting the changes (which anyone can try to do, if they're up for it).
A more practical problem is that I don't actually own an Android device, so I'm not easily able to test anything for it.
Well, to be honest, I would support the choice to rewrite the entire game in libGDX.
Reasons are because of libGDX are targeted at making games on any platform as well as cleaner code base (as long we don't do much of editing and mucking around)
From my view, most of the game (map parser, objects, states (need confirming, yet to reach that part), sounds) itself can be retained as is, but the drawing part must be rebuilt to use libGDX platform.
Also, by changing to libGDX, the performance issues on opsu-android may be possible to be handled since there's no API faking going on everywhere as well as the desktop version which seems still have room for more improvement
For the part of rewriting, I might able to offer my help but because of my Java skill limitations (and the fact that libGDX documentation is quite lengthy, so it takes time for me to understand how the whole platform works for now), I might unable to handle the project on my own and have to keep up with RL stuff.