HWGuy wrote:A big and simple improvement to the GUI system would be to change from 640*480 screen space scaled to a floating point.
0,0 being the middle, 1,1 top right, -1,-1 bottom left.
Uh... why?
I guess we'd just have the same problem with different numbers.
I also wonder if it is actually possible to solve this problem in all cases:
For example, if the user sets a 4:3 resolution (e.g. 1024*768 or 640*480) on a 16:9 screen, then the 4:3 == 12:9 would obviously be scaled horizontally by a factor of 16/12 == 4/3 to match the width of the screen, yielding
non-square pixels.
As a result, it is the users responsibility to set only display resolutions that match the physical aspect ratio of his screen. If he doesn't, there will be distortion -- without anyone the wiser.
In fact, neither the Cafu engine nor the OS can reliably know the physical dimensions of the attached screen. For example, Win7 allows me to set a resolution of 800*600 on my 16:10 display. "Rage" by id Software addresses the problem by explicitly stating the proportions next to the resolutions in the video menu, e.g. "1024*768 [4:3]".
Finally, under the assumption that the user has set a good resolution with square pixels, in the next step we face a very similar problem with our virtual GUI windows. Now we
do know both the true physical size (learned e.g. from
GetClientSize()
), as well as the (virtual GUI) window size, which is proportional to 640:480. That is, if
GetClientSize()
returns 1920:1200 == 16:10, making our 640:480 == 13,3333:10 match involves implicit scaling in horizontal direction by factor 16/13,3333 == 1,2.
(This, or in fact its inverse, is also the factor that Haimi'd need if he implemented my above suggested "short term solution".)
Unfortunately, this is not the end of the story. In some cases, instead of all the above, we may want to specify render coordinates in true, physical pixels, just as reported by
GetClientSize()
. This is helpful e.g. for rendering text perfectly, with sharp, crisp contours. The
size of such text would vary with screen resolution, but for some use cases, that might be acceptable.
How exactly this is best implemented I've not yet fully thought through, but I hope you can see that the solution to the problem is not a simple matter of changing the virtual GUI size, the scales, or the numbering system.