Changing font-size in _rgb32 mode

[Kernelpanic]

Thanks @SMcNeill for the explanations. I have now reproduced this with "Monospace". But there remain open questions.
I can't understand the spacing between the textes; see the screenshot. I can't find an explanation for this.

My guess is that this is where "Locate" and "_PrintString" somehow get in each other's way.

Code: (Select All)

Option _Explicit

Screen _NewImage(600, 440, 32)

Dim As Integer schrift
Dim As String text

schrift = _LoadFont("C:\WINDOWS\Fonts\Arial.ttf", 14, "Monospace, Bold")
_Font schrift

'Notwendig fuer Locate Zeile 22
Locate 3, 10
text = String$(20, "X")

'Positionierung in Grafikpixeln!
_PrintString (20, 20), text

'Die Positionierung durch Grafikpixel
'wird NICHT beruecksichtigt.
Locate CsrLin + 2, 3
Print "Screen width is 80 chars"

'Locate CsrLin + 2, 297
'Print "Middle"
_PrintString (35, 300), "Mitte"

'Neue Schriftgroesse
'Eigenartiges Verhalten bei der Darstellung und Positionierung.
'Nach was richtet die sich?
_Font 16
_PrintString (145, 297), "Middle"

_FreeFont schrift

End

[mnrvovrfc]

LOCATE works just fine in graphic screens.  Why mnrvovrfc would tell people not to use it is completely beyond me.  Might as well not use PRINT or COLOR or CLS or any of the other simple and common to use commands in that case.  After all, each of them is slightly different than when used in text screens!

It was only for consistency between old and new but anyway... you're right as always.

But it's not as pretty to use monospaced fonts in a game which has three-dimensional graphics live action going on! Why offer _PRINTSTRING at all then? It was supposed to draw those vector fonts at one time...

<--- wanted to make use of a feature of M$ QuickC but those FON files were unwieldy. The BGI fonts that came with Turbo Pascal and Turbo C++ were more advanced than that but the statements to use them were clunky. We wanted to use "gotoxy()" to locate text in text mode and in graphics mode back then!

