Some small changes to start with .. first of all I added the ViewportRatio variable to the RenderFont scale calculation. I'm a little surprised this was not there already, as it's the cause for fonts to look vertically squashed at the moment.
Additionally I've added a Stretch field, with a default value of 1. Now the thing is, this will cause projects that make use of Font and RenderFont to look slightly different, but I could change the default to 4/3 for backwards compatibility.
In the future I'd like to add a ZExpression field to the Font component in which you can define the Overlap per ASCII code manually. With which you can overwrite the horizontal spacing of specific symbols.
I guess the whole Viewport deal in Renderer.pas pushed some things around I used the second glScalef you refer to ( first in source ). Hadn't noticed that Push / Pop Matrix snippet even .. why do you use 2 separate glScalef's? And I used the Stretch variable on the Y axis, so you won't have to get all tricky with multiplying Overlaps and such.
The first scale is used for the general scale that makes 1.0-scaled characters fit 20 on each line. The second is for adjusting the scale of each character with the renderchar-zexpression. Push/pop matrix around every letter is needed because transformations should be reset between every call renderchar-zexpression.
Ah of course, the CharScale in RenderCharExpression. At least I got it in the right place then, unless somebody wants to be able to stretch each individual character that is ..
I applied the ratio to y-scaling and it looks good. But I'm not sure I understand why . Can you please explain why this scaling is needed? Is it an adjustment of the y-axis to match the x-axis with regards to pixel-size?
In previous releases I had already noticed that my fonts always where 25% less tall as they should ( when using a 4:3 Resolution ). Now my workaround was to use a single row of symbols, use 75% as CharPixelHeight in the Font component of the desired height, and to offset the Bitmap 25% ( or so ) pixels up to get things centered again. However, this method became insufficient as soon as I implemented the customResolution properties. For example, the difference became 0.4375 when using a 16:9 ratio, not leaving enough space in the bitmap for the symbols themselves. But the solution was rather obvious.
Why exactly this happens in the first place I'm not sure of either. My guess is that OpenGL by default takes a 1:1 ratio as departure point, and starts squeezing elements when diverting from that, hence the counter measures in ViewportRatio and now RenderText.
*By the way, I'd rename Overlap in the source to ( Letter ) Spacing .. as negative overlap doesn't make a whole lot of sense.
This must be because I set up a 2d-screen space in the range -1 .. 1 when drawing text. However when RenderText.UseModelSpace is set then the viewportratio-correction should not take place, right? Perhaps then viewportratio can be set directly for the y-axis in the glOrtho(-1, 1, -1, 1, 1, -1.0) line. However that would also affect the x,y positioning of the text. I'd like Y=-1 to always mean "top of screen".
Don't worry, I'll ask for help when I get stuck .. and I will
The -1 to 1 range was actually something I had to get used to in the beginning, I'm used to Homogeneous Coordinates being in the 0 to 1 range, and being optional as well ( pixel based being the default ).
By the way, is a separate Orthographic projection created for each RenderFont component currently? Would be nice if you could control projections from within ZGE actually, to pull off split-screen and layering and such. Right now both the perspective and orthographic projections seem rather hard-coded though .. you'd need to convert this to some sort of list / array that holds all the projections that the Renderer iterates through, and all Render components would need a target projection property too I guess.
The rendering system in ZGE is immediate in the way that all render-components in OnRender-lists instantly execute the OpenGL commands. A more advanced and optimized technique would be to write all commands to lists and then sort according to texture, shader, rendertarget, camera etc before sending it to OpenGL. Another discussion indeed