Oh, yeah, I guess Fill(0->{A},10) isn't that much more code than Fill(A,0,10)...

By the way, Quigibo, would 1->{_E86EC}^r be exactly the same (e.g. speed, size, etc.) as 1->A?

If you mean _E86EC, and $86EC is the address of A, then yes. Note that you should be saying 1->{^oA}^r, though, to be future-compatible
Edit: ninja'd

Maybe... I'm not sure, and if Quigibo changes anything...

I suppose you could... but you would not be allowed to use the variables A-Theta in your program then.  You would have to use the r1-r6 variables and store the rest directly to another buffer which could be very confusing given that you have to write down what variable each address represents.

I've already moved all of my vars in-prgm. Bit more mem, but some of it's initiated, anyway. (That's why I asked the question, btw.)

What are r₁-r₆?

And another question: I noticed the GetCalc([NAME], [FILE]) syntax. Where are "files" stored?

And yet another question : Why is L₁ SaveSScreen+56? A-Z and theta are only 54 bytes... I heard that the last one's used for random numbers, though. How is it updated?

For me, i think an upgrade to the Fill() command is in order.  Usualy when people fill elements in RAM, they want to fill it with specific values.  But currently they have to put the value in the first element for fill to work, and this means you have to calculate the Address twice.  Wouldn't it make a lot more intuitive and useful sense (not to mention probably smaller) to do something like Fill(Address,Length,Number) ? that could even be an alternative syntax if you wanted backwards compatibility.

Yeah I think it should work like in BASIC. That's unless it is much larger of course.

Holy crap that was a huge storm of sudden posts Just to make sure you didn't miss it Quigibo, did you see my feature request for vector/jump tables?

I deleted it

J/k, but the ironic thing is that there was a huge storm of posts, then now tonight, there's a huge storm of 500 Internal Server Errors, even thought almost nobody was posting

Lol as said in my post I was kidding, unless you mean the 500 server errors?

New request (I think):
Line(X₁,Y₁,X₂,Y₂,)^r.  Lines draw directly to the back-buffer.

Also I'm not sure how hard it would be but might there be a third buffer sometime in the future?  Not for grayscale, but pxl-test to it?  Something like this would really help me optimize the game I'm working on (In the sig it says I'm done, but I'm trying to make a more memory-friendly version for the 83PBE)

New request (I think):
Line(X₁,Y₁,X₂,Y₂,)^r.  Lines draw directly to the back-buffer.

Also I'm not sure how hard it would be but might there be a third buffer sometime in the future?  Not for grayscale, but pxl-test to it?  Something like this would really help me optimize the game I'm working on (In the sig it says I'm done, but I'm trying to make a more memory-friendly version for the 83PBE)

Ive already asked Quigibo for a line routine for the back buffer but maybe your second request for it will help better convince him to add it.

As for a third buffer, Quigibo is limited by the safe RAM areas that exist on the calculator and are big enough to hold 768 bytes, of which there are only three. L₆ and L₃ are two of them, and the third is at L₁-56. The first 56 bytes of this screen storage area are used by the random number generator and the 27 variables. If you wanted to use this area, you would have to avoid the use of the rand function and allocate some other place in RAM for variables (and any other data you might have had in L₁), possibly a different safe RAM area or an appvar. However, this is a bit of a pain, so what I would suggest is creating a 768-byte appvar for the third buffer when your program starts and delete it when exiting.


EDIT: How did I know I would get ninja'd on this one...