GuiControls w/ F32 coords ?
by Orion Elenzil · in Torque Game Engine · 10/11/2007 (4:51 pm) · 8 replies
Has anyone converted or thought about converting or known anyone who's converted or thought about converting the GuiControl system in TGE to use float coords rather than ints ?
does TGB have float coords ?
would this be a Bad Thing tm ?
we currently carry around a few float copies of various dimensions of GuiControls
and cast them to int's only at the last moment, and it's annoying.
does TGB have float coords ?
would this be a Bad Thing tm ?
we currently carry around a few float copies of various dimensions of GuiControls
and cast them to int's only at the last moment, and it's annoying.
About the author
#2
The only "Bad Thing" for me is will be floats instead of integers, so it could take more processing time for calculations...
Using floats can give lots of benefits (incl. yours, Orion, the "new GuiControl resizing mode: fit (in parent)" resource).
11/15/2007 (4:56 pm)
The GUI in TGB is the same - Int's everywhere, while the T2D engine itself is float-based (like the Torque GameBase objects).The only "Bad Thing" for me is will be floats instead of integers, so it could take more processing time for calculations...
Using floats can give lots of benefits (incl. yours, Orion, the "new GuiControl resizing mode: fit (in parent)" resource).
#3
i think i heard that floating point divide is faster then integer on some modern CPUs.
11/15/2007 (5:25 pm)
True, altho i believe casting from int <--> float is possibly more expensive than typical floating point operations themselves, and of course, FLOPs keep getting faster & faster.i think i heard that floating point divide is faster then integer on some modern CPUs.
#4
I'll look at moving my project to floats as soon as I find time.. hopefully I'll get some :)
11/16/2007 (4:13 am)
Hm. you're right here, so I believe moving into floats will be not a "bad" thing at all. More positive stuff are "covering" the possible slow-down.I'll look at moving my project to floats as soon as I find time.. hopefully I'll get some :)
#5
Relative sizing scale is set at 640x480 and if you bump that up you'll see a big difference. We used relative sizing exclusively so it solved all our problems, and I guess if you use the other types of resizing it wouldn't help.
11/16/2007 (4:36 am)
Forgive me if I missed the point entirely, but why do you want to do this? Increased precision?Relative sizing scale is set at 640x480 and if you bump that up you'll see a big difference. We used relative sizing exclusively so it solved all our problems, and I guess if you use the other types of resizing it wouldn't help.
#6
say for example i want to make my GuiControl animate its position towards some point.
assuming a simple scenario of a fixed 60FPS,
if i use only integers, the minimum velocity is one pixel per frame, which is pretty fast.
so i'm going to want to use a float to keep track of the control's position.
another example is my "fit in parent" resizing mode -
say the parent is a square 20 x 20, and the child is originally a rectangle 200 x 104,
and i now want to resize the child so that it snugly fits inside the parent.
obviously i would want my new size to be 20 x 10.4, which means i have to round to 20 x 10.
but then i resize the parent up to say 200 x 200, and want to fit the child inside it again.
so the child is currently 20 x 10, which will expand up to 200 x 100, and you can see we've lost four pixels.
if all these numbers were floating point, the situation would be dramatically improved.
11/16/2007 (10:38 am)
Floats are just easier to work with.say for example i want to make my GuiControl animate its position towards some point.
assuming a simple scenario of a fixed 60FPS,
if i use only integers, the minimum velocity is one pixel per frame, which is pretty fast.
so i'm going to want to use a float to keep track of the control's position.
another example is my "fit in parent" resizing mode -
say the parent is a square 20 x 20, and the child is originally a rectangle 200 x 104,
and i now want to resize the child so that it snugly fits inside the parent.
obviously i would want my new size to be 20 x 10.4, which means i have to round to 20 x 10.
but then i resize the parent up to say 200 x 200, and want to fit the child inside it again.
so the child is currently 20 x 10, which will expand up to 200 x 100, and you can see we've lost four pixels.
if all these numbers were floating point, the situation would be dramatically improved.
#7
The one (arguably minor) downside to this technique is when the client changes resolution multiple times--while GUI location coordinates are currently integers, the relative algorithm does use floats, and the rounding errors converting back and forth can cause your perfectly aligned GUI's to become staggered by just a pixel or two--not huge, but enough (and uncontrollably really) to make GUI's look pretty unprofessionally misaligned when this circumstance occurs.
11/16/2007 (12:11 pm)
Quote:
Relative sizing scale is set at 640x480 and if you bump that up you'll see a big difference. We used relative sizing exclusively so it solved all our problems, and I guess if you use the other types of resizing it wouldn't help.
The one (arguably minor) downside to this technique is when the client changes resolution multiple times--while GUI location coordinates are currently integers, the relative algorithm does use floats, and the rounding errors converting back and forth can cause your perfectly aligned GUI's to become staggered by just a pixel or two--not huge, but enough (and uncontrollably really) to make GUI's look pretty unprofessionally misaligned when this circumstance occurs.
#8
I haven't been into the GUI code for a while so I could be mistaken, but wouldn't this be trivial to solve by either storing the original coords (the relative ones in the GUI file) when parentResized () is called, and then recalculate the 'real' screen coords each time resolution changes?
Hope we're not way offtopic btw.
11/17/2007 (5:38 am)
Quote:
The one (arguably minor) downside to this technique is when the client changes resolution multiple times--while GUI location coordinates are currently integers
I haven't been into the GUI code for a while so I could be mistaken, but wouldn't this be trivial to solve by either storing the original coords (the relative ones in the GUI file) when parentResized () is called, and then recalculate the 'real' screen coords each time resolution changes?
Hope we're not way offtopic btw.
Torque 3D Owner Matthew Jessick