Feature/make radial menu great again #32653
Conversation
github-actions
bot
added
the
Changes: UI
|
add a video to show everyone how cool this is |
|
|
||
| var dist = Math.Sqrt(Math.Pow(point.X - cX, 2) + Math.Pow(point.Y - cY, 2)); | ||
| var isNotInRadius = dist > Container.Radius * 2 || dist < Container.Radius / 2; | ||
| return isNotInRadius; |
There was a problem hiding this comment.
this DOES NOT respect not full circle menu! I feel like it will be real pain to make it work with with it. Maybe use default behaviour in this scenario and fallback to texturebutton mouse detection?
|
|
||
| // Add padding from the center at higher child counts so they don't overlap. | ||
| Radius = baseRadius + (childCount * radiusIncrement); | ||
| Radius = baseRadius + (elementCount * radiusIncrement); |
There was a problem hiding this comment.
This adjustment changes the overall area of the container, so there's a large disparity in size between menu layers that contain only a few elements and those that contain many. Consider having a set size for the sectors and only shifting the positions of the icons
On the topic of size, the amount of screen real estate that the sectors take up is quite large, consider reducing the outer radius as well, if it doesn't cause issues with the above
There was a problem hiding this comment.
i'll remove separators from radius increment - that makes sense, it was my failure to properly understand why it is there.
About size of sectors and 'free-space' - the point of this UX changes was to make it require less precision - so you can click it faster and not really aim, but make choice of direction. Size is just for that - most of games have this 'wheel' ui blur and grow in opacity from center to outer corners - i could not make it work here, sadly (tbf was not trying) but REAL size of radial menus were quite the same overall (if we remove blur and make controls constant color), i belive!
There was a problem hiding this comment.
If there is some proposal about how to change numbers exactly - you are welcome to ask and i will try it - currently its radius * 2 for outer, radius /2 for inner
There was a problem hiding this comment.
Changed back to only use child count thanks to eoin. Kinda missed it initially. Yay!.
Multipliers were moved to properties - so can be easily changed.
|
is there a way to make it smaller? This looks way too big |
Agreed theres a lot of deadspace. |
github-actions
bot
added
the
Status: Needs Review
Can this be idea for future improvement? In separate PR. |
Most of our contributers won't have experience with writing shaders, so I don't we can really request that they do so |
|
can you also move text from on hover to make him permanent under or below icons? |
I belive that part of hover behaviour is from parent component (TextureButton) so that would need... some copy-paste from there. Also not all tooltips would look nice, i feel >_> which is out of current PR scope. I'd better have separate issue for that thing to be fixed and reviewed without all other garbage i coded here |
|
@eoineoineoin can u please resolve stuff i that was fixed and where answer statisfied you? |
I don't have any ability to resolve those threads, I'm afraid. Did you see these comments? |
Thank you! I will look at that! |
Ok i found out why it was happening - float was messing up numbers. I floored position on menu item controls - it snapped to physical grid and al of the math works perfecly now - no holes, not in graphycs, not in HasPoint checks! |
|
Any chance you can have the option to chance opacity on it? That looks too obnoxious for me to use. |
Color (and as result opacity) is a public property of control, so it can be changed. What exact values to use by default - dunno ;( |
| tb.AngleSectorTo = sepAngle * (childIndex + 1); | ||
| tb.AngleOffset = angleOffset; | ||
| tb.InnerRadius = Radius / 2; | ||
| tb.OuterRadius = Radius * 2; |
There was a problem hiding this comment.
If the inner and outer radii are going to be set by RadialContainer, the multipliers need to be fields, no magic numbers
I'd suggest 1.5f for the the outer radius, there's too much empty space inside the sector otherwise
There was a problem hiding this comment.
extracting property for multipliers - thats actually good idea : >
about 1.5f - ok, but bear in mind WHY we are adding those changes - we want control to be not requiring precision, so you can use it very-very fast. Making it too small make it not UX but just visual change. But having it variable - we can change it in any moment - so its fine.
| var type = filled | ||
| ? DrawPrimitiveTopology.TriangleStrip | ||
| : DrawPrimitiveTopology.LineStrip; | ||
| drawingHandleScreen.DrawPrimitives(type, _sectorPointsForDrawing, color); |
There was a problem hiding this comment.
| drawingHandleScreen.DrawPrimitives(type, _sectorPointsForDrawing, color); | |
| drawingHandleScreen.DrawPrimitives(type, _sectorPointsForDrawing, Color.ToSrgb(color)); |
Drawn primitives require that supplied colors be specified in srgb format
There was a problem hiding this comment.
having to call it on each draw is a bit wierd. But ok. fixed.
There was a problem hiding this comment.
If it's too expensive here, move it else where,or use a lookup table to convert between rgb and srgb colors
There was a problem hiding this comment.
Its not like 'too expensive', but we shove everything that sure we can be cached to the cache for perf. Not nice thing is that it will require some wierd getter-setter dancing. I don't mind it, gonna do it...
…olor pallet for radial menu button
… menu buttons with sectors, RadialContainer Radius renamed and now actually changed control radius.
chromiumboy
added
Status: Awaiting Changes
…converted to and from sRGB in property getter-setters
| /// <summary> | ||
| /// Color of background in non-hovered state. Accepts RGB color, works with sRGB for DrawPrimitive internally. | ||
| /// </summary> | ||
| public Color BackgroundColor |
There was a problem hiding this comment.
Hmm, this is a bit sussy. It's probably better if we just call this field 'BackgroundColorSrgb' (same for those below) and expect people to supply a srgb formatted value rather than this conversion back and forth. Sorry 'bout misleading you on that
There was a problem hiding this comment.
There is not 'srgb c-tor', so its just plain harder to supply correct thing - i see no reason to enfoce developer to do more action that is actually required. Stylesheet code includes only RGB and not sRGB colors as far as i can see at first glance, so if it will be applied - it should break notion just for this control, and also contain more code then it is crucial to declare stylesheet info (transform to srgb). Getter/Setter logic IS bad when you are going to apply it every second /tick or so, but thats clearly not he case, right?
|
enabled any functional keys pressed when pushing radial menu buttons as AI requires alt to be pressed when opening door menu - this will make it feel more fluent as now u dont need release alt when clicking menu, and then press it again to call menu on next door. |
About the PR
Radial menu was great addition to UI but it requires precision as it is now. To bring up better UX it needs to be usable without too much precision so it can be used effectively in panic situations. This problem was already solved by wheel menu in most modern games - use sectors of circle to pick options and not icons themselves.
Why / Balance
Robust wheel UI!
Technical details
RadialMenu now uses 'special' button as context button in center - RadialMenuContextualCentralTextureButton. It considers space inside inner circle of parent RadialContainer half radius, and ALL outer space outside twice of its radius - as itself.
RadialContainer now puts angle sector data in each child RadialMenuTextureButton.
RadialMenuTextureButton now can draw bagle segments!
Media
new-radial-menu.webm
Requirements
Breaking changes
removed RadialMenuButton - was not used.
now RadialMenuTextureButton requires to be inside RadialContainer to work properly
Changelog
🆑 Fildrance, SaphireLattice, eoineoineoin