Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SCREEN() function doesn't make nice with _FONT in graphic modes
#2
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.
Reply


Messages In This Thread
RE: SCREEN() function doesn't make nice with _FONT in graphic modes - by SMcNeill - 05-21-2023, 09:55 AM



Users browsing this thread: 2 Guest(s)