Yes, you're right.

Forget about mViewer and its 16 grayscale levels (4-bits).

The last build of mViewer is now able to display your bitmaps in not less than 31 different grayscale levels! (8-bits)

And guess what? While viewing the image, it as fast as the last public binary.


It was quite hard to take a photo.



Note: it looks much better without an APN.

Isn't that 5bit grayscale? (2^5=32)
I experimented with that a while ago. Are you using the checker pattern, like what is used for 3 lvl grayscale on the 83/84?

And to make sure I have this straight, the LCD driver is physically incapable of displaying any more that 16 shades of gray, right?

Just saw this, and once again, epic job, critor

Gonna download this as soon as I have the time.

Woah 31 colors is awesome! I was sure such thing could be possible, because of how good 16 level GS looks like. Do you use the same method as on the TI-83 Plus series, kinda? On the 83+, flashing between black and white to get gray causes some static and flickering to happen. To make the eye think it's flickerless, we simply use a checkered pattern that changes rapidly, creating an illusion of flickerless gray due to the pixels being small. Here's an attachment below

It's similar.

I'm flashing between 2 consecutive gray values among the 16 standard ones, in order to get 15 intermediate grey values.

I just hide the 2nde value for each pixel in the blue color bits, and then alternatively swith between RGB and BGR color modes.
So nothing is copied or calculated.

I see Critor. Is there a checkered pattern? That said, even with none, I don't think the flickering would be noticeable, though, since the difference between grays isn't too large. Could it be used inside games?

Here is my latest build of mviewer2.
It's not an alpha version any more: i've promoted it to a beta now!


* All graphic functions are now supporting both the standard 4-bits mode (16 grayscale), and the super 16-bits mode (31 grayscale).

* The 31 grayscale mode delay has been set to 40 (40ms very approximatively). This seems to produce the best display on both tested Nspire (a basic and a CAS ClickPad), because the screen must be done refreshing the previous "action".

* No data copy any more to refresh the screen. I'm using 2 identical buffers: onscreen and offscreen. I update the screen when needed just by setting the SCREEN_BASE_ADDR to the start of the offscreen buffer. The 2 buffers roles are switched this way: onscreen is becoming offscreen, and offscreen is becoming onscreen.

* New emergency key to immediatly turn the screen off, if you were about to be caught viewing something forbidden.

* The '"non-centered zoom" bug has been fixed. There is another minor zoom bug.


The 31 grayscale mode doesn't allways give you a better image. It depends upon the image. Images with areas including very similar adjacent grey levels are going to be wonderfull. You'll have the impression of not being able to count the grey levels in those areas any more.

In 31 grayscale mode, if you look carefully you'll guess which are the new 15 levels. Their display is not perfect. This seems to be related to the way the screen refreshes itself.


Here are the keys not mentionned in the readme from the stable link:
- 'C': switch between 16 grayscale mode and 31 grayscale mode
- 'Home' and 'Menu': increase or decrease the 31 grayscale mode delay (if you've got a "bad" display with the default delay - might be removed in the future, depending upon the tests results)
- 'Ctrl': turn the screen on/off




Future tests:
------------

The 31 grayscale mode is obtained by switching the color encoding from RGB to BGR alternatively.
The 2 different gray levels are stored in the R and B bits and then mixed on the screen, producing a new gray level.
There is another way to produce the new grey levels.
It is to have 2 screen buffers containing the different grey levels, and to change the SCREEN_BASE_ADDRESS alternatively between the starts of those buffers.
I wonder if this method would produce better/worse results...

By combining both methods, we could get (in theory) something like 48/64/... grayscale levels. I wonder how it would look like.
64 levels will be hard (propably impossible), because the total refreshing cycle would need something like 120ms. And the human eye is able to detect a 120ms delay.
With a 80ms delay, 48 levels is "limit" but might give something interesting.


Future features:
----------------
* If the tests are good (but don't be too optimistic), more grayscale levels.
* Going back to 8-bit data to spare some more memory.
* Supporting other image files: PNG/JPG/GIF.