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!
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??
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.
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
SystemTry 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.