musings on graphics support

[Sterling Christensen]

A complete list of QB's gfx commands with suggested alternative syntax and commentary, in rough alphabetical order:

1. CLS fillColor

2. COLOR fore, back
And maybe: COLOR(r, g, b) returns LONG

Is this confusing?:

Code:

COLOR COLOR(foreR, foreG, foreB), COLOR(backR, backG, backB)

3. FLIP
for double buffering

4. GET [STEP](x1,y1)-[STEP](x2,y2),arrayname[(indices)]
EDIT: Problem: If you save the sprite to a file, what do you get? An SDL_Surface struct with no pixel data? When you PUT a string to a file, you get the data instead of a pointer - perhaps sprites could be handled similarly? With a built in SPRITE type (or whatever alias for "SDL_Surface") it could automagically append pixel data when you PUT a SPRITE to a file?

5. Doc should tell people INP(&H3C9) won't work, replaced with (maybe?) : longInt = PALETTE(color)

6. LINE [[STEP] (x1,y1)]-[STEP] (x2,y2) [,[color][,[B[F]][,style]]]
But maybe the style mask is 32 bit instead of 16 like QB? Or an extra param for # of bits in style? Should style not be supported? PureQB™ font routines use it, but so what?

7. PAINT [STEP] (x,y)[,[paint] [,[bordercolor] [,background]]]
Support ANY for bordercolor (to fill a region not bordered by a single color like most other paint routines) or maybe dropping bordercolor altogether depending on what SDL's paint equivalent can do?
Probably drop support for background param (nobody uses it) and passing a string to paint param (allows painting with a fill pattern)

8. PALETTE col, r, g, b
Doc for OUT should point to PALETTE

QB also supports: PALETTE USING array-name [(array-index)]
Nobody uses it, but it probably translates to SDL better (does SDL even have functions to set one pal entry at a time?)

9. POINT(x,y)
and POINT(0) current gfx cursor x coord, POINT(1) for y
POINT(2) and 3 not needed with no VIEW/WINDOW

10. PRESET (like PSET, but draws with background color instead of fore)
I suggest this be dropped, nobody uses it...

11. PSET [STEP](x,y) [,color]

12. PUT [STEP](x, y),arrayname[(indices)][,actionverb]
TRANS=color and SOLID for actionverb instead of XOR etc?
Or TRANS could use background color set by COLOR

13. The SCREEN function (row,column[,colorflag]) doesn't work in gfx modes, does it? Probably dropping it anyway, right?

SCREEN 12|13|(width, height)[, depth] ?
no apage,vpage params because multiple page support is replaced with double buffering and FLIP

14. VIEW [SCREEN] (x1,y1)-(x2,y2) [,[color][,border]]]
I suggest dropping both VIEW SCREEN and color,border params and making it set the clipping box instead of doing what QB's view does.

Not supported:
PCOPY (no multiple page support - double buffering with FLIP instead, right?)
DRAW
WINDOW
PMAP (useless without WINDOW)

[marzecTM]

oki doki, that's one way, but i somehow have the feeling that it will be a nightmare to implement.

i dunno bout 8-bit support, will anybody use it afterall? i mean if you can simply load a 24-bit bmp and blit that to the screen, i dunno. i would not support 8-bit

i would come up with something like that

SCREEN modenum
-- modenum: 1, 2, 3, 4, 5 .... mapping to some standard modes like 640x480x16-bit 640x480x32-bit etc. indexed by the modenum, one would have to figure out what 's supported on most cards, that's a problem, cause all the original qb screens where cga, ega and vga (whatever) so they where supported by everything

FLIP / SHOW
dunno what name would be better. basically it should be called when you want to present on screen what you have just drawn by the following commands

PSET x, y, color
not really tricky, just psets to the offscreen buffer, the tricky part is the color, colorcomposition with RGB may confuse people, maybe providing constants for the old qb standard palette colors, like RED, BLUE, GREEN, YELLOW etc. everybody who needs more or different colors has to dive into rgb color creation

PGET x, y
returns a 32-bit integer containing the color value at x, y

LINE x1, y1, x2, y2, color
same as pset, also concerning the color

BOX x1, y1, width, height, color
FBOX x1, y1, width, height, color
draws a box with x1, y1 as the coordinates of the upper left corner, box draws only a frame, FBOX a filled box

CIRCLE x ,y , radius, color
well, guess...

CLS color
yeah we all know that one

COLOR r, g, b, modenum
should return a 32-bit integer containing the colorvalue for the specific modenum, i guess that's as easy as it can get.

that's for the basic primitives. i guess it's really simple implementing them provided the constrains of not supporting 8-bit and housekeeping what mode we are.

now on to bitmaps or better the GET/PUT problem. first i would say that we simply provide a type BITMAP or something like that

