Screen 12 backgrounds in QB 4.5
| Author |
Message |
|
Michael A. Cle
#1 / 11
|
 Screen 12 backgrounds in QB 4.5 I'm pretty new at programming. I started a program using Screen 12 because I wanted to use the higher resolution (640x480), not realizing the difficulties of using color in it. I did my homework and figured out how to use the PALETTE command to change the attributes, and that the 0 (zero) attribute is (always?) the background color. But at certain points I want to display a message box to the user. I draw a colored box (with the LINE command), then I print the text of the message in the box. The trouble is that the background of the text is the zero attribute, not the same color as the box. If I change the zero attribute, it changes the background for the entire screen, and not just for the text. So how can I have the background of the text match the color of the box without changing anything else on the screen? It's not like it's ruining my program, or keeping it from working, but
little touches like this make it nicer.
Thanks for help...
|
| Tue, 13 Jul 2004 12:28:47 GMT |
|
 |
|
Tom Wer
#2 / 11
|
Screen 12 backgrounds in QB 4.5
Quote: > I'm pretty new at programming. I started a program using Screen 12
>because I wanted to use the higher resolution (640x480), not realizing
>the difficulties of using color in it.
> I did my homework and figured out how to use the PALETTE command to
>change the attributes, and that the 0 (zero) attribute is (always?) the
>background color.
> But at certain points I want to display a message box to the user. I
>draw a colored box (with the LINE command), then I print the text of the
>message in the box. The trouble is that the background of the text is
>the zero attribute, not the same color as the box. If I change the zero
>attribute, it changes the background for the entire screen, and not just
>for the text.
> So how can I have the background of the text match the color of the
>box without changing anything else on the screen?
> It's not like it's ruining my program, or keeping it from working, but
>little touches like this make it nicer.
There's not much you can do in mode 12 that's really fun without using DOS Interrupts. Do you have any books on EGA/VGA regsiters & programming at home or in your library? You'll need to spend a lo-o-o-o-o-o-ng time with these unless you're a heck of a lot smarter than me. (which probably wouldn't take much). In 16-colour graphic modes, you normally get 4 bits per pixel to{*filter*}
around with, but there's this "attribute mode control register" you
can play with. There's a bit in there that will alternate between
"background intensity" and "blink enable" so you can actually get that
blinking on your text characters in the graphics mode as well as the
text modes.
This one's easy to play with because there is a DOS function 10h
interrupt to set it on or off. So I just did it to see if this
register is active - but it made the text blink for all chararcters
already drawn in the colour that by coincidence had that
blink/intensity bit enabled - not just the new ones I was drawing!
----------
Slightly more difficult to twiddle, because there's no Dos function to
do it, is another bit called "Graghics/Text mode". You'd have to
change this one with reads & rewrites to the register itself.
The dox say this bit "determines whether attributes are decoded as
four-bit graphics pixels or as byte-wide attributes."
I didn't test this one just now - ran outta gas - and I'm going to
throw this at you then hit the sack. I may fart around with it again
tomorrow.
If you are allowed to switch this bit around in the mode control
register whenever you want, and if the graphics character drawing
software will actually look at this bit when you are drawing text in
graphics mode, then it will probably do what you want, because the
attribute byte for text is :
1 bit for blink or bkgrnd intensity
3 bits bkgrnd colour
1 bit fgnd intensity & generator select
3 bits fgnd colour
Has anyone else actually tried this to see if it works?
The bottom line is it probably ain't worth the hassle.
Why not just draw the box border and leave the inside of the box as
the background colour, and write your text in it in the same colour as
the box border or something like that?
|
| Wed, 14 Jul 2004 00:56:37 GMT |
|
|
|
Andreas Meil
#3 / 11
|
Screen 12 backgrounds in QB 4.5
Quote: > I did my homework and figured out how to use the PALETTE command to
> change the attributes, and that the 0 (zero) attribute is (always?) the
> background color.
This is a very well known issue. I recommend to use a small COLOR/PRINT replacement: SUB ColourPrint(t$, fg%, bg%)
' t$ = printing text
' fg% = foreground colour
' bg% = background colour
DIM h%(1 + 32 * LEN(t$))
x1% = 8 * (POS(0) - 1)
y1% = 16 * (CSRLIN - 1)
x2% = x1% + 8 * LEN(t$) - 1
y2% = y1% + 15
LINE (x1%, y1%)-(x2%, y2%), bg%, BF
GET (x1%, y1%)-(x2%, y2%), h%
COLOR fg% XOR bg%
PRINT t$;
PUT (x1%, y1%), h%, XOR
ERASE h%
END SUB
A more luxurious version can be found at
http://www.hofen.ch/~andreas/Englisch/Download/Grafikbibliothek.html
Andreas
|
| Wed, 14 Jul 2004 02:26:48 GMT |
|
|
|
Michael A. Cle
#4 / 11
|
Screen 12 backgrounds in QB 4.5 Quote:
> > I did my homework and figured out how to use the PALETTE command to > > change the attributes, and that the 0 (zero) attribute is (always?) the > > background color. > This is a very well known issue. I recommend to use a small COLOR/PRINT
> replacement:
I kinda figured somebody would have already encountered it, but in my search through Google groups, I couldn't find any posting that directly addressed it (maybe I overlooked it?). Thanks for the help! Quote: > SUB ColourPrint(t$, fg%, bg%)
> ' t$ = printing text
> ' fg% = foreground colour
> ' bg% = background colour
> DIM h%(1 + 32 * LEN(t$))
> x1% = 8 * (POS(0) - 1)
> y1% = 16 * (CSRLIN - 1)
> x2% = x1% + 8 * LEN(t$) - 1
> y2% = y1% + 15
> LINE (x1%, y1%)-(x2%, y2%), bg%, BF
> GET (x1%, y1%)-(x2%, y2%), h%
> COLOR fg% XOR bg%
> PRINT t$;
> PUT (x1%, y1%), h%, XOR
> ERASE h%
> END SUB
> A more luxurious version can be found at
> http://www.hofen.ch/~andreas/Englisch/Download/Grafikbibliothek.html
> Andreas
|
| Wed, 14 Jul 2004 02:43:22 GMT |
|
|
|
Michael A. Cle
#5 / 11
|
Screen 12 backgrounds in QB 4.5 Quote:
> "Has anyone else actually tried this to see if it works? > The bottom line is it probably ain't worth the hassle.
Yeah, that does sound like a lot of work, assuming I even understand what I'm doing. Quote: > Why not just draw the box border and leave the inside of the box as
> the background colour, and write your text in it in the same colour as
> the box border or something like that?
Well, I could do that if I had to, but I think I'll check out this other poster's link, too. Like I said, this isn't critical to the program (it's a 3D maze program), but the program itself is a learning experience for me, as I try to add more features to it. Thanks!
|
| Wed, 14 Jul 2004 07:37:43 GMT |
|
|
|
Michael A. Cle
#6 / 11
|
Screen 12 backgrounds in QB 4.5 Thanks for the advice. For the curious, I'm working on 3D maze program I call Blind Alley. The executable and source code is available from my website at: http://server3002.freeyellow.com/macsnafu/pcstuff/blindaly.zip
It's only up to version 0.62, there's more work to be done.
Quote:
> I'm pretty new at programming. I started a program using Screen 12 > because I wanted to use the higher resolution (640x480), not realizing > the difficulties of using color in it. > I did my homework and figured out how to use the PALETTE command to > change the attributes, and that the 0 (zero) attribute is (always?) the > background color. > But at certain points I want to display a message box to the user. I > draw a colored box (with the LINE command), then I print the text of the > message in the box. The trouble is that the background of the text is > the zero attribute, not the same color as the box. If I change the zero > attribute, it changes the background for the entire screen, and not just > for the text. > So how can I have the background of the text match the color of the > box without changing anything else on the screen? > It's not like it's ruining my program, or keeping it from working, but
> little touches like this make it nicer.
> Thanks for help...
|
| Thu, 15 Jul 2004 12:46:19 GMT |
|
|
|
Andreas Meil
#7 / 11
|
Screen 12 backgrounds in QB 4.5
Quote: > Thanks for the advice. For the curious, I'm working on 3D maze program I > call Blind Alley. The executable and source code is available from my > website at: > http://server3002.freeyellow.com/macsnafu/pcstuff/blindaly.zip
I have written a similar maze program, so check it out at http://dreael.catty.ch/Deutsch/Download/Labyrinth.html
Note: Use http://babelfish.altavista.com/ to translate the German text.
You will find it in source code form, too - it even works fine with the
QBASIC.EXE (QBasic V1.1) interpreter. :-) The faster your CPU the smoother
the realtime walking animation (higher frame rate).
Andreas
|
| Thu, 15 Jul 2004 19:12:22 GMT |
|
|
|
Michael A. Cle
#8 / 11
|
Screen 12 backgrounds in QB 4.5 Quote:
> > Thanks for the advice. For the curious, I'm working on 3D maze program I > > call Blind Alley. The executable and source code is available from my > > website at: > > http://server3002.freeyellow.com/macsnafu/pcstuff/blindaly.zip
> I have written a similar maze program, so check it out at
> http://dreael.catty.ch/Deutsch/Download/Labyrinth.html
> Note: Use http://babelfish.altavista.com/ to translate the German text.
> You will find it in source code form, too - it even works fine with the
> QBASIC.EXE (QBasic V1.1) interpreter. :-) The faster your CPU the smoother
> the realtime walking animation (higher frame rate).
> Andreas
Pretty nice little program, there. Certainly, the variety of color makes it easier to look at. The main concern of my program was strictly getting through the maze. Your walking animation would make your program good for some kind of adventure game, but it's tiring when all you want to do is solve the maze. That's why I stuck with one cell per movement. There are other limitations to my program that I need to work on, but the most important one is in the maze-generation process. My program can handle mazes as big as 254 x 254 (or any combination where the number of cells is equal to or less than the sum of 254 and 254). However, there's a noticeable delay when generating mazes larger than 100 x 100, and that delay becomes quite significant on 486's. I shudder to think how slow it would be on a 386 or 286. I haven't tried to run it in QBasic 1.1, but I'm not overly concerned about that. I also haven't tried that translation, yet. What's the third line that the program asks you?
|
| Fri, 16 Jul 2004 05:12:55 GMT |
|
|
|
Michael A. Cle
#9 / 11
|
Screen 12 backgrounds in QB 4.5 Quote:
> I haven't tried to run it in QBasic 1.1, but I'm not overly concerned about
> that.
I tried it, and Blind Alley *does* work in QBasic 1.1, but I had to convert my source code from the QuickBasic Binary format to the plain text format before QBasic could read it. The source code contained in my zip file is the binary format.
|
| Fri, 16 Jul 2004 12:21:10 GMT |
|
|
|
AskMeToSear
#10 / 11
|
Screen 12 backgrounds in QB 4.5 For easy access to Babelfish-Altavista Site Translation, check out: http://www.geocities.com/askmetosearch/babel.htm
Quote:
> > > Thanks for the advice. For the curious, I'm working on 3D maze program I
> > > call Blind Alley. The executable and source code is available from my
> > > website at:
> > > http://server3002.freeyellow.com/macsnafu/pcstuff/blindaly.zip
> > I have written a similar maze program, so check it out at
> > http://dreael.catty.ch/Deutsch/Download/Labyrinth.html
> > Note: Use http://babelfish.altavista.com/ to translate the German text.
> > You will find it in source code form, too - it even works fine with the
> > QBASIC.EXE (QBasic V1.1) interpreter. :-) The faster your CPU the smoother
> > the realtime walking animation (higher frame rate).
> > Andreas
> Pretty nice little program, there. Certainly, the variety of color makes it
> easier to look at. The main concern of my program was strictly getting through
> the maze. Your walking animation would make your program good for some kind of
> adventure game, but it's tiring when all you want to do is solve the maze.
> That's why I stuck with one cell per movement. There are other limitations to
> my program that I need to work on, but the most important one is in the
> maze-generation process. My program can handle mazes as big as 254 x 254 (or
> any combination where the number of cells is equal to or less than the sum of
> 254 and 254). However, there's a noticeable delay when generating mazes larger
> than 100 x 100, and that delay becomes quite significant on 486's. I shudder
> to think how slow it would be on a 386 or 286.
> I haven't tried to run it in QBasic 1.1, but I'm not overly concerned about
> that.
> I also haven't tried that translation, yet. What's the third line that the
> program asks you?
|
| Fri, 16 Jul 2004 23:30:58 GMT |
|
|
|
Michael A. Cle
#11 / 11
|
Screen 12 backgrounds in QB 4.5 Quote: > > I also haven't tried that translation, yet. What's the third line that the
> > program asks you?
The third line translates to: probability, straightforward drive on?
Any idea what the heck *that's* supposed to mean?
|
| Sat, 17 Jul 2004 08:19:29 GMT |
|
| |
|
