12-02-2022, 05:41 AM
Before I do much explaining, copy and run the code below so you can see what I'm talking about for yourself:
Now, LOCATE works *EXACTLY* the same in graphics mode as it does in Pete's SCREEN 0 example -- *as long as you're dealing with a monospace font*!
Font F, in the example above, is monospaced and thus locates 10 rows down and 10 columns over. It starts printing just where we'd expect to see it.
Font F1, on the other hand, is a variable-width font (we didn't specify the "monospace" tag with it), and as such, it has a _FONTWIDTH of 0 (ZERO!). There's no way we can figure out where to put the font in regards to the "10th column of text", as it's variable width. 10th column of what?? i's or W's? When the w's of many variable width fonts are easily twice the width of the i's, you can't know where the 10th column of anything is going to be -- the 10th letter of your text will start wherever the width of the previous 9 characters place it!
So how does LOCATE work with variable width fonts??
It still locates by ROW, which is why the !! in that LOCATE 11, 10 ends up placing us exactly one line below the LOCATE 10, 10 we used previously. The difference is, it no longer locates by COLUMN, but instead by PIXEL.
For a fixed width (monospace) font, LOCATE works by ROW, COLUMN.
For a variable width font (no monospace), LOCATE works by ROW, PIXEL.
And that's basically the difference in LOCATE with a graphical environment, verses a SCREEN 0 environment. In SCREEN 0, one doesn't have to worry about how locate acts with variable width fonts, as they're simply not allowed in screen 0 to begin with.
It's only in graphic modes, and with non-monospaced fonts, that one has to remember that LOCATE works by ROW, PIXEL. In all other cases, it work via ROW, COLUMN.
Code: (Select All)
Screen _NewImage(800, 600, 32)
f = _LoadFont("cour.ttf", 16, "monospace")
f1 = _LoadFont("cour.ttf", 16)
_Font f
Locate 10, 10: Print "FONT F, MONOSPACE"
_Font f1
Locate 11, 10: Print "FONT F1, NO-MONOSPACE"
sleepNow, LOCATE works *EXACTLY* the same in graphics mode as it does in Pete's SCREEN 0 example -- *as long as you're dealing with a monospace font*!
Font F, in the example above, is monospaced and thus locates 10 rows down and 10 columns over. It starts printing just where we'd expect to see it.
Font F1, on the other hand, is a variable-width font (we didn't specify the "monospace" tag with it), and as such, it has a _FONTWIDTH of 0 (ZERO!). There's no way we can figure out where to put the font in regards to the "10th column of text", as it's variable width. 10th column of what?? i's or W's? When the w's of many variable width fonts are easily twice the width of the i's, you can't know where the 10th column of anything is going to be -- the 10th letter of your text will start wherever the width of the previous 9 characters place it!
So how does LOCATE work with variable width fonts??
It still locates by ROW, which is why the !! in that LOCATE 11, 10 ends up placing us exactly one line below the LOCATE 10, 10 we used previously. The difference is, it no longer locates by COLUMN, but instead by PIXEL.
For a fixed width (monospace) font, LOCATE works by ROW, COLUMN.
For a variable width font (no monospace), LOCATE works by ROW, PIXEL.
And that's basically the difference in LOCATE with a graphical environment, verses a SCREEN 0 environment. In SCREEN 0, one doesn't have to worry about how locate acts with variable width fonts, as they're simply not allowed in screen 0 to begin with.
It's only in graphic modes, and with non-monospaced fonts, that one has to remember that LOCATE works by ROW, PIXEL. In all other cases, it work via ROW, COLUMN.