> On 17.1.2024 3.02, Brad Smith wrote:
>> 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.
Dumping something that cannot be read by any known application (AFAIK) does
not make much sense, does it? So I agree with Nicolas here to omit the code..
I feel the situation has been drastically misunderstood.
The code that was omitted from the patch integration was not ONLY for screenshots that could not be represented in the NEO format, it was primarily written to make relevant old-format compliant screenshots work for ST Hires, as well as TT and Falcon mode screenshots that use ST-compatible low/medium/high resolutions. These all could be read by existing tools. NEOChrome itself cannot read medium or high resolution, but there are several other tools that can read this kind of NEO file.
Because this code to handle those was omitted, these relevant cases will produce NEO files with empty screens in the current version. This is a flaw that should be corrected.
The question of supporting other modes (different dimensions, other bpp) is not the reason that removed code existed, and in fact this code simply supported them generically. There are no extra special cases for 8bpp or 16bpp data, or for different dimensions. It was just one piece of code that dumped whatever memory GenConv was using for the image, always by the same method. There was no extra code burden to support other modes here, beyond what was ALREADY needed to support the 3 standard resolutions.
If the decision is that we should forbid any image that doesn't fit the 3 standard NEO resolutions, I feel the correct thing to do would be to write code to generate an error in the case where there is not a match for those 3. This would likely take slightly more code than the RGB palette suffix, but if it needs to be forbidden, that's what I think the correct solution would be. I did not write such code to generate an error for these case in my patch, because it seemed the simple extension of the format was less code to implement, and more useful than forbidding it.
However, I don't agree that it's useless to dump such non-standard NEO files. In my view, the specific format isn't what's important here. I think it's useful to have a screenshot that contains a direct ST graphics dump. NEO is one such format, and I think the most popular one. The 3 Degas forms are trivially equivalent, though they disambiguate the resolution instead with the filename extension. The XIMG suggestion is maybe OK but I think this is a far less popular format.
To me it doesn't matter which one in particular, as long as it contains the ST memory dump of the bitmap + the ST palette + something to identify resolution and dimension. NEO has all of that capability, so would a few other formats.
Alternatively, we could instead create palettized PNG or BMP that is generated directly from the graphics memory bitmap, rather than the what the other BMP/PNG screenshot solutions do which is simply based on the graphical output of Hatari. This would also have the same useful information, just in a less directly "ST-like" format.
I think it's useful to have such a direct dump version of the screenshot, that matches exactly what was in memory at that time. The NEO format request seemed to fit that bill to me, which is why I was interested in it. Maybe the NEO format is specifically useful to the one user who requested it, I have less to say about that, but I do have a use for an ST graphics memory dump like this, for debugging and inspecting graphics in a running game, or extracting images and processing them. It's probably easier to use and understand this if it's not reprocessed into another PNG option.
Since I don't believe the issue is added code complexity, for the user of TT or Falcon who also turns on this option and tries to take a NEO shot of an 8/16bpp mode, I think it's better to just give them the dump containing the screen data than an error message complaining that what they want doesn't quite fit the old NEO format. It's better to have the data preserved than have nothing. Writing new tools to process this stuff is relatively easy, as long as you managed to get the data saved in the first place. Trying to go back in time to recreate the screenshot you lost because you didn't know it was going to be forbidden is not so easy.
-- Brad Smith