Anyway, the following code gives me an illegal function call. Try explaining that, which was what I was trying to say above. Use _PRINTSTRING instead for this! (Trying hard not to be like that privileged user from Galleon's forum who liked using exclamation points...)

Code: (Select All)

screen _newimage(800, 600, 32)
$IF WIN THEN
'DK if this file exists
h& = _loadfont("C:\Windows\Fonts\DejaVuSerif.ttf", 18)
$ELSE
h& = _loadfont("/usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf", 18)
$END IF
if h& <= 0 then end
_font h&
locate 400, 300
print "Hello"
end

But you guys go ahead and use whatever you want if you're comfortable with it.

[mnrvovrfc]

My guess is that this is where "Locate" and "_PrintString" somehow get in each other's way.

LOL they don't get in each other's way. You just didn't bother to read what I wrote for you last time.

LOCATE was designed originally to position the cursor in text mode SCREEN 0, to set up PRINT. However, people expected the same exact behavior eg. in SCREEN 12, so it was left to its fate.

_PRINTSTRING is a different creature which requires screen pixel coordinates to work, treating the text also given to it as a graphics figure such as line or circle. That's why you have to compute stuff with other functions to be able to center the text, without caring if it's a monospaced font.

LOCATE can be used with PRINT only with monospaced fonts as Steve had said. It limits its use because it doesn't work as well with variable-spaced fonts. In that case _PRINTSTRING is available although it requires more "skill" to use it.

[SMcNeill]

Thanks @SMcNeill for the explanations. I have now reproduced this with "Monospace". But there remain open questions.
I can't understand the spacing between the textes; see the screenshot. I can't find an explanation for this.

My guess is that this is where "Locate" and "_PrintString" somehow get in each other's way.

Ariel isn't a true monospaced font.  It's variable width, by its very nature.

W -- This is a sample of Ariel font.
iiiii -- you can easily see that the "W" is somewhere around 4 to 5 times wider than the "i" with this font.

So when we specify _LOADFONT with "bold, monospace", as you have in your example, what happens??

Monospace says that all the characters in a fontset are all the same space -- that they all use up the same amount of width.  Then when we type, we always have the exact same number of columns in a row, regardless of what characters we might be typing.  See my screenshot of my example program above -- with the monospaced version of the font loaded, my 10 "i" characters all take up the same amount of screen space as my "W" characters...

But, as you can easily tell, the W is much, much wider than the i:

W
iiiii


So what's the solution to space our letters properly??

W
 i

We make each character the same width as our widest character (usually the W or M character, though I've seen some fonts where Q has a large flourish and is the widest), and then we simply center all our letters into that space.

The "W" might be 16 pixels wide, while the "i" is only 4 pixels in width, but they each need to take up the same screen space so they all align perfectly.  To accomplish that, the W has 0 pixels of blank padding before and after it, while the i would have 6 pixels of blank space padding before and after it.  (6 blank, 4 for the i, plus 6 blank = 16 pixels width -- the same as the W.)

So when you look at your screenshot and say, "What are these spaces??", they're simply the padding required to make a variable-width font perform the same as a natural monospaced font.

Honestly, I find them quite ugly, and it's not my habit to tend to use "monospace" with most variable-width fonts, but the option's there just in case it's required for some strange reason.

Try your code with a TRUE monospaced font ("courbd.ttf" for example), and you'll see that problem with having to center the letters disappears completely.  When the widest character is 16 pixels in width and the narrowest character is 16 pixels in width, there doesn't need to be any padding before or after anything to center those characters.

[SMcNeill]

Anyway, the following code gives me an illegal function call. Try explaining that, which was what I was trying to say above. Use _PRINTSTRING instead for this! (Trying hard not to be like that privileged user from Galleon's forum who liked using exclamation points...)

Of course it's going to give you an error.  Let's take a moment and look at why:

h& = _LoadFont("C:\Windows\Fonts\DejaVuSerif.ttf", 18)  <-- This line loads a font, non-monospaced, at size 18.  That gives us a _FONTHEIGHT of 18 and a _FONTWIDTH of 0.

Locate 400, 300  <-- This says that we're going to locate 400 rows down and 300 pixels across.

Since each row is 18 pixels in height (font width 18, as specified above), you're trying to print down at position (300, 400 * 18 -- in x/y graphic coordinates)...

Your screen is defined as being 800 x 600 pixels in size.

400 * 18 = 7,200.

What do you think should happen when you try to print at (300, 7200) on a screen that is only (800, 600) in size?  Where would the print cursor go after printing at that position?  How far should the screen scroll?  What do you think is the normal behavior for PRINT in such a situation?

ILLEGAL FUNCTION CALL  (BEEEP!)

---

Even with variable width fonts, you still always LOCATE by row with the first value.

LOCATE 1 is the first row of text on the screen.
LOCATE 2 is the second row of text on the screen.
LOCATE 400 is an error since your 600 pixel high screen can only hold 33 rows of text upon it at a time.

In a SCREEN 0 text screen, what happens if you try to LOCATE 400, 300?  Isn't that the exact same Illegal Function Call?

[SMcNeill]

Code: (Select All)

Screen _NewImage(800, 600, 32)
h& = _LoadFont("C:\Windows\Fonts\courbd.ttf", 18)
_Font h&
For i = 1 To 33
    Locate i, i: Print i;
Next
Sleep


Locate 400, 300 'This will ERROR on you as it's waaay off the screen
Locate 20, 300: Print "Hello after the ERROR"
Sleep
System

An example to showcase the error for you and why you're seeing it.

Notice without the "monospace" being specificized, the second half of the locate is working with a basic fontwidth of 1 pixel (the smallest possible), but the first half of the locate is -- like always -- in relation to the row we want to print upon.

At LOCATE 400, 300, we generate an error as we simply don't have 400 lines upon the screen with which to print to.

[SMcNeill]

LOCATE was designed originally to position the cursor in text mode SCREEN 0, to set up PRINT. However, people expected the same exact behavior eg. in SCREEN 12, so it was left to its fate.

_PRINTSTRING is a different creature which requires screen pixel coordinates to work, treating the text also given to it as a graphics figure such as line or circle. That's why you have to compute stuff with other functions to be able to center the text, without caring if it's a monospaced font.

LOCATE can be used with PRINT only with monospaced fonts as Steve had said. It limits its use because it doesn't work as well with variable-spaced fonts. In that case _PRINTSTRING is available although it requires more "skill" to use it.

LOCATE was designed to work in SCREEN 12 exactly as it had in SCREEN 0 because it used the EXACT same fonts. QB45 doesn't have a _LOADFONT command and it doesn't allow you to load variable-width fonts. Same command for SCREEN 12 as for SCREEN 0, if you wanted to print and position text onto the screen.

_PRINTSCREEN isn't all that different. The only real difference with it is that it takes graphic coordinates instead of text coordinates, and it doesn't change the print cursor location.

LOCATE works just fine with variable-width fonts. When did Steve say it didn't? I just mentioned that the second parameter works with a pixel value rather than a column value -- as variable width columns aren't set at the same position on each line of text.

LOCATE down, right --- in ALL screen modes and with ALL fonts, that statement works without any issues. down is always going to be the number of rows down where the text is located. right, when used with variable width fonts, is going to be the number of pixels right to offset the text. With monospace fonts, it's going to be the number of characters right to offset the text.

That's the only difference in the behavior with LOCATE.

When used with variable-width fonts, the second parameter for LOCATE relates to pixels instead of characters. <-- It really is that simple.

[PhilOfPerth]

LOCATE was designed originally to position the cursor in text mode SCREEN 0, to set up PRINT. However, people expected the same exact behavior eg. in SCREEN 12, so it was left to its fate.

_PRINTSTRING is a different creature which requires screen pixel coordinates to work, treating the text also given to it as a graphics figure such as line or circle. That's why you have to compute stuff with other functions to be able to center the text, without caring if it's a monospaced font.

LOCATE can be used with PRINT only with monospaced fonts as Steve had said. It limits its use because it doesn't work as well with variable-spaced fonts. In that case _PRINTSTRING is available although it requires more "skill" to use it.

LOCATE was designed to work in SCREEN 12 exactly as it had in SCREEN 0 because it used the EXACT same fonts.  QB45 doesn't have a _LOADFONT command and it doesn't allow you to load variable-width fonts.  Same command for SCREEN 12 as for SCREEN 0, if you wanted to print and position text onto the screen.

_PRINTSCREEN isn't all that different.  The only real difference with it is that it takes graphic coordinates instead of text coordinates, and it doesn't change the print cursor location.

LOCATE works just fine with variable-width fonts.  When did Steve say it didn't?  I just mentioned that the second parameter works with a pixel value rather than a column value -- as variable width columns aren't set at the same position on each line of text. 

LOCATE down, right --- in ALL screen modes and with ALL fonts, that statement works without any issues.  down is always going to be the number of rows down where the text is located.  right, when used with variable width fonts, is going to be the number of pixels right to offset the text.  With monospace fonts, it's going to be the number of characters right to offset the text.

That's the only difference in the behavior with LOCATE.

When used with variable-width fonts, the second parameter for LOCATE relates to pixels instead of characters.  <-- It really is that simple.

Just read trough all those responses, and now my head hurts! But thanks for that great infomation!
Basically, I've got three new commands to experiment with: _Printstring ( a MUST DO for me), _Printwidth, and _Fontheight. My toolbox feels heavier, but I should be able to master these new tools.