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.
So, looking at the merged commit vs. the PR:
-
https://git.tuxfamily.org/hatari/hatari.git/commit/?id=dd0c3b993ad068a9323ebf3c735bf5935febad68
- https://github.com/hatari/hatari/pull/31/files
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
On Tue, Jan 16, 2024 at 5:28 PM Nicolas Pomarède <npomarede@xxxxxxxxxxxx>
wrote:
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 :) )