An example of the JPEG display in MODE 31 (16 colours)
Better than that, there is an option of loading and displaying the JPEGs directly from file so
that building a JPEG viewer into QuickVoy was pretty much a matter of creating a loader and a
redraw routine, both calling the JPEG system calls.
Trivial really, which is why QuickVoy has a built-in JPEG viewer.
By way of demonstration, the source file was that lovely picture of Alyson Hannigan lying in the grass...
When you are in a screen mode with less than 256 colours, the image will be rendered in monochrome. The rendering is a bit worse than ChangeFSI - it is like ChangeFSI with the dithering disabled, but the results are still quite useful.
In 256 colour (or more) modes, the rendering is dithered and in colour. The quality isn't bad, especially given the processing speed.
In 32 thousand colour modes, the picture would become as below. Note that this example is itself a JPEG, so may suffer slight loss of resolution due to being decoded, encoded, and decoded again by your system.
In a 16 million colour mode, it would be as below. This is also a JPEG, and you need to be in a
16 million colour mode (also referred to as "TruColor" on PC systems) in order to see
any difference between this and the above - though the difference is slight.
PS: Spot who only has 1Mb of VRAM installed! :-)
The rendering is done directly from file, so it is slow during repeated redraws (if, for example, you drag a menu across the display window). However, in comparison to FYEO2 or ChangeFSI, you will notice that the system JPEG handling is extremely quick, even on the older ARM3 hardware.
On a RiscPC system, QuickVoy will load the JPEG into a dynamic area and render it from there.