musings on graphics support

[na_th_an]

two cents:

Emulating modes 1 to 12 may be... unneeded. I doubt someone is gonna code something in 320x200x2bits.

Anyhow, I'll be happy with a lo-res mode. 320x240xwhatever and you'll make my day.

[Jofers]

Nonono, I was saying "Pain in the lockers", a favorite expression of mine

Either way, if you can't alter syntax to support something like LINE (x1, y1)-(x2, y2) then it couldn't be implemented. Maybe one day I'll become an awesome programming and implement some kind of syntax extendor for FB.

[Dr_Davenstein]

I saw up there on the circle function you had:

Circle x , y , radius , color

Is there any way to draw ovals?

[Jofers]

I would say ovals coudl be another added routine. or read below about overloading.

Hey marzec, possibly vic by proxy: What about a way for missing parameters to be "undefined" or set to zero, like a DIMmed but not set variable? This is something many scripting languages do, but I'm one of those idiots who wouldn't understand if it's efficiently possible with compiled code.

Also, overloading might actually be a possibility with a preprocessor. It would definately take a lot of work, but while QB has a lot of babysitting routines it's still a semi-strong-typed langauge, and all unspecified variables that aren't declared are 32-bit floating point numbers. If variables and their types, along with functions and their parameter types could be detected by a preprocessor, it could replace those functions with the same name as an existing function with a generated name before compiling, so they'd be seen as two different functions. It could generalize number types for checking, so you couldn't get away with:

sub1 x%

and

sub1 y&

being overloaded, but it would help with two subs with different parameter lengths.

1) it would make it so you wouldn't need stuff like "angle2" or "print3"

2) it would make some more functions available for a "retroporting" lib, like SCREEN, LINE, CIRCLE and others.

3) such a routine could double as a syntax and type-mismatch checker for an IDE.

[marzecTM]

well since i've done the preprocessor i can tell you i won't go into that trouble, overloading and the like is much more then just that. i'd have to implement a symbol table with all the logic behind it for the preprocessor, again not worth the trouble. plus its definitely not the task of a preprocessor to do that. i guess you'll have to ask v3c wheter he wants to go into all that trouble, since overloading would introduce some nice other stuff in the parser, like detecting the correct function for a specific function call etc. etc.

on the optional arguments thing, again not the task of a preprocessor. there'd be two ways

1) optional arguments, solved from the right side like

sub somesub arg1, arg2, arg3

you could use somesub like this

somesub arg1, arg2, arg3
somesub arg1, arg2
somesub arg1

but not like this

somesub arg1, arg3

cause there's simply no way for the parser to tell what argument is the second one (either arg2 or three)

2) the vb way, given the above sub

somesub arg1=whatever, arg3 = whatever

and has again deep impact on the parser itself, and from my point of view it's not worth the trouble, but that's v3cs business so i really don't care heh

from a compiler point of view, the qb syntax is a pain in the ass. it has so many ambiguities, you just can't parse it without any hacks. and this is especially true for the gfx commands, not to say they introduce the worst ambiguities in what is called a grammar. things like the syntax of line can't be solved with the above mentioned two methods for optional arguments in a procedure declaration. so all those commands would become a hack inside the parser code of the compiler.


beside, honestly aren't the proposals of sterling and myself worth to be considered? i mean is it really that hard to think in that way or are the interfaces to hard to use? is anything missing? i still don't get the point, from my point of view there's everything that should get a n00b started on gfx programming. if one wants to dive into that topic more deeper he/she'd use a real gfx lib i guess...

[dilettante]

2) the vb way, given the above sub

somesub arg1=whatever, arg3 = whatever

The VB way also includes:

somesub arg1, , arg3

[marzecTM]

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.

you're joking are you? first i don't get the 16-bits thing. do you mean all those old ega modes should not be offered? yeah i agree on that. but the thing on the wrapper that "vaguely resembles dx or opengl" that must be a joke. don't you think that would overwhelm any newbie? i mean when starting gfx stuff would you start of with 3d gfx? i don't think so. plus the dx api is not really intuitive i'd really stay away from that interface design, plus it's object orientated, so it's not suitable for fb (atm, right v3c? hehe...) though i have to admit a 3d gfx wrapper around opengl would be neat, though hard to achieve cause i don't think you can abstract that opengl interface further

[Jofers]

woo-hoo, back on the defensive.

A symbol table wouldn't need to know whether someone put in:
sub1 arg1, arg3
or
sub1 arg1, arg2

Because that's something that's physically impossible. That would end up with an error being reported because the function is defined twice. However, you could do something like this:

sub1 arg1$, arg3
or
sub1 arg2, arg3

Because the goal would be able to tell types. Etiher way, Im jes' brainstorming.

I'm not a fan of default values. If something isn't passed, it should be either undefined or sparking an error. Anyhoo, if something like that gets done, I'd do it myself, that ain't no feature request.

As for graphics, openGL and DX do more than just 3d graphics. Well, maybe not openGL, but dx and SDL have equivalent functions to make porting easy, so it's not a horrible idea to make a library that resembles them.

Getting around object orientation is easy, just use a typed handle which library routines could understand.
Instead of:

x->something();

have

something(x_handle);

That, or with pointer functions you might be able to fake something. But whatever. I mean, you could model it after the GDI, really. Just something someone's going use in the distant future, instead of the runtime of a compiler for a completely different operating system. "dx and opengl" was just a blurb for "major libraries used by 32-bit programs", because they're going to have to use something along those lines when they stop using a beginner's library. And there's a lot of ways to simplify those libraries while keeping the basic structure.

BAH, it's late. and Im' tired.

[adosorken]

On the subjects of ovals and whatnot...ovals (ellipses) are pretty easy to draw. I used Bresenham's algorithms for all my libraries. All the code's in either BASIC or C (check out Useless Sock for a BASIC example). It's pretty effective and quite accurate.

[Jofers]

Yup... and for an even more satisfying result the bresenham algorithm can be used to make wu circles.


....


I don't know how that's important, but I felt like saying it anyways.