musings on graphics support

[VonGodric]

and one bye datatype?
other then string * 1?

[v3cz0r]

The data types currently supported are:

byte: 8-bit, signed integer
ubyte: 8-bit, unsigned int

short: 16-bit, signed integer
ushort: 16-bit, unsigned int

integer/long: 32-bit, signed integer
uinteger: 32-bit, unsigned int

single: 32-bit, fpoint
double: 64-bit, fpoint

var-len string: up to 2GB long
fixed-len string: ditto

Plus pointers to all data types, UDT's (Type or Union) with them and of course arrays, with unlimited number of dimensions.

if you don't lile "ubyte", "uinteger", you can use "unsigned byte", "unsigned integer" to declare them.. Blitz's idea..

[Sterling Christensen]

Update:
I need csrlin, pos, and print hooks, and it still doesn't ever set FB's ERR, Inkey doesn't repeat if you hold a key down, no INPUT or LINE INPUT, and SDL_gfx's ellipse code sometimes leaves gaps, but besides that it's finished.

EDIT: I forgot to mention, I added style support to LINE.

I'm preparing it to be released as an external library until v1c can integrate it into FB's runtime library (or until it's ready for that).

Something's been bugging me about it: When you GET/PUT, it has to create and free an SDL surface each time. And if the screen and the sprite are 8 bit, it copies 768 bytes of palette data from the screen's palette to the sprite's palette (this is a must, otherwise SDL will try to map the sprite's colors from the default palette to the screen's palette, which will be slow and ugly).

It seems fast enough on my Athlon XP 3200+/nVidia GeForce FX 5700, but the speed hit will matter a lot more on slower computers.

But even as I type this now I'm concocting a scheme to avoid all that. If it works, I won't have to create/free any surfaces each time or copy over the sprite surface palette. But I promise I'll release it an alpha version first rather than let this and other stuff delay the initial release further.

I'll try to upload it somewhere as soon as I can.

[na_th_an]

Great news, Sterling

[Sterling Christensen]

Btw, does anyone use or care about VIEW PRINT? Speak now or forever hold your peace...

Right now text can either wrap to and scroll in the entire screen or the viewport, or not at all (you can set it not to wrap or scroll).

If I did add VIEW PRINT (don't worry, it would be after I release what I've got so far - I'm sorry I'm so slow), it would optionally support pixel coordinates (or the old text row, column) like all the other text functions... Maybe it could be useful to have text bounded by a different rectangle from the one graphics are clipped to? I dunno.

[na_th_an]

I've used VIEW PRINT a whole lot in text mode, but never with graphics.

[relsoft]

Sterling: How about limiting it to just 32 bits. It would make things faster.

And for the line thingy, you could prolly do an gl_lineStripple something.

[Sterling Christensen]

Sterling: How about limiting it to just 32 bits. It would make things faster.

And for the line thingy, you could prolly do an gl_lineStripple something.

I already gave line a 16 bit style parameter, but that would probably be faster.