Game, set up a convention for managing half-pixels for centering elements

[LeHerosInconnu]

Preliminary checks

• I've checked that there aren't other open issues on the same topic.

Describe the problem requiring a solution

I suggest to set up a convention for managing half-pixels for centering elements.

Also for the "half pixel" that can't be separated when an uneven number is used, e.g. 25 pixels divided by two gives 12.5, i.e. 12 pixels on one side and 13 pixels on the other, we should set up a convention so that the non-separable pixel is always added on the right side for a horizontal dimension, i.e. in the example 12 pixels on the left and 13 pixels on the right, and is always added at the bottom for a vertical dimension, i.e. in the example, 12 pixels at the top and 13 pixels at the bottom.

Originally posted by @LeHerosInconnu in #9180 (comment)

Describe the possible solution

For horizontal and vertical centering of elements, text or graphics in a button, button in a window, window in a screen, in short any element in another element, make sure that pixels that cannot be split are added to the right for the horizontal dimension and to the bottom for the vertical dimension.

Additional info

No response

[ihhub]

This is an extremely difficult to follow as developers do not use hardcoded pixel values but rather rely on math. So, if a length is 9 then the first position is going to be 9 / 2 = 4 based on integer calculations. This is how the code looks right now:

const int32_t posX = width / 2;

Simple and easy to read. Now if we try to impose the proposed logic the code might look like this:

int32_t posX = width / 2;
if ( posX * 2 != width ) {
    posX += 2;
}

As you can see the code is way longer and harder to read.

Therefore, I don't see that any of developers is going to follow this.

[LeHerosInconnu]

Hello @ihhub,

So how is a value that is not entirely divisible handled mathematically?
How is the (non-divisible) remainder handled?
Is there some common default method in place to deal with this situation?
So everything should already be automatically centered in the same way then.

[zenseii]

Hi, @LeHerosInconnu. Could you please point out where there currently is inconsistency in the buttons' centering regarding the leftover pixel?

[LeHerosInconnu]

Hello @zenseii,

Hi, @LeHerosInconnu. Could you please point out where there currently is inconsistency in the buttons' centering regarding the leftover pixel?

I haven't checked the buttons recently, but I'll be sure to report a problem if I find one. :)

The purpose of a convention would be to avoid having to check all the "centering", whether for text in buttons or other things.
A defined automatic centering (with management of the indivisible remainder) seemed to me to be a more appropriate solution.
Any action to center elements together using a unique centering "function" (I don't know if that's the right term).
Basically, when the programmer wants to center two elements in relation to each other, he indicates the starting zone (in which another element is to be centered), then indicates the element to be centered there and calls up the centering function.

[ihhub]

I don't think such a solution even exists within reasonable development resources. We also handle some "special" cases here and there just to accommodate either the original game design or limitations of dialogs like placing some UI elements on a specific position.