Best binary format for storing Next's graphics

This section is for discussing everything about Next hardware and latest updates.
Post Reply
Posts: 7
Joined: Sun Jul 07, 2019 11:25 am

Best binary format for storing Next's graphics

Post by moroz1999 » Tue Jul 09, 2019 10:06 pm

There are already some great pictures done for Next by Andy Green, and I would like to make it available on ZX-Art. I only store "memory dump-like" formats on ZX-Art and convert them to PNG/GIF for displaying on website on-the-fly by PHP. This is the only way to retain accuracy in displaying, and that already saved me from reconverting thousands of images after palette adjustments, SRGB corrections and so on.
This policy also ensures that 100% of archive can be easily used on a real hardware. This is why I'm not supporting BMP/PNG/JPG image sources on ZX-Art.

So I wanted to ask is there already some binary format to store the original ZX Spectrum Next images? Like 6912 SCR for classic ZX, but for the Next.
If there is no such format, I propose to discuss it here, so I would be able to implement it on ZX-Art, and it could become some sort of standard.

User avatar
Posts: 221
Joined: Mon Jun 05, 2017 5:30 pm
Location: USA

Re: Best binary format for storing Next's graphics

Post by SevenFFF » Tue Jul 09, 2019 10:44 pm

For layer 2 only, I suggest .nxi format. Info here:

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!
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel Spectron 2084blog

Posts: 7
Joined: Sun Jul 07, 2019 11:25 am

Re: Best binary format for storing Next's graphics

Post by moroz1999 » Wed Jul 10, 2019 9:11 pm

Thanks a lot for the detailed information!
I totally agree that it would be near to impossible to store the most difficult cases in one single format, and probably no one would bother to support that hypothetical format on a real hardware.

I think that we should start from supporting what's already available: .nxi format, which would be great for storing at least the currently available original Layer2 artwork. When some significant amount of original pictures in other modes would appear, then we can think about other formats for other modes or their combinations.

Is there any example of .nxi file available? It would be nice if emulators could have an option to save a screenshot of Layer2 directly in NXI, as Spectaculator or Unreal Speccy can currently save SCR files.
I will implement the support in ZX-Image library, so anyone with PHP would be able to use it:

User avatar
Posts: 70
Joined: Mon May 29, 2017 6:55 pm

Re: Best binary format for storing Next's graphics

Post by emook » Sun Jul 21, 2019 8:07 am

Hi Moroz1999

The format is quite simple for a layer2, it’s a 256x192 per pixel image. Each pixel is a value 0-255 which indicates what palette index value to use. So the standard image is 49kb in size.

I’ve written a drawing package that I tag the palette and also a colour cycling block after the main image which allows Amiga / ST like palette cycling. (Skip to 5:30m for the cycling)
ZXorDIE NextBuild ZXBD Snapshot uploader ZXBasic Online Database

Post Reply