Re: [hatari-devel] Screenshots in NEO format

["J.Young" <jyoung8299@xxxxxxxxxx>]

On 1/2/24 15:37, Nicolas Pomarède wrote:
> Le 02/01/2024 à 21:17, Anders Eriksson a écrit :
> > On Tuesday, 2 January 2024 at 19:15, J.Young <jyoung8299@xxxxxxxxxx> 
> > wrote:
> >
> >
> > > On 1/2/24 13:02, Andreas Grabher wrote:
> > >
> > > > > Am 02.01.2024 um 18:27 schrieb Nicolas Pomarède 
> > > > > npomarede@xxxxxxxxxxxx:
> > > > >
> > > > > Le 02/01/2024 à 18:23, Andreas Grabher a écrit :
> > > > >
> > > > > > Probably the way Previous does it would be interesting. It does 
> > > > > > generate PNGs directly from the VRAM of the emulated machine:
> > > > > > https://sourceforge.net/p/previous/code/HEAD/tree/trunk/src/grab.c 
> > > > > > https://sourceforge.net/p/previous/code/HEAD/tree/trunk/src/grab.c
> > > > > > Hi
> > > > >
> > > > > that would be extremely difficult for hatari when you consider all 
> > > > > the possible overscan modes. re-interpreting the RAM content would 
> > > > > be complicated, while the job is already done in screen.c, hence 
> > > > > why hatari grab screenshot from the emulated screen, not from the 
> > > > > RAM.
> > > > >
> > > > > Nicolas
> > > >
> > > > I see! So this is quite different from the NeXT. Isn‘t there some 
> > > > intermediate buffer that contains the interpreted data before being 
> > > > handed to the SDL renderer?
> > >
> > > Hmm, interesting, Steem has been able to do this forever. Maybe it can
> > > be added just for low/med/high standard modes?
> > >
> > > Atm, I have to check the video base address, savebin the screen data,
> > > savebin the palette then run go on the host and run a bash script to
> > > assemble the header and tack on the screen data. Very time consuming.
> > > The sort of thing that programs are very good at doing fast :).
> > >
> > > I am working on a game launcher and being able to get screenshots for
> > > new conversions/adaptations is a big part of the ongoing use of it.
> >
> > Hello,
> >
> > another way is to set Hatari to 320x200 display without statusbar, 
> > take a regular png screenshot.
> > Now if you use Linux install Imagemagick. If Windows first install 
> > WSL2 then Imagemagick. For macOS first install Homebrew or Macports 
> > followed by Imagemagick.
> >
> > Then you can easily make an ST-image with "convert pic.png pic.pi1", 
> > and batch convert easily. If the picture contain no more than 16 
> > colours there won't be dithering etc applied. PI1 shouldn't be an 
> > issue to display in your program as it's more or less the same as a 
> > NEOchrome file, just palette and bitmap on different offsets (+2 and 
> > +34).
> >
> > Good luck :)
>
> +1 for this solution, I don't see where's the need to keep indexed 
> palette (as it is in ram / color registers) as you can tell 
> imagemagick to do the conversion to NEO/PI1 with only 16 colors and it 
> should be similar to what was in ram (except for colors maybe being in 
> different order, but it shouldn't matter for the resulting image)
>
> Nicolas
Hi Nicolas,

Color order does matter for my use case.  The launcher allows viewing 
screenshots and most have black borders in-game but when using something 
like this for the screenshots:

> cat "$image" | pngtopnm | pnmquant 16 | ppmtoneo > TMP.NEO

The colors are rearranged and when flipping through screenshots in the 
launcher it can strain the eyes with all the color flashing.

Jeff