The NEO format seemed to have a header that specifies dimensions of the picture, resolution (low/medium/high), and a 16-colour palette, followed by a 32k dump of screen data. The original NEOChrome program itself only works with 320x200x4bpp images, however.
So, the question becomes what to do with the other screen modes available for STE/TT/Falcon. My thought was rather than dumping nothing, or something incomplete, just include the missing information in a benign way. I tried to add the minimum amount of information needed for a complete reconstruction of the image. I felt the goal was not only to make something that NEOChrome or existing tools could open, but to store the ST's graphics memory in its original format.
It omits the alternate path for GenConv from the PR, but without this I believe you'll just end up filling a NEO file with uninitialized/left-over data from the unused ST raster render memory, which I feel is worse than emitting no file at all. The user will see files created, but will later find they contain no useful screenshot information. Would it not be better to give the user a file containing a dump of the actual graphics data? That was the purpose of what I wrote.
What I had done instead was using the header as already described, but allowing for the extra cases we have:
- Header still specifies dimensions as before, but they might be different than the usual 320/640 x 200/400.
- If the header's resolution is not one of 1, 2 or 4bpp, the "resolution" field will just be equal to BPP..
- The filename field, which most tools leave blank, was used to indicate hatari and BPP as an ASCII text hint.
- Following the header, instead of dumping 32k, instead dump as much data as required for the dimensions/bpp.
- Finally, a suffix is added containing up to 256 RGB palette entries, so that no colour information is lost. (Without this we can only store the first 16 colours, and they will have reduced bit depth.)
So, while the suffix or previously-unused resolution values will not be processed by any existing tools, I only added it because otherwise the file will not not have enough information to reconstruct the image. I am unaware of any other suitable format besides NEO that can handle this, so I tried to extend NEO in the simplest way I could. I felt this was valuable for diagnostic purposes. I was able to verify reconstruction of the TT/Falcon images for various extended resolutions using my own generic binxelview image tool, but the point was just to get the necessary data into a file so that anyone who needs it can use it. Requires new tools, perhaps, but depending on your purpose the information may even be useful with just a hex-editor.
The palette suffix isn't added for any mode that is already normal for the format, and even if added for those modes, every NEO tool I checked would just ignore it.
If the concept of using the format in an extended way is not acceptable, I would at least suggest returning an error from ScreenSnapShot_SaveNEO for the GenConv case, so we aren't generating a file containing uninitialized data, and at least giving a warning through stderr.
-- Brad Smith
Altough Brad's patch also supported TT/Falcon screen or more than 4 bpp
screen, I only applied the parts that handle standard STF/STE video mode
and a resulting 32128 bytes .NEO file.
I'm not quite sure that the extended format Brad added for TT/Falcon and
that stores some extra palette is needed, I'd rather keep a .NEO file
format that matches the "original" specs (if such things ever existed :) )