Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Changing font-size in _rgb32 mode
#1
Is there a (simple) way to increase font- size during programme execution when using the _rgb32 screen? If not, could this be made possible?
Of all the places on Earth, and all the planets in the Universe, I'd rather live here (Perth, W.A.) Big Grin
Please visit my Website at: http://oldendayskids.blogspot.com/
Reply
#2
_LOADFONT and _FONT are what you're looking for.
Reply
#3
Thanks Steve. I got that working ok, choosing an Arial font, size 24, bold.
But the Tab() function seems to not work normally any more.  I would expect this code: 

SCREEN _NEWIMAGE(1200, 640, 32)
f& = _LOADFONT("c:\WINDOWS\Fonts\arial.ttf", 24, "bold")
_FONT f&
PRINT STRING$(79, "X")
PRINT "Screen width is 80 chars"
LOCATE 4, 38: PRINT "Middle": SLEEP

to print the first two lines normally ( a line of "X"s, then the message) which it does, and the next line to print "Middle" in the centre of line 4.
but instead, it prints this at tab position 4 on line 4. What did I get wrong?

Edit:
S'okay, I found it. I was not using a monospaced font. Adding"monospace" gave the correct result.
Of all the places on Earth, and all the planets in the Universe, I'd rather live here (Perth, W.A.) Big Grin
Please visit my Website at: http://oldendayskids.blogspot.com/
Reply
#4
It is suggested to use _PRINTSTRING instead of PRINT in graphics modes and not in SCREEN 0. Also the ancient functions which are "PRINT helpers", SPC(), TAB() and USING were designed to be used only with PRINT in SCREEN 0.

Use SPACE$() function instead of SPC(). Have to do the trick to write PRINT USING output to a file, then read it back into a string, to be able to use _PRINTSTRING with it. One of my longest feature requests is "USING$()" because some people hate C/C++ which doesn't make "sprintf()" an option, and also "Format()" from Visual Basic isn't good enough.
Reply
#5
Yes it is probably better to use _PrintString specially with fonts.

_PrintString takes (x, y) arguments in graphics pixels (not text character cells) and does not error if text does not fit screen like Locate and Print would.

_PrintWidth(text$) is handy for knowing pixel width of text$, for centering on the screen row for example.
b = b + ...
Reply
#6
It goes, but: "Locate" does not take into account the positioning by graphic pixels. After what is based on something the positioning after increasing the font size?  Sad

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, "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, 10
Print "Screen width is 80 chars"

Locate CsrLin + 2, 297
Print "Middle"

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

_FreeFont schrift
End

[Image: Font-Grafikpixel2023-04-08.jpg]
Reply
#7
Here is an exercise of making a box centered on screen and surrounded by a character like X:
https://qb64phoenix.com/forum/showthread...6#pid15056
b = b + ...
Reply
#8
(04-08-2023, 04:15 PM)Kernelpanic Wrote: It goes, but: "Locate" does not take into account the positioning by graphic pixels. After what is based on something the positioning after increasing the font size?  Sad

It's not productive to use LOCATE in a graphics screen. What would be an RPG programmed in QB64PE if only LOCATE and PRINT could be used to display text? No game programmer in his/her right mind would take up that offer, and wouldn't create thousands of picture files that have to be imported, only for basic printed text! Maybe for stuff which is embossed, or aligned into curves or other fancy effects found on signs but anyway...

You're supposed to use _FONTHEIGHT() and _PRINTWIDTH() to determined the dimensions of a font letter, and then use that information toward _PRINTSTRING. That's to show text anywhere on the screen, not aligned according to rules of 16-bit software and tiny amounts of memory. This is so we don't have to draw characters using DRAW, but I'm still waiting for that kewl vector font library that somebody else didn't finish long ago...
Reply
#9
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!

In text screens, COLOR 0 is black with full alpha.  In graphic screens, COLOR 0 is black with ZERO alpha as well.  It behaves completely differently than before, so you might as well just toss it aside and forget about it!

Code: (Select All)
Screen 0
Cls , 4

Color 2, 0
Print "Hello World"

Sleep

Screen _NewImage(640, 480, 32)
Cls , &HFFFF0000 'Red

Color &HFF00FF00, 0 'Green on 0
Print "Hello World"
Sleep

System


Try the above, you can see the difference in the background color of the two statements.  In one, 0 is full alpha black.  In the other, it's transparent zero-alpha clear.

