Next version of xLIB - features?

[dysfunction]

masking might be more useful (I am aware it can be done with the current xLIB, but it's kinda awkward). it could be made way easy - give parameters for 2 sprites instead of 1, one of them being the mask..

Not really, once you grasp the concept of masking in the first place it's easy enough.

[King Harold]

ofcourse, but it could be easier, and probably faster too..

[jimmothy]

idk, all it takes is 2 commands to mask a sprite, its not hard at all and i consider myself an xlib noob. and you cant really sense the speed difference between non/masked sprites. It will be a bit easier, but it seems unecessary.

[dysfunction]

Yeah, and you'd have to add more arguments to the sprite command to tell it where the mask is stored, it just isn't worth it.

[ProphetsDementia]

It would be so awesome if xLib was able to switch the greyscale pixels using XOR and OVER logic in ONE real( command!

Also, it would be nice if you could enable and disable the ON key with a real( command.

[Halifax]

wait? Wasn't there a big discussion on grayscale in xLIB. IIRC it was decided that it wouldn't be possible/it wouldn't be good enough. Although I would want to see grayscale in xLIB as much as the next guy I agree and I really don't think it is possible.

[ProphetsDementia]

tr1p1ea, go to ticalc.org and search for 'Program Options'. Look at it's functions and integrate them with xLib.
Please?

[DJ_O]

What's new in xLIB 0.602b? o.O I just discovered there was a new version (last one was 0.601b)

[tr1p1ea]

Just some bugfixes, i uped the version since there were some different 601b's floating around.

[DJ_O]

ok good, because i was posting a news about it on Omnimaga since nobody did when it was updated in march and I did not even knew what was the update about so i just said to update anyway

[Demon]

Three other programs that could be integrated or from which features could be implemented from:

ERRH by Benjamin Moody - executes a string of BASIC; returns any errors in X and 0 if no errors.

Celtic by Iambian - Lets you read and modify programs and appvars.

Omnicalc by Detatched Solutions - There's some useful functions Omnicalc does that xLIB still won't do yet like the play() command.

[calc84maniac]

And ExecAsm. That's useful. Not to mention LinkSend and LinkGet (or whatever they're called)

[dysfunction]

Hmm, I was wondering, just how compatible is BasicBuilder with xLib? Does it support 256 pics?

[kalan_vod]

Well, I know of several games that use both and they work...I am unsure if there are any problems, as I have never tried them fully. The bowling game is a BB app, and it uses xLIB.

[dysfunction]

Ok, tr1p, just one more question... Some of these questions I've been asking are ones I might have asked before, I'm not sure, it's been a while since I used xLIB so now I'm finding problems I might already have found solutions for and forgotten. Anyway, the CreatePic function automatically updates the screen when it is called. I've noticed a number of xLIB games (ReubenQuest for one) have to render a map or a map section into pics for faster display later for various reasons- ReubenQuest needed the speed for its grayscale, for example. This would be useful for my own coding as well, but it's annoying to have to turn the contrast all the way up so the user can't see as the pics are displayed and stored. It would be much better to be able to display a loading screen, then render your map without updating, run CreatePic (which I've found does take from the graph buffer rather than what is actually displayed on the screen), and repeat as necessary- all without updating the display after showing the loading screen. So, would it be possible to make it so CreatePic does not update the lcd, or even give it the option of whether or not to?