DJ_O wrote:
When using Z-address on the TI-84 Plus, does it automatically updates the LCD? If it's the case, then I assume that scrolling around will cause the part of the screen that is scrolled in to temporarily show up on the other side of the screen, right? (like on the NES)
The LCD outputs vertical scanlines from left to right, and the scrolling function changes which scanline it starts displaying from. Whether the old graphics that were scrolled in show up depends on whether that scanline is outputted before the game can write the new data. This is a general problem with any kind of graphics output though, it might be hard to avoid tearing completely when erasing/redrawing sprites or whatever.
DJ_O wrote:
When using Z-address on the TI-84 Plus, does it automatically updates the LCD? If it's the case, then I assume that scrolling around will cause the part of the screen that is scrolled in to temporarily show up on the other side of the screen, right? (like on the NES)
Yes, that's correct. It's the same idea.
As I understand it, it should be possible to limit the image display area using R60, so that (for example) an 8-pixel-wide area at each side of the screen is not displayed. Those areas would appear as either solid white or solid black, and meanwhile, the program could be updating the corresponding region of GRAM.
FloppusMaximus wrote:
As I understand it, it should be possible to limit the image display area using R60, so that (for example) an 8-pixel-wide area at each side of the screen is not displayed. Those areas would appear as either solid white or solid black, and meanwhile, the program could be updating the corresponding region of GRAM.
I'm not so sure, after all it says "The number of lines must be the same or more than the number of lines necessary for the size of the liquid crystal panel." So I think it might be there only for using LCDs with fewer scanlines. I guess we'll just have to test it out, though.
That was my understanding of that particular LCD register as well. Can I do anything with my TI-84+CSE to help us test out what happens?
Edit: I mean, I know what I can do, set a higher scan start position, but would that be useful to test?
I'd say anything is useful to test, as long as you share the test results
calc84maniac wrote:
I'd say anything is useful to test, as long as you share the test results
KermMartian wrote:
calc84maniac wrote:
I'd say anything is useful to test, as long as you share the test results
That is awesome, I was just wondering about this! I was thinking that for some games that use a small enough piece of the screen, we could keep another screen 'buffer' in the VRAM.
Yes, that's something DrDnar and I had been discussing on IRC a few days ago. There's something called a front porch/back porch, which we were hoping would let us store extra data off-screen, but closer reading revealed that it's related to the scanline timing of the LCD. This method would allow that, though, which is quite handy.
If for some reason you only used half the screen, could something like that be used together with the z-addressing to quickly switch between two screens, for example? I'm not sure what use that would be, though.
chickendude wrote:
If for some reason you only used half the screen, could something like that be used together with the z-addressing to quickly switch between two screens, for example? I'm not sure what use that would be, though.
As a matter of fact, you could! You could set up the middle 160x240 of the LCD as the viewable area, and use LR:60 and LR:61 to mask off the left and right sides of the screen. I believe that you could then use the Z-addressing to switch back and forth quickly? I could also be totally wrong on that. In addition, there is a feature called Partial Images, but we haven't explored that yet.
Double buffered display seems like it would be beneficial given the slowness of rendering. Even if the performance isn't *great*, individual frames should appear all at once, right?
elfprince13 wrote:
Double buffered display seems like it would be beneficial given the slowness of rendering. Even if the performance isn't *great*, individual frames should appear all at once, right?
If there was a way to double-buffer within the device's memory, yes. Any buffering outside the GRAM would be far from instantaneous.
Isn't that what essentially what we were just discussing, as far as Z-addressing and LR:60 / LR:61 are concerned?
elfprince13 wrote:
Isn't that what essentially what we were just discussing, as far as Z-addressing and LR:60 / LR:61 are concerned?
Yup, the only question is whether it will be feasible. There are some mode changes that require you to re-write the entire GRAM after the mode change, for example setting line inversion or switching between RGB and BGR mode.
"Require" is such a strong word. I'm sure what they mean is simply that if you don't rewrite the GRAM data, the colors won't be what you expect (most likely, the red and blue channels will be switched.) If your program only uses white, black, green, and magenta, that shouldn't be an issue.
FloppusMaximus wrote:
"Require" is such a strong word. I'm sure what they mean is simply that if you don't rewrite the GRAM data, the colors won't be what you expect (most likely, the red and blue channels will be switched.) If your program only uses white, black, green, and magenta, that shouldn't be an issue.
Can you define a window range such that part of it goes off the screen? I am wondering this because I am writing a sprite routine with clipping and this would simplify the code a bit. Also, for pixel-testing, do the coordinates get incremented when you read from the LCD data port? I am working on a few other graphics commands and it would be useful to not have the coordinates incremented.
Xeda112358 wrote:
Can you define a window range such that part of it goes off the screen? I am wondering this because I am writing a sprite routine with clipping and this would simplify the code a bit. Also, for pixel-testing, do the coordinates get incremented when you read from the LCD data port? I am working on a few other graphics commands and it would be useful to not have the coordinates incremented.
You're not supposed to define a window range that goes offscreen, but we won't know what happens if you do until we try it 
And the coordinates do not get incremented on reads. You can safely do read/modify/write for the GRAM buffer, as long as you do a dummy read directly after initially setting the LCD coordinates.
Edit: And dummy read, like all other accesses, must be 16-bit.
Any time you set off-screen or out-of-window x/y/window coordinates, the LCD starts flickering vertical one-pixel white and black bars, which persist until you power off and reset the display. There might be some "safe" way to do this, especially if you use LR60/61 to un-gate parts of the screen, but it seems fiddly for now.
