Cool to hear . 20x14 sprites will be handy (or of course in the case of text sprites any size, but won't take as long to render).

2 wide pixels? commodore 64 emulator, anyone?

Calc84maniac, do you think you could release a 8xp program for BASIC programmers allowing them to change the screen position and resolution directly from BASIC programs? You could put the program in Omni archives along with ticalc.org ASM misc programs:

If X=1, it would change resolution to 160x240.
If X=Anything else, it would change resolution to 320x240.

Ans would contain the screen position (which I assume would be 0 to 319 in 320x240 mode and 0 to 159 in 160x240 mode). So basically the syntax would be something like this (kinda like other libraries):

1->X:159:Asm(prgmZSCRNRES

Just did a quick mockup of what a game could look like at 160x240 resolution using the full color depth of the calculator and it definitively doesn't look bad:



And of course for side scrollers, you just have to make the HUD as minimal as possible then shift the screen starting position to scroll around. There might be some shaking occuring during scrolling for the HUD before it gets updated to its appropriate position, but it would be much faster to display 8x16 sprites than 16x16.

True, although for a Mario game this might be annoying to play

True. Although I think a lot of action games based on platformers might require smooth movements to prevent hindering gameplay. For example, try to play Sonic the Hedgehog at 4-8 frames per second while still being able to control Sonic properly.

Also besides 160x240 resolution, since the speed bottleneck is really drawing to the LCD, you could sacrifice display quality further by using 160x120 mode instead. In 160x120 mode, however, you would need to only update every 2 line of pixels on the screen to gain speed at all:



It may not look super nice, but since pixels are kinda small, it might not be that bad either. Some graphics might sometimes need to have higher contrast so it's not too dark, but this would not be the first time that such technique is used in games, since some old computers did as well.

In the example above, you could go further by using interlacing as well, alternating between odd and even line rows every frame.

In the case where someone would still want to use 160x240 with such technique, interlacing or moving scanlines would be necessary.

So basically, to update the entire game area for vertical scrolling, speed would max out at the following values:

320x240: 4 FPS
320x240 interlaced: 8 FPS
320x120: 4 FPS
320x120 drawing every 2 line: 8 FPS
160x240: 8 FPS
160x240 interlaced: 16 FPS
160x240 scanlines: 16 FPS (might be annoying for the eyes)
160x120: 8 FPS
160x120 drawing every 2 line: 16 FPS

Scanline mode would be kinda useless because it would require shifting the LCD position back and forth between 0 and 160, so you might as well go with interlaced mode. Plus I am unsure if many people would like if their games looked like this:

On a Nspire CX it would be so fast that it would look smoother but on the slower 84+CSE that's how fast the scanlines would alternate.

Then there is also the Starwing/Star Fox and Stunt Race FX trick on the SNES: Not using the entire screen for the game. If you play Star Fox for the SNES, notice how there's a big black frame surrounding the gameplay area. Gemini for the 83+ did that too.

Personally, I think the non-moving scanlines look quite good. However, that animated one won't look good at all, mostly due to the fact that, like our computer screens, the 84+CSE has an active LCD matrix. (I think. Most color LCDs are, but some older ones weren't and you never know with TI )

To sum things up, what I noticed is that on the CSE the scanlines are vertical instead of horizontal, so it's possible that it wouldn't affect the display methods above. The screen, unlike on the Game Boy Advance and TI-Nspire CX, was rotated 90° inside the calc it seems.

KermM figured that out long ago based on the datasheet for the driver, which is specifically designed for portrait-orientation LCDs. Hence why the WikiTI page on the LCD has this warning:

For those following along with the data sheet: Like before, the X/Y plane is flipped in the data sheet documentation. Specifically, the the screen is rotated 90 degrees from the way the manufacturer expects, so "horizontal" and "vertical" refer to the OTHER, i.e. horizontal means up and down on the screen. Also, "up" and "down" are switched with "left" and "right".

This is also why we select interlaced mode for the double-width pixels hack. If the controller scanned the other way, it would generate double-height pixels.