Alternative GFXlib released

[retsyo]

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...

Do you mean that we can always use an array with width*height bytes to hold a width*height sprite safely? If so, it is great since I do not have to turn to QB manual to find the forumla everytime, and plz keep this feature.
What if we use the new lib that supports any color depth?

[relsoft]

I don't think it matters either. The executable for Half-Life is like 930KB... 40KB is peanuts.

That's just the EXE. Most of the GFX code and Game Engine is stored in DDL's.

So 40 kb is less than peanuts. If people want to make GFX demos they'd have to use PTC,GL or DX directly.
;*)

[lillo]

ok, MULTIKEY and GETMOUSE now in CVS.

retsyo: from the docs I'm writing, description of GET:

Code:

Use this function to save blocks of graphics so you can later use PUT to draw
them. The coordinates of the block are affected by the most recent WINDOW and
VIEW statements, and must be both inside the current clipping region set by
VIEW. The supplied array must be large enough to hold the block you're going
to save; the required array size depends on both the block size in pixels and
the current color depth. Use the following formula to compute the right size
in bytes:

For color depths 1, 2, 4 and 8:
    size = 4 + (w * h)
For color depths 15 and 16:
    size = 4 + (w * h * 2)
For color depths 24 and 32:
    size = 4 + (w * h * 4)

Where w and h are the width and height of the graphics block you want to save.
Assuming you're working with INTEGER arrays, and as an INTEGER in FB is 4
bytes long, to save an 8bpp 32x32 block for example, you'll need an array of
(((4 + (w * h)) + 3) / 4) elements.

relsoft: actually I think this gfxlib is already far ahead of TinyPTC... Both in speed (at least for modes <32bit; 32bit mode is a bit faster in TinyPTC as it uses MMX color converters; wait until I write them too for gfxlib and the speed will be almost equal) and functionalities. 8)

[na_th_an]

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:

Code:

PALETTE 1,10

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:

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%

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

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

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

[na_th_an]

I can be really puzzling at times

Don't worry, I'll elaborate a complete document about all this and post it here.

[dumbledore]

will there be a linux port of this gfx lib?

[lillo]

na_th_an: ok, rewrote palette handling to better emulate QB. Now in CVS.

dumbledore: an X11 driver is next on my ToDo list :bounce: