It's kinda weird since each VAT entry is a different size, but to go to the next VAT entry (backwards), here's what you do. I haven't tested it yet, but it should work.

If A is the VAT pointer pointing at the first byte of the current entry, first subtract 6 to get to NL (the byte that tells you the length of the name of the VAT entry):

Code: (Axe) [Select]

:.A is currently at the first byte of the VAT entry
:A-6→A

Then subtract the value stored there, which should move you to the end of the VAT entry:

Code: (Axe) [Select]

:.A points to a value that tells you how long the rest of the VAT entry is
:A-{A}→A

Then subtract one more to get to the first byte of the next entry:

Code: (Axe) [Select]

:.A is at the end of the VAT entry
:A-1→A

To put it together:

Code: (Axe) [Select]

:A-6→A-{A}-1→A

For more info, here's a page that tells you how the VAT basically works.

Umm, I don't think that would work... That's just another way of doing what Quigibo's code that goes to the next entry does.

Here's a 16-frame rotation for the captured ship sprite SirCmpwn made. The rotation kicks the corners of the sprite out 1 pixel in each direction, so the resulting rotation occupies a 9x9 space, which might be a little tricky to account for. No single sprite is bigger than 8x8, though, so you could try to deal with it by fitting them all into 8x8 sprites and then displaying some of them shifted 1 pixel in the x and y directions.

Just wondering, because every time I see this topic I wonder... why 50x50? It might just be how the interface is set up that allows for a 50x50 space for this, but it bugs my semi-OCD side that the X value isn't a multiple of 8

just found something cool. if you *really* don't have any temp variables to exchange two values, the following code should do the trick:

Code: [Select]

. "xor" is the 16 bit plotstyle-box xor, not the actual word xor.
A xor B->A
A xor B->B
A xor B->A


Woah, that's a neat trick! I never thought of that. But you could optimize it a bit

A xor B->A xor B->B xor A->A

I'm not sure how _InsertMem and _DeleteMem work, but couldn't they mess up data pointers in the VAT? I thought they were used only in edit buffers.

Seeing that there's a bcall called InsertMemNoUpdateVAT, I would have to assume that InsertMem (and DelMem) automatically update the VAT.

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...

I got ninja'd before I could even post. I had the sprites done for my attempt, I was just making a fancy animated GIF so you could see how well they animated.

int ntg = myRandom.Next();
I believe the problem exists with this line, as you don't specify a range to choose the number from. Without specifying a range, ntg will just equal a random 32-bit integer, and the probability of that being in the range of 1-30 is about 0.0000007%.