Feature Request: More Colors for SCREEN 0

[manstersoft]

Edit: This post was a bug report regarding the SCREEN() Function, but as SMcNeil pointed out...

SCREEN 0 stores your ASCII character in memory, so it can always retrieve that value for you.  No other screen does this.

A graphical screen draws GRAPHICS onto the screen and has to compare pixel-by-pixel to guess at what the character is in any given space.  It can't tell you the difference in CHR$(0), CHR$(32), or CHR$(255).  If you draw a line above a period, it might read that as a colon or semi-colon.

I've dabbled in a few other iterations of BASIC, and the reason I never wanted to switch was because they all lacked a SCREEN() Function. It's one of the wonderfully unique aspects of qbasic/qb64. But...

I would argue that the worst limitation of qbasic/qb64's SCREEN 0 is being limited to 16 Colors (attributes) and worst of all 8 background colors (attributes). This limitation is something I've struggled with in my ASCII games for a long time. Would it be possible to have a way to up that limitation? 64 seems like a logical number (DAC). 256 would be better.

SCREEN 0 can already successfully load custom fonts (and scale them), and can use the SCREEN() function. Removing the COLOR limitations would make it perfect in my book.

My old post that details the issues with using SCREEN() in graphic modes is below...

Issue 1: In modes other than 0; using SCREEN() to find an ASCII character on a background other than COLOR ,0 results in a solid block (cc 219).

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 256): _FONT 8
2. COLOR 5, 1
3. PRINT "Hello World!"
4. PRINT SCREEN(1, 6); SCREEN(1, 7)
5. COLOR 5, 0
6. PRINT "Hello World!"
7. PRINT SCREEN(3, 6); SCREEN(3, 7)

Issue 2: In modes other than 0; Using SCREEN() after loading a custom font triggers an illegal function call.

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 256)
2. F = _LOADFONT("cyberbit.ttf", 32, "monospace") 'replacing with F = 8 works fine
3. _FONT F
4. PRINT "Hello World!"
5. PRINT CHR$(SCREEN(1, 1))

I tested 256, 32, and SCREEN 12. With both FONT 8 and FONT 16

[Cobalt]

as per wiki,
"The code value returned is the ASCII code from 0 to 255."

 so it is meant to work with the BIOS font. not a loaded TTF
and I'm guessing its meant to work with the 8x16 form not the 8x8 form, but not sure there.

just FYI.

[manstersoft]

as per wiki,
"The code value returned is the ASCII code from 0 to 255."

 so it is meant to work with the BIOS font. not a loaded TTF

As I said, when using SCREEN 0 and a custom font, Issue 2 doesn't happen.
Custom fonts do read ASCII. Otherwise the _MAPUNICODE statement would be useless.

and I'm guessing its meant to work with the 8x16 form not the 8x8 form, but not sure there.

I tested everything with both FONT 8 and FONT 16. Both bring up the issues.

[SMcNeill]

One thing to remember guys:  SCREEN 0 stores your ASCII character in memory, so it can always retrieve that value for you.  No other screen does this.

A graphical screen draws GRAPHICS onto the screen and has to compare pixel-by-pixel to guess at what the character is in any given space.  It can't tell you the difference in CHR$(0), CHR$(32), or CHR$(255).  If you draw a line above a period, it might read that as a colon or semi-colon.

[manstersoft]

One thing to remember guys:  SCREEN 0 stores your ASCII character in memory, so it can always retrieve that value for you.  No other screen does this.

A graphical screen draws GRAPHICS onto the screen and has to compare pixel-by-pixel to guess at what the character is in any given space.  It can't tell you the difference in CHR$(0), CHR$(32), or CHR$(255).  If you draw a line above a period, it might read that as a colon or semi-colon.

Dang, I feared that might be the case.
In that case it's less of a bug and more of a miracle that the graphical screens can use SCREEN() at all.
I've edited my post.

To be honest, all I really want is a Text mode with more than 16 fg / 8 bg colors. That's the only reason I use SCREEN _NEWIMAGE(x,y,256) to begin with. The limitation seems like a needless relic from the qbasic days.

[SMcNeill]

One easy trick is to use 2 screens and work with both at the same time.

DisplayScreen = _NEWIMAGE(X, Y, 256)
CharacterScreen =_NEWIMAGE(R, C, 0)
SCREEN DisplayScreen
PrintBoth "Foo"

SUB PrintBoth(text$)
  _DEST CharacterScreen
  PRINT text$
  _DEST DisplayScreen
  PRINT text$
END SUB

Now, you can use SCREEN with the text screen (CharacterScreen), and retrieve your characters properly.

[manstersoft]

One easy trick is to use 2 screens and work with both at the same time.

Code: QB64: [Select]

1. DisplayScreen = _NEWIMAGE(640, 400, 256)
2. CharacterScreen = _NEWIMAGE(80, 50, 0)
3. SCREEN DisplayScreen: _FONT 8
4. PrintBoth "Foo"
5.  
6.  
7. SUB PrintBoth (text$)
8.     _DEST CharacterScreen
9.     PRINT text$
10.     _DEST DisplayScreen
11.     PRINT text$
12. END SUB
13.  

Now, you can use SCREEN with the text screen (CharacterScreen), and retrieve your characters properly.

Interesting. I updated with my own variables.

_DEST is new to me; is it like a more flexible way of page flipping?
Also, on the code above, why is "Foo" printed twice, even though we're viewing SCREEN DisplayScreen? Maybe I'm missing something.

[FellippeHeitor]

Add DIM SHARED DisplayScreen  AS LONG, CharacterScreen AS LONG to the top.

[manstersoft]

Oh, haha. I should have noticed that. Alright, I'll mess with this in the following couple of days.
Thanks to you both.
I would of course prefer that SCREEN 0 gets more colors (or another text mode is added so as not to mess with blinking text compatibility). I don't know the feasibility of that addition though.

[Pete]

I use PALETTE to squeeze out a little more color in my SCREEN 0 programs. Screen Zero, the only screen anyone really needs.

Pete

[manstersoft]

I use PALETTE to squeeze out a little more color in my SCREEN 0 programs. Screen Zero, the only screen anyone really needs.

Pete

What I'm looking for is more attributes; More than 16 Colors on screen at the same time.

And really, 16 Colors is enough. But 8 background colors? Woof.

[SMcNeill]

What I'm looking for is more attributes; More than 16 Colors on screen at the same time.

And really, 16 Colors is enough. But 8 background colors? Woof.

If you turn off blinking, you can have 16 background colors.

[FellippeHeitor]

Indeed, with _BLINK OFF.

I don't know how they behave regarding PALETTE though. Uncharted territory there.

[manstersoft]

I saw that on the wiki, but I was unable to get it to work.
The blinking did stop, but for example COLOR ,9 is always COLOR ,1

[FellippeHeitor]

You must go beyond color 15 to get it to work, since high-intensity backgrounds take place of the blinking spots. Try COLOR 31, 9, for example.