gintoki147 wrote:

I love this project.Personally, I think you should drop desktop support and focus only on the Android version. Too bad it's almost impossible to play streams on a touch screen. D:

I think you got the point wrong here. There is one guy working on the PC version, which is opsu! itself, and another one who is working on opsu! for android. I think euphyy (the creator and mantainer of the PC version) would rather carry on working on it for the PC version, while leaving everything related to the android version to fluddokt, the guy working on the android port.

Howl wrote:

gintoki147 wrote:

I love this project.Personally, I think you should drop desktop support and focus only on the Android version. Too bad it's almost impossible to play streams on a touch screen. D:

I think you got the point wrong here. There is one guy working on the PC version, which is opsu! itself, and another one who is working on opsu! for android. I think euphyy (the creator and mantainer of the PC version) would rather carry on working on it for the PC version, while leaving everything related to the android version to fluddokt, the guy working on the android port.

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.

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.

chong601 wrote:

I don't think there'd be any significant performance gains because opsu! isn't very resource-intensive anyway. There's also a lot of Slick-specific code in the states and audio, so there's more rewriting required than you'd expect. I'm not discouraging you from porting the code, but if you're willing to do that much, it might really be more worth your time to help fluddokt merge changes over to his fork. (Though the new slider rendering code might be a pain to move over there...)

I don't know if this is a known issue, but still...Even though I adjusted the music offset in the options menu, some songs are clearly out of sync with the objects, while others play just fine.Maybe opsu! is not reading the beatmaps' offset correctly?

gintoki147 wrote:

I don't know if this is a known issue, but still...Even though I adjusted the music offset in the options menu, some songs are clearly out of sync with the objects, while others play just fine.Maybe opsu! is not reading the beatmaps' offset correctly?

I'm playing on Android btw

Probably the beatmaps don't have a correct offset. A local offset feature (per-beatmap offset) has already been requested on this thread.

Gradle: With the help of LemonLake, you can now build opsu! using Gradle (or keep using Maven). This came with the bonus of removing JarSplice from the build cycle, as opsu! now has its own native loader.

The bug fixes are too numerous to list here, so check out the release notes if you're interested. Thanks again for all the support!

Osugye wrote:

Nice work but I have some requests:MouseSpeed = xx.xxFrame Limiter = UnlimitedSkinnable Logo and Play / Exit / Download buttons :/

No idea how to change mouse sensitivity in LWJGL (you probably can't). I don't think unlimited FPS is necessary (it really eats up CPU in Slick2D, and it probably wouldn't have any benefits), but feel free to modify the source code yourself -- I can point out the few lines you'd need to change if needed. And everything is skinnable.