Bug discovered via an incomplete fix in Sudachi.
Some Progress Dialog callbacks pass the wrong type (Double instead of Long) from C++ to Java code causing a crash at runtime.
To fix this a new function is implemented to convert to a Java Long and that is used instead of the function that converts to a Double.
Reviewed-on: http://vub63vv26q6v27xzv2dtcd25xumubshogm67yrpaz2rculqxs7jlfqad.onion/torzu-emu/torzu/pulls/58
Co-authored-by: echosys <echosys@noreply.localhost>
Co-committed-by: echosys <echosys@noreply.localhost>
Update the dependencies of the Android app (used libraries and SDK). The Android SDK was not updated to the latest version, because then the build fails.
The `gradle-wrapper.jar` (the only binary blob touched in this PR) can be verified by checking against the official checksums [here](gradle-wrapper.jar).
Co-authored-by: spectranator <spectranator@vub63vv26q6v27xzv2dtcd25xumubshogm67yrpaz2rculqxs7jlfqad.onion>
Reviewed-on: http://vub63vv26q6v27xzv2dtcd25xumubshogm67yrpaz2rculqxs7jlfqad.onion/torzu-emu/torzu/pulls/52
Co-authored-by: echosys <echosys@noreply.localhost>
Co-committed-by: echosys <echosys@noreply.localhost>
Fixes x86_64 builds for Android by stubbing a function that calls into libadrenotools to query GPU driver information. libadrenotools is only available for arm64.
The function should not be called anyways, as the menu that would display the information is disabled on unsupported devices.
To enable x86_64 for building change the line `abiFilters += listOf("arm64-v8a")` in `src/android/app/build.gradle.kts` to `abiFilters += listOf("arm64-v8a", "x86_64")`.
I did not do this by default as it significantly increases the build time (the native part needs to be build once for each architecture) and increases the app size (this is less of a concern as games are already significantly larger).
It might allow usage on Chromebooks (the internet tells me those run on x86_64) and some few Android devices. The main advantage I see is for development of the app itself, as it allows running it in waydroid for local testing.
Reviewed-on: http://vub63vv26q6v27xzv2dtcd25xumubshogm67yrpaz2rculqxs7jlfqad.onion/torzu-emu/torzu/pulls/49
Co-authored-by: echosys <echosys@noreply.localhost>
Co-committed-by: echosys <echosys@noreply.localhost>
Removes the early access Android app variant from the build config and removes the get early access button from the settings tab.
I also tried to remove the code for the variant (different logo + colors) and the code for the button, but I am no Android developer so I might have missed some stuff.
Additionally I did not touch the translation files.
Essentially this gets rid of the now useless fancy button and improves build times as it only needs to build one apk now.
Reviewed-on: http://vub63vv26q6v27xzv2dtcd25xumubshogm67yrpaz2rculqxs7jlfqad.onion/torzu-emu/torzu/pulls/27
Spec's note:
Whatever there's left can still be removed at a later point.
Co-authored-by: echosys <echosys@noreply.localhost>
Co-committed-by: echosys <echosys@noreply.localhost>
Adds a new option "On Load" to the "Optimize SPIRV output" option that turns on optimizations during the loading of the shader cache from disk, but turns it off after that.
The previous checkbox states have been named "Never" for unchecked and "Always" for checked.
The idea is that once the shader cache has most of the shaders in a game cached they can be optimized during initial game startup (where a performance hit matters less) and the few shaders that get compiled during runtime are not optimized to reduce performance hits.
Most of the commit is adding the setting to the Android app, the main logic is in the `gl_shader_cache.cpp` and `vk_pipeline_cache.cpp` files.
Reviewed-on: http://vub63vv26q6v27xzv2dtcd25xumubshogm67yrpaz2rculqxs7jlfqad.onion/torzu-emu/torzu/pulls/13
Co-authored-by: echosys <echosys@noreply.localhost>
Co-committed-by: echosys <echosys@noreply.localhost>
If you tried to connect a controller that was previously configured with an unsupported style for your game, when you try to connect that controller, it will immediately disconnect. This ensures that the controller that is being connected will be changed to the first supported style index before being connected.
Controls can have no mapping if they are either "[empty]" or and empty string. This was causing an issue if you reset mapping on all controllers and then tried to play a game. The check to determine whether auto mapping was required would fail and leave you will no mapped controllers. This feels a bit like user error but it smooths things out if you forget so I see it as necessary.
It's a bit of a hack since I'm moving the view instead of telling the Vulkan surface to bias itself to the top/bottom/center but it works fine for now.
