Skip to content
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

Use case: Tiling visualization #46

Open
VisenDev opened this issue Feb 4, 2024 · 5 comments
Open

Use case: Tiling visualization #46

VisenDev opened this issue Feb 4, 2024 · 5 comments

Comments

@VisenDev
Copy link
Contributor

VisenDev commented Feb 4, 2024

It would be useful to be able to have a way to visualize how a sprite would look tiled. This would be very useful for things like creating tilesets

@foxnne
Copy link
Owner

foxnne commented Feb 4, 2024

Agreed! I haven't gotten to the point in my game project to need this quite yet so I haven't looked into how I want this to look yet, but I'm very open to ideas. I'm considering using Tiled or similar and need to examine the workflow and how to bridge between the two. PyxelEdit, which I used to use, had this built in and we could do similar for tiled sprite editing.

slimsag added a commit to slimsag/pixi that referenced this issue May 26, 2024
This adds a checkbox under the Packing tab which aims to support packing
a texture atlas for _tilesets_ better, particularly for consumption in
level editor programs like LDTK.

These programs typically expect a uniform grid of sprites (e.g. 32x32px tiles)
where each sprite's size is generally 'fixed', or a multiple of the smallest
sprite size (e.g. you might have a 64x64px or 96x96px sprite inside a texture
atlas among mostly 32x32px sprites.) - and so expect that e.g. transparency is
surrounding sprites' unused space, rather than it being trimmed for more
efficient packing as Pixi does today.

With the checkbox unchecked, Pixi exports as it did before:

<img width="1392" alt="image" src="https://github.com/foxnne/pixi/assets/3173176/3af7cbab-df13-46e6-bf4a-3e963b7ec5b5">

With the checkbox checked, Pixi will try to export a sprite atlas that is more
compatible with common tileset software like LDTK. Right now this just means
it tries to export a uniform grid, not tightly packing sprites:

<img width="1392" alt="image" src="https://github.com/foxnne/pixi/assets/3173176/2fddaa56-edee-44ce-b2bd-f91a05313baa">

In the future, we might need some other options to support this use case better
but for now this at least means that if you have a bunch of pixi files representing
tilesets, you can export those and get a packed texture with a uniform grid inside
it and then consume that in LDTK or other level editor software fairly easily.

Helps foxnne#46

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
@slimsag
Copy link
Sponsor Contributor

slimsag commented May 27, 2024

For a pixi file like this in Lord of Zero:

image

I think what I want is really the ability to say "hey, this tile over ? it's exactly the same as this tile over - when I make edits to it, make edits to all the others. Consider it a clone."

I think the most intuitive UX for this would be: select the tile you want to clone, do some key combo like cmd/ctrl+shift+c and then cmd/ctrl+shift+v to "paste" the clone into another cell.

Also, the packed image ends up with a fair amount of wasted space because I have the tile duplicated so I can see it visually:

image

It would be nice if these tiles "considered a clone" would be skipped during export too.

@foxnne
Copy link
Owner

foxnne commented May 27, 2024

That sounds good! I had a similar idea myself. The other option that might be just as nice is to have a setting for the "flip book" panel at the bottom, to instead of drawing individual scrolling cards, draw the selected tile 9 times, a 3x3 grid, all duplicating the selected sprite. Then also make each tile editable directly. Then you could select a tile to begin drawing, and draw on any of the 3x3 grid to draw the tiling sprite. You'd then only need the single tile in the main drawing so it wouldn't be duplicated.

@slimsag
Copy link
Sponsor Contributor

slimsag commented May 27, 2024

That seems like it would be a good approach, too. The limitation I see there is that if you are working on this:

image

Or this:

image

In a 3x3 view, it would be hard to see the 'overall picture' there, since not all of the 3x3 are the same, so you'd probably need to duplicate anyway to see that - or view them in a level editor.

Similarly, being able to see transitions from one tile to another - like this telling me the rick tile and ground tile don't have the same height:

image

I think the copy+paste cloning would be more powerful for those situations, but would have the drawbacks you mentioned (it uses a slot in your actual grid-although those are 'cheap', and is maybe a bit more complex to setup just for the 3x3 case which is very common)

@foxnne
Copy link
Owner

foxnne commented May 28, 2024

@VisenDev @slimsag This commit added a setting under the View menu option to change the flip book view from sequential to grid, which allows easily making seamless tiles. All the usual controls work with this new view.

As @slimsag mentioned, there are some cases where it would probably be really handy to be able to make tiles a reference to another tile, I need to think on this a bit more as I don't want things to become hard to follow. Tiles that are references need some visualization.

Anyway, hopefully this helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants