Open DeltaFlyerW opened 3 weeks ago
The core logic of the block area now works as intended in custom playfield sizes. However, after more intensive testing, I think the UI of the block area manager can still use a bunch of work. There are weird irks that may hinder UX:
z-index
to the button container, but this will produce a case where a block area can be completely behind a button, so you cannot interact with it at all. Maybe a more viable approach is to put the buttons on the left/right side with a grid container?mousemove
or touchmove
and cancel the operation on mouseup
or touchend
if it fires. If it is not enough, the operation may be cancelled if there is enough displacement from the press position to the movement position (see how BeatmapButton
handles this).Despite the above, I received an information from @Reco1I that he may try to make a native Android UI for this rather than using a WebView, but I would like to confirm with you if you are okay with it.
Additionally, here is a video demonstrating the issues:
https://github.com/osudroid/osu-droid/assets/52914632/aebada9f-9e75-455b-96eb-9e7aeb46074d
As Rian says I would offer myself to contribute.
- Maybe a block area should have a minimum width and height? It is quite tricky to manage very small areas, and I doubt many players will try to hyper-optimize blocking small areas.
the current implementation does enforce a minimum dimension of 5px for both width and height. This can be observed in the video at the 00:26 mark, as detailed
- Is there a specific reason for a347d04? It is not guaranteed that the WebView loads instantly in slow devices. In such cases, showing a loading indicator is more user-friendly than having them stare at a blank screen.
An issue occurs that re-entering the configuration page was causing the loading animation to persist indefinitely.
Despite the above, I received an information from @Reco1I that he may try to make a native Android UI for this rather than using a WebView, but I would like to confirm with you if you are okay with it.
I would be glad to have a contributor take part in this feature. Should @Reco1I decide to proceed with creating a native Android UI rather than using a WebView, I will hold off on making further commits to this PR. If any assistance is needed, please do not hesitate to reach out—I am willing to help in any way I can.
the current implementation does enforce a minimum dimension of 5px for both width and height
Aha. It was noticeable that the red squares don't perfectly align when the block area was made as small as possible, although I'm not sure if it's enough to not confuse the user on which corner was pressed. The CSS does have a cursor
property for each corner, but this is irrelevant due to touchscreen.
Nonetheless, there's no need to work on the current UI for now. The core logic can be reused by the Android native UI if it's made.
Description
Add an anti-accidental touch feature, which allow user to select some area on screen that the touch inside will not be a valid input event for game.
Justification
As screen-to-body ratio grows in decent mobile devices, accidental touch has been a problem for many play styles. During play, accidental touch causes unexpected drop as your palm or finger touch screen edge.