Next screenshot format

[R-Tape]

We need to decide on a format for Next screenshots. This isn't my area at all, but people have been taking screenshots as .png so far.

Do we say:

.scr for pure Speccy mode
.mlt for anything multicoloury
.png for anything that looks Amiga?

or something else?

tagging [mention]Einar Saukas[/mention] and [mention]moroz1999[/mention] as I believe he's involved in coding a viewer.

[Seven.FFF]

The Next has up to four layers with transparency, clipping windows, stacking priorities, stencil mode and blend modes (where one layer affects another rather than being itself displayed), and multiple colour depths and resolutions based around 128x96, 256x192, 512x192, extending partway into the borders with 320x256 or 640x256. Any given screenshot will be a stack of these lasers plus timed copper effects. There are eight 256 colour palettes which can contain 9 bit RGB definitions. It’s a bit more complicated but that is the basic overview.

If you want a structured format that can capture the makeup of anything on the screen at a given time, as I think Einar prefers for ZXDB, you will need to devise your own format.

If you prefer a single flattened format that can represent the end result of any frame, then 640x256 24-bit RGB PNG would handle it all (apart from the remaining border).

If using .scr or .mlt for a single layer then you may want to think about a palette extension. Those formats currently hold standard ULA or Timex screens, with or without or ULAplus palettes, but a Next palette can be either ULAplus or ULANext (greater colour depth, more colours per palette, and variable split mask between ink and paper allocation).

Almost all Next-specific games will use more than one layer simultaneously, so do consider both options carefully.

[moroz1999]

If image fits into one of the existing video memory dump formats (scr, mlt, whatever) - we should use one.
For the composite images we can agree upon a composite format. Some file which would combine all Next layers memory dumps/palette info required to display the result image. I don't see any other way really.

I think that we need to think first about the real needs. What real cases do we already have? Let's start from agreeing upon a simple layer2 screen format. I think that this format + scr + mlt will cover a lot of real life cases, and then we'll see what would be required next. We can agree upon any format, but without support in emulators (quick save of screenshot in such format) nobody would use it.

[ZXDunny]

If you're gonna use .png for these screengrabs, then make sure that someone with no code running at all can display that PNG file on their Next's screen. If it relies on stuff like copper effects etc then you might find that there's no reliable way to display the file on the real hardware.

[moroz1999]

PNG is not the best way to store the original data, because of:
1. We are making tool for preservation. Preservation is about storing the original data, not result of conversion.
2. PNG can become outdated as technology. In fact it already is replaced by much more effective and modern WEBP on websites. PC image standards change, we should not depend upon them.
3. If we find out that we rendered our PNGs in a wrong way, then we are in trouble. Changing resolution, gamma, palette, rendering bugs, whatever is much easier if we have original dump. This is conclusion from practice on ZX-Art: thanks god I have chosen to store the original dumps once instead of GIF/PNG.
4. Native formats are much more easily displayed on real machines. This becomes really crucial when real machines reach their own Internet via wifi modules or spectranet. How would we play AY music on real ZX Evolution (and one day Next) if it was MP3, for example, like I was suggested to by many people?

[moroz1999]

If using .scr or .mlt for a single layer then you may want to think about a palette extension. Those formats currently hold standard ULA or Timex screens, with or without or ULAplus palettes, but a Next palette can be either ULAplus or ULANext (greater colour depth, more colours per palette, and variable split mask between ink and paper allocation)

BTW, there already is a format for ULAplus image storing. It basically is 6912 + 64 bytes of ULAplus palette.
http://zxart.ee/eng/authors/a/andy-gree ... m-ulaplus/ - example.

We should agree upon ULANext images storing. There are three ways as I see them:
1. New file extension for each pallette. Hard way and unreliable.
2. Just Screen data + palette and leave the ULANext mode information outside.
3. Screen data + control byte for ULANext mode + ULANext palette data
4. Heading + Screen data + ULANext palette data

