Yes, like that, DJ, but keep in mind it will never be more than 1 pixel behind. That GIF is very exaggerated. Broadcast television is interlaced.

Depends on the framerate we get, though.

I doubt we'll be seeing any live action games for a while. Turn based RPGs wouldn't be so terrible, though, since you can just render your effects directly.

I think that the last TI-83+/84+ ASM RPG ever completed was in 2004.

Wow, that seems pretty crazy.

I tried to write a routine to take a 768-byte buffer of the form we currently use for B/W display and from my calculations, it can manage 20FPS at 6MHz. I was trying to get a head start on making Grammer compatible

I did some other calculations in class and I have some good news The current LCDs are very slow and cause a big speed bottleneck for ASM games. At 6MHz, it takes about 55 t-states between LCD writes and at 15MHz it takes about 135. On the new LCDs, in a discussion with calc84maniac, I learned that every output/input to the LCD costs an extra 3 cycles. Even so, using the new screen is faster for most sprites at 15MHz. Before I learned about the 3-cycle cost, the routine was faster for every sprite that was 89-pixels wide or less (even faster as it got smaller, compared to doing it on an 84+). I think 16x16 sprites will be pretty popular to deal with the larger screen and because it gets a pretty decent speed boost.

What does this mean? Combined with the ability to shift the screen left/right with z-addressing, we could make some pretty fast side scrollers and having enemies on the screen shouldn't be too bad.

Also, people were talking about CaDan last night on IRC and the question of bullets was brought up. However, remember that with the old LCDs, we typically copied data to a buffer in RAM (the graph buffer) and then copied to the LCD. Then for bullets, we would use another buffer to store their locations. With the new calc, we will be copying directly to the LCD and we won't need to worry about LCD delays (except the 3-cycle thingy). So we could probably easily manage an average of 100 cycles  per bullet. That is less time than it would require to draw a byte to our current LCDs o.O This is great news for things like Grammer's particle engine because this means that it could handle the movement of 150000 particles per second. 150 000 ! Now I am starting to get excited

EDIT: Although, with each of the particles, it would probably take about 150 t-states to also compute collisions and choosing a direction to move, so that would actually be more like 60 000 particles per second. So 1000 particles could be handled at 60FPS with multiple colors

Looks like someone is working on a jezzball port, from that pic.

Are you sure there's not backwards compatibility? It sounds really backwards compatible to me. The only things messed up are drawing commands. Most programs that TI cares about would work just fine.

Some existing BASIC programs will be compatible; no existing assembly programs will be (although some very simple assembly programs will simply need to be re-assembled with a new header file.)  Put it this way: there was more backwards compatibility between the TI-83 and 83+ (or even, arguably, between the TI-82 and 83+) than between the 83+/84+ and 84+C.