Maybe it's possible to premultiply the textures, but for 4 different levels of light that's already 2MB for a 512px texture. I don't know, maybe in a later version.

I was going to suggest exactly this. Keep in mind that (I believe) a lot of people are happy with the original 16px textures, and with those you could have copies of one texture for all 16 light levels in only 8KB. Of course, if you implemented this for all block types it would start to add up, but it would still only be about 2MB for basically every block in current Minecraft, which includes far more block textures than you'd need with the current set of blocks supported.

Also, hi. I normally don't tread outside of 83+/84+ threads, but this is the one thread that I make an exception for and keep track of because your work on this is awesome. Out of curiosity because I don't have an Nspire and couldn't see the statistics anywhere in recent posts, what's the performance of this like relative to the draw distance?

the stuff is this:
nib{E+1*2+1}->D
({L5+11} and D=D and ({L5+10}>=nib{E+q*2}) and (N={E}))?{E+3}->{L4+{E+2}}

Yup, the issue is in the "stuff with E". To read data from inside your program/application, you want to use nib{}^r. The nib{} command with no modifier always reads from the $8000-$FFFF address range (RAM), whereas the command with the modifier always reads from whichever range your code resides in: still $8000-$FFFF for programs, but $0000-$7FFF for applications.

I was curious, what's the distribution of the 10KB of RAM needed? That sounded like a lot to me, especially considering this had to be a BASIC game that resided in RAM itself in the past.

I'm not convinced that using a custom display routine like that would really save you that much speed. The only possible merit would be if it runs at 15MHz, and that's still a small one.

At 6MHz, even if nothing changed between one frame and the last, my best efforts at prototyping a fast diffing display algorithm that also clears the last frame buffer resulted in something that still runs in about 2/3 of the time that Axe's standard DispGraphClrDraw runs in. That may sound like a big speed boost, but when you take into account the other processing that has to be done each frame, it really isn't. Assuming the current framerate is relatively low (<=30) and that's why you were searching for this boost, the framerate would only improve by about framerate/3 percent; 30fps would become 33fps, 20fps would become 21.3fps, and 10fps would become 10.3fps. The total percentage gains only start becoming substantial above 30fps, but if the framerate is above 30fps, you don't really need the gains anyways.

At 15MHz, it might be worth it. With my prototype algorithm, if nothing changed between one frame and the next, it would run in about 1/4 of the time that Axe's standard DispGraphClrDraw runs in. With a relatively low framerate (<=30), it would improve by about framerate*4/5 percent; 30fps would become 37.6fps, 20fps would become 23.1fps, and 10fps would become 10.7fps. But keep in mind that these are numbers for the best case scenario, in which nothing at all has changed between frames. Even if only a quarter of the buffer bytes changed, I suspect those gains would be about cut in half. If about half of the buffer bytes changed, the gains would probably be cut down to a quarter.

In conclusion: you'd probably be better off spending your time looking for optimization potential elsewhere, namely in the graphics rendering code itself. If you want to fill me/us in on the kind of computations that are done for graphics on an average frame, I/others might be able to give some ideas.

Be sure to send the App and all three Appvars to your calc. The Appvars must be in archive.

Is there some weird reason behind this? Because the GetCalc(NAME,FILE) command for reading from archived variables has also worked with variables in RAM for a while now.

In order to re-adjust the greyscale you must delete the appvar GS

Just map a key to the GTune() function. Alternatively, you can be a bit more bold and make your own contrast/grayscale controls, in which case I'd advise checking out the source of the GTune() function to see how to properly change contrast and grayscale delay.

Are ports 25 and 26 actually bank-specific? I don't see that suggested in their WikiTI documentation, and my hunch was that they weren't. The default values of 10h and 20h seem to make sense with what areas are normally executable.

I read somewhere in the topic that you used to have an 8*9 Reuben sprite for the map. I can hack Axe's sprite routine in two seconds if you want so that you can use it because it looked better IMO.

I can confirm that any sprite routine can be hooked into to support variable height for probably about 40-50 bytes (per routine, although there might be a clever way to combine them).