I personally like options 3 and 4. 3 is practical, 4 may be reasonable just in case for Next, since we are dealing with a lot of formats combinations here.

[Guesser]

I don't really understand the necessity of storing screenshots and music etc in a format the original machine can load. Surely the point is to show what it looks like on a web page? The loading screen is already present in a format that can be displayed on the real hardware: the program itself.
How many people ever download multicolour screenshots and a suitable viewer (I assume one exists?) to view them on a speccy? Is it worth the engineering effort of developing a new format, viewer, conversion script (because a png of gif will still need to be generated and cached)?

[4thRock]

It's worth for preservation and future proofing. If you have the original file, why not display it ?

[moroz1999]

I don't really understand the necessity of storing screenshots and music etc in a format the original machine can load.

https://www.youtube.com/watch?v=u1yWYj4_vZ8 - this is a custom WiFi-based HTTP client working on ZX Evolution with TSConf. That's real machine, not emulation, and it's only a matter of time when we see something like this (or even mode advanced!) on a real Next with WiFi module.

Is it worth the engineering effort of developing a new format, viewer, conversion script (because a png of gif will still need to be generated and cached)?

Conversion script would not be a problem. I have already provided one (already supports 27 zx-related native image formats) and I will implement a support of Next-related formats as well as soon as we get any.
https://github.com/moroz1999/zx-image - opensource, MIT, free to use anywhere you want. It supports file caching and automatic cache clearing as well.
The only concerns I have are:
1. Next case is much more complex than most of others since Next is really advanced and can have a lot of layer combinations. That's true.
2. This potential new format will not be useful unless it gets support from emulators.

[Guesser]

If you have the original file, why not display it ?

If you're having to invent a new file format and add code to emulators to create the files then I would argue you don't "have the original file"...

[Guesser]

and it's only a matter of time when we see something like this (or even mode advanced!) on a real Next with WiFi module.

Fair enough, if someone makes a ZXDB front end that displays screenshots I'll stand corrected.

[PeterJ]

I have to admit I'm not an expert in the area of image formats, but I contacted [mention]moroz1999[/mention] last night with the hope of moving forward with screens for Next games.

The preferred format for [mention]moroz1999[/mention] is nxi from here:

https://wiki.specnext.dev/File_Formats

I then contacted [mention]Seven.FFF[/mention], who is always very helpful with anything Next related. This is what he had to say (Checked that it was OK to publish this publicly) - Note much of this was mentioned earlier in the thread by [mention]Seven.FFF[/mention]

For layer 2 only, I suggest .nxi format. Info here: https://specnext.dev/wiki/File_Formats

This is a deep complicated subject though, because the Next display can be composed of multiple layers stacked on top of each other. Some layers are mutually exclusive, but generally four separate layers plus copper fx can be displayed at once.

ULA, low res, Timex hi colour, times hi res, layer 2, tile map, sprites and copper effects can all be displayed, with separate palettes for each layer, including transparency which can reveal layers below, or reveal global transparency fallback colour.

Thee are eight separate palettes which can be used, each with 256 colours chosen from a 9 bit RGB palette of 512 colours. For some layers like sprites or tilemap, 16 colour modes are possible, chosen from 16 subpalettes of 16 colours each.

Layers can be in various resolutions - 256x192, 512x192, 320x256, 640x256 or 128x96. Some of these resolutions/layers extend into the border for a full screen effect.

As well as transparency merging, certain layers can be merged with blend modes. One layer can be used to lighten or darken another layer, separately across R, G, B channels, for effects like lamplight.

As you can imagine from that rough description, it is almost impossible to create a complete screen snapshot of any given Next frame. I would not like to even calculate the number of valid permutations that are possible - or write the rules that exclude the invalid ones. The file format to capture the pixel info for each layer, combined with their palettes and layer order/blend mode relationship, in any kind of structured way, would be extremely difficult to design.

