Improving The Behavior or HorizSizing/VertSizing == "relative

@Community

I recently fielded a question from Matthew Johnson. He was experiencing an issue where his controls would migrate over time as he editted.

Although I was aware of this behavior, it didn't occur to me right away that he was seeing a little-discussed issue with 'relative' resizing.

In TGE, relative resizing affects both the position and size of a child control. That is, when a parent control is resized, all of its children are resized also. Furthermore, a control using relative resizing will re-scale and reposition based on the re-scale factor. For example, if you are viewing in 1024x768 and start your GUI editor in 800x600, the multiplying factor is 0.78125. Thus, all relatively sized controls are translated and scaled by this factor.

This might not seem to be a problem until one remembers that all control sizes/positions are in pixels which are measured as integers. However, the scaling results in a floating-point value. Herein lies the problem. The current algorithm for scaling of controls does not account for floating-point to integer truncation.

If you will recall, when a floating-point value is stuffed into an intger variable, the mantissa is simply truncated, not rounded. Thus whenever a value has a mantissa > 0.5 we effectively lose one pixel.

So, before I turn this into a lecture, let me just cut to the chase.

This problem has bothered me for some time, but I didn't do anything abou it. However, with Matthew raising the issue again, I decided to fix it.

So, if you are currently working with TGE 1.4 you can edit the file guiControl.cc and modify the code starting at about line 340 to look like this:

else if (mHorizSizing == horizResizeRelative && oldParentExtent.x != 0)
   {
	   F32 oldParentExtentX = oldParentExtent.x;
	   F32 newParentExtentX = newParentExtent.x;
	   F32 scale = newParentExtentX / oldParentExtentX;
	   F32 oldPosX = newPosition.x;
	   F32 newPosX = (oldPosX * scale);
	   F32 oldExtentX = newExtent.x;
	   F32 newExtentX = (oldExtentX * scale);

	   if( (newPosX - mFloor(newPosX)) < 0.5 ) 
		   newPosX = mFloor(newPosX);
	   else
		   newPosX = mFloor(newPosX) + 1.0;

	   if( (newExtentX - mFloor(newExtentX)) < 0.5 ) 
		   newExtentX = mFloor(newExtentX);
	   else
		   newExtentX = mFloor(newExtentX) + 1.0;

	   newPosition.x = newPosX; 
	   newExtent.x   = newExtentX;
   }

	if (mVertSizing == vertResizeCenter)
	   newPosition.y = (newParentExtent.y - mBounds.extent.y) >> 1;
	else if (mVertSizing == vertResizeHeight)
		newExtent.y += deltaY;
	else if (mVertSizing == vertResizeTop)
      newPosition.y += deltaY;
   else if(mVertSizing == vertResizeRelative && oldParentExtent.y != 0)
   {
	   F32 oldParentExtentY = oldParentExtent.y;
	   F32 newParentExtentY = newParentExtent.y;
	   F32 scale = newParentExtentY / oldParentExtentY;
	   F32 oldPosY = newPosition.y;
	   F32 newPosY = (oldPosY * scale);
	   F32 oldExtentY = newExtent.y;
	   F32 newExtentY = (oldExtentY * scale);

	   if( (newPosY - mFloor(newPosY)) < 0.5 ) 
		   newPosY = mFloor(newPosY);
	   else
		   newPosY = mFloor(newPosY) + 1.0;

	   if( (newExtentY - mFloor(newExtentY)) < 0.5 ) 
		   newExtentY = mFloor(newExtentY);
	   else
		   newExtentY = mFloor(newExtentY) + 1.0;

 	   newPosition.y = newPosY; 
	   newExtent.y   = newExtentY;
   }

Yes, this code is a bit bruteforce-ish, but it should be clear what is being done.

With this code change, and using an editting resoultion of 800x600 with a previewing resoultion of 1024x768, you will get zero truncation errors.

Note: This does not solve migration from non-adjacent resolution scalings, but its a definite improvement.

Cheers!

Hall Of Worlds - For Gamers
EdM|GPGT