I'm for polygons and mesh.  This, folks, is the same kind of 3D you get on a computer!  I would vote there, too, if I were you.

The question is, could you get a polygon engine to run quickly?

Admittedly, it would be sick. But unfortunately its uses would be limited due to its inability to be used in realtime games. That's why I voted for Mode 7, it's probably the most reasonable option in terms of realtime usage.

Done

I think it should be fine. Such thing needs to be fast enough so I think the space it takes is worth it.

Btw, are you gonna use Calc84maniac mode 7 engine or are you making your own? His ran at like 20-30 fps I think, if not more. I think it was on SE, though.

As far as 3D stuff goes, I at first voted mode7 but then revoted for polygons. I think polygons can be done if you don't have too many at the same time. I think it is just awesome if we could work with them! I can already imagine a on-calc model creator-viewer that stores models into appvars. I guess using the OP registers for the vertices would be the fastest?

mode7 has my second vote if there is such a thing. In terms of speed I still do recon it faster then poly's but it is 'less 3D' then the poly's.

Now here I am just gonna suggest something that is maybe out of bounds but I'll say it anyway. How about a combined mode7 and poly's? can you imagine a character (poly) walking around in a mode7 world? All the structures and trees would be poly's but the basic ground texture could easily be a mode7 'texture"

I am really looking forward to this!

On a side note I personally would like different tokens for Axe then for basic, but that is just me having hard times switching between the two.

If you are planning those, I've always wanted to use recall like the homescreen.
For instance, pushing [2nd]+Recall should open the same text dialog, but should let you type in more than one token and execute it, and recall the answer.  I've wanted to do [2nd]+Recall length(Str1 but have never been able to.

I just thought of something really useful that I can't believe I didn't think of before.  Its the fact that 256³ = 64⁴.  The reason that's so important is that the labels, subroutines, and pointer names were all being stored as 3 byte entries.  Once byte for the type and 2 for the characters of the name itself.  But since I'm only using a few possibilities; letters, numbers, and theta, I can get away with storing that data in only 6 bits per entry instead of the full 8 bits of a byte.  So now the 3 bytes I was using in memory can suddenly hold 4 entries!  That means that all labels and pointers can now be up to 3 letters long instead of 2.  That one extra character actually allows you to spell comprehensible pseudo-words like sub(BUF) or Lbl MOV.  This wasn't a feature I was planning to add, but I just couldn't stop myself once I realized how easy it would be to do.

I don't think I will ever have enough RAM for the 7 character label names like I was planning unless I use the extra ram pages so this will have to do for now, at least its an improvement.

Also, I changed my mind about the Axe include files.  They will need a special header beginning with 2 periods instead of 1.  That way, you still have the Axe Tokens and eventually the Axe Editor to use when writing the subroutines.  But the extra dot will conveniently make them invisible from the compile list.

Didn't I read a while back that you might support filenames with more letters if some of them were lowercase?  Like LoseTheGame could also be called by sub(LTG)