Went ahead and posted the cap in my first post for those who are interested.
Anyway this cap relies on a formula I'm not even completely sure how it works, but it does. The formula can be found here.
Obviously, a few tweaks were made since this formula is meant to give the location of points, not objects with rotations; not mention the formula makes the center (0,0) instead of the top left. The formula for rotations was mostly guesswork, although it wasn't much different than it was for the single-axis-3dcameras that occasionaly permeate this board.
I should mention,there's a bit of a bandaid coding with camera pitching. The camera actually starts pointed at the sky (Or is it the ground?), if you catch my drift. It was a bit easier to code that way.
One of the big downsides to having a psudo-camera is that is makes rotating objects on a world basis with more than just yaw a huge challenge to implement with the tools construct offers. Since world rotations come before camera induced ones and construct is limited to a yaw-pitch-roll order of rotations, you can sanely do Yaw(Wld+Cam)-CamPitch, but not Pitch(Wld)+Yaw(Wld+Cam)+Pitch(Cam).
Python and Speed
Python has really been a timesaver, it's kinda nice being able to find and replace small parts of code without turning all of it into a warzone. The other great thing is that done right, it works with families, so I could possibly even make a formula and apply it to all 3d objects, sprites, and boxs, with only 3 lines of code.
Although from what I've heard, behaviors and plugins are the faster and less intensive. So I would probably say that any large project would definitely need them, either that or real 3d camera support.
chris, I would really like to see what inventive thing you cook up with this, and I would have no problem elaborating further on this and some other little experiments I've done if you're interested. <img src="smileys/smiley4.gif" border="0" align="middle">