SCREEN Function

[CletusSnow]

Hey folks,
I have a minor but strange problem with the SCREEN function.

This works fine:

SCREEN 12
LOCATE 10, 10: PRINT "TEST"
FOR a = 1 TO 4
a$ = a$ + CHR$(SCREEN(10, 9 + a))
NEXT a
LOCATE 12, 10: PRINT a$ <-- Output is, as expected, TEST.

If I replace SCREEN 12 with SCREEN _NEWIMAGE(1800, 900, 32) or any other resolution with 32bit, the output is ████ (4x chr$(219))

What am I doing wrong? 256 instead of 32 also works, but this is not an option in my case.

Regards,
CletusSnow

[Petr]

The problem will be that 8-bit graphics modes have values in memory 0-255, so this corresponds to the values in the ASCII table.

But 32-bit screens use pixels, not codes from the ASCII table.

The solution is to keep both screens in memory and always copy the 8-bit one to the 32-bit one before displaying it and release it from memory after displaying it.

Ideas like "I'll compare pixels and determine the character number based on that" will fail. It's enough to have graphics under the text, different colors of the letters' pixels, or just change the font... Moreover, in 32-bit mode, the text can start anywhere, but on a text screen, it's strictly defined. Even if you place the text on an 8-bit screen outside the place where Locate would place it, even SCREEN won't read it.

Code: (Select All)

Screen _NewImage(640, 480, 256)

'Locate 10, 10: Print "TEST"

_PrintString (72, 144), "TEST" 'the same position as Locate 10, 10 <---- try use (73, 144)

'Line (50, 120)-(78, 160), , BF



For a = 1 To 4

    a$ = a$ + Chr$(Screen(10, 9 + a))

Next a

Locate 12, 10: Print a$ '<-- Output is, as expected, TEST.

change printstring position and try it...

[bplus]

Code: (Select All)

Screen _NewImage(80, 25, 0)
Locate 10, 10: Print "TEST"
For a = 1 To 4
    a$ = a$ + Chr$(Screen(10, 9 + a))
Next a
Locate 12, 10: Print a$ '<-- Output is, as expected, TEST.

This works, I think Screen() needs 0 for color bit mode, ie Screen() doesn't work in graphics screens. Curious Wiki doesn't specify that?

[RhoSigma]

Code: (Select All)

Screen _NewImage(80, 25, 0)
Locate 10, 10: Print "TEST"
For a = 1 To 4
    a$ = a$ + Chr$(Screen(10, 9 + a))
Next a
Locate 12, 10: Print a$ '<-- Output is, as expected, TEST.

This works, I think Screen() needs 0 for color bit mode, ie Screen() doesn't work in graphics screens. Curious Wiki doesn't specify that?

It also works with _NEWIMAGE 256-color screens (because otherwise it wouldn't work with SCREEN 12/13 either), only 32-bit doesn't work. @SMcNeill once detailed why but can't find the post now. What's not working on graphic screens is to obtain the bg/fg colors using the SCREEN function, as color information is stored different in graphic screens compared to text mode.

[bplus]

+1 Rho

Yes 256 works also!
   

[SMcNeill]

The reason this doesn't work on graphic screens is rather simple -- SCREEN has to do OCR to try ang get those characters back from a graphical screen.

On SCREEN 0, character data is stored *perfectly* in two bytes for each character on the screen.  One is COLOR, the other is the ASCII character stored on the screen.

On any other graphic screen there's no information recorded anywhere which records those characters on the screen.  They're just colored *pixels*.   PICTURES of characters, if you want, and QB64PE tries very pitifully to see if the character you have on the screen happens to match the font for that screen. 

What it does is basically grab a fontwidth by fontheight square at the location you specify.  Then it looks for what might be the first color and what might be the second.  Got more colors than two?  It BLAHs out instantly and says, "I have no idea how the hell a three color picture can be a character!" 

It wants a foreground and a background color -- two colors.   

Then it compares that foreground color with the current font and looks for the closest match.   

Then it returns some garbage and says, "Ehh!  I guess this is your character?!"

And.... It's occasionally right.  In some cases.

BUT -- it's *always* wrong in others.

Quick -- someone tell me what the difference is in a CHR$(0) printed, a CHR$(32) printed, and a CHR$(255) printed.  One is a null character, the other is a plain space, and the last is a non-breaking space.

For OCR (Object Character Recognition), tell me how the hell those three things *LOOK* different. 

Show Content

SpoilerThey don't

In *NO* graphic screen will you ever get back the character you expect if you're dealing with various blank spaces.  You'll also probably not get back a lot of information properly as fonts can be the cut off and not display fully due to clipping or other issues.  If you're off by a single pixel, that changes the closest possible match for your character, so it's going to be wrong.  If there's a stray color or line or pixel that was plotted by something else on the screen... It's going to screw up the results.  If you have more than two colors, that's going to screw up the results.

It's not very good OCR at all, and IMHO it shouldn't even work *at all* for anything other than SCREEN 0.  I don't think QB45 promised anything with SCREEN giving you back characters in non-text mode.  Did it even attempt to do it, or just toss an error?  I don't recall.

The reason why it *sometimes* works with SCREEN 12 and 256 color modes is you're not dealing with any blending or alpha or mixing of colors.   A 32-bit screen has a transparent background by default.  It deals with alpha colors.  It does automatic blending.  It has so many extra hoops that other screens *don't* have, AFAIK it just craps out and says, "Hahahaha!! Good luck with that!", and tosses a CHR$(219) for anything and everything without even trying to sort out all the mess that could be going on with the pixels on that screen.

Fonts have to match.
There can't be any more than two colors.
Pixel position has to be perfect.
There can't be any stray lines, points, or imperfections on the screen.
You have to sacrifice three pygmies and dance naked under the harvest moon.
No blending can have happened.
No alpha can be in use.
Characters can't look the same (such as the three various different spaces in CHR$ 0, 32, 255.)

So, with allllll those restrictions in mind, you can *TRY* to use SCREEN to get back characters from a non-text screen.

Just don't be surprised when it fails or gives false results.

[CletusSnow]

Okay, thank you so much for these overwhelming explanations. Now I understand why it's not working. I will have to solve it completely different, without text or pixel recognition.
Have a nice Sunday, wherever you are.

[bplus]

@CletusSnow I have used a "Virtual Screen Array" an array that tracks every print to screen so I could do exactly this without Screen() in graphics screens. I made a modified Print sub that printed both screen and array to track what was on screen. I've also done this for Just Basic points, lines and circles that doesn't have Point() either. Not too diferent from a screen editor.

[TempodiBasic]

@CletusSnow
yeah it is an OCR, so you can get it working if you obtain a strong contrast between foreground and background but only if you use normal font images... if you use for example script font you don't, or weddings font or others in which the sign of character is so much artistic that its shape is far from standard one.

A good option is the duplication of screen output that Bplus has already posted.
Moreover if it is your habit, you can go down to lowlevel and read directly the video ram...search in the forum the _MEM examples code... I remember different threads , one of  these is that of scrolling video started by me and made richer by important post from smarter QB64pe friends.