Huh it does seem that the 2 sprite is slightly off I'll fix that

Oh, okay. I get it now
I thought it was half for some arndom reason. I see why I'm wrong now.

To initialize the memory, do you have to use Zeros(?

When I say initialize, I mean create the appvar.  The command for that is getCalc("appvName",size)

Good idea, I think i'll move it.  Some of the ideas are applicable, but its really only for Axe and Asm.  Do you think I should sticky it?

Ah yes i see now, we need to be able to write some sort of Flash to C compiler

Considering the current way I am "playing" the video by showing a stream of images

Isn't that exactly what video is? o.O

Virtual Pixel Testing

We all know about the basic command Pxl-Test() right?  It tests a pixel on the screen/buffer and returns whether or not the pixel is on or off.  This seems simple enough, but actually can be used to provide some fairly quick alternatives to using matrix based collision detection.  Not only are we eliminating the need to a matrix, but by simply drawing to the screen, we have already generated the data we will need for collision.  Eliminating the Matrix, as well as the time needed to spend writing to it, mean that pxl-testing is a formidable way to speed up your Basic or Axe game!

But, there are some issues with this.  What happens when your game requires tiles that might not be solid black?  We run into problems fast if we have complicated graphics, and have to resort to complex trickery in order to get collision to work.  One option is to have a single pixel in each tile of a tilemap be the indicator on whether or not the tile is filled or not, but this is hardly a perfect solution.  What if we wanted to be able to detect alternate things?  Like for instance certain tiles might slow down your character, or make them enter a swimming animation. Certainly we can’t assign properties to all of the pixels of a sprite, that would be both slow and limiting in the graphics we could choose.  The solution lies in Virtual Pixel Testing.

A virtual pixel test is a test that behaves like a pixel test, but returns a value that doesn’t have to do with the pixels color.  Instead, it has to do with any attributes that the pixel has.  If we make this simple, we can have the virtual test determine whether or not the pixel is solid or not, independent of its color.  We could even expand this to return a value that relates to something like friction or temperature.  But how to implement such a function?  In this tutorial, I am going to be focusing on Tile Based Virtual Pixels, and Mask Based Virtual Pixels.

Tile Based Virtual Testing:

Say you have a tilemap, for any sort of game, sidescroller, top down, platform, you name it.  Chances are some of your tiles are going to need to be solid.  Now up until now, you have might gone by using some tricky byte testing mixed with modular arithmetic, wishing it were as simple as using a pxl-test() command.  Well, using virtual tests, it can be just as simple:

Lbl TST
{r2/8*W + (r1/8)+L1}
Return
Given a byte based matrix array located in L1, that represents a tilemap with width W, this function will return the tile number associated with any given pixel.  Note that r2/8*W is essential, r2*W/8 would not work.  

This simple function, coupled with clever ordering of your tiles, can make for very simple collision checking.  When you design your game, order the tiles so that all the solid ones come first, followed by all of the empty tiles.  This way, checking for a solid tile is as simple as a comparison test.  

Lbl TST
{r2/8*W + (r1/8)+L1}<N
Return
Where r1 is the X position, r2 is the Y position, N is the tile number where your empty tiles start, and L1 is the location of your matrix data buffer.

Using this routine will allow you to test a pixel and either get the tile number associated with that pixel (which could tell you any number of things) or test whether or not the tile is solid.  Using this information for accurate physics is now easier, and will be addressed in a later chapter.

Masked Virtual Buffer Testing:

This is all fine and dandy for tile based physics, but what about tiles that are not square?  Say you were making a sonic game, and you needed ramps and loops and things like that?  How could you modify this code such that it would work correctly?  The answer lies in Masks.

All a mask is, is an alternate sprite that tells you where your main sprite is solid.  If this is your normal sprite:

-------O
------OO
-----O-O
----O--O
---OOOOO
--O----O
-O-----O
OOOOOOOO
A simple ramp like sprite, then this is your sprite mask:

-------O
------OO
-----OOO
----OOOO
---OOOOO
--OOOOOO
-OOOOOOO
OOOOOOOO
Note that your regular sprite can be any design it wants to be, and your mask is black where it is solid and white where it is not.  The code for testing this is as follows:

Lbl MSK
{{r2/8*W+(r1/8)+L1}*8+(r2^8)+Str1}e r1
Return
Where r1 is your X position, r2 is your Y position, W is the width of your tilemap (in tiles), L1 is the location of your matrix data buffer, and Str1 is the start of your Mask Sprite table.

Your mask sprite table is identical to your sprite table, but instead of normal sprites, it includes the masked sprites.  This code will return the value of the bit in the mask sprite where your pixel is located, which can make for pixel based physics and terrain, in a tile based world.

What to watch out for:

Make sure that instead of using a variable W, use a constant!  Also try to make sure it is a power of 2, as this makes for very quick and simple multiplication.  You can further speed up both subroutines by changing the /8 into /2/2/2, although this will create an increase in size.  Also, the e in the mask operation is the euler's constant e found on the divide button.

Also note that all of the code in this lesson is based on the assumption that your pixel coordinates are based off of the upper left hand corner of your matrix, and that your matrix follows the left-to-right moving-down standard.  It also assumes you are using 8x8 sprites, although 16x16 sprites would not be difficult to accommodate.

Cellular Automata

Cellular Automata is described by a grid of pixels, where each pixel has a certain amount of rules determining what happens to it.  The Game Of Life is a great example of this type of simulation, but how can this be used for physics?  Using pixel based rules is a great way to simulate large scale effects that would normally be difficult to program.  Things like fluid dynamics, sand, fire, and acid, sounds complicated?  Well all of these things are possible with cellular automata, and will be covered in this tutorial on how to use pixel rules to simulate all of your effects needs.

We are going to base our tutorial off of the water simulation, since that is a simulation that will cover the basics of everything else to come.  Water sounds like an extremely difficult thing to implement on a calculator; it’s so dynamic and hard to define!  How would you even go about storing the data?  Well cellular automata provides a great method for us to solve this.  First, we need to come up with our expectations:

1) The water must be affected by gravity
2) Water must flow

