musings on graphics support

[marzecTM]

i agree on that, that special syntax for some qb cmds suck if you come from another language...

[adosorken]

Most people are used to QB's graphical libraries, and the format for such things is never along those lines. I say it would be best to go with something like PSET x, y, c. But hey, that's just one hack's opinion.

[Z!re]

It would be more consistent with the external libs and DLL's if you go with
pset x, y, c

instead of
pset (x, y), c


Or
line (x1, y1)-(x2, y2), c, [bf], [pattern]


But then again, it all depends on how much compatibility you want.

[Neo]

Maybe you can just make a convertor which changes any of the following...
PSET (x, y), c
PUT (x, y), z, zz
GET (x, y)-(x, y), z
LINE (x, y)-(x, y), z, zz, zzz
CIRCLE (x, y), z, zz, zzz
... etc ...

to their "better" alternatives. Something like a special QB Special Syntax Preprocessor.

[marzecTM]

well, i guess pset x, y, c is the best thing, people should get used to use libs, and no lib will come with special syntax like the one the qb gfy libs have. so i'd stick to normal proc syntax.

btw, i find it funny that people want object orientation like stuff and the like but can't cope with a slight change in syntax. the qb to fb porting argument is none existant cause in my opinion most of the qb stuff is obsolete with the introduction of libs like ogl, sdl and the like.

[Sterling Christensen]

I just realized my idea doesn't address the "-" in "LINE (x, y)-(x2, y2)" - d'oh! Oh well, yeah you guys are right.

I've done some work and the library is [edit]missing[/edit] CIRCLE, DRAW and a lot of other commands but otherwise functional, but is there any point in finishing it? I guess it won't be that much trouble to port QB graphics to whatever else. This library is only useful is you're really, really lazy...

So far the C library can do this:[syntax="c"]BasicSDL_Screen(13); /* also sets QB palette */
/* or: BasicSDL_ScreenEx(320, 200, 8); /* same, but leaves SDL's default 8 bit palette */

BasicSDL_PsetA(100, 100, 15);

/* Draw a bright red line from (100, 100) to (150, 175) */
BasicSDL_Color(12); /* set default color */
BasicSDL_LineR(50, 75, USE_DEFAULT_COLOR, LINE_TYPE_LINE);
/* LineR = Line with 1 relative coord */

/* Draw a dark blue box */
BasicSDL_LineAA(10, 10, 400, 300, 1, LINE_TYPE_BOX);
/* LineAA = Line with 2 absolute coords - there's also RA, AR, RR, and A */[/syntax]
Which is equivalent to:[syntax="qbasic"]SCREEN 13

PSET (100, 100), 15

COLOR 12 ' bright red
LINE -STEP(50, 75) ' from (100, 100)-(150, 175)

LINE (10, 10)-(400, 300), 1, B[/syntax]
This would convert to FreeBasic code very similar to the above C code, looking something like:

Code:

Screen 13

Pset 100, 100, 15

Color 12
LineR 50, 75, USE_DEFAULT_COLOR, LINE_TYPE_LINE

Line 10, 10, 400, 300, 1, LINE_TYPE_BOX

And if FreeBasic supports optional parameters, those constants could be omitted for even easier porting.

[barok]

btw, i find it funny that people want object orientation like stuff and the like but can't cope with a slight change in syntax. the qb to fb porting argument is none existant cause in my opinion most of the qb stuff is obsolete with the introduction of libs like ogl, sdl and the like.

It'd probably be the fact that people who already have projects in the works that use those commands probably don't want to have to replace 100 pset, 20 line, 50 circle commands for others.

[marzecTM]

that's a point

[Jofers]

There is one final option. Make

"(x1, x2, x3)" a syntax for parsing array data.

Code:

dim x(0 to 2) as integer
x = (1, 2, 3)

(x1, y1)-(x2, y2), but "-" could be also be defined as an array concatenator, when dealing with arrays.

[v3cz0r]

Can't do that, Jofers.. () is already used for function parameters, array indexes, passing by descriptor and will be a pain to parse arrays of function pointers, like: funcptrTB(a,b,c)(a,b,c).. and so on..


If allowing ()- into GFX statements, a new parser routine will be needed for each one.. there's no other way..