Why are objects like buttons not a slice9?

[zeroZshadow]

Im seeing the buttons have 9 seperate images. But why not have 1 image, and 4 offsets ? (2 vertical slices and 2 horizontal slices)
This should allow but much easyer editing of the one button image, while decreasing the amount of data you need to specify in the theme file.

[alaa-eddine]

Hi @zeroZshadow actually the 9 slice skin is the most complexe one, EZGUI support others (not the one you described).
the reason for 9 slices is to minimize the rescale bluring effect, and get almost resolution independent GUI.
if you want you can specify a single image to be used as a button, no need to offsets. (like those used in the levels screen here http://ezgui.ezelia.com/examples/game/pixi.html )
or you can only specify the right and left sides (or only left side in which case it'll be mirrored to produce right side).

it doesn't make the theme definition more complexe because in most cases you only define one corner, one line and one background, the corner will be rotated to create the 3 missing corners ...etc

corner-tl/tr/bl/br variants are provided to provide more customisation freedom (let's say you need one corner to be different from the three others ...) (see the wiki for details https://github.com/Ezelia/EZGUI/wiki/01---Themes )

regarding the needed data, it do not make too much difference if you pack all the files in a texture atlas. (one of the provided themes use texture atlas)

[zeroZshadow]

There is no difference in scaling at all though?
http://www.discretelogix.com/wp-content/uploads/image/9%20patch_scaled.jpg

It only becomes easyer to change a button image as a whole (instead of having to change the seperate images)

[alaa-eddine]

I don't get your point here
the image you showed is exactly how EZGUI works :)

[TimMensch]

I came here to ask the same question, but it's been closed for nearly a year, so I somewhat despair of getting a better answer.

the image you showed is exactly how EZGUI works :)

No, it's not. The image @zeroZshadow posted represents one source image, not 9, and the sub-images are sliced from that one image based on supplied offsets. The Google-defined 9-patch image is even better: The image has a border that defines where the patches are, AND where the padding should go, so you could specify one image with all of the information and simplify the theme definition.

As it stands in EZGUI, you have to do the slicing into 9 images yourself. A preprocessing tool can do this slicing for you, but it saves even more space to use proper pixel offsets into a 9-slice image at run time. Especially since EZGUI seems to be forcing all the images to be powers-of-two in size even in an atlas.

There are multiple Phaser plug-ins that support this:

https://github.com/orange-games/phaser-nineslice
https://github.com/VitaZheltyakov/phaser-nine-patch-plugin

Obviously you'd want the code to support PIXI for EZGUI, but it seems like it must be possible.

[alaa-eddine]

Hello @TimMensch , I get it now.
well the reason of not using the dynamic slicing, is to preserve the user freedom for buttons creation.
9sliced buttons are good, but they don't cover all use cases .

take a look at those buttons
some of those cannot be defined using 9 slices, ezgui provide three types of slices : 9, 3 and 1.
it don't cover all usecases too, but it cover more than 9slices only.

the usage of dynamic 9 slice hase some simplification for sure, maybe it'll be interesing to provide the option in EZGUI I'll think about it, but it should keep the same logic as the existing theme definitions.

about the power of two, EZGUI don't force you to use it, but it's recommanded in all game engines and there's reason for this : GPUs are optimised for PoT images, when used, you get better performance and better quality in image manipulation.

[TimMensch]

I just happened across this feature request:

#4

In in you say that the four corners need to be the same size; many or most of the buttons in that link you posted wouldn't work with that constraint. And if that's still the case in EZGUI, then you'd need to fix that in order to work with 9-slice.

You said that you provide 9, 3, and 1 slice: The "3" case is handled by 9-slice by simply making one dimension have degenerate edges (zero width or zero height).

If you are seriously considering adding this as a feature, why not re-open it and mark it as an enhancement?