+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2)
+--- Thread: SCREEN() function doesn't make nice with _FONT in graphic modes (/showthread.php?tid=1694)
SCREEN() function doesn't make nice with _FONT in graphic modes - mnrvovrfc - 05-21-2023
It looks like SCREEN() function was broken in one of the updates, either that or it's not designed anymore to work in graphic modes. Particularly in 32-bit color.
Run this example:
Code: (Select All)
screen _newimage(800, 600, 32)
print "Hello"
print screen(1, 1)
print chr$(screen(1, 1))
endBelow the message it returns 219 and the solid block.
The thing is that I want to read characters from "PRINT USING" output without setting up another hidden screen for it and without creating a temporary file which causes wear and tear on the system due to the thousand calls that my program could potentially generate from it.
After being run my program kept returning an illegal function call because QB64PE doesn't seem to like neither the text coordinates given to it for SCREEN() function. It looks like one cannot set a _FONT and then call SCREEN().
Run this example:
Code: (Select All)
screen _newimage(800, 600, 32)
dim i as integer, amf as long
amf = _loadfont("/usr/share/fonts/liberation/LiberationSans-Regular.ttf", 12)
_font amf
for i = 1 to 120
locate 4, i
print chr$(i + 32);
locate 5, 1
print i; screen(4, i);
next
endTested on Linux; replace the _LOADFONT() line with the appropriate for MacOS or Windows. I have tried this with a monospace font, and with optional "MONOSPACE" parameter to _LOADFONT(). This doesn't even go beyond the first position.
So I guess I will have to do without "PRINT USING" formatting toward using _PRINTSTRING or _UPRINTSTRING.
RE: SCREEN() function doesn't make nice with _FONT in graphic modes - SMcNeill - 05-21-2023
Screen has never been reliable for anything except SCREEN 0. In screen 0, data is stored in 2 bytes -- ASCII character for one and COLOR value for the other. Since the information is there, it's a simple matter of just reading that existing data and returning it to you. It's absolutely possible to distinguish if a line has a CHR$(32) space in it, or if it's a CHR$(255) non-breaking space.
Any other screen mode store's information only by pixel color, making it impossible to guarantee you'll get the proper results back every time. There's no OCR library incorporated into PE, and there never has been. Waaay back in the day, Galleon tried to extend the SCREEN function for graphic modes, but even then it was inconsistent and extremely limited via only working with solid characters on a solid background with the default Font 16, with perfect x/y line placement.
If you need to retrieve screen data in graphic mode, your best bet is to store the data in an array or on another screen 0 text mirror. Depending on it in graphic mode will always be hit and miss and miss and miss at best.
RE: SCREEN() function doesn't make nice with _FONT in graphic modes - mnrvovrfc - 05-24-2023
I guess I will have to imitate many other programming languages, especially those "related" to C or "quite similar" to C, and import "printf()" and "sprintf()" and definitely forget about PRINT USING. I don't think PRINT USING was used very often for histograms, pie charts and three-dimensional graphic plots. I looked at the source code of QB64 v0.954 and focused on the "USING" scheme. It looks more involved than trying to capture a "qbs" object out of the output to create a new string variable out of it.
LOL I was supposed to be ranting about something else, such as the lack of search using regular expressions. That should be a specialty for QBJS.
I have allowed years pass that I would have done a virtual machine for Lua so we could use the groovy table functionality, and the regular expressions that work even though they are weirder than what is known by Perl, GREP and other programs. I wasn't able to go beyond a replication of the "direntry.h" offered on this forum. Created also as a "dot-SO" file was a routine that read in a binary file into an array-like table of integers. It was faster than doing it only with interpreted code for loading WAV files but was unreliable, and only worked for a specific format. The code to manipulate WAV files overall was still very slow but I wasn't confident doing it in QB64 and I couldn't use QB64, Freebasic, Purebasic or anything like that while totally offline and only with 32-bit Ubuntu Studio.
LOL I said dealing with WAV files with my Lua scripts was very slow but it was slightly better than using Openshot Video Editor with all the Python going on to do almost the entire program.
RE: SCREEN() function doesn't make nice with _FONT in graphic modes - Ultraman - 05-24-2023
You can do regex in QB64 using a regex library. I think I've used tinyregex before or something.
RE: SCREEN() function doesn't make nice with _FONT in graphic modes - dbox - 05-24-2023
Good suggestion, perhaps I should add an advanced string library to QBJS.
In the meantime, you could use this little function to do a regular expression search:
Code: (Select All)
Dim s As String
s = "The quick brown fox jumps over the lazy dog. If the dog barked, was it really lazy?"
' Find any character that is not a word character or whitespace
Dim idx As Integer
idx = Search(s, "[^\w\s]")
' Expected output: 43
Print idx
Function Search (searchStr As String, regex As String)
$If Javascript Then
Search = searchStr.search(regex);
$End If
End FunctionRE: SCREEN() function doesn't make nice with _FONT in graphic modes - sivacc - 05-30-2023
I am using Indic script . As you are using Font statements, you can help me , I am sure . I can print correctly in Libre Office, but not in QB64pe, versions 3.6 as well as 3.7 . The example under _UPrintstring in Russian , in 3.7 ran correctly, but when I substituted the font and the DATA, print was wrong. I will be grateful for any suggestion .Thanks a lot