Now that we have our expectations, we need to find some rules that we can apply to our pixels.  In our simulation, each pixel will represent a small part of water, and each pixel will move corresponding to our rules.  I would like to introduce a 3rd rule:

3) Pixels cannot intersect eachother!

This is very important!  If one pixel moves itself onto another pixel, those pixels merge and become a single pixel, and we will lose a small piece of water.  This is fine if that’s what you want, but we want our water to stay at a constant volume, we don’t want to lose any pieces of water.  So no matter what, if a pixel moves, it must always move to an empty space!

With this, we can devise some simple rules:

Rule # Condition Action
1 Space below empty Move down
2 Spaces to the sides empty Move either left or right
3 Single empty space to a side Move into that empty space
These rules are followed top to bottom.  This means that first rule 1 is checked, if the condition is satisfied, we do the action.  If not, we move onto the next rule and continue.  If no conditions are satisfied, the pixel stays where it is and we move onto the next pixel.

That’s it!  Those are the rules!  Simple rules right? And yet they can yield surprisingly advanced responses…



Pretty impressive eh?  Let’s look at some other sample rules that we could apply:

Sand:
Rule # Condition Action
1 Space below empty Move down
2 Space to the bottom-right/left empty Move to that empty space
Fire:
Rule # Condition Action
1 Space above is empty Move up
2 Space above is filled Move left/right
3 rand<.05 End life of this pixel
Acid:
Rule # Condition Action
1 Space below is not Acid Move down
2 Spaces to the sides is not acid Move either left or right
3 Single non-Acid space to a side Move into that empty space
Note that these are not the only way to achieve the effects desired, this is not a precise art, and many different rules can be applied to achieve many different effects, the best way to find out what works is to try everything yourself!

How To Use It:

Well that’s nice, how do I implement this in my program?  Well, it would be tempting to rely on pixel commands alone, but a more elegant solution is to have a list of pixel locations, and to loop through them.  This allows for better speed and a larger area of simulation.

Here is some sample code in Axe format:

For(F,0,N For N+1 Pixels
D*2+L1->L Find their location in L1
{L}->X X location in first Byte
{L+1}->Y Y location in second bytes
Pxl-Off(X,Y

If Pxl-Test(X,Y+1) If ground below is solid
  Rand^2*2-1->A Choose a random direction
  !If Pxl-Test(X+A,Y If that direction is empty
    X+A->X Move there
  Else!If Pxl-Test(X-A,Y Else, if the opposite direction is empty
    X-A->X Move there instead
  End
Else
  Y+1->Y If all else fails and ground below is empty, move down
End

Pxl-On(X,Y
X->{L}
Y->{L+1}
End
Note that this code won’t work by itself; you still need a way to put the pixels into L1, and to remove them.  You will also need to create the environment and everything, but this I leave up to you.

What to look out for:

I presented an option to store the pixels in an array, which takes a fair amount of memory.  It is tempting to just work off of the screen as a buffer, and loop through every pixel on it, but there is an inherent problem with this.  Not only does it limit the size of your screen, but the fact that you are either going to pass through the screen left to right, or right to left, introduces a bias into the simulation that might make fluids tend to flow left, or for smoke to drift right.  The results are unpredictable, and unless you know that the rules you introduce will not interfere, and that you have a small enough space to keep speed up, you should stick with the pixel buffer.

As would I, there are some things Axioms can't do