-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate Android framework to SDL #6105
Conversation
Interesting that you got this to work (I tried what sounds to be the exact same approach, more or less, and it didn't work - input was broken, and so was debugging). Interested to see if this actually works. The packaging 200% needs work though. We cannot be consuming random binaries from random sources. The build toolchain for our SDL2 fork (https://github.com/ppy/SDL2-CS) must be used for SDL binaries. Maybe the extra wrapper code must live there too (or else, in a separate repository), and if possible, the changes to the SDL Android project should be upstreamed. |
I understand that reproducibility and integrity matter a lot in packaging, so I even considered excluding my binaries from this PR, but I thought it would cause some big inconvenience for testing, so I just went with having binaries included. I should have mentioned it. I will look into that repo and open another PR there if I come up with an okay solution. |
You could try using With this, Example code from another project, here the native library expects a |
I'm not sure it will be relevant but the last time the words "AOT" and "android" were in close proximity things fizzled out very quickly due to being terminally broken. So I'm not holding my breath... |
Above PR adds SDL2-CS-Android project to SDL2-CS. Changes in Java code are no longer needed, too. You can test it by removing Edit: Tried AOT, but it doesn't seem to launch on my device... |
libsdl-org/SDL@3a482eb could be used to avoid the need for |
I will just push my local framework as local SDL2-CS is needed to test at the moment anyway, and tidy up once things look okay. With @Susko3's suggestion, I got it working and successfully removed SDL2AndroidMainSetter! You can test it by using SDL2-CS update-android-binaries branch. |
On the framework apps (test and samplegame), I get a potential crash when rotating 90 degrees (osu! not affected as it can't rotate 90):
This may also resolve ppy/osu#5236 for android, but there's a resizing bug which may be a blocker as it's really broken (on Pixel 6a with Android 14 beta if that changes anything): screen-20240210-143706.mp4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As commented above.
b1bdead
to
d7dfd76
Compare
I actually have run into that crash when I was writing this PR, but didn't fix it eventually since osu-framework/osu.Framework/Platform/SDL2Window_Windowing.cs Lines 309 to 317 in 0e88708
I can't reproduce the resizing bug in the video you posted, In the latest release (osuTK), my game doesn't get moved/resized at all, so I can't see what I am typing because keyboard hides bottom half, and in my build (SDL2), the game goes up (only showing bottom half), so I can see my chat fine. My phone is Galaxy A51 on Android 13, so something may be different with keyboard handling, but I'm not really sure.. |
d7dfd76
to
241d73c
Compare
I can't seem to reproduce the resizing bug anymore. Probably incidentally fixed with the new commits. The textboxes still have an off-by-one screen offset bug though:
|
I applied most of the review suggestions, but there seem to be some remaining issues (keyboard screen offsets and multi-touch assert fail for now?), but I currently don't have much time to actually investigate into them.. I should be more free after a week, so I'll look into them then. Though if anyone suggests fixes for the forementioned issues in the meantime, I'll try applying them (or just commit them yourself if you have perms?). |
The main problem with the keyboard is that we're calling From
I'll try to figure something out. |
I've reported #6105 (review) upstream in libsdl-org/SDL#9591. This issue is not unique to android and can fail on Windows too. |
@Susko3 is this fine to move forward after all of the other PRs? |
Yep this is good to go, just needs merge master + removal of no longer necessary workarounds:
|
All of it? What about this thing? I don't see it being moved anywhere? |
You're correct, that has to stay, I must have confused it with the dropped events that were fixed with #6259. |
Not sure why it's still here, I asked during review and it was supposed to be removed.
Have removed this in dad23c0.
I can't seem to be able to remove these. Doing so results in the window never becoming focused and as such touch input doesn't work. I'd really like to move this along now so I think this can be fixed as a follow-up. |
// blocks back button | ||
SDL.SDL3.SDL_SetHint(SDL.SDL3.SDL_HINT_ANDROID_TRAP_BACK_BUTTON, "1"u8); | ||
|
||
// hints are here because they don't apply well in another location such as SDL3Window | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason why I didn't remove them was because SDL docs had this comment on the hint:
* This is necessary for the right mouse button to work on some Android
* devices, or to be able to trap the back button for use in your code
* reliably. If this hint is true, the back button will show up as an
* SDL_EVENT_KEY_DOWN / SDL_EVENT_KEY_UP pair with a keycode of
* SDL_SCANCODE_AC_BACK.
*
* The variable can be set to the following values:
*
* - "0": Back button will be handled as usual for system. (default)
* - "1": Back button will be trapped, allowing you to handle the key press
* manually. (This will also let right mouse click work on systems where the
* right mouse button functions as back.)
https://wiki.libsdl.org/SDL3/SDL_HINT_ANDROID_TRAP_BACK_BUTTON
I should have made it more clear..
Not sure how it works without the hint though, but I guess it may be fine if it works?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seemed fine to me /shrug
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to work well, just need to remove the osuTK.Android
reference as it's no longer needed.
} | ||
|
||
/// <summary> | ||
/// Updates the <see cref="IWindow.SafeAreaPadding"/>, taking into account screen insets that may be obstructing this <see cref="AndroidGameView"/>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be updated to mention the proper class, and remove using osuTK.Android;
/// Updates the <see cref="IWindow.SafeAreaPadding"/>, taking into account screen insets that may be obstructing this <see cref="AndroidGameView"/>. | |
/// Updates the <see cref="IWindow.SafeAreaPadding"/>, taking into account screen insets that may be obstructing this <see cref="AndroidGameSurface"/>. |
@@ -19,6 +19,7 @@ | |||
</ItemGroup> | |||
<ItemGroup> | |||
<PackageReference Include="ppy.osuTK.Android" Version="1.0.211" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<PackageReference Include="ppy.osuTK.Android" Version="1.0.211" /> |
Not needed if the xmldoc reference in AndroidGameSurface
is removed.
Or you can merge right now, and we do this later in osuTK cleanup. |
This PR lets Android devices use SDL for windowing/input. osuTK usage got removed in the process of doing it.
It also removes Android input handling code and replaces them with existing SDL components.
I did test using Vulkan with it and it kind of works, but it was just full of glitches (a lot of flashes and tearing). Veldrid backends (OpenGL/Vulkan) crash if they are brought up from background. I don't know well about graphics, anyway.. the only graphics backend that works well is Legacy OpenGL.
Java is needed because SDL Android heavily relies on JNI, and its binding is made with Xamarin.Android.
I didn't reuse the code, but brought an idea from https://github.com/0x0ade/SDL2Droid-CS, it helped me a lot!
Tested on my tablet with Android 14.
You can use this osu! branch if you want to test.