Quote:na_th_an: about your supposed bug... that's not a bug at all. Mode 7 is supposed to be EGA, and in EGA you only have a 64 colors palette to play with: that means that you can assign any of these 64 colors to your base 16 colors by doing
Code:
PALETTE index, color
where index ranges 0-15 and color ranges 0-63. The EGA palette is a fixed one; I should write down in the docs what color corresponds to what. So OUT &h3C9 makes no sense here...
Nope, it does make sense. In VGA cards, you could access the DAC registers just fine in SCREEN 1, 2, 7 and 8.Also in SCREEN 9.
In SCREEN 1 and 2 you had 4 and 2 "colour slots", respectively. Each one of them could be assigned any of the 16 colours (using PALETTE). Each one of those 16 colours had its associated DAC registers that could be changed (using OUT...).
In SCREEN 7 and 8 you have 16 "colour slots". Each one of them could be assigned any of the 16 colours (using PALETTE). Each one of those 16 colours had its associated DAC registers as well.
In SCREEN 9 and SCREEN 0 you have 16 "colour slots". Each one of them could be assigned any of the 64 colours (using PALETTE). Each one of those 64 colours had its associated DAC registers that could be changed using OUT and stuff.
This info is somewhat hidden, though, but the DAC register work in those modes. Try it. The problem is that the OUTs don't affect the "colour slots", but the colours themselves. For example, in SCREEN 1, you can do this:
Code:
OUT &H3c8, 10
OUT &H3c9, 50
OUT &H3c9, 50
OUT &H3c9, 50
But that new light grey shade won't be visible until you assign colour #10 to one of the 4 colour slots with PALETTE:
Now colour #1 will be light grey.
The same you can do in SCREEN 7, 8 or 9. It's good practice to assign colours to colour slots before with just a simple:
Code:
FOR i% = 0 TO 15
PALETTE i%, i%
NEXT i%
And now you can use the OUT stuff to change the colours directly.
I've used OUT to change SCREEN 7 the palette many times. Try it in QB to check it for yourself
Read this:
http://faq.qbasicnews.com/?blast=PaletteInScreenNine
For SCREEN 1 you have 4 slots, 16 attributes. For SCREEN 2, 2 slots, 16 attributes. For SCREEN 7 and 8 the DACs are mapped in an odd way if you don't "rearrange stuff", I can't remember how right now.
EDIT: I wrote this stuff some time ago for a tutorial. It has the mappings:
Quote:In SCREEN 1, the initial asociations are:
Code:
(colour set 1)
SLOT -> ATR
0 -> 0
1 -> 11
2 -> 13
3 -> 15
(colour set 2)
SLOT -> ATR
0 -> 0
1 -> 10
2 -> 12
3 -> 14
(colour set 3)
SLOT -> ATR
0 -> 0
1 -> 3
2 -> 5
3 -> 7
(colour set 4)
SLOT -> ATR
0 -> 0
1 -> 2
2 -> 4
3 -> 6
In SCREEN 2 the initial associations are:
Code:
SLOT -> ATR
0 -> 0
1 -> 15
In SCREEN 7 and 8 the associations are:
Code:
SLOT -> ATR
0 -> 0
1 -> 1
2 -> 2
3 -> 3
4 -> 4
5 -> 5
6 -> 6
7 -> 7
8 -> 16
9 -> 17
10 -> 18
11 -> 19
12 -> 20
13 -> 21
14 -> 22
15 -> 23
In SCREEN 9 and 0 you have this:
Code:
SLOT -> ATR
0 -> 0
1 -> 1
2 -> 2
3 -> 3
4 -> 4
5 -> 5
6 -> 20
7 -> 7
8 -> 56
9 -> 57
10 -> 58
11 -> 59
12 -> 60
13 -> 61
14 -> 62
15 -> 63
To alter the DACs without problems it's good practice to assign the attributes just after your SCREEN statement:
Code:
FOR i% = 0 TO numSlots%-1
PALETTE i%, i%
NEXT i%
Quote:About GET arrays size: yes that's true, gfxlib always requires 1 byte per pixel for color depths <= 8. I can change that if it's really needed, but is it? Having always 1 byte per pixel really speed things up...
That's why I called it "feature". You shoud just document it so people can port their stuff correctly. It's okay for me. One just has to make the arrays bigger
Quote:Now on to the suggestions:
1) PALETTE doesn't work in SCREEN 1. For SCREEN 1, you can use COLOR (as stated in the QB inline help) to switch the palette between the two CGA default palettes. See the QB COLOR statement details.
Wrong again. See above and try it in QB. Or check my old "StarOdds". It uses the trick all the time. If you want black, dark grey, dark green and light green in SCREEN 1 you just have to do:
Code:
PALETTE 0, 0
PALETTE 1, 8
PALETTE 2, 2
PALETTE 3, 10
Quote:2) You can always just do
Code:
PALETTE index, &hBBGGRR
where BB, GG and RR are the blue, green and red values ranging &h00 to &h3F (0-63)
BTW, in hi/truecolor modes you can always specify a color by using
Code:
COLOR &hRRGGBB, &hRRGGBB
(note the inverted order, RGB makes more sense to me) or by using the RGB function:
Code:
COLOR RGB(Red, Green, Blue), RGB(Red, Green, Blue)
as in Sterling's gfxlib.
Great to know. I did't think about that possibility. Thanks