Could you upload the program and provide a link, or paste the relevant part?

Making a guess, though, the second issue you described could be a combination of two individual issues: drawing the two parts of each sprite to the wrong (inverted) buffers, and calling DispGraph^r (meant for 3-level grayscale) instead of DispGraph^rr (meant for 4-level grayscale).

As for the first issue, if the "dots" aren't horrendously prominent, then that's probably just a side effect of updating the screen out of sync with its refresh rate. The closer it is to about 60Hz, which is very roughly the refresh rate of the calculator screen, generally the better the grayscale looks. You can achieve (nearly) perfect grayscale with GrayLib, but that may be overly complex if you're still just becoming familiar with the language.

Here's the source code for it:
:

Code: [Select]

.TEST
:
:[FFFFFFFF00000000]→Pic1
:[F0F0F0F0F0F0F0F0]→Pic2
:
:Repeat getKey(15)
:Pt-On(0,0,Pic1)r
:Pt-On(0,0,Pic2)
:DispGraphrr
:ClrDraw
:ClrDrawr
:End
It was just meant to be a test to see how it worked. It was just suppose to draw a black square, a dark gray square, and a light gray square. The funny thing is, I got it to work a long time ago, but I forgot how I did it and the code got deleted.

As for GrayLib, I think I'll check it out.

I switched pic1 and pic2 and it worked fine for me.
You can replace DispGraph^rr:ClrDraw^r:ClrDraw with :DispGraphClrDraw^rr
ClrDraw^rr also works

Quote

I switched pic1 and pic2 and it worked fine for me.
You can replace DispGraphrr:ClrDrawr:ClrDraw with :DispGraphClrDrawrr

Thanks for the advice E37! That fixed the colors in the wrong places. However, I noticed that the dark gray wasn't well defined from the black, so I did some screwing around and found that if you do :DispGraphClrDrawrr after pic1 and after pic2, It's perfect! Problem solved. I'm sure to implement this into some game down the line. Thanks for the help! 

Glad to hear it!
I don't know why that fixed the grey problem. It should look exactly the same. (are you calling it multiple times in the loop?) Try adjusting your contrast, that should make the dark grey more distinct. If you didn't already know, you can do that with the Shade(EXP) command. Shade(Shade()) will return the contrast to what it was before the program started.
If you haven't already tried it, interrupts work very well with greyscale.

The appearance of different contrast (shade) values varies from calculator to calculator. There's no fixed good number. Many programs/games just rely on the user to set a good contrast value beforehand in the OS.

Some may also implement a tuner in their program that allows the user to adjust the contrast for their program, distinct from the OS. GrayLib provides such functionality with the GTune() function. If you're going to use this part of GrayLib, though, you should probably consider just using the whole thing.

While I'm talking to Runner112, I might as well ask, whatever happened to that program you were making that upscaled a sprite, rotated it, then downscaled it again? Did you finish it? Because it'd be really helpful for this one game I want to make. I couldn't find it when I was reading the forum you talked about it on.

I vaguely remember trying something like that, but I don't believe it panned out. If you're looking to create rotated versions of sprites, I would recommend doing so ahead of time on a computer with a tool like RotSprite.

EDIT: For those wondering, I believe I found the thread in question where my failed attempt lives: [AC] rotating sprites.

Very small, pixel art images generally don't look good when geometrically transformed, which includes rotation (by a non-right angle). I would recommend using a tool like RotSprite to generate rotated sprites at even intervals up to 90 degrees and touch them up by hand, and then these can be rotated by right angles in the program using the rotC() and rotCC commands to fill out the three missing quadrants of rotation from the one you have.