By the way tr1p1ea, a good trick to make smoother screenshots would be to slow down your programs to about 30 times their original speed, take a capture then speed it back up to the original speed in VirtualDub. Just make sure that the screenshot speed remains as accurate as the calc, though. This is what I do with Nspire screenshots when I want quality, because I can't get more than 7 FPS on this computer for such animated screen captures, but luckily the Nspire emulator supports slowdowns.

Ah I see now. Thanks for the info.

As for the screenshots just make sure to link to them, though, if you make any like that, else they will be like 8 MB large

Yeah true. By the way how do you make them now? Do you manually edit them frame by frame? Because that must be long!

Oh I see now. I guess that works then. And yeah a port of the 3D engine would be nice. Please don't go too overboard on 3D features, though, because many inexperienced programmers and new community members will go nuts when seeing screenshots of more advanced projects then all start trying making 3D games, even though they have zero experience in 3D and that BASIC is slow. Even in Axe we have yet to see proper 3D games (non-raycasting/mode 7 I mean)

I guess you could just write a BASIC+xLIB program that showcases the polygons and your 3D routine, to show its potential. Can we chain polygons like with sprites?

As for text, you could always just re-use the sprite routine but via a different syntax (assuming, for example, that text is made of 8x8 sprites containing 7x7 chars), eg:

real(666,X,Y,Stringoftext,<NumOfCharPerRow,TxtColor,BgColor,DoYouWantToSwitchGRAM>

1) Anything after Stringoftext would be optional and if BgColor isn't specified it would be transparent by default.
2) X and Y could be any number from 0 to 159 and 0 to 119 respectively, not just multiples of 8. This would allow people to do special effects with text such as scrolling, shadows or bold text.
3) Idk if chars per row would be hard to implement, but it could be handy for people with RPG boxes. Anything you display outside the current GRAM area would be clipped.
4) For the font, if you go with 7x7 this allows a max of 20x15 chars at once in the screen.

Then comes the problem of displaying variable content via such text routine. Some people might want to show HP/MP, so what you could do is:

1) If user displays a real var instead of text or str var, just display that number instead as you would do with the BASIC Text command
2) If user displays ONE element from a list, do the same as in BASIC
3) If user displays ONE element from a matrix, do the same as in BASIC
3) If user tries to display anything else (such as an entire matrix or even a pic), trigger the ERR:DATA TYPE msg or do nothing.

Else, if it's too complicated, you could always only show content from the Ans var, nothing else.

Yeah I guess that could work too. Also good idea about the background lol. Actually I guess this makes sense since most people will display text over a window or the map anyway, so on a window he already has a background setup anyway.

Hopefully this works (posting from my phone). Anyways, my idea was to be able to draw text vertically and to also be able to treat a string like a 2D array and given a height and width argument, extract a row or column (with clipping). This would be useful for text based tilemaps, but this is just an idea. This would probably be a better idea applied to drawing a single row or column of a tilemap. I hope this makes sense!