Alternative GFXlib released

[Dr_Davenstein]

The function name is fine, after all, you can always find and replace if you meet a conflict. To me, "MOUSE" sounds a lot like a keyword. Same for "MULTIKEY(scancode)". I'd go with these two.

I agree totally. They do sound like natural QB style keywords... Line, Circle, Inkey$, MultiKey, Mouse... They just seem to fit right in.

By the way, I was just kidding about the sprite roto-zooming thing. It just seems like we keep pushing and pushing! :rotfl:

[barok]

heh... next we'll have tile engines right in the libs.

I'd like to see the option to build the lib customly. Like, choose what routines are going to be in, get rid of any you don't need, and then finally just link all the commands that are wanted into a lib. UGL had something like that.

[Shok Teenik]

first of all, great job with this library! you're getting closer and closer to near complete legacy support ... I love it.

now, a suggestion: how about implementing VIEW PRINT in gfx mode? it already seems to work using pure text, but not with SCREEN 12, etc. which is kind of annoying.

[KiZ]

Angelo, I wanted to take this opportunity to say thankyou for DirectQB!

The most amazing QB library I have used! It rules. Well done man.

[na_th_an]

Sure. Count me in. DirectQB is _THE_ QB library. It made my games run in a 486. Man, that's magic

[na_th_an]

Btw, I've found several bugs/features. In fact, 1 bug and 2 features. The features should be documented, as they represent important differences from QB.

Oh, and I found them in the already released binary distribution, not in the CVS one. Maybe they have been corrected already. I am reporting just in case:

Bug: In SCREEN 7, the palette changes (with out &H3c8, etc) don't produce the correct colours. Changing SCREEN 7 to SCREEN 13 fixes the problem, though.

Feature #1: Arrays for GET/PUT have to be dimmensioned as if they were for SCREEN 13, i.e., 1 byte per pixel plus two array elements for width/height. This has to be documented, as in QB sources array sizes may differ depending on the screen mode (i.e. in SCREEN 1 and 10 you have 4 pixels per byte, in SCREEN 2 and 11 you have 8 pixels per byte, in SCREEN 7, 8, 9 you have two pixels per byte).

Feature #2: It seems that freeBASIC handles arrays in row-order, and not in column-order as QB does (i.e., QB stored them in memory this way: column 0, column 1, ... and fB does it the way around, just like C: row 0, row 1, ...). That causes an important compatibility problem when attempting to store several sprites in a single 2D array.

In QB, to store 10 16x16 sprites you had:

Code:

DIM sprites%(129, 9)

GET (0, 0) - (15, 15), sprites%(0, 7) ' gets sprite #7
PUT (100, 100), sprites%(0, 7) ' puts sprite #7

And in fB you have to use:

Code:

DIM sprites%(9, 129)

GET (0, 0) - (15, 15), sprites%(7, 0) ' gets sprite #7
PUT (100, 100), sprites%(7, 0) ' puts sprite #7

It's way more logical now in fB than it was in QB, but it should be mentioned. I have used the 2D arrays trick since I remember, and I have found a lot of QB games that do the same. People porting old code should take this in account.

I also have a couple of suggestions as well:

1.- In QB, you could do PALETTE a%, b% in SCREEN 1, 2, 7, and 8 to assign any of the original 16 colours to a value. I.E. in SCREEN 1, a PALETTE 3, 10 would make colour #3 show light green. This doesn't seem to be supported, at least on SCREENs 1 and 2.

2.- I dunno if this has been added, but it would be cool to have an actual command to change the palette. PALETTE a%, r% + 256 * g% + 65536 * b% looks ugly, and having to do OUT &h3c8... etc looks ugly as well. They are great for backwards compatibility, but I guess that a statement RGB c%, r%, g%, b% would be better. Or RGB c%, (r%, g%, b%) to make it more "QB-ish". Or even PALETTE c%, (r%, g%, b%), whatever fits you more.

[lillo]

Thanks about DQB, it was nice to work on it, and I'm glad so much people liked it. But let's concentrate on FB now...

About VIEW PRINT support, that's doable, I'll have a look.

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

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

About GET order: true here too. I must remember to state this in the docs...

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.

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.

EDIT:
I have a final thing to say: today I've worked out the new MULTIKEY and GETMOUSE (yes now it's named like this, should be fine):

Code:

if (multikey(1)) then ' ESC (scancode 1) is currently pressed

Code:

dim x as integer, y as integer, wheel as integer, buttons as integer
getmouse x, y   ' Now x and y hold the current mouse position
getmouse x, y, z  ' Same as before, but also gets wheel position
getmouse x, y, z, buttons ' buttons has lowest bits set if left/right/middle buttons are pressed

Now the problem is: for the win32 driver I use DirectInput for the keyboard and the win32 API for the mouse handling. Well, today I made yet another test to see the bloat of the lib after this addition: compiling this very simple program:

Code:

SCREEN 13
SLEEP

results in a 48K exe. The same program with first line removed (which makes the linker to skip gfxlib) gives an 8K exe. I think a program using gfxlib adds from 40 up to 80K of more size to your exe... Ok you don't depend on external libs (except DirectX) but is this acceptable enough? Or maybe I'm worrying too much...

[Jofers]

Nope, that's just how I recall QB being. A 40k padding is not a problem when your talking about using gfxlib.

Now if you had a PRINT program that was 40k, I'd be upset, but nah.

[adosorken]

I don't think size is as big a deal here as it was when we were all coding in DOS. Back then, a 40KB library had better make your toast in the morning in addition to its normal duties. Nowadays, a 40KB library addition is nothing. So don't worry about it, imo.

[Dr_Davenstein]

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