So, DispGraph displays only the front buffer, DispGraph^r displays both buffers with 3-level grayscale, and DispGraph^rr displays both buffers in 4-level grayscale.

Additionally, the Pt- commands display to the front buffer by default, and the back buffer if you add a ^r

Adding a ^r actually draws to the back buffer for most graphics commands

Here is a more in-depth how-to:

The TI-83 series doesn't support grayscale natively, but axe has some functions to alternate checkerboard patters, but that is so fast (and the screen is blurry too), so that it looks for the human eye like it is gray.

Because one buffer can only store data for two colors, you'll need two buffers for 2² = 4 level grayscale. Depending on the pixel combination of both buffers you can get black, dark gray, light gray and white. The easiest way (for me) to remember the combinations is, that the main buffer has a higher "priority" or "level" than the back buffer, so if you change a pixel on the front buffer, it'll cause the result to change more than when you do it on the back buffer.
Here are the combinations for 4 level grayscale:

Front buffer:  Back buffer: Result:

off off white

off on light gray

on off dark gray

on on black

In order to display a 4-level sprite, you have to create two 8x8 sprites, one for the front buffer, one for the back buffer. With the table above as reference, you can make your 2 sprites out of the one desired gray sprite.

To display them, you need two Pt-commands:

[Hex for Front buffer]→Pic1A  ; you can use other names for pointers if you want
[Hex for Back buffer]→Pic1B
...
ClrDrawrr  ; clears both buffers at the same time
While 1
...
Pt-Off(X,Y,Pic1A)   ; X and Y are the coordinates
Pt-Off(X,Y,Pic1B)r
...
DispGraphClrDrawrr   ; for 4 level you need two radian r's
...
EndIf getkey(15)

For 3 level grayscale you need DispGraph^r, for 4-level you need ^rr. Same when you use the DispGraphClrDraw.

Every time the DspGraph^rr is passed, the checkerboard pattern is changed.

That should be it.

It's above, just change the hex codes.

The square brackets? Nope, they should be there.

I meant the "..." also why is it pt-off instead of pt-on?

Yeah, remove the dots (you can add other code in there, like movement)
Make sure to initialize X and Y or replace them with constants.

Pt-Off is slightly faster than Pt-On (when X is a multiple of 8 ), so that's why I used that for the example. But doesn't really matter.

Hex:
[FFFFC3C3C3C3FFFF] for front buffer
[FF81BDA5A5BD81FF] for back buffer

That should be a neat little box with all colors!

Quote from: Link on September 05, 2012, 03:02:29 pm

I meant the "..." also why is it pt-off instead of pt-on?

Yeah, remove the dots (you can add other code in there, like movement)
Make sure to initialize X and Y or replace them with constants.

Pt-Off is slightly faster than Pt-On (when X is a multiple of 8 ), so that's why I used that for the example. But doesn't really matter.

Hex:
[FFFFC3C3C3C3FFFF] for front buffer
[FF81BDA5A5BD81FF] for back buffer

That should be a neat little box with all colors!

Ooh, thanks, it works now, Time to go see If i can remove flicker now.

It also depends of the calc model, right? For example, newer calcs might be faster or have a crappier LCD driver causing grayscale of some games to not flicker, while others will flicker, or vice-versa.

Removing the entire flicker is impossible without ASM (and even then, it requires a calibration screen like ThePenguin or Hot Dog's grayscale games), though, so while you can make the grayscale looks close to perfection, you'll still always notice a little bit of scanlines.

The loop has to be in sync with the LCD driver speed, which is different on every calc, even accross the same models, so if your loop is too slow or too fast, flicker will be more noticeable.