Now this is one of our older "new" keywords by now, having come out over a year ago, in v3.7, and this is one of the most overlooked new keywords by our user base.
Steve honest opinion here -- EVERYONE SHOULD START SWAPPING OVER TO USE _UPRINTSTRING!!!
For me to explain why I say that, I'll have to trust you guys to do two things to understand my following points:
1) Download this font and move it over to your QB64PE folder:
SourceCodePro-Medium.7z (Size: 52.38 KB / Downloads: 25)
1b) (Don't forget to extract it from the 7z archive so you can actually use it.
)
2) Grab the code below and stick it in the IDE and run it:
Now this little program makes use of the font above (which is why I asked you to grab it and download it), and it highlights one of the most important reasons to make the switch over from PRINT or _PRINTSTRING, to start using _UPRINTSTRING -- proper spacing and formatting of letters!
Look at the top block of text on your screen -- that's printed with _UPRINTSTRING.
Look at the middle block of text. That's using _PRINTSTRING.
And finally, compare to the last block of text using plain PRINT.
Can you see how much more of the screen the _UPRINTSTRING is using vertically??
It's not a grand amount, but it's a couple of pixels in each row -- and that makes one heck of a difference!!
The problem arises with PRINT and _UPRINTSTRING, where it crams those letters so tightly together, that the top of one row will begin to overwrite the bottom of another row. To see the potential of the issue (I didn't choose a font/size here where the issue is truly happening, as I actually wanted every character to appear on the screen), look at those last two sets of underscores and letters on the screen...
Notice in that top row how close we come to those underscores?? Notice the extra space in the bottom row?
Now, let me ask -- "What do you guys think would happen if the font size was odd and a little rouding happened, and that bottom row shifted up by a single pixel?"
I'll tell you, so you don't have to wonder: The _PRINTSTRING version would have the tops of the letters cut off a pixel of the row above, making all those underscores evaportate and disappear and go bye-bye forever.
The underscores are so low down, and the next row cuts into it to such a point, that the bottom row overwrites the last few pixels of the top row!!
And that applies to ALL letters. The p's are cut smaller, as are the q's and j's and anything with a subscript...
And THAT's what _UPRINTSTRING works and fixes for us! It has the proper spacing for the characters, so one never cuts off the other!
And, I can hear some of you guys now going, "Well WTF didn't you just fix _PRINTSTRING so it doesn't cut off letters??!"
And the answer to that is: "READ THE FORUMS!!" /GROWL!! /BITE!! /HISS!!
Read the forums and take a moment to see how important ANY change to fonts is to our user base. "Things are faded!" "Things aren't spaced the same!" "This broke my old code!"
Fonts are an essential part of programming. When you write a program with a font in use, and you have 30 lines of screen to make use of, you make use of those 30 lines of screen. Having us make changes to the commands -- even if it's to fix what I personally consider to be a major bug -- to add an extra pixel or three between each character (depending on font size and rounding and what not), would result in FEWER LINES ON THE SCREEN!!
If we just changed PRINT and _PRINTSTRING, how many people's existing code would break and need to be reworked?? It's not like these are new commands -- they've been in the language for over a dozen years now, I bet. They're probably two of the most used commands that we have, and would tend to affect everyone's programs...
...so we can't just pop up and say, "Hey! We're going to break the world to add some extra whitespace to your fonts, so they display properly!"
Folks would revolt!! They'd hunt us down with pitchforks and rotten tomatoes and old smelly socks and lots of other nasty things!
And thus, instead of breaking everything old, we added in the _UPRINTSTRING set of commands.
And _UPRINTSTRING has proper spacing. It displays all the character as it should. It doesn't overwrite characters, or clip characters, or any of that screwy stuff.
_UPRINTSTRING is what _PRINTSTRING should actually be, if we could change _PRINTSTRING without breaking folks existing stuff.
And that's why, in Steve's Honest Opinion(tm), EVERYONE SHOULD SWAP OVER TO USING _UPRINTSTRING ASAP!!
And I'll finish this up as PART ONE for this KotD, as there's quite a few things to go over with syntax and usage and stuff, and I don't want to write a whole novel for folks to have to slug through, for a single post. I'll get around to writing up a guide to syntax and such (though it is awfully like _PRINTSTRING already is) with the next KotD entry.
For now, just try the code I posted above. Then have fun and play around with the font I uploaded... At various sizes, this font in particular is one where that underscore just evaportes and disappears with PRINT.
Then ask yourself: "Which do I really want in my programs? Cramped, compacted rows with little to no whitespace between them?" or, "I can live with maybe two fewer lines per screen (or having to make my screens a few pixels larger). What I want is for my dang letters to display and render properly!"
Your answer to that question will determine if you're one of the folks who still can make use of PRINTSTRING, or whether you might want to look into swapping over to UPRINTSTRING as soon as possible.
Steve honest opinion here -- EVERYONE SHOULD START SWAPPING OVER TO USE _UPRINTSTRING!!!
For me to explain why I say that, I'll have to trust you guys to do two things to understand my following points:
1) Download this font and move it over to your QB64PE folder:
SourceCodePro-Medium.7z (Size: 52.38 KB / Downloads: 25)
1b) (Don't forget to extract it from the 7z archive so you can actually use it.
)2) Grab the code below and stick it in the IDE and run it:
Code: (Select All)
Screen _NewImage(1024, 720, 32)
_ControlChr Off
font = _LoadFont("SourceCodePro-Medium.ttf", 16, "monospace")
_Font font
For x = 0 To 31
For y = 0 To 7
t$ = Chr$(y * 32 + x)
_UPrintString (x * _UPrintWidth(t$), y * _UFontHeight), t$
Next
Next
For x = 0 To 31
For y = 0 To 7
t$ = Chr$(y * 32 + x)
_PrintString (x * _PrintWidth(t$), y * _FontHeight + 180), t$
Next
Next
For y = 0 To 7
For x = 0 To 31
t$ = Chr$(y * 32 + x)
Locate y + 22, x + 1
Print t$;
Next
Print
Next
_PrintString (0, 500), "___________________"
_PrintString (0, 500 + _FontHeight), "ABCDEFGHIK"
_UPrintString (0, 550), "___________________"
_UPrintString (0, 550 + _UFontHeight), "ABCDEFGHIK"
Now this little program makes use of the font above (which is why I asked you to grab it and download it), and it highlights one of the most important reasons to make the switch over from PRINT or _PRINTSTRING, to start using _UPRINTSTRING -- proper spacing and formatting of letters!
Look at the top block of text on your screen -- that's printed with _UPRINTSTRING.
Look at the middle block of text. That's using _PRINTSTRING.
And finally, compare to the last block of text using plain PRINT.
Can you see how much more of the screen the _UPRINTSTRING is using vertically??
It's not a grand amount, but it's a couple of pixels in each row -- and that makes one heck of a difference!!
The problem arises with PRINT and _UPRINTSTRING, where it crams those letters so tightly together, that the top of one row will begin to overwrite the bottom of another row. To see the potential of the issue (I didn't choose a font/size here where the issue is truly happening, as I actually wanted every character to appear on the screen), look at those last two sets of underscores and letters on the screen...
Notice in that top row how close we come to those underscores?? Notice the extra space in the bottom row?
Now, let me ask -- "What do you guys think would happen if the font size was odd and a little rouding happened, and that bottom row shifted up by a single pixel?"
I'll tell you, so you don't have to wonder: The _PRINTSTRING version would have the tops of the letters cut off a pixel of the row above, making all those underscores evaportate and disappear and go bye-bye forever.
The underscores are so low down, and the next row cuts into it to such a point, that the bottom row overwrites the last few pixels of the top row!!
And that applies to ALL letters. The p's are cut smaller, as are the q's and j's and anything with a subscript...
And THAT's what _UPRINTSTRING works and fixes for us! It has the proper spacing for the characters, so one never cuts off the other!
And, I can hear some of you guys now going, "Well WTF didn't you just fix _PRINTSTRING so it doesn't cut off letters??!"
And the answer to that is: "READ THE FORUMS!!" /GROWL!! /BITE!! /HISS!!
Read the forums and take a moment to see how important ANY change to fonts is to our user base. "Things are faded!" "Things aren't spaced the same!" "This broke my old code!"
Fonts are an essential part of programming. When you write a program with a font in use, and you have 30 lines of screen to make use of, you make use of those 30 lines of screen. Having us make changes to the commands -- even if it's to fix what I personally consider to be a major bug -- to add an extra pixel or three between each character (depending on font size and rounding and what not), would result in FEWER LINES ON THE SCREEN!!
If we just changed PRINT and _PRINTSTRING, how many people's existing code would break and need to be reworked?? It's not like these are new commands -- they've been in the language for over a dozen years now, I bet. They're probably two of the most used commands that we have, and would tend to affect everyone's programs...
...so we can't just pop up and say, "Hey! We're going to break the world to add some extra whitespace to your fonts, so they display properly!"
Folks would revolt!! They'd hunt us down with pitchforks and rotten tomatoes and old smelly socks and lots of other nasty things!
And thus, instead of breaking everything old, we added in the _UPRINTSTRING set of commands.
And _UPRINTSTRING has proper spacing. It displays all the character as it should. It doesn't overwrite characters, or clip characters, or any of that screwy stuff.
_UPRINTSTRING is what _PRINTSTRING should actually be, if we could change _PRINTSTRING without breaking folks existing stuff.
And that's why, in Steve's Honest Opinion(tm), EVERYONE SHOULD SWAP OVER TO USING _UPRINTSTRING ASAP!!
And I'll finish this up as PART ONE for this KotD, as there's quite a few things to go over with syntax and usage and stuff, and I don't want to write a whole novel for folks to have to slug through, for a single post. I'll get around to writing up a guide to syntax and such (though it is awfully like _PRINTSTRING already is) with the next KotD entry.
For now, just try the code I posted above. Then have fun and play around with the font I uploaded... At various sizes, this font in particular is one where that underscore just evaportes and disappears with PRINT.
Then ask yourself: "Which do I really want in my programs? Cramped, compacted rows with little to no whitespace between them?" or, "I can live with maybe two fewer lines per screen (or having to make my screens a few pixels larger). What I want is for my dang letters to display and render properly!"
Your answer to that question will determine if you're one of the folks who still can make use of PRINTSTRING, or whether you might want to look into swapping over to UPRINTSTRING as soon as possible.
