Next version of xLIB - features?

Moderator: tr1p1ea

User avatar
dysfunction
Calc Master
Posts: 1454
Joined: Wed 22 Dec, 2004 3:07 am
Location: Through the Aura

Post by dysfunction »

Heh :lol: Seriously, I don't want to push, just whenever you get around to it.
Image


"You're very clever, young man, but it's turtles all the way down!"
magicdanw
New Member
Posts: 30
Joined: Mon 16 Jul, 2007 7:02 am

Post by magicdanw »

I've got an idea for a feature. It might not make sense, since I haven't done any grayscale programs, but I think it might make sense. Every other line, you need to call a function to cycle the grayscale bits. What if there was a function to load a list of bits to cycle, or a list of functions to run, or whatever, and then you would only call real(xx every other line, instead of real(xx,yy,zz or whatever. XLib would keep track of the place in the bit cycle it was up to, instead of taking new info every line. This way, the basic program would be smaller, the grayscale function parsing would be faster, and higher-quality grayscale might be possible. It would be closer than before to having a real grayscale interrupt, like in assembly code.
User avatar
dysfunction
Calc Master
Posts: 1454
Joined: Wed 22 Dec, 2004 3:07 am
Location: Through the Aura

Post by dysfunction »

Well, here's the thing- for 3-level grayscale in basic, all that happens is one of the layers is repeatedly displayed using xor logic, so it 'flickers' on and off, resulting in grayscale if you do it fast enough (only fully effective with an SE's speed). I don't really see what function xLib could incorporate to make that simpler/faster, besides incorporating a full-on grayscale interrupt routine.
Image


"You're very clever, young man, but it's turtles all the way down!"
magicdanw
New Member
Posts: 30
Joined: Mon 16 Jul, 2007 7:02 am

Post by magicdanw »

According to a basic grayscale guide I found on ticalc.org, every other line you need to use a command like "real(20,8,0,0,96,62,0,0" to flip the bits. What I'm saying is, there should be one command that tells xLIB that you want to use the parameters 8,0,0,96,62,0,0, and then you call real(20 every other line, with no more parameters. That way, the basic program is smaller, and it is faster for xLIB to read the other 7 parameters from an appvar in single-byte format than to convert the 7 parameters from TI's real format into single-byte format every single line. Maybe even fast enough to support it on non-SEs?
merthsoft
Extreme Poster
Posts: 496
Joined: Tue 21 Dec, 2004 6:49 am
Location: WI

Post by merthsoft »

That actually could be useful not just in that sense. Maybe have a command that has two arguments, the first being the number of commands, and the second a string of these commands, each on separated by "/" or anything, really. And then you have another command that you pass the number corresponding with that command, so, for example (not using any real commands or anything, just making up numbers):

Code: Select all

CommandList(4,"1,2,3/4,6,5,3,4/7,6,2,3/1")
Command(2)
Command(3)
Command(0)
Command(0)
Command(1)
And that be equivalent to:

Code: Select all

real(7,6,2,3
real(1
real(1,2,3
real(1,2,3
real(4,6,5,3,4
Obviously I know that they wouldn't be called CommandList and Command, but that was just so you knew what I was talking about.
Shaun
magicdanw
New Member
Posts: 30
Joined: Mon 16 Jul, 2007 7:02 am

Post by magicdanw »

Well, that would be more difficult that what I suggested. This would involve dynamically creating some way of looking up functions and parameters, which might even be slower than originally, I'm not sure. At any rate the data would probably have to be written to an appvar for storage, and accessing the appvar is slow. My suggestion above (despite the fact I said it could be in an appvar, which was a bad idea since they'd be slow to look up every other line) would involve storing 7 bytes to some saferam. xLIB already uses saferam, so I'm sure 7 bytes could be found somewhere.

Merthsoft, your idea might be possible, but I just think that it would slow down the commands, which is bad, even if it means the program is smaller. My idea, while more limited, should only be able to make the execution faster, and also make the program smaller.
User avatar
Demon
Regular Member
Posts: 85
Joined: Wed 31 Jan, 2007 12:11 am
Location: (806), Texas
Contact:

Post by Demon »

Has someone (or I) already suggesting adding some way to let people do arrays and array functions with strings?

If not then that is my suggestion. And if someone (or I) have, then this is a quote for empahsis. :P :)
"Python has dynamic typing, and dynamic binding, which means that not only does it make a great secretary, it is also pretty damn kinky." --Henry the Adequate

<My Artwork>
magicdanw
New Member
Posts: 30
Joined: Mon 16 Jul, 2007 7:02 am

Post by magicdanw »

Hmm. Well, there are something like 255 possible strings on the calculator. What if there were an assembly program that could store to and retrieve from each string, using a variable to specify which string you wanted. Then, you could use Strings 1 through 0 (10) as normal strings, and Strings 11 through whatever (using the program) as a one dimensional array, or two one dimensional arrays, or (with some math) multi-dimensional arrays. It shouldn't be too hard to do this. I think I'll add it to my list of ideas for CalcUtil.
User avatar
DJ_O
Calc King
Posts: 2323
Joined: Mon 20 Dec, 2004 6:47 pm
Location: Quebec (Canada)
Contact:

Post by DJ_O »

magicdanw: that guide was actually for Omnicalc, not xLIB. I did it but I need to update it because XLIB app didn't existed back then.

Basically I don't think there should be a grayscale command for xLIB, it's just easy to just use the rclpic command after every one or two BASIC commands to switch bits back and forth. Plus if you make your game for the SE and are good enough you can even manage to get 4 or 5 level grayscale
ImageImageImageImage
magicdanw
New Member
Posts: 30
Joined: Mon 16 Jul, 2007 7:02 am

Post by magicdanw »

Oh, sorry. I guess I didn't read the guide as closely as I should have. Still, how many arguments are needed for the xLIB rclpic command? I maintain that it is still faster for a function to be called with one argument than 8, it is still faster for an assembly program to read a byte out of ram than to pop 9 bytes off the stack and then convert to a one byte number, and it is still smaller to have four bytes every other line than 20 bytes every other line.
User avatar
DJ_O
Calc King
Posts: 2323
Joined: Mon 20 Dec, 2004 6:47 pm
Location: Quebec (Canada)
Contact:

Post by DJ_O »

4
ImageImageImageImage
magicdanw
New Member
Posts: 30
Joined: Mon 16 Jul, 2007 7:02 am

Post by magicdanw »

Ok. Well, it'd still be faster and smaller if you could store the data as single-byte numbers and call a function with one parameter. I'll leave it up to the author to decide if the function is worth adding. I think it is.
merthsoft
Extreme Poster
Posts: 496
Joined: Tue 21 Dec, 2004 6:49 am
Location: WI

Post by merthsoft »

So is what you're asking for then a recall function? So everytime you call it, it just recalls the last command? IF so, that would be cool too, but I think my idea might be applicable too, though if an AppVar is slow, maybe store commands in a string, and then tell the command what string to execute. You said yourself that there are a lot of them, so that wouldn't really be an issue.
Shaun
User avatar
calc84maniac
Regular Member
Posts: 112
Joined: Wed 18 Oct, 2006 7:34 pm
Location: The ex-planet Pluto
Contact:

Post by calc84maniac »

Appvars are the same speed to access as strings.
~calc84maniac has spoken.

Projects:
F-Zero 83+
Project M (Super Mario for 83+)
User avatar
DJ_O
Calc King
Posts: 2323
Joined: Mon 20 Dec, 2004 6:47 pm
Location: Quebec (Canada)
Contact:

Post by DJ_O »

would a recall command be much slower than the recalled command? Because then it would screw up grayscale
ImageImageImageImage
Post Reply