I can do that, I just changed the height of the camera sometime between those two screenshots. The one you mentioned was taken with height = 16, and the last one I uploaded was at height = 2. Actually, when I plan on doing texture mapping, what is each square ATM will have a whole texture in it.

Here's a screenshot with height = 32:

It should run at about the same speed no matter how large the map is, possibly a little slower because there would be more cache misses with a larger map.

I'm pretty positive you could get a nice speed boost if you used one of the many available fixed-point math libraries in C, especially if the program messes around a lot with floating point data (the ARM doesn't have an FPU).

I am using my own 16.16 fixed point number routines in most of the code. It should be faster than using a library because I can write only the features I need for this.

Maybe, but I doubt it is faster. Many of the libraries use very clever hacks, such as this one that even uses ARM assembly.

As promised, here are some textures! I also made movement dependent on the direction the camera is facing, rather than a fixed direction for each key as it was previously.

Thanks! I haven't been using nSDL, so I just switched to reading the timer directly. However, back when I was using SDL_GetTicks(), it was returning zero on the emulator as well.

Thanks a lot! That's some pretty damn clean code, it's a pleasure to read/mess with.

EDIT:
Purely for viewing pleasure, a CX color version:


And some on-calc footage to see how it runs:

(I edited a few lines to get it working with nSDL and got about 6 FPS extra at the same time)

It runs at a rather constant 28-31 FPS on CX (could certainly be pushed further if it was optimized for 16 bpp) and 45-47 FPS on Touchpad when the whole lower half of the screen is filled.

EDIT2: I added the TNS if somebody wants to play with it.