musings on graphics support

[Sterling Christensen]

Status update:

So far the library I'm writing for FB's QB compatible graphics supports screen 12, 13, and also any arbitrary res/depth that SDL can do (actually the lib only supports 8, 15, 16, 24, and 32 bit. I dunno of SDL can do 1, 2, or 4 bit).

It supports:
1. WINDOW and VIEW
2. STEP anywhere QB supports it - for example: LINE STEP(2, 3)-STEP(4, 5), 2, BF
3. COLOR - you can omit the color parameter on any graphics command to use the color set by COLOR. Also an RGB function for non-palette modes
4. PALETTE command, both (paletteIndex, r, g, b) and QB's (attribute, color)
5. OUT/INP vga palette emulation
6. GET/PUT are QB compatible for 8 bit sprites. Format: 2 bytes = width * 8 + bitDepthCode, 2 bytes = height, width*height*bytesPerPixel bytes pixel data.

and every QB graphics command except DRAW, PAINT, and PCOPY.

I'm planning to get PAINT in, and v1ctor says I don't have to do DRAW but I might anyway.

Stuff that won't work and differences:
1. LINE doesn't allow a style parameter.
2. CIRCLE can take start/end or aspect<>1, but not both.
3. There's no 2, 4, or 16 color support in GET/PUT - SCREEN 12 is 256 color.
4. Page flipping. SDL doesn't really support screen modes with multiple pages. I'd have to emulate it by blitting, which could be slow.
5. You have to call FLIP periodically to make any changes to the screen/palette take affect.

After I fix something about CIRCLE that isn't behaving exactly like QB's CIRCLE (and add start/end/aspect support), and do WIDTH, LOCATE (pixel instead of text coords), PRINT etc, that should be everything.

[relsoft]

Good news!!!

I myself is gonna make a small PTC lib. :*)

[na_th_an]

1. LINE doesn't allow a style parameter.

Oh, bad news for me. Am I the only one who has used that? Why don't you implement it? nasty problems?

[barok]

Status update:

So far the library I'm writing for FB's QB compatible graphics supports screen 12, 13, and also any arbitrary res/depth that SDL can do (actually the lib only supports 8, 15, 16, 24, and 32 bit. I dunno of SDL can do 1, 2, or 4 bit).

It supports:
1. WINDOW and VIEW
2. STEP anywhere QB supports it - for example: LINE STEP(2, 3)-STEP(4, 5), 2, BF
3. COLOR - you can omit the color parameter on any graphics command to use the color set by COLOR. Also an RGB function for non-palette modes
4. PALETTE command, both (paletteIndex, r, g, b) and QB's (attribute, color)
5. OUT/INP vga palette emulation
6. GET/PUT are QB compatible for 8 bit sprites. Format: 2 bytes = width * 8 + bitDepthCode, 2 bytes = height, width*height*bytesPerPixel bytes pixel data.

and every QB graphics command except DRAW, PAINT, and PCOPY.

I'm planning to get PAINT in, and v1ctor says I don't have to do DRAW but I might anyway.

Stuff that won't work and differences:
1. LINE doesn't allow a style parameter.
2. CIRCLE can take start/end or aspect<>1, but not both.
3. There's no 2, 4, or 16 color support in GET/PUT - SCREEN 12 is 256 color.
4. Page flipping. SDL doesn't really support screen modes with multiple pages. I'd have to emulate it by blitting, which could be slow.
5. You have to call FLIP periodically to make any changes to the screen/palette take affect.

After I fix something about CIRCLE that isn't behaving exactly like QB's CIRCLE (and add start/end/aspect support), and do WIDTH, LOCATE (pixel instead of text coords), PRINT etc, that should be everything.

Hey, it sounds awesome Sterling!!! When this comes out i'll most definately use this to port my current project. (So long as you have a poke/pset command. )

Rel: Port Mono & Disco.

[relsoft]

Barok: Porting it is prolly a good idea but with like a lot of mem at my disposal, I'd rather make another demo using PTC.

Why poke when you can:
1. Buffer(offset) = color
2. *P = color

The same as poke but better and easier to undestand.

[barok]

I agree, but i'm lazy and don't want to change poke 20-30 times. Don't listen to me, you can say i'm trying to find someone to do my work for me.

[adosorken]

1. LINE doesn't allow a style parameter.

Oh, bad news for me. Am I the only one who has used that? Why don't you implement it? nasty problems?

It's harder than it looks to implement, but can be done. Methinks someone's got a mild case of coder's slack :lol:

[Sterling Christensen]

1. LINE doesn't allow a style parameter.

Oh, bad news for me. Am I the only one who has used that? Why don't you implement it? nasty problems?

It's harder than it looks to implement, but can be done. Methinks someone's got a mild case of coder's slack :lol:

QB starts with style at bit 15, which means I have to choose between compatibility and a 32 bit style mask... or I'd have to add an extra parameter to tell the library how many bits from style to use. This is the problem, any ideas? What should I do?

[na_th_an]

I haven't quite understood what you meant when you wrote "starts at bit 15". What does that mean?

Anyhow, I'd go for the good ol' 16 bits pattern, just for compatibility reasons.

[Sterling Christensen]

I haven't quite understood what you meant when you wrote "starts at bit 15". What does that mean?

You probably know know most/all of this, I don't mean to patronize, I'm just covering all the bases (not sure what you're asking):

QB's line basically works like this:

Code:

IF style AND 2& ^ 15 THEN PSET (pixel #1)
IF style AND 2 ^ 14 THEN PSET (pixel #2)
IF style AND 2 ^ 13 THEN PSET (pixel #3)
...

and so on down to 2 ^ 0 and pixel #16, after which it starts over at 2& ^ 15 again.

2& ^ 15 in binary is 1000000000000000 (that should be a 1 followed by 15 zeros). If you call the lowest bit (in the one's place) bit zero, then the highest bit (where the one is, in the 32768ths place) is bit 15. When QB draws a styled line, it starts with bit 15 - bit 15 determines whether the first pixel (and the 16th, the 32nd, the 48th, etc) gets drawn or not.

Now what use is a 32 or 64 bit style mask if it starts at bit 15 for compatibility? Maybe I should stick with 16... but that's just so limited... It's the reason why a lot of PureQB™ font routines have maximum heights or widths of 16.