In and out of gui editor moves controls around

#1 You got it....it is a "rounding" issue. I was told that the recalculating uses float math but is converted to integers for final positioning. I had the same question and Ben Garney mentioned that fixing this "bug" is on his to do list. For now, the way to avoid this issue, is to edit only in the screen resolution. In fact, I have added 1280x1024 to the GUI Editor res list because that's my preferred res at this time :)

#2 I've found that in the long run, designing all of your GUI's in the lowest targetted resolution you will support for your project will be your best path. That way, if/when a player wants to play at a higher resolution, the conversion errors are only in one direction, and very minor--and therefore don't compound themselves during the back and forth conversions.

#3 Sounds like a good suggestion...do we know if this issue will be addressed in TSE? I suppose that if Ben - or anyone fixes it in TGE, it would be possible to implement it in TSE also.

#4 I would have to say you are doing something wrong.

First of all, it would obviously be wiser to use 1024x768 resolution and then work on an 800x600 pallet instead of using a 800x600 pallet to work on a 1024x768. However, I did run your crazy configuration while switching resolutions and fullscreen to window and back again. Working in 640x480 while running 1280x1024 and working on 1024x768 resolution and pallet and I cannot get things to "slide" around on me. I admit that controls can be a freaking nightmare when you don't know how to work them properly, but they aren't giving me any trouble at all. Send me your GUI and I'll send it back with some tips on what's going wrong if you like.

#5 Gonzo, this bug has been confirmed by GG staff before. About a year ago when I created a thread about it.
Say you position a button at 320x320, then you disable the GUI editor to test the button. You find that the position is satisfying, but you want to change it's shape.

So you go back into the GUI editor, and.. what has happened? The element has moved 2x2 pixels.
This is the same on both 800x600 and 1024x768 with stock TGE.

#6 Thanks for your offer Gonzo,
but there is no problem for me anymore. I just run in the same resolution I design in and it's fine. I tested playing with an interface I designed in 10x7 at 6x4 and it was fine....well almost fine, a couple of the text controls I had set to relative shrunk so small you couldn't read the text...but that's another problem.

#7 @Gonzo: The issue doesn't actually become humanly visible until you also start using "Relative" in your gui positioning, which is possibly why you haven't noticed it.

#8 I see what is happening now. You have to be testing for it to notice what the deal is. The problem is quite simple actually. It's that damn number 'Zero' that just throws everything out of whack. the upperleft corner of the screen that is as far as you can go without going negative is "0 0". Now lets say you take an 800x600 Canvas and devide it in half. 400x300 is what you get, right? Not exactly. we see 400x300 but the engine see's 400.5 x 300.5 because the Canvas resolution is in reality 801 x 601. So every time the window changes size you lose a half on the first change and then a half on the change back which totals 1 pixel per screen swap or resolution change.


I managed to confirm this by setting resolution at 800x600 and then using a GuiWindow of 600 x 400(leaves me 100 pixels even on each side), set sizing to relative, move the GuiWindow to position "60 60", and then toggled back and forth, back and forth between the screen and the GuiEditor and I could clearly see a it move to "59 59", "58 58", "57 57", "56 56", etc...

I would seem that the most intuitive solution would be to adjust the engine to set the bounds at a proper setting like 799x599 or 1023x767, 1279x1023, 1599x1199, etc... Or to have the first co-ordinate "1 1" instead of "0 0". Without even looking at it though I would say the adjusted resolution is probably a more viable solution. I guess you could also visit all of the resizing functions and wherever the resolution is devided by 2, you could FIRST have it add back in 1.0 to make up for the miscount of one that you gets you the 0.5's when you devide


if you haven't quite grasped what I'm saying then think of it like this... When you count to 800 the first word out of your mouth is "one", not "zero". If you start at zero and count to 800 you end up with 801 numbers counted total because zero is in fact "one" number. So to get a proper count of 800 you need to either start at 1, or end at 799.

#9 Sor for reviving an old thread but was this problem ever fixed ???? i would like to have this functionality in my game