One additional complication comes with dynamic processing during the frame: copper effects can be actively applied at any half-pixel during the frame, sprites can be multiplexed many times during the frame, tilemap csn be multiplexed, and ULA screens and layer 2 can have backbuffer switching during the frame. In short, it isn’t enough to store the complete video RAM and register state of the Next to reconstruct the output - you must also take into account any code that is running to produce “impossible” raster-chasing effects.

If you wanted to capture any possible image that could be displayed, flattened into a single layer so that it could no longer be reconstructed back on the next, then that becomes an easier job. Here a 640x256 PNG with 24-bit colour depth can represent everything in a common standard format. But the difficulty remains, shifted from difficulty designing the file format, to difficulty capturing the information from the Next into the PNG file.

And, of course, conversely not every PNG of that spec can be displayed on the Next!

[mention]Seven.FFF[/mention] also pointed out to me that pressing CTRL + F3 in the latest version of CSpect will now save a screenshot into the current folder (without shader effects).

I have taken a couple of examples which are available here:

https://drive.google.com/drive/folders/ ... sp=sharing

If we want to start having screens for Next games then I suggest we use this format (Even if its only temporary). If some option comes up in the future which is better, we can always re-take the screens. I understand that PNG is not favoured by many, but unless I'm wrong (which is quite possible), you can't currently export screens in any other format for Next titles.

As long as the games are FoC I'm happy to take on the task of creating screens with Cspect.

Thoughts, much appreciated.

[moroz1999]

I'm a little bit tired of arguing and proving my point for may be tenth time already, so I will do what I can from my side and so be it.
1. I will implement nxi support in ZX-Image. I just need one sample, it's an easy format.
2. I will not accept png for graphics art preservation on ZX-Art.
3. I will accept both nxi and png for software screenshots on ZX-Art.

[PeterJ]

Hi [mention]moroz1999[/mention]

Apologies. Certainly not my intention to argue.

nxi is excellent, but what I'm unclear about is how we actually create the files in the first place. With .scr we just export the file from Fuse. How would the equivalent work with nxi? Will we need to wait for an emulator to support the format.

I appreciate there are tools out there to convert BMP files to nxi. See post below.

Thank you.

[PeterJ]

OK, so I'm trying to create some sample files for [mention]moroz1999[/mention].

I found nextraw from [mention]Seven.FFF[/mention] here:

https://github.com/stefanbylund/zxnext_ ... /README.md

So, I found a nice picture of Port Isaac in Cornwall (Many nice holidays spent there! - Hope we can visit again some time soon), and used Paint.NET to convert to a 8bit bmp file. I then created the files as shown below using the documented examples:

Code: Select all

nextraw PortIssac.bmp
nextraw -sep-palette PortIssac.bmp sep-palette.nxi
nextraw -no-palette PortIssac.bmp no-palette.nxi

This seemed to complete smoothly in all cases.

Then I stored the images here (and on my Next SD Card):

https://drive.google.com/drive/folders/ ... sp=sharing




I then downloaded PlotIt from here, and ran it on my Next.

https://www.spectrumnextgames.uk/plotit

But when I try and open the file I get an 'invalid file' message. Any idea what I'm doing wrong? Does the input bmp file have to be the same dimensions as the required output file?

Edit: Have tried again starting with a file 640 X 256 - Same results. The files on Google Drive are the original ones. I can upload the second set if needed.

[4thRock]

So, I found a nice picture of Port Isaac in Cornwall (Many nice holidays spent there! - Hope we can visit again some time soon),

Been there once for a short visit and indeed it was quite nice!
There's a certain light in Cornwall that's very special, even for those used to sunny skies all year round

I'm very curious to see Next screens. Looking forward to see them on ZX Art and of course Spectrum Computing

[moroz1999]

So, there is a converter after all
Thanks, I will try. Peter, seems like your BMP is a bit too large, I will try to resize it first.

update: or may be not so large, I have to check the docs a bit more.

[moroz1999]

