Tileset mode

[Epitrochoid]

Started playing with rx for the upcoming Rust game jam and so far I absolutely love it, in only a day my workflow is already far faster than it was in Krita. The only area I haven't been able to work out a decent workflow is tileset making. Currently I've been using individual animation frames for tiles, but then I have to reorganize them into a new png in my map editor. It also makes it hard work on vertical and corner tile transitions. A tileset mode where the frames are laid out in an n*m grid along with h,j,k,l navigation would make working this way much more seamless and I could go straight from rx exported image to my map editor.

Would this feature be desired for rx? I'd be interested in working on it, but from a quick browse through the relevant areas of the code it seems like a decent sized feature so I wouldn't be able to make any guesses on a timeline.

[cloudhead]

Great to hear!

I'm curious, what exactly do you miss from using a single frame + the grid? I'm not sure using the animation feature is a good idea here. What do you gain from it exactly? Is it navigation?

I ask because perhaps adding grid-based navigation/control may be a solution. Or is it the exporting that could use some work?

[Epitrochoid]

Oh wow, I completely missed that there was grid mode, just checked and its right there in the guide.

Played around with the grid for a bit and the only thing that really feels to be missing are some visual navigation commands that animation frames have. In the frame mode its really convenient to quickly yank frames and insert them somewhere else. I was able to map some selection commands to fill that gap, but they end up being dependent on the grid sizing. It should be enough to use for the game jam and see if there are any additional ergonomics that would be nice.

map g :selection/resize 7 7 {:selection/move 0 -7} // had to settle for selection starting in top left corner, ideally any pixel within grid would work
map 7 :selection/move -8 0 // capital commands didn't seem allowed so there weren't many options for binding
map 8 :selection/move 0 8
map 9 :selection/move 0 -8
map 0 :selection/move 8 0

[cloudhead]

Ok nice, perhaps it would be a start to be able to move based on the grid size then, or have the grid-size be a variable that can be used in mappings 🤔

[Epitrochoid]

Adopting vim's options-as-variables feature along with making grid/spacing shorthand for grid/height and grid/width would make the selection moves quite clean.

map 8 :selection/move &grid/width &grid/height

Expanding and contracting the visual selection would be a bit trickier I think. If arithmetic operators were supported along with chaining commands I think it would be doable though, something along the following lines would be the grid equivalent of ].

map } :selection/resize
    (1 + &selection/width + &grid/width - (&selection/width % &grid/width))
    (1 + &selection/height + &grid/height - (&selection/height % &grid/height));
    :selection/move 0 0 // Too early in the day to try and theorycraft the move formula to lock the selection to the grid

Adding arithmetic parsing to the command system might be expanding the scope of the command system too far though.

[cloudhead]

Why can't expanding/contracting stay as-is? ie. +1/-1 pixels.

[Epitrochoid]

Ah, I meant in addition to the existing expansion operator. Often I'll want to move a grid tile around to work on its boundary with another tile (even if they won't be adjacent in the final tileset image). A simple "expand visual selection to grid" would work for that, but I figured having an operator like above would let the user select a pixel, hit } and have the selection expand to the grid boundaries containing it, then hit } again and have that selection expand out by more grid boundaries.

[cloudhead]

Oh gotcha, yeah that would work.