-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI texture slice texture flipping reimplementation #15034
Conversation
Seems to work, just going to get something to eat then I'll make a few more test examples to be sure. |
It seems to be alright but I'd be happiest if @ManevilleF could have a look before it's merged. |
The generated |
FYI @janhohenheim, this is the other blocker on 0.14.2 :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good except for one potential mistake that I'd like sorted out. The rest are just minor style nits.
Thanks for adding an example with the implementation, I really appreciate it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, you can shave off half of the size of this png with oxipng
, but at this low filesize I'm fine with merging as-is. Something to keep in mind for bigger pngs :)
let tsx = target_size.x * (1. - border[0] - border[2]); | ||
let tsy = target_size.y * (1. - border[1] - border[3]); | ||
let isx = image_size.x * (slices[2] - slices[0]); | ||
let isy = image_size.y * (slices[2] - slices[1]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know much about the nine-patch implementation, but the code before used 3
instead of 2
on this line.
I assume that's what you meant with your quote
Also fixes a bug that was causing the side and center slices to tile incorrectly.
?
Can't comment on the mathematical correctness of this change in general. It looks like it's doing something else than before mathematically? Could you comment on that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the old texture slicing implementation (which used a separate sprite for each slice) insets were used to define the slices, but I found it more natural to use normalized coordinates, offset from the the top-left corner.
So previously nine slicing a 100x100 image with 25x25 border corner pieces you had
border = [
0.25 // left inset,
0.25 // top inset,
0.25 // right inset,
0.25 // bottom inset,
]
and then to calculate the normalized width of the horizontal side and center sections it would do:
1 - border[0] - border[2] = 1 - 0.25 - 0.25 = 0.5
whereas now it's
border = [
0.25 // top-left x,
0.25 // top-left y,
0.75 // bottom-right x,
0.75 // bottom-right y,
]
and to get the normalized width it's
border[2] - border[0] = 0.75 - 0.25 = 0.5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that affect how users define the slices? Will it break current usage ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No the user API should behave the same as before, the coordinates change is just for the internal calculations.
let image = asset_server.load_with_settings( | ||
"textures/fantasy_ui_borders/numbered_slices.png", | ||
|settings: &mut ImageLoaderSettings| { | ||
// Need to use nearest filtering to avoid bleeding between the slices with tiling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's only because they're pixely, right? Would a more high-res png also require this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It depends on the texture and the result the user wants. If, as in the ui_texture_slice
example, the source texture is seamless and the sides are just mono-coloured horizontal and vertical lines then it can be stretched or tiled without any artifacts even with blending.
With the numbered texture from the example here, there is bleeding between each slice if you use ImageSampler::linear()
. The same was true of the previous implementation using multiple sprites, it's not a regression at least.
@@ -0,0 +1,75 @@ | |||
//! This example illustrates how to how to flip and tile images with 9 Slicing in the UI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some links or a basic explanation as to what 9-slicing even is would nice for beginners.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd rather make an issue and leave that for a separate PR. The new example is just adapated from the ui_texture_slice.rs
example which didn't have much in the way of explanation either.
Co-authored-by: Jan Hohenheim <[email protected]>
Co-authored-by: Jan Hohenheim <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lovely changes, thanks! Left two very minor suggestions to apply, feel free to ignore :)
Co-authored-by: Jan Hohenheim <[email protected]>
# Objective Fixes #15032 ## Solution Reimplement support for the `flip_x` and `flip_y` fields. This doesn't flip the border geometry, I'm not really sure whether that is desirable or not. Also fixes a bug that was causing the side and center slices to tile incorrectly. ### Testing ``` cargo run --example ui_texture_slice_flip_and_tile ``` ## Showcase <img width="787" alt="nearest" src="https://github.com/user-attachments/assets/bc044bae-1748-42ba-92b5-0500c87264f6"> With tiling need to use nearest filtering to avoid bleeding between the slices. --------- Co-authored-by: Jan Hohenheim <[email protected]> Co-authored-by: Alice Cecile <[email protected]>
Objective
Fixes #15032
Solution
Reimplement support for the
flip_x
andflip_y
fields.This doesn't flip the border geometry, I'm not really sure whether that is desirable or not.
Also fixes a bug that was causing the side and center slices to tile incorrectly.
Testing
Showcase
With tiling need to use nearest filtering to avoid bleeding between the slices.