Hi Will,
Steps to reproduce:
Launch SLXEditor 2.8.8
Tools
tick 'Snap to Grid'
(tick 'Snap to Grid' <=> 'Snap-to-Grid amount in pixels' ticked)
Settings
Snap Pieces to Grid
GridSize '1'
Choose grid color 'Blue' (Blue for example, any color except invisible)
Save And Close
File/Exit
When exiting and relaunching SLXEditor, 'Snap to Grid' in unticked and GridSize returns to its default value of '8' (note that this does not happen if GridSize is different from '1', any GridSize value other than '1' is maintained as well as the grid color and 'Snap to Grid' is always ticked).
This can be annoying if you're working with a full background (blue, for example) because you have to redefine GridSize each time you work.
When activating 'Snap to Grid' AND 'Snap-to-Grid amount in pixels' with GridSize '1', is there a solution so that when SLXEditor is exited, the Gridsize '1' setting with 'Snap to Grid' ticked are maintained when SLXEditor is restarted?
Well, the bug here is really that a grid size of "1" is available at all.
If the grid size is 1, it's the same difference as simply not having the grid active at all. Modifiers aside, if you select and drag a piece with the grid switched off, the piece will move in 1px increments anyway. Setting a 1px grid, then, actually has no effect.
To put it another way, the Editor will always snap pieces to a minimum grid of 1px, whilst providing a variable grid size specifically for the purpose of making the minimum grid something other than (and necessarily higher than) 1px.
The next Editor update will set the minimum variable grid size to 2px, which is really as it should be.
Addressed in commit dc9bd91.
You can already do that; create a background image that's a single colour, and place it in the "backgrounds" folder inside the style folder. See the ones in proxima_tile for examples. For good performance, it's better for the image to be relatively large, not 1x1.
QuoteYou can already do that
For me, size 1 grid allowed me to have a uniform background (without grid) of a color other than invisible (black), and that was what mattered to me rather than the grid itself. It wasn't the right way to proceed, but it allowed WillLem to make a correction that will be included in the next version.
Yeah, of course your suggestion is the right solution to use and it works perfectly.
Thanks Proxima
I'm not sure I understand exactly what you're after here @chroda, and therefore also don't understand how Proxima's suggested solution helps.
Could you perhaps elaborate on what's needed? It may be something we can work into the Editor's functionality if it's (a) not too obscure, (b) would prevent the need for a workaround, and (c) would help others with the same use case.
No Will, I don't need anything... for the moment.
All the features are available in the excellent editor that I'm learning to use by trial and error.
And precisely in error mode, I was simply using the Gridsize 1 in workaround to get a solid background different from the standard black (invisible) background when practicing with the editor, but this is not the right solution because the background chosen this way is not saved when you save the created level.
So, as an exercise, I created a chroda_background style folder with a backgrounds subfolder in which I placed several 32x32 pixel images in colors such as blue, gray, midnight, and yellow. This way, when I select this style and a background image, the chosen background is saved when I restart the level created with this background and so everything is OK.
Voilà!
Ah yes, if the idea is to get a solid background colour, that's the way to do it :)
EDIT: This topic has now been marked as resolved.