I would assume that basic is out of the question. But axe is definitely do-able.

You should also check out, LZ77, I didn't read the whole pucrunch article, but LZ77 seems a lot easier to do. I used it in Z-Rox and it cut the program from 15k to 7k. It cut the pictures from 13k to 5k. It also does RLE natively.

I don't think I am going to add flags because there would be no reason not to use them. In the real game, when you start using flags, you lose the awesome music, which is really the whole reason you want to go farther, and get some elevator music.

My game would have no reason not to use the flags aside from the that it takes the fun out of the game.

lol why didn't I ever think of that. Much better.

Edit:
   This messes with the 6 bits per sprite if you were to look at it closely, but the way the calculator runs, no one would ever notice.

i liked it, but i got a RAM clear right after i played it  

Did you play it in DCS? There is a problem with the extra ram page usage that I recently pointed out to kerm martian.

Edit:
    Anyways, here is a version that shouldn't crash.

We have collision detection. Although, it's only with the blocks, and instead of dying, a black line appears at the bottom.

Ok that's good.

I don't know the inner workings of axe, but couldn't you change the last letter of the source name to something random, like B or %, archive it, remake the source program, and copy the source back from archive? That way, the backup would always be there and would not require any extra ram to create.

You could then have an option to restore backup.

Edit:
    Better yet, just change it's type to appVar, no name changing required.

Ya, it looks like that's just going to be how it is. I made a quick demo of my idea in the previous post with the intentional grayscale and it didn't work well.

The reason this was a problem is because I basically have a fixed frame rate I have to use. My goal is to have this game exactly match the real one as far as speed, which requires the 50 fps. It also has to move 2 pixels per frame because I don't like the idea of having no frame of margin on hard jumps if I were to go 3 pixels per frame.

For all you googlers out there. Here's the newest official version with screenshots of all the levels.

And here's the actual newest version with a screenshot of the full new level here.

---

The next game that I want to make is the impossible game. This game is originally from xbox live and was ported to iPod. So now I will port it to Ti.

Here is a youtube video showing you what the game is like.

I was not going to actually post this game in the projects forum, but I need some help. Everything was going very well in creating the game, 2 days in and I already have the map engine and jumping. The graphics were really smooth, 50 fps at 2 pixels per frame. It was going so well that I sent it to my calc to test it out.

Then the problems started. The calculator screen obviously doesn't respond as fast as wabbitemu's and the whole game was grayscaling. So I am basically stuck now. The screen just isn't really responding the speed that I need it to. All the sprites were two light, so I double imaged them, (made them look as if they are stuck between two frames), and now they are two dark.

Does anyone know any cool lcd tricks or am I just kind of out of luck?

Btw, the reason I had this problem is that the newest version of wabbitemu glitches for me, so I use the last stable (83).

The first clip is how the game looks theoretically, the second is how it really looks. Don't forget to use firefox.