Update to gamesdk v4.0.0 with our rebased patches #189
Conversation
This reverts commit 6b33074.
Just revert the changes to upstream so that we can reapply the rebased on This partially reverts 41f30c3 Signed-off-by: William Casarin <[email protected]>
… destroyed" This reverts commit 2a2f276.
This reverts commit 9835d1d.
This reverts commit 73d56ed.
This reverts commit 202ab4c.
This reverts commit d6345ab.
|
Cool - thanks for taking a pass at this! It's good that this explicitly re-applies I'm not so sure that we need to pull in the upstream history for GameActivity into the repo though by rebasing all of their patches. Previously we've just taken a vanilla snapshot of whatever version we want to support (replacing whatever we have in tree previously) and then applied our integration patches on that. I guess we won't really gain the ability to bisect by pulling in their full history while we still require some patches on top that would also need to be rebased if you wanted to try bisecting through specific gamesdk commits? If we use a merge commit with this PR that could help avoid having their history add noise to the Maybe you're guessing it might be useful to be able to rebase the integration patches to bisect any potential issues while testing? |
I did it both ways so we can use that one, i just thought it might be useful to see the changes individually and for bisectability since some people prefer it that way, up to you |
We need to do this so that we can update our patches so they apply cleanly on v4.0.0 Signed-off-by: William Casarin <[email protected]>
Signed-off-by: William Casarin <[email protected]>
Give C symbols that need to be exported a `_C` suffix so that they can be linked into a Rust symbol with the correct name (Since we can't directly export from C/C++ with Rust+Cargo) See: rust-lang/rfcs#2771
The real `android_main` is going to be written in Rust and android-activity needs to handle its own initialization before calling the application's `android_main` and so the C/C++ code calls an intermediate `_rust_glue_entry` function.
This makes a small change to the C glue code for GameActivity to send looper wake ups when new input is received (only sending a single wake up, until the application next handles input). This makes it possible to recognise that new input is available and send an `InputAvailable` event to the application - consistent with how NativeActivity can deliver `InputAvailable` events. This addresses a significant feature disparity between GameActivity and NativeActivity that meant GameActivity was not practically usable for GUI applications that wouldn't want to render continuously like a game.
This ensures that any java Activity callbacks take into account the possibility that the `android_app` may have already been marked destroyed if `android_main` has returned - and so they mustn't block and wait for a thread that is no longer running.
This also adds `InputEvent::TextEvent` for notifying applications of IME state changes as well as explicit getter/setter APIs for tracking IME selection + compose region state. (only supported with GameActivity) Fixes: rust-mobile#18
The `unicodeChar` in `GameActivityKeyEvent` wasn't being exposed by `android-activity` because we couldn't expose the unicode character in the same way with the native-activity backend - due to how events are received via an `InputQueue` that doesn't expose the underlying Java references for the key events. Now that we have a consistent way of supporting unicode character mapping via `KeyCharacterMap` bindings it's redundant for the `GameActivity` backend to call `getUnicodeChar` automatically for each key press.
jb55
force-pushed
the
gamesdk-4.0.0-with-patches
branch
from
1d76468 to
dc2ef75
Compare
|
squashed! |
This is a WIP as I have not tested or compiled anything, I simply rebased our local patches (with proper formatting) on top of 4.0.0. It was surprisingly a clean rebase even though upstream moved things around and clang-formatted everything. I had to get somewhat clever with the patch rebasing and formatting to align things up.
I decided to replay all of the patches from gamesdk so that it can be verified that nothing was messed up and to not break bisectability.To do this I first reverted the original patches on 2.0.2, reformatted them, and then cleanly rebased them on top of 4.0.0.I noticed some includes changed which might have broken stuff. I will start testing this next!
Left to do
Fixes #185
Fixes #188