Perhaps I made an implication I didn’t mean, I’m sorry if I was confusing.
All I meant is that when I looked at the original code and tried to modify it by changing this number or that one I either got no results or results that made no sense to me.
For instance at one point I tried to place entities wherever the user touched the screen but I just couldn’t get it working at all.
I had wanted to adjust the demo and make it a little more interactive, because as is, to the naked eye, it doesn’t visually seem much different than a single ‘sprite(assetName)’ call.
So I thought, hey, it’s made this atlas, let’s show it dynamically placing the slices based on user touch. And then I got all lost in how the atlas uses slices but the slices are turned into sprites to make them compatible with entities…
Honestly if the point is to demonstrate the atlas ability, I’d put forward the perspective that including entities and camera positions at all is significantly distracting from the point of the lesson to such a degree that it presents a significant struggle to separate what’s essential to using an atlas from what doesn’t pertain specifically to atlases at all.
Right now, even though the code is very short, understanding it requires learning about images, slices, atlases, entities, 2d scenes, cameras and viewers—which is a lot all at once. if the lesson is meant to illustrate images, atlases, and slices, it’d be way easier to grasp if it only used images, atlases and slices.
And unless I miss my guess it’s entirely possible to make the exact same visuals without using entities, scenes, cameras, and viewers at all—no?
I see what you mean, I created all this stuff and I’ve used it for a while so I have a skewed perspective when it comes to how other people see a particular piece of code. For the most part you can treat a slice as a sprite. So you can remove/ignore all the scene stuff and just do
sprite(mySlice, x, y) including any that you find in the atlas. So you can do
sprite(atlas[index]). Internally a slice is literally just an
image object and some configuration options (rectangle within the original image, drawing mode, 9-patch border, etc…)
You can create a slice out of an image, if you want to have some extra drawing options, which is useful for 2D UI stuff as well (i.e. 9-patches for buttons and panels)
I don’t know what a 9-patch is…
a 9 slice might be another term for it
when you stretch the center out but keep n the edges static, it’s called 9 slice but really 4 cuts is a better way to think of it, like a tic tac toe grid
@skar - Are we talking pyramid here or just a bigger rectangle ?
i don’t understand how a pyramid comes in? 9 slice is for 2d images, they have to be rectangle
@skar - it was your expression stretch the center out which made me think of the other axis. I couldn’t picture moving the center in 2D as adding extra points unless you just mean completely moving 2/3 of the points in sync away from the centre to give 5 initial points and 9 points in the resltant rectangle, although 2/3 of those would be within the rectangle, not on its periphery.
@John - thanks for the link. Looks like a good extension for V4.
That’s interesting and cool. It seems like it’s very specifically for situations like UI where you need borders and corners to scale differently than content.
I am not sure I see an application for it in things like scaling game sprites. 8-bit Mario, for example, would look very strange if his center scaled differently than his edges, am I right?
Yeah it’s mainly meant for UI