Atari ST(e) Multipalette Picture file format

Too much time since I haven't written to this blog!

From last time, among other things I have participated to the Antiques demo, an Atari STe demo by Dune and Sector One. This is to my opinion a great Atari demo, which is really worth the look. It features great physics and 3D effects by Chuck, great graphics from Mic and awesome music from Dma-Sc. All of this put together by the Sector One conductor, ST Ghost.

In this demo I have done minor helper animation code, like the intro and the greetings part. I also used a new method for displaying still pictures with a large number of colors available on the screen.

Here is for instance one of such pictures, by Mic:

Antiques Hicolor picture #1 by Mic of Dune

Can you believe this picture can be displayed by an Atari STe, which is supposed to be able to only display 16 colors per picture, from a palette of 4096 colors? Well it can! Basically, Atari ST coders know from a long time how to display pictures with more than 16 colors. This is done by synchronizing palette changes with the screen refresh. Some graphics programs even take profit from such techniques like the famous Neochrome Master which allows to schedule the palette changes at determined vertical positions in the image, or Spectrum 512 which even allows to display more than 16 colors in a single scanline, typically 44 of them. The method used in Antiques demo allows to display 56 different colors per scanline from 29791 possible shades, making use of the blitter chip for that purpose.

In fact, the display method was not the trickiest part in the project. The biggest challenge was to determine a method to generate the data (pixels and palette) to make images look the best as possible when displayed on the STe. A program like Spectrum 512 uses a very basic method to construct image data. It also behaves badly when it has to deal with numerous colors. Of course it had to run on the Atari, with very limited processing power.

My method uses a heuristic method to generate pixel and palette data. It spends a lot of processing power to run a simulated annealing based search method to try and find the best data for each scanline of the picture. The image generation is written in C language and is rather well optimized, to reduce useless computations and make the overall run time acceptable on a modern computer. The program even works on the Atari, if you have enough patience ;)

I have diversified the display method from a single STe-only method to four different methods, the remaining three being also able to run on a plain ST (only 3375 colors are available on the ST though). One mode supports fullscreen, allowing a picture resolution of 416x273 pixels with 48 different possible colors per scanline. I created my own file format to support the different display modes and image types. This format is called MPP, for "Multi Palette Picture".

I am releasing the code of the image converter and the file viewer running on the ST and STe. The Mega STe is also supported. The code is available under the WTFPL public license, which basically corresponds to the public domain. People can use it for what they want, use the code in file conversion plugins, make better sophisticated viewers, etc. You will find the link to the archive at the bottom of this article. I also provide an archive with different sample images. Hoping people will do funny things with that code!

Comments

1. On 15/10/2012, 17:58 by Petari

This is very promising. I will try it on my Atari machines.
Especially interested about how it can be used for playing videos
- in 4096 color mode on STE with audio. It is possible even at 25fps
and decent res. at 320x172 (and likely more).
See page http://atari.8bitchip.info/movpst.p...

2. On 16/10/2012, 22:00 by zerkman

@Petari: I visited your website, your project is very interesting ! You could quite easily convert pictures of the resolution you want (320x172 is okay) with minor modifications in the converter code.

Some tests should be done to test if the MPP 12-bit palette format is suitable to save some space while not taking too much time to convert back to STe palette format (16-bit entries with the four topmost bits set to 0). Otherwise you can use the --raw switch to generate a file with only the raw palette and pixel data, exactly as needed as input for the image viewer code. Good luck ! :)