musings on graphics support

[v3cz0r]

Can't say much about the gfx atm, sorry.. loads of things to add yet :/ Other than the COLOR() function should be RGB(), as in VB, PB and such


QB gfx statements aren't that hard to parse (compiler can be expanded to n look-ahead tokens, it's not locked to 1), but getting gfx as is done in DOS in a multi-threading platform is quite hard.. most gfx libs need a flip() for example, so you don't draw directly to the frame buffer, as you do in QB, but to a back-buffer.. i'll let Sterling and marzec find a solution ;)

[Sterling Christensen]

I think there is a need for at least 3 graphics libraries in FreeBasic:
1. Something powerful, for knowledgeable programmers
2. Something simple, but "vaguely resembl[ing] dx or opengl routines" for beginners to learn/grow into Windows/Linux graphics
3. Something to make old QB gfx programs easier to port, and to make PureQB™ beginning QB programmers a little more comfortable, something not too different

I think external libraries can fill the need for #1 and #2, and that the built in graphics routines should be along the lines of #3.

[dilettante]

3. Something to make old QB gfx programs easier to port, and to make PureQB™ beginning QB programmers a little more comfortable, something not too different.

I wonder how long before QB is just a fond memory among old-timers though? This project would seem to lead to a serious thinning of the ranks of those still needing it.

[Sterling Christensen]

I wonder how long before QB is just a fond memory among old-timers though? This project would seem to lead to a serious thinning of the ranks of those still needing it.

You're right... maybe FreeBasic would be better off without any built in graphics commands? Or more modern ones instead?

[Jofers]

Maybe. It's still pretty easy to have an interpreter and a nice IDE without having to install anything.

It'll definately be a challenge to get a legacy program to run in a thread without a fuss, though, vic's right.

[barok]

Maybe someone should make a new library that has support for qb's graphic commands? That way if someone wants to run pqb graphic demo's they just have to include a pqb library.

[Sterling Christensen]

Maybe someone should make a new library that has support for qb's graphic commands? That way if someone wants to run pqb graphic demo's they just have to include a pqb library.

That sounds like a better idea, but you'd still have to change stuff like:

Code:

PSET (x, y), c

to:

Code:

PSET x, y, c

...unless...

Hey, v3cz0r, suppose you made it so that for any set of parameters in a sub call, this:

Code:

PSET (x, y), c

and this:

Code:

PSET x, (y, c)

are the same as:

Code:

PSET x, y, c

That way you could use QB-gfx-command-like syntax with any graphics lib, and those who prefer not to won't be forced to. I'm sure with the right approach it might not be too difficult or require any weird hacks or anything. Please? Pretty please?

[dilettante]

Or maybe a nice project might be to develop a QB -> FB import filter as a standard part of the eventual FB toolkit. Sort of like the thing Microsoft has for importing VB6 into VB.Net?

[Jofers]

Yeah, at this point that seems like a better idea. QB's got so many different syntaxes I wonder how that even worked.

[Marcade]

Maybe someone should make a new library that has support for qb's graphic commands? That way if someone wants to run pqb graphic demo's they just have to include a pqb library.

That sounds like a better idea, but you'd still have to change stuff like:

Code:

PSET (x, y), c

to:

Code:

PSET x, y, c

...unless...

Hey, v3cz0r, suppose you made it so that for any set of parameters in a sub call, this:

Code:

PSET (x, y), c

and this:

Code:

PSET x, (y, c)

are the same as:

Code:

PSET x, y, c

That way you could use QB-gfx-command-like syntax with any graphics lib, and those who prefer not to won't be forced to. I'm sure with the right approach it might not be too difficult or require any weird hacks or anything. Please? Pretty please?

Hrmm I personally don't like the statement of
PSET (x, y), c and PSET x, (y, c) being the same as PSET x, y, c

I don't know about C/C++ or Pascal .. but the foreign languages I am working in at my work, (y, x) is seen as an array. (I think in Perl this resembles an array too?)

So if I'd see PSET (x,y), c .. I'd see 2 parameters; one being an array and the second one being an integer.

I'm kind of against this idea. Might also give some trouble in the future when expanding freebasic maybe (?)