Well you could pack multiple columns into 1 write?

Would the array work if I made it 8 times smaller? Do you guys think its crashing because of lack of memory?

I am not sure exactly what method you are using. But trying to copy an extra-large array to the LCD ram would probably overflow to other sensitive memory.

My guess is that each memory sector is 65536 bytes, right?

(such array would most likely be 76800 bytes large, unless I am wrong, right?)

I have no idea how the flash memory on the Nspire works, actually. Though, we are talking about RAM here, which isn't really in "sectors". And the array would actually be 38400 bytes, since there are 2 pixels per byte.

Yay! I implemented double buffering, and its much less flickery now. For some strange reason , though, it flickers and becomes choppy when you get near a wall.

Screenshot:


It runs a lot smoother on-calc than the screenshot makes it seem (why won't CalcCapture give me a higher framerate?)
I've attached a demo.

I think texture resolution shouldn't affect speed, since the loop that does the texture mapping depends only on the height of the column I'm drawing.
Speaking of texture mapping and speed, I think I figured out the cause of the slowdown when you get near a wall: the columns become longer, so the engine needs to do more texture calculations. I guess my texture mapper really needs optimization

This could be passed of as a flash game or something...

That looks really good.  TI calculator programming has entered a new era

I already have texture mapping--those checkered squares are an 8x8 texture map.