Grammer 2-The APP

[nxtboy III]

Yes... But what if you wanted to make the tiles not tiles, but pixel-by-pixel?

[Xeda112358]

It would take a lot more memory, but if you wanted it to still be speedy, too, you could make several buffers containing the data in layers. For example, 3 buffers could make each pixel in 8 different states. To better save on memory, you could store the location of a few pixels and what they do in memory and just check to see if the region does anything. You could still use tilemaps and not the command. For example, I made a maze like program that used 6x6 tiles and a buffer that contained the values for those regions. The program would manually draw the stuff, but it was easy to see if you were on a warping tile or a tile that would kill the player or whatnot.

[nxtboy III]

Just wondering, exactly how long does it take to use pxl-test in Grammer?

[Xeda112358]

I just ran this code and it took 8 seconds to pixel test 10 000 times:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6

0→X→Y For(A,0,9999 pxl-Test(X,Y End Stop

That was in 6MHz, too

EDIT:40 seconds to do 60 000, so about 1500 pxl-tests per second

[turiqwalrus]

I just ran this code and it took 8 seconds to pixel test 10 000 times:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6

0→X→Y For(A,0,9999 pxl-Test(X,Y End Stop

That was in 6MHz, too

therefore about 5 seconds to check the entire contents of the screen(not as if that's actually needed)

[Xeda112358]

I just tested on my real calc and all the pixel commands are that fast
EDIT:
it takes about 4 seconds to fill the whole graph screen using Pxl-On( which is 6144 pixels (also at 6MHz)
Using math is what will slow it down, though It takes 7 seconds if I use Pxl-On(X+1,Y+1

And about 10 to 11 seconds when multiplying by 65535 (the slowest multiplication)

[nxtboy III]

Wow, so it takes about 1.25 milliseconds to do pxl-test.
On a similar thing for pxl-test on my NXT, it takes around .48 milliseconds. How fast does it go running at 15 Mhz?

EDIT: On my NXT it takes 1.221 seconds to fill the screen with going just pixel by pixel.

EDIT2: So how does PARTEX2 run so fast with so many particles??

[Xeda112358]

It takes about 1.70 seconds to fill the screen at 15MHz. As for Partex2, I just wrote the code to be fast. It reads the coordinates from an array and pixel tests as needed. To update a particle, it just changes the coordinates and draws accordingly. I am actually going to rewrite it to be faster, hopefully. I made a grayscale version over spring break, but at 2000 particles, it definitely could not do grayscale It did not look bad at all, actually, but I still want to see if I can speed up the process

[Yeong]

* TBO_Yeong thought new Grammer came out

[Xeda112358]

Sorry I am trying to think of what I can easily tackle or fix for now

[nxtboy III]

So it reads from a map and an array? Why not just one?

[Xeda112358]

I am confused... A tilemap is an array...

[nxtboy III]

oops....  I meant to say that it reads from the screen (pixel data) and an array?

[Xeda112358]

Oh, for the particles. Yes, it has to read from both so that it can interact with the environment. There is a particle buffer and screen buffer. The particle buffer interacts with the screen buffer That is how it flows around static objects

EDIT: I refer to the particle array as a particle buffer.

[nxtboy III]

So are the particle location's stored in a variable (array of locations)?