In previous iterations of BB before 2.3 it was easy to find the centre of the screen moving any objects to hit 320 in a UI. Now it seems to be locked into hitting 275 or 325! Don't get it! How Can I set this to move in whole numbers again aka in multiples of 10 eg: 300. 310. 320 etc.
Actually, this reveals something that I was not aware of. There is not intended to be any snap grid in the UI editor, currently. Only on the Scene editor. It seems that when the grid is enabled for the Scene editor, all other editors are enabled as well, but should not be. Snap grid IS planned for the UI editor, we will be adding the snap guides from Pixelbox once we do a little preparatory work. I think it could be expected for Buildbox 2.3.4. Until then, as I'm sure you are aware, you can manually enter 320 in the text box.
OK thats good to know that will be fixed. However checking in the World now Im still seeing issues. For instance if I set the grid size to 10 x 10 I still cant drag and snap to a whole number horizontally or vertically. Its moving in multiples of 5 eg: 315, 325 etc. If I reduce the grid size to even smaller at 5 x 5 im now moving in .5 decimal chunks. Maybe Im using this wrong but the simplicity of moving and dragging to centre at 320 just doesn't seem possible. Not making any sense to me that even setting manually at 320 if I click and drag with a grid size of 10 x 10 I'm moving in odd numbered snaps!
In the scene editor, the origin point is (0,0) bottom, left. I talked to Nik about this already and it didn't seem to be an issue for the way the grid is typically used to build games. I'm open to arguments though. I've also proposed allowing half steps in the scene editor, which could solve the issue.
OK on the right path I guess. But whilst the origin point is 0,0 which makes total sense. Unless im mistaken the scene width horizontally is 640,0 so again moving in steps of 10 when your grid size is set to 10 x 10 and being able to centre at 320 would be logical.
No, because you are using a number that gets you an even amount of squares across the screen. Try 128 x 128 grid, it will work perfectly for your proposed case. Most game types do not have a need for identifying the exact center of the screen when laying out levels. The odd case when you do need it just enter manually. If it's integral to building your game type you will need to calculate a grid size that gets you an odd number of cubes across the screen.
I'm not talking about UIs... UI snapping will be available shortly, and it will be the typical guideline/layout snapping you see in lots of software. Center snapping will be there for sure in the UI editor. We just need to bring it over from Pixelbox in the next few releases. To be clear. The grid snapping in the scene editor is based on laying out tiles. Objects snap to the center of the grid squares. I'm willing to entertain improvements for sure. A couple possible modifications would include: half step snapping. modifying the origin point for the grid system.
I was only considering UI’s. Many vertical games or single scene games require center snapping. That’s half of BBs presets.
It's a valid point, but I've given a solution and 2 possible enhancements. Do you have any specific comments related to those? All three would allow snapping to the center if that is what you need for your gameplay. Or do you have something else in mind?
option to turn off the grid please haha my games have tons of UIs, manually entering 320 each time I move something is laborious. and sometimes I use the UI for weird reasons and wouldnt really need snapping (when I make visual novels).
No. Being able to have a half-step snap would work great. The only thing that’s annoying for me while using Snapping is for example, when you manually position your character at 320x425 and want to move your character up by a tile (50px for example) to 475 with the arrow keys, pressing the up key doesn’t move the character up, it resets it’s X-position back to 325... So you end up entering the coordinates manually anyway if the character or object doesn’t sit on both snapped locations. I think the arrow keys should only snap to their corresponding axes.
Perfect, thanks for that. I'm taking this back to the team as one of the major points we should discuss.