Wow the new 32x32 bit textures look great. I would highly suggest studying the code from the FAT engine, it was able to render 64x64 bit textures on a 10mhz calc (although it was only rendering to a 96x96 pixel screen), you've got a lot more processor speed to work with, despite the fact that your engine uses the whole screen, I think you could use some of the optimization concepts from that engine in your code.

Also do you  have a maximum distance for rendering coded in yet? if not you could glean a few FPS's of speed from not even bothering with tiles that are outside of that distance. You probably have, but that's just a thought. At a certain distance and beyond, the walls would all render as a single pixel in each column, so there's no real need to calculate anything at that distance and beyond. It would make more sense to just render a pixel.

Also after a certain distance, you could just abandon textures, and just render the wall as a solid color, like black would be good, because it would appear that you just couldn't see that texture, and it would probably speed things up a bit.

Just a couple of thoughts. I tried writing a raycasting engine for the HP50g once, and only managed to make a really fish-eyed representation of the walls, and only in one color, so I think your expertise in these matters severely outweighs mine

Good work! Keep it up! It won't be long and I might be working on a Wolfenstein port for the nSpire.

Im checking this out as soon as possible! It sounds awesome!

If only the programmers of the offending malware and viruses and such spent their time more effectively and usefully by programming games like us!

Good to know dude, It's also good to have a social life in real life as well as online. I for one know how hard it can be to juggle the two effectively. When things go wrong in real life, my activity level usually plummets online.

Well in Portal i believe i used 1/64 pxl per frame per frame, but it depends heavily on your frame-rate.  The best way to find a good acceleration is just to run some tests.  As a general rule you don't want your player moving too fast because that makes collision very difficult.

Sometimes you can get around the collision detection issue with fast motion by pre-calculating the next position, and calculate where it would actually collide if it were going point by point, then simply change the position of the object to that collision point, thereby bypassing any graphical glitches you might have in your detection. It can be a pretty simple section of code within your collision detection subroutine.

What I would really like to know is how you solved the problem of implementing angular momentum in addition to gravity when you come out of a portal from another direction. I was having a time trying to figure that out.

EDIT:

I read back over some of the tutorial, it says you're doing a section on collision detection, I'm interested to see what methods you have to implement this and what kind of uses you're going to cover. It can be a really tricky thing, especially in an environment like Portal, any 3D environment, or any environment involving uneven surfaces or curved objects. I'm sure you've got a few tricks up your sleeve from what I've seen you do so far.

There's always TIEmu if you don't have an 89, you can download it here:

TIEMU

Also, you'll need a flash OS for the 89 available here:

TI-89 OS

If that happens we will all stand behind you because we know the real story. Good thinking though Kev.

All is going better! In fact, I have a release for the public.

http://www.tifreakware.net/atg/DOA_BETAS/Release-3-10-2010.zip

If you find any errors, have any ideas for improvement, or any general constructive criticism then please let me know. Also if you like something then let me know that too please! thanks!