I've added parser of nxi according to official Wiki:
512 bytes of palette, 256*192 bytes of pixels, filesize is 49664. My test nxi file (converted from 8 bit 256*192 BMP file with nextraw) is working just fine.

A new version 3.1.0 of ZX-Image is sent to Github - https://github.com/moroz1999/zx-image
I will now add the support of this new mode into ZX-Art.

updated: I had a typo, wrote "I will NOT add" instead of "I will NOW add"

[PeterJ]

Thank you [mention]moroz1999[/mention], as you say my file must have been to large. This was a bmp reduced to 256 x 192 of Saint Michael's Mount (are you starting to see a theme!) then converted with nextraw:



So, my question is, how do we actually start creating bmp files from Next Games? Do we need to wait for an emulator to support 8bit BMP screen saving [mention]moroz1999[/mention]? I'm assuming so?

[moroz1999]

Since nxi is basically just a straightforward dump of memory banks, may be nxi exporting would be even easier to implement for emulator authors than BMP?
Saving to BMP and then converting it to NXI would do but that kinda ruins the idea of preservation, because nobody can guarantee that we dont lose anything in process

The format is now supported on ZX-Art, so we just the need the images themselves.

[Seven.FFF]

NXI format is easily dumpable, but only represents one of the many layers of the Next display. A NXI dump of almost any running game will not give you anything close to a screenshot.

[moroz1999]

NXI format is easily dumpable, but only represents one of the many layers of the Next display. A NXI dump of almost any running game will not give you anything close to a screenshot.

First of all I wanted to ask you about how much games really combine the different modes, but then I realized that really having only a dump of Layer2 memory is not really solving much. There is low-res, and so on.
Actually, nxi support is ok for most of static artwork, but for game screens we either need to make some complex format with all layers and ULANEXT support or stick to some simple format like BMP.

1. As for a complex format: it's not a problem for me to make a parser, but I think we shouldnt run in front of train with this one. We need the support in emulators for it AND we need the support in at least some of Next's software. Otherwise it will not have any usage at all: using complex format is unreal
without emulator's support for screenshots and is pointless without support in viewers on a real hardware.

2. As for BMP: it's simple enough to be parsed on a real hardware, but how would we ensure that its palette is a real one? BMP can technically have more colors than RGB333 supports, and this is bad for preservation.
I have already met this problem: there was a competition for ZX Evolution in BMP format. Turns out that BMP images made for this compo were not using the exact palette of ZX Evolution, so some images looked really differently on a real hardware.
This is one thing I would like to avoid totally.

3. One more question for BMP: how would we be sure that it uses a right gamma correction? If we are outputting #808080 color on Next, would it mean 50% of gray (linear RGB) or a darker color (sRGB on every modern PC)?
This is one question to decide before we make a lot of images in BMP modes and it turn out that they would all be different without common logic and rules for palette.

[Seven.FFF]

I agree with all three points.

[mention]TheSMoG[/mention] has some reference gamma data, and is also the author of some Next gfx tools. I will ask him to look at this thread.

[PeterJ]

For Spectrum Computing we have decided that Next screenshots will use PNG as a temporary solution. These will be exported from CSpect. This will be replaced with a better format as soon as it is available.

[TheSMoG]

A few things (I'll return to this thread later as I've screwed up System/Next v.1.3.2 and I'm rebuilding it now so I don't currently have a lot of time).
As [mention]Seven.FFF[/mention] correctly said the Next's display is a amalgam of many layers. There is one layer however that's undumpable and that's the Sprite System. As a result, an honest to goodness COMPLETE screenshot from a Next is impossible to make as the resulting image is a combination of actual RAM (which is dumpable) and BRAM which is inaccessible from the outside. Moreover you cannot just dump two palettes and expect that you're good to go as there are up to 8 palettes in use constantly depending on the software.
I'll have more info plus a few suggestions a bit later! In the meantime have a look in the description of Layers (Chapter 16 of the Next User Manual) to understand the challenge presented