Gosh!  Might as well quit using it then!  (At least, if you agree with mnrvovfc's philosophy above, you should!)



Which honestly, I think is just a silly way of doing things.  It's just much better to learn exactly what your tools do, and what they're expected to do and be used for, rather than just throw them away!

In text mode, COLOR 0 is full alpha black.   In 32-bit graphic mode, COLOR 0 is zero-alpha clear.   <-- That's the intended behavior.

Now, when it comes to LOCATE, there's **ABSOLUTELY NO DIFFERENCE IN GRAPHIC MODE AND TEXT MODE**!!   None.  Zero.  Zip.  Nada.  Locate works ***EXACTLY*** the same way in graphic modes as it does in text modes!

"WAHHH???"  <-- I can hear some of you blinking confusedly and scratching your heads and muttering, "Steve has really lost it this time.  He's an idiot!  KernalPanic's demo above shows that it behaves differently!!"

.
.
.

And it does!

.
.
.

Just not because of any graphic mode vs text mode behavior!!

The issue with KernalPanic's use of LOCATE is that he's trying to use locate with a **VARIABLE WIDTH FONT**.  How do I know that?? 

Code: (Select All)
schrift = _LoadFont("C:\WINDOWS\Fonts\Arial.ttf", 14, "bold")

Notice that there's no "MONOSPACE" in use with that _LOADFONT statement.  Without "monospace", it's a variable width font!  You can test it if you doubt me, easily enough -- just use a PRINT _FONTWIDTH statement and check for yourself.  Monospace fonts will print a value for their width, non-monospace fonts will print a big fat 0 (ZERO). 

So with a Width of ??? (non-set due it being a variable width font), where does that LOCATE 3, 10 locate to?  That 10 is 10 characters over from the left edge of the screen, so does it locate the width of 10 "W" characters, or 10 "i" characters?  The font I'm printing in here isn't monospace either, so let's see if we can showcase the difference in those two characters:

WWWWWWWWWW
iiiiiiiiii

10 W's and 10 i's, on the two lines above.  Now which do we use as our standard when it comes to non-monospaced character width??

Obviously, we can't use either, as to do so would screw up the formatting for any other line with a different character on it!  

So then the question comes:  HOW DOES LOCATE WORK WITH VARIABLE-WIDTH FONTS???  It basically assigns a fontwidth of 1, so when you locate 3, 10, you're locating 3 rows down and 10 pixels over.  The height is set with variable-width fonts, but the width isn't, so therefore LOCATE works with the information that it has -- it locates down by fontheight and over by pixels (a fontwidth of the minimal 1).

That's all there is to it.  There's no "Gosh, this works in text mode but not in graphics mode."  It's how LOCATE works in relation to your _FONTWIDTH and whether you're using a variable width font, or not.

Take the statement where KernalPanic loads his font and add "monospace" to it, and then see if LOCATE doesn't perform *EXACTLY THE SAME AS IN TEXT MODE*, with a monospace font.  

Nothing odd, or broken, or non-working here.  Everything is as it's intended to be.  If you want LOCATE to behave 100% the same in text and graphic modes, then simply make sure that you load your font as a "monospace" font.  That's all there is to it.
Reply
#10
For an example of what's going on guys, take a look at this little demo:

Code: (Select All)
Screen _NewImage(600, 440, 32)

schrift = _LoadFont("C:\WINDOWS\Fonts\Arial.ttf", 14, "bold")
schrift_monospace = _LoadFont("C:\WINDOWS\Fonts\Arial.ttf", 14, "bold, monospace")

Print _FontWidth(schrift), _FontWidth(schrift_monospace)

_Font schrift
Locate 4, 10: Print "Hello World (4 down, 10 over)"
Locate 10: Print "Hello World (variable width)"
Locate 15: Print "WWWWWWWWWW (variable width)"
Locate 16: Print "iiiiiiiiii (variable width)"


_Font schrift_monospace
Locate 5, 10: Print "Hello World (5 down, 10 over)"
Locate 11: Print "Hello World (monospace)"
Locate 20: Print "WWWWWWWWWW (monospace)"
Locate 21: Print "iiiiiiiiii (monospace)"


   

Does the above showcase and make sense as to why LOCATE would behave differently in regards to monospaced fonts and variable-width fonts?
Reply




Users browsing this thread: 3 Guest(s)