musings on graphics support

[na_th_an]

Oh, cool, thanks no prob for the explanation, the part I didn't get is why was that a problem, but now I understand, sorry

If you really want to add support for 32 or 64 bits styles, I'd go for an extra parameter or whatever, or, to make it more VBish, define a structure which contains info about what kind of style will be used, whatever suits you more:

Code:

DIM style AS StyleType

style.format = STYLE_16_BITS
style.value = 38482

LINE (0,0)-(100,100), , style

That way would eliminate compatibility, though... I don't really know. I think that the easiest thing is adding support for 16 bits patterns just for legacy. I've used those things for fonts and even for sprites.

If you are gonna alter the syntax to allow more functionality, you could use the extra parameters to especify not just 16 or 32 bits, but any number "n" between 1 and 32. The bit pattern would loop after "n" bits are drawn.

[Jofers]

Well, I've been thinking again about using comma delineation for lists. In the idea, PSET would actually look like this:

Code:

pset (x, y), c

sub pset(pos(), c)
    x = pos(0)
    y = pos(1)
    realpset x, y, c
end sub

Here's vic completely valid point:

Code:

dim x(4) as integer;
x = 1, 2, 3, 4; 'valid, is is now an array with values from 1 to 4
y = mysub(x, 5) 'valid
z = mysub(1, 2, 3, 4, 5) 'perfectly logical, INvalid.

function mysub (param() as integer, param2)
    mysub = 123
end function

But is this really so bad? I mean, would it be a bug if a compiler read that as an error? After all, this would still work mathemetically parsing:

Code:

z = mysub((1, 2, 3, 4), 5)

Now, this comma delineation would be a "list", going by perl definitions here. The list would be the same kind that is going into a function, but if it was assigned to a variable, it would simply attempt to copy each value to incrementing indices. (0, 1, 2, 3, 4).

Now, LINE(x, y),-(x2, y2) is a little harder to implement.
My original suggestion was to create a vector type. This is really unfeasable, though, as it would have little use other than graphics syntax. A more reasonable suggestion, is array concatination.

After all, string concatination is this:

Code:

mystring$ = "1234" + "5678"

So now, if you have:
dim x(4) as integer
x = (1, 2)-(3, 4) ' is the same as...
x = (1, 2, 3, 4) ' this

AAAAAAAANYWAYS. If you're not going to incorporate the increasingly odd-seeming syntax into a functional part of the language, then it's best not to incorporate it at all. No 16-bit modes, or whatever. If array notation can't be done, then the best way is simply a qb syntax converter and a retroqb library.

[Sterling Christensen]

I think v1c said that if he supported "PSET (x, y), c" syntax, it would be with a custom parser. I got the feeling he wasn't talking about anything fancy like a new array notation or anything like that.

[Jofers]

Yeah. I know. Vic can do whatever he wants, that's how'd I'd do it, and might do it if I ever find the time to learn how to do it. But probably won't do it.

[Jonathan Simpson]

na_th_an: I personally love the idea of having a user defined repeat on the patterns. I've used style for a few things myself, and while there are certainly other ways, it's just something I've grown used to... call it my "style"

I'm following this forum and this program closely, I think there is something big going on here.

[Z!re]

How about a command/whatever that can return the bit lenght of a variable...

a% would be 16
a& would be 32

(In QB that is, FBs integers are 32bit.. but anyways)


Then you could just use byte, short integer, integer, long integer, whatever as the line style parameter...

It just wraps around...


Also, a function to return number of bits would be useful to allow users to send any value to a proc.

Code:

Sub Blarg (a As Any)
If BITS(a) = 16 Then [...]
If BITS(a) < 0 Then string?
End Sub

Negative numbers for strings perhaps?, a 8 char string would return -64... i dunno... would be nice to allow unicode or other strings too...

Like..

a$ = "a"
Len(a) 'would return 1
Bits(a) 'would return 8 for standard ASCII, or 16 for UNICODE, depending on what you have specified...

[v3cz0r]

Yeah, it's easier to do at the parser, for each quirk gfx statement, probably will make other module just for that, there aren't too many anyway, PSET, POINT, LINE, CIRCLE, GET and PUT - forget PAINT and DRAW, you got filled circles, elipses, boxes, reading from VRAM (that's is needed with PAINT) is so damn slow that it isn't worth adding support for that.

Adding support for Perl-like array constructions would make it too complex, temp array must be created to pass by reference etc.. so painful as it was to add var- and fixed-len strings.


(btw, you can declare a proc argument as ANY, but the proc itself can't have any as ANY arg - same as in QB)

[Jofers]

how about just a function for determining types?

if typeof(var%) = "integer" then print "integer" ' 32 bits

or

if var% as integer then print "integer"

etc. or something of that sort. a little more useful and logical than just bit length, and you can still use it for stuff like line functions.

[v3cz0r]

All vars would have to be Variant's or then objects to be able to do that.. or if FB was an interpreter, it would be simple to do ;)


But yeah, writing proper runtime lib wrappers at the compiler, you can call different versions of on functions depending on the variable type passed.. that's what i did for PRINT and SWAP, for example..

[Jofers]

Ah so. I always wondered why typeof was in crap like "C#", Javascript and Java, but not in other languages.

But I suppose I'll hold off asking for an "eval"

Hey, this has probably been asked, but will there a "short" type or "word" or something to replace the 16-bit INTEGER?

EDIT: Now that I think about it, it shouldn't be terribly hard to make a typeof function with error trapping anyways. Be a wee tad slow for all practical purposes though.