Skip to content
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

[WIP] Android build #88

Closed
wants to merge 61 commits into from
Closed

Conversation

ciciplusplus
Copy link
Collaborator

@ciciplusplus ciciplusplus commented Mar 21, 2023

What is this all about?

This is a WIP Android build, supporting aarch64 devices

What was tested?

  • Super Monkey Ball 1.02 on Google Pixel 3a (playable, but tilt controls not working, so not that playable) All supported apps (fully playable!)
  • touchHLE build for macOS (builds, runs)

I've not tested Windows version after the changes

How to use

Refer to BUILDING.md in android folder for building instruction.

IMPORTANT: in the current state Android app expects a particular setup for file folder to work.
In particular, /data/data/org.touchhle.android/files folder on your device should contain:

  • Super Monkey Ball v1.02 .ipa (legally obtained and owned; note 2 spaces between Ball and v1.02) a touchHLE_apps folder with your apps
  • touchHLE_fonts and touchHLE_dylibs folders from touchHLE source or binary distribution

Important changes

  • Introduction of android project, which is a copy of SDL2 2.26.4 android template project with small modifications (zlib LICENSE.txt file, cargo-ndk plugin and some cosmetic changes)
  • main.rs is split now to lib.rs (android build) and main.rs (desktop build)
  • passing from [bundled, static-link] mode to [bundled] for sdl2 dependency
  • introducing OpenGL ES 1.1 native implementation
  • Android app has org.touchhle.android bundle
  • SDL source is added to vendor/ folder, used only for Android build

Known issues

  • No mechanism for app/ipa selection/loading
  • Tilt controls are not implemented
  • Splash screen is disabled
  • App scale/orientation is hardcoded
  • Only arm64-v8a arch is supported
  • SDL is built twice: once with rust-sdl2 and once specifically for Android
  • SDL 2.26.6 version was patched here (and as consequence sdl2-rust as well) to workaround SDL build issue with ANDROID_NDK not set... Something is wrong here on one of the crate among cmake, cargo-ndk, sdl2-rust or cargo itself, as locally I can do build SDL from sources (and it's also done during gradle build). Maybe it's related to the changes of Android tooling itself. Or maybe it's cmake config of SDL2 which is wrong. Or...
  • Some GL functions in update_renderbuffers do not have equivalents in Gles 1.1, so i just commented them out. While I've not observed any visible glitches, the cleaning/restoring of gl context may not work perfectly here.
  • Logging with println!() is not working. Normally, with android_log it should be redirected to logcat, but, firstly, log dependency of it conflicts with internal log module and, secondly, even if fixed, it's still not working. At the brighter side, sdl2::log works, so all log!() calls using it instead

References

  1. https://julhe.github.io/posts/building-an-android-app-with-rust-and-sdl2/
  2. https://github.com/libsdl-org/SDL/blob/release-2.26.4/docs/README-android.md
  3. https://github.com/rust-mobile/rust-android-examples/tree/main/na-mainloop

P.S.

Hope that my monkey patching (pun intended) it's not too big to review 😸

@hikari-no-yume
Copy link
Collaborator

Congratulations on getting this in a good enough state to open a pull request? And thanks for your efforts on this, I know it's been a lot of work!

To others: please do not comment on this PR asking when this will be merged, thanks in advance.

@ciciplusplus ciciplusplus marked this pull request as ready for review March 21, 2023 23:30
@ciciplusplus
Copy link
Collaborator Author

Congratulations on getting this in a good enough state to open a pull request? And thanks for your efforts on this, I know it's been a lot of work!

Thanks and sorry, in case it wasn't clear, I think it's ready to be reviewed.

It would be great to receive at least high level feedback, like which parts are absolutely necessary to be reworked and which are ok to merge in the current state.

/// Variant of present_renderbuffer but for Android
/// Instead of blitting between framebuffers, we use CopyTexImage2D to copy renderbuffers to a texture
/// TODO: refactor common parts with present_renderbuffer
#[cfg(target_os = "android")]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how realistic this is, but can we share most of the code rather than duplicating the whole function?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I see 2 possibilities:

  • use present_renderbuffer's platform specific versions
  • have single function filled with platform specific branching inside function body

I opted for first one for the sake of readability, but can try to implement second option if you think it's preferable

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh wait I forgot that it bypasses the API abstraction, so it is actually API-specific right now :(

I guess this conflicts with what I said above about wanting GLES1Native to be available on desktop. Okay, I guess we'll leave it as-is for now and we can clean it up later.

src/fs.rs Outdated Show resolved Hide resolved
I refuse to commit huge scripts and binaries I didn't write, and which
don't have license headers, to git. That gradle is hard to use without
them is gradle's problem.
@touchHLE touchHLE deleted a comment from Boom20230908 Oct 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants