Feature request for SCREEN function

[SMcNeill]

I do understand that QB64 graphics modes do not contain a character array in video memory.  I also understand that the SCREEN() update for QB64 in graphics modes is a hack that will not always work correctly.

I still think it should use the current FG/BG colour instead of requiring one specific colour be used.  It gives more power to the programmer.

The problem with that is remembering what color is each each position.

SCREEN 13
FOR I = 1 TO 10
   COLOR I, 255 - I
   PRINT “HELLO WORLD”
NEXT

Now, if I use screen for position 1,1, what result would I get?  My current FG/BG isn’t what it was when I printed it, so would my “H” be a SPACE? 

[Raven_Singularity]

You make a feature request sound like an accusation, that's weird.

That wasn't my intention.  I may be a bit blunt at times, but I am open to explanations and changing of my mind.  I'm not sure what part of my comments sounded like an accusation.

The problem with that is remembering what color is each each position.

SCREEN 13
FOR I = 1 TO 10
   COLOR I, 255 - I
   PRINT “HELLO WORLD”
NEXT

Now, if I use screen for position 1,1, what result would I get?  My current FG/BG isn’t what it was when I printed it, so would my “H” be a SPACE?

But the very same applies to every other background colour that is not transparent black, as it is now.

If SCREEN() accepted FG/BG colours, the programmer could specify which colours to use when scanning for text characters.  If it used the current FG/BG, and that wasn't the correct, then the programmer could save the current FG/BG colours and set the FG/BG to whatever was needed for SCREEN() to work, then restore the FG/BG colours.

As it stands now, simply opening a 32bit screen without specifying any colours at all, causes SCREEN() to fail.  It would be more beneficial if SCREEN() used the current FG/BG so it worked on fresh screens.

[SMcNeill]

See if this little demo doesn't showcase a much easier way to reliably work with character values for a graphic screen:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. CharacterInfoScreen = _NEWIMAGE(_WIDTH \ _FONTWIDTH, _HEIGHT \ _FONTHEIGHT, 0)
3.  
4.  
5. RANDOMIZE TIMER 'so we get colorful background and foreground colors
6.  
7.  
8. FOR i = 1 TO 10
9.     COLOR _RGB32(RND * 255, RND * 255, RND * 255), _RGB32(RND * 255, RND * 255, RND * 255)
10.     DPrint "Hello World"
11. NEXT
12.  
13. COLOR -1, 0
14.  
15.  
16. FOR i = 1 TO 10
17.     PRINT CHR$(DScreen(i, i))
18. NEXT
19.  
20.  
21. SUB DPrint (text$)
22.     SHARED CharacterInfoScreen
23.     D = _DEST
24.     PRINT text$
25.     _DEST CharacterInfoScreen
26.     PRINT text$
27.     _DEST D
28. END SUB
29.  
30. SUB DLocate (x, y)
31.     SHARED CharacterInfoScreen
32.     D = _DEST
33.     LOCATE x, y
34.     _DEST CharacterInfoScreen
35.     LOCATE x, y
36.     _DEST D
37. END SUB
38.  
39. FUNCTION DScreen (x, y)
40.     SHARED CharacterInfoScreen
41.     S = _SOURCE
42.     _SOURCE CharacterInfoScreen
43.     DScreen = SCREEN(x, y)
44.     _SOURCE S
45. END FUNCTION
46.  

Never any loss of character info, printing in such a manner.  You can even tell the difference between a CHR$(32) and a CHR$(255).  And, best of all, it only takes a few moments to add such routines to your program, once you get used to making and working with them.  (After all, this one only took me about 2 minutes to whip up.)

[Pete]

Close, but it prints...

H
e
l
l
o

W
o
r
l

So it misses the ending d of World. That's because of the space. So it needs to map 11 positions, not just 10. Other than that, nice!

Pete

[PMACKAY]

for graphics mode to detect text i use something like this in my games

dim screen$(22) = eg y=height
store my date in a varable to width (such as 40)

so above is a 40 wide by 24 height....

i use mid$(screen$(height),width,1) to either store or retrieve my data   screenmem=screen(x,y)

this way i can use a loop to update then display

for height=1 to 22: for width=1 to 40:locate  height,width:print mid$(screen$(height),width,1)next width:next height:_display

this way I can read my ascii characters and write them. then display one entire frame

example:

 DIM SCREENMEM$(22)



DISPLAYDATA: FOR K% = 1 TO 22: FOR L% = 1 TO 40: LOCATE K%, L%: B$ = MID$(SCREENMEM$(K%), L%, 1)
        IF B$ = "W" THEN B$ = "Û": COLOR COLDATA%(1)
        IF B$ = "w" THEN B$ = "±": COLOR COLDATA%(2)
        IF B$ = "." THEN B$ = "°": COLOR COLDATA%(3)
        IF B$ = "r" THEN B$ = "O": COLOR COLDATA%(4)
        IF B$ = "d" THEN B$ = "": COLOR COLDATA%(5)
        IF B$ = "X" THEN B$ = "
": COLOR COLDATA%(6): MX% = K%: MY% = L%
PRINT B$;: NEXT L%: NEXT K%: LOCATE 23, 15: COLOR 15: PRINT "TIME ¯"; LEVTIM%; " ";: RETURN

I use on timer to make my screen automatically update and when ever i change data all i do is

MID$(SCREENMEM$(K%), L% - 1, 1) = "r"

you can make a simple print string by b$="hello world": mid$(screenmem$(y),x,1)=b$

not sure if this will do what you wanted... all characters will be located on a 8x8 or 8x16 matrix using my method and will detect the character...
 

[Raven_Singularity]

To be clear, I was not looking for a workaround for storing text cells on a graphical screen.  I have no issues doing that.  I was only suggesting that the hack used by QB64's screen function in graphical mode to take into account the active background colour, not requiring transparent black.