dimensioning like this:
dim somesprite as BITMAP

sure, nothing new about that, but i thing BITMAP should not be a structure itself but a handle to a reall SDL_Surface/Array in the runtime lib. basically we'd have an SDL_Surface* array in the rtlib

no on to the commands:

GETBITMAP x, y, width, heigth, var as BITMAP
this would copy the rectangular are (x,y topleft corner), create an SDL_surface for it store it in the array within the rtlib module and put the handle number into var. it would check before wheter the handle in var is already a valid SDL_Surface and if so it would delete it before creating a new one.

PUTBITMAP x, y, var as BITMAP
well, this would put the BITMAP speficied in var at the location x, y (topleft corner as always), if var is not valid we simply ignore the command so this would be more save i guess...

LOADBITMAP filename, var as BITMAP
well i guess the name tells it all would do the same as GETBITMAP except that it loads form a file rather then retrieving the data from the offscreensurface. a concern her is wheter this should return a value wheter the function succeeded or not

STOREBITMAP filename, var as BITMAP
well, same as LOADBITMAP, also taking the error code returning into account

i guess that's as easy as it can get. some problems with BITMAP though

1) since BITMAP is really just an integer, nobody would be forbidden to assign one BITMAP to another like

dim bmp1 as BITMAP
dim bmp2 as BITMAP
bmp2 = bmp1

if someone would destroy or alter bmp1 at some point this would also have an effect to bmp2 since both vars refere to the same SDL_Surface stored in the rtlib module

2) return code checking, maybe this could be done with on error or optionaly with the returnvalue itself, so the user has the choice wheter he wants to check or not

my 2 cents

[Jofers]

My 2 cents:
Dont change the syntax. Make a wrapper that, with an initialization, will create some virtual screen buffers and work as closely to the old as possible. Otherwise, there's no point in sticking with QB's ol' runtime names altogether.

...and on that note:
Is there some sort of syntax altering or function overloading or defaults for parameters?

[marzecTM]

no and the syntax thingy would introduce a nice package of sideeffects in the parsers, ask v3c hehe..

[Jofers]

Aw, phooey *kicks dirt*

[marzecTM]

so you think none of this proposals is suitable?

[adosorken]

When I developed my TinyPTC extension in VC, I created graphics routines that were pretty much the same as the ones QB uses. The only difference was that 32 bits were needed per pixel instead of 8, so an entire integer (the size of QB's LONG) was required per pixel.

marzec: some ideas:
- VB has a function called QBcolor, which returns a composite value of red green and blue for the sixteen default colors, as well as the RGB function which returns a composite value for any passed red green and blue. Perhaps for PSET, you can use these concepts. Those of us who're already very used to VB will be right at home with them, and new people won't have to fiddle with converting values.
- SCREEN: This is the method I used in OBDS...for any value of the first argument of 13 or lower, emulate the old mode of that number. For values higher, use the first argument as the horizontal pixels, the second for the vertical pixels, the third for the bitdepth, the fourth for the scanrate, and the fifth for the number of emulated pages (offscreen buffers). It worked beautifully.
- 8 bit color...well, that's a tricky one. For one, some people do like it for its ability to do fast color switching, but in Windows, 8 bit modes aren't particularly fast because of the color manager. What I did in my TinyPTC extension library is wrote routines which could alter the color information in realtime and display the same sprite raster data at any color level. (It really helped while implementing light depth for my raycaster...)

As far as I'm concerned...any NEW projects which are developed in freeBASIC won't be using SCREEN 13, so about the only good emulating legacy modes will be is in porting old DOS-based programs to freeBASIC.

[marzecTM]

i wouldn't think of thise like a legacy thing but rather a starting point for n00bs to get into gfx stuff. so i was not really focusing on qb compatiblity with my approach. it's more a completely new thing that only supports high color modes, making life easy for everybody. non will use 8-bit again after he's once used high color modes in win32 at least. so ....

[Jofers]

If it's something to get beginners started with graphics, then why not a wrapper the vaguely resembles dx or opengl routines? Like how Javascript is to other c-based languages. Best to move beginners a step forward, not a step back into 16-bits.

I guess if you really wanted an EASY set o' routines, just make some extentions to tinyptc that'll draw stuff into an array buffer. But Adsorken seems to have already tackled that.

I'd like to see some GUI libraries out there. Making API programs is a pain in the cahones in pretty much everything but Java and VB.

[adosorken]

Well, with TinyPTC, using buffer-based sprite routines is definately the easiest way to go about it (likely best as well, frankly), since TinyPTC already uses buffers for its display. The routines I wrote aren't optimized in any way, but if anyone would like them, I'd be glad to give them out.

By the way, I don't mean to be a semantic prick or anything, but it's spelled cojones, Jofers