+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Official Links (https://qb64phoenix.com/forum/forumdisplay.php?fid=16)
+--- Forum: Learning Resources and Archives (https://qb64phoenix.com/forum/forumdisplay.php?fid=13)
+---- Forum: Keyword of the Day! (https://qb64phoenix.com/forum/forumdisplay.php?fid=49)
+---- Thread: Extended KotD #15.1: _UPRINTSTRING (Part 1) (/showthread.php?tid=2765)
Extended KotD #15.1: _UPRINTSTRING (Part 1) - SMcNeill - 06-01-2024
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: 26)
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.
RE: Extended Kotd #15.1: _UPRINTSTRING (Part 1) - OldMoses - 06-02-2024
I noticed this one when it came out in v3.8.0, but I didn't really look into it. Thanks for the writeup. I may start playing with this one. I presume that _UFONTHEIGHT, _ULINESPACING and _UPRINTWIDTH are all related functions to this one.
One question: If one were to just go into a project and blanket replace all _PRINTSTRING commands with _UPRINTSTRING, would it look and act the same? Assuming one left the parameter list the same...
RE: Extended Kotd #15.1: _UPRINTSTRING (Part 1) - SMcNeill - 06-02-2024
(06-02-2024, 12:42 AM)OldMoses Wrote: I noticed this one when it came out in v3.8.0, but I didn't really look into it. Thanks for the writeup. I may start playing with this one. I presume that _UFONTHEIGHT, _ULINESPACING and _UPRINTWIDTH are all related functions to this one.
One question: If one were to just go into a project and blanket replace all _PRINTSTRING commands with _UPRINTSTRING, would it look and act the same? Assuming one left the parameter list the same...
Generally speaking, if that's the only change you made, you probably wouldn't notice much difference. The issue would come up if you rely on spacing with _FontHeight, as you'd still have that cramped in tight poistioning. All the letters would render, without overwriting each other, but you'd end up with them "touching" an awful lot more.
_UPRINTSTRING tends to print an extra pixel above or below what we had with _PRINTSTRING, which would really cram all the letters in there tightly together.
Look at the image above. Pay particular attention to the 5th row as you compare the letters. Notice how that extra spacing makes everything keep from touching? Look at the top (_UPRINTSTRING) and compare the upside down question mark to the bottom (_PRINTSTRING). That's the difference I was talking of with my post above.
Now, look at the picture above here. For this one, I did as you suggested -- simply replaced _PRINTSTRING with _UPRINTSTRING. Everything renders, but look how much overlap there is here!
You're not accounting for the increase space of the font, and since the font is slightly larger, it's going to be packed in there tight as heck using the old size.
If you're going to swap to _UPRINTSTRING, you should also swap from _FONTSIZE to _UFONTSIZE, _PRINTWIDTH to _UPRINTWIDTH, and such...
But that's going to lead to wider/taller columns/rows, which means you may not have as much screen space as previously. You may have had 30 rows of text before, but only 28 rows of text, accounting for that extra space between lines and such...
..and it's up to you to decide how much of a change that might make in your program.
Me personally, my old code is just going to stay the way it's always been. I'm not going to try and go back and sort things out to convert from _PRINTSTRING to _UPRINTSTRING.
I'm just going to make certain that for all forseeable projects, I'm going to end up using the new commands and not the old ones.