I'll make a page on the different Axe releases.

I'd be in on this. Maybe I could help a bit with designing it? We could use the Wikimedia template.

Then we can share routines, etc. and access them more easily.

...or entire source codes. 

wat?
stallman's up to no good again...

My speed worries are over, thanks to optimization in collisions and the code leafiness gave me. It looks like it will run in 6mhz! In this update, I've gotten orb collecting and enemy collisions working.

I now am done with the final level design of the first act: Razor Forest. I'm hoping to make levels similar to the ghost houses in Super Mario World, in that they will try to make you get lost while playing them. I plan on being especially cheap with some of the later levels. 

On another note, I tried using crabcake, but Axe told me that AxesOn and AxesOff were invalid. I had to to compile it as an app in this case, because it crashed otherwise (it's over 9,000 bytes in size). Was there something I was doing wrong with crabcake?

Thanks everybody. I've now gotten gravity to work on enemies, and doors now work. I've got four rooms set up right now temporarily, but that should soon change. Something that is very evident in the screenshot is the difference in framerates between the 24 x 16 rooms with enemies and the 12 x 8 rooms without them. Does anybody have any suggestions for helping to stabilize the framerates? Keep in mind that this is still running at 6mhz.

Well, I'll try to help you out here.

To put it simply, a tilemap is a grid of numbers, like a matrix. Depending on the number of each element of that grid, a different tile is drawn. For example, here's what a 4 x 4 grid would look like:

1111
1001
1001
2222

'2' might represent a ground tile, while '1' would maybe represent a regular block, and '0' would be air (so nothing would be drawn).

The tiles can be read by a for() loop. Then, they would be drawn to the screen based on the modulus of the width (remainder of division by the width (for example, 13 modulus 8 would be 5)), and the and the floored (rounded down) division of the number that the for() loop is on and the width. These numbers are then multiplied by the dimensions of the block.

Here's an example: let's use the above grid again.

1111
1001
1001
2222

Let's say in this hypothetical situation that we have a screen that has dimensions of 32 x 32, and we are using 8 x 8 blocks (for simplicity's sake). Let's figure out the coordinates for the second block on the second row. That would be the 5th block out of 15 (since it starts with 0 and goes to 15) in the for() loop. The x value would be 8, because the modulus of 5 and 4 is one, and multiplied by 8 is 8. The y value would also be 8, because the floored division of 5 and 4 is one, and multiplied by 8 is 8. Although, nothing would be drawn, since the value of that block is 0.

For scrolling, an offset is just subtracted from the x and y values. I use the variables z and theta to do this.

Please let me know if I can clarify anything.

Another small update: I've gotten the enemies to actually move at this point. I've also added in death animations and a life count (which is why the program ends after three deaths). However, I'm having a bit of a dilemma. Though the program is running alright right now, the keys are beginning to act a bit unresponsive due to lag. This will be made much worse with other additions to the code. I'm still trying my best to optimize, but at this point there's not too much to optimize left. I'm considering making this a 15mhz game, but should I also release a watered-down 6mhz version alongside of it? Thoughts?