Thank you very much, Paul, your demonstration explains everything!
So, as I can see, background colors rotate through the 16-color
standard VGA palette, and in this palette "color 3" happens to be
exactly = "color 1" in the 4-color CGA palette ... with any other
value in my test program I would have noticed it myself, since
the colors would have been different!
Oh yes, there is always something new to learn.
Anyway, thank you a lot for taking the time to explain it to me.
Regards,
Hans Ruegg
Announcement
Collapse
No announcement yet.
Please test: Weird output in CGA mode
Collapse
X
-
Hans,
in SCREEN 1 color defines the background and the palette, not the forground color.
Code:color background [,pallette]
You then draw a screen of forground color 1.. which in the current palette is actually the same as background color 3.
You then create a background colored square.. but the background and forground are the same color so you can't see it.
Without the "color 3" statement, the background remains black so things act as you expect.
I don't see the black line that you do but I suspect it is the gap between the top of your monitor and the top of the colored screen that you've drawn as is the area beyond that which you can draw.
Try this and watch how the edge of the screen (beyond the part that you can draw on) changes as you press the enter key to change the background color.
Code:screen 1 line (0,0)-(319,199),1,bf color 1: print "abc"; line (20,20)-(40,40),0,bf for r% = 0 to 20 color r% input a$ next
------------------
Leave a comment:
-
Oh, I forgot... Take into account also, that my screen
background is blue (color 1), while the COLOR statement
sets the color to 3 (=white), so if you were right, there
should at least be a WHITE box.
Hans Ruegg
Leave a comment:
-
Thank you all for your replies.
However, this does not explain two things:
1. Why does the black box appear correctly, when I leave out
the COLOR 3 statement? (Note that this color statement has
nothing to do with the box; it defines only the foreground
color for the following PRINT statement. - The color of the
box, on the other hand, is defined by the number 0 in the
very LINE statement, which should override any previous color
definition in a COLOR statement. So changing the color for the
PRINT statement, should not have any effect whatsoever on the
LINE statement.)
You could even try (I think I did so) putting the COLOR and
PRINT statements AFTER the LINE statement, with similar results.
2. Where does the horizontal black line come from?
Regards,
Hans Ruegg.
Leave a comment:
-
Right. You only get four colors in SCREEN 1. One of them is the
background color, 0, which is normally black. In this particular
screen mode, though, the COLOR statement changes the background
color.
------------------
Tom Hanlin
PowerBASIC Staff
Opinions expressed may not be those of my employer or myself
Leave a comment:
-
Hans,
colours in SCREEN 1 are odd.
I think "black" as a forground colour isn't black, it just shows the current background colour.
Your "black" box just sees through to the light blue background.. which is the same at the rest of the foreground you just drew so you don't see it.
Paul.
------------------
Leave a comment:
-
Yes, same result here with PB/DOS 3.5
Bye!
------------------
Try TrID file identifier! Recognize over 1.160 filetypes and counting...
Give a powerfull scriptable Lua interface to your application with PowerBLua
PBTracer - Tracer / Profiler for PowerBASIC (soon!)
Leave a comment:
-
Please test: Weird output in CGA mode
May I ask some fellow programmers to test if I am crazy or if this
is a real bug?
The following short program did not produce the expected output
(tested on a VGA display, but this should not matter):
Code:screen 1 line (0,0)-(319,199),1,bf color 3: print "abc"; line (20,20)-(40,40),0,bf 'This should create a black square, 'but instead there was a horizontal 'black line near the top of the screen. do: loop while inkey$="" screen 0 end
Does someone else get the same results?
Regards,
Hans Ruegg
Tags: None
Leave a comment: