Currently, we do not display every second frame in 25fps/30fps games
which run to vsync. This improves performance as there's less rendering
for the GPU to perform, but when combined with vsync, could cause frame
pacing issues.
This commit adds an option to force every frame generated by the console
to be displayed to the host, which may improve pacing for these games.
We must set Java_GCAdapter.manager before the GC adapter thread (C++)
starts. We used to set it at emulation start, which was fine until
9f3f45a made the GC adapter thread start much earlier.
Because trying to fit a 3:1 banner into a circle looks very awkward.
Also move the banner below the title/description now that it
takes up more space horizontally.
When using motion controls, it's useful to be able to lock the screen
to a certain orientation so that Android won't interpret game motions
as an intent to change the screen orientation. To this end, I've
changed the existing orientation lock setting in the following ways:
- A portrait lock mode has been added in addition to the existing
landscape lock mode and unlocked mode.
- The landscape lock mode now locks to regular landscape rather than
letting you change between the two possible landscape orientations.
- The setting is now accessed during emulation rather than outside.
Not that this has much relation to the rest of the PR, but it's an
easy fix that we might as well throw in while we're already
overwriting everyone's WiimoteNew.ini.
This will help to disable all inter-instruction dependencies.
So android users can check if only a single instruction is broken without compiling dolphin on their own.
The workaround was added in 0446a58.
The underlying problem is that we must not destroy the surface
while the video backend is initializing, otherwise the video
backend may reference nullptr.
I've also cleaned up the logic for when to destroy the surface.
Note that the comment in EmulationFragment.java about only being
able to destroy the surface when emulation is running is not true
anymore (due to de632fc, it seems like).
Much of our native code assumes that UICommon::Init has been called
(for reasons such as wanting to access the user's settings),
so not calling it until emulation start heavily limits what native
code we can use in the Android GUI (except during emulation).
Tilka