Tileset mode about rx HOT 7 OPEN

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?

from rx.

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

from rx.

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 🤔

from rx.

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.

from rx.

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

from rx.

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.

from rx.

Oh gotcha, yeah that would work.

from rx.