Screenshots

[lfaria]

ZX-Image allows you to define border colour on .scr conversion for each image.

Code: Select all

$converter->setBorder(5); //cyan

If we had that information for each game (perhaps another column on ZXDB ? ) we could display the correct border...

And what would be the value for the above mentioned Aquaplane? Blue (1)? Cyan (5)?
I'm afraid both choices would be incorrect.

[4thRock]

We have 2 situations:

a) Border effects (ex: Aquaplane)
Here you need a .PNG to preserve all border details (or .BSC if some emulator supports it)

b) Has a single solid border colour - no border effects (ex: Advanced Lawnmower Simulator )
Here you only need the colour number.

[zup]

And what would be the value for the above mentioned Aquaplane? Blue (1)? Cyan (5)?
I'm afraid both choices would be incorrect.

The "right" answer would be storing the entire screenshot. As you said in your first post, border effects means that there are more than one colour.

BTW, I've been taking some screenshots from ZXSpin. It supports three formats:
- SCR: No border at all.
- GIF: It shows FLASH correctly, but the border is single coloured (i.e.: during load, it is either yellow or blue).
- BMP: The border shows correctly (i.e.: bars during load), but FLASH is not shown.

IMHO the best method would be a GIF storing all (or part of) the border, with one or two frames depending on FLASH being used. Any other thing would mean losing information. PNG does not support multiple images (APNG and MNG does, but they're not widely supported).

It would be interesting doing the same with load screens, so you could see if it loaded with multicolored border, strange colours or without an border. In both cases, I'd recommend to keep the standard scr files too.. they can be useful to edit or include in spectrum programs.

[druellan]

ZX-Image allows you to define border colour on .scr conversion for each image.

Code: Select all

$converter->setBorder(5); //cyan

If we had that information for each game (perhaps another column on ZXDB ? ) we could display the correct border...

I was thinking of that, but bothers me the information is part of the database and not part of the screenshot file, since in the end it will become another value to maintain.

The suggested pair of files, gif + scr might work.
If 00000-run-1.gif exists, is preferred over 00000-run-1.scr But again, to keep an standard size is important, even between scr and gif. We can't rely on one emulator output.

A gif with the loading bars is something I will looooooove to see, even an animated gif with the loading scheme for the most unusual ones, something [mention]kolbeck[/mention] did as an experiment on zxinfo and it was very nice. But this is another discussion.

[Guesser]

Animated png is widely supported now https://caniuse.com/#feat=apng

[Einar Saukas]

The SCR format can be saved from all emulators. It's supported by all Spectrum image tools. It's also the most convenient format for developers. This format can perfectly represent 99.9% of our game screens (including hidden pixels), if we simply add an extra column in ZXDB to store the border color (as suggested by [mention]4thRock[/mention]). That's exactly how ZX-Art handles it. I think this is the best option we have.

The BSC format cannot be saved by emulators and it's not supported by any tools. In practice, anyone producing a BSC file would need to generate SCR first, then convert it. Anyone that downloaded a BSC file would need to convert it to SCR first before using it. So it would be better to store and provide SCR files directly. The BSC is such an obscure format that attempting to search for the Spectrum format BSC in Internet will only give you this link, that refers to something different. So it's not a better choice than SCR.

For the few remaining cases, we can use a special format more adequate for each case. We currently use MLT and IFL for multicolor screens, and SS4 for Sam Coupé screens. We can also adopt more special formats as needed and, when all else fails, store images too (preferably PNG).

For instance, the animated loading screen for Heavy on the Magick is currently stored as both SCR and animated GIF. The running screen for Rotatrix is stored as PNG only, because a SCR wouldn't show anything (everything happens in the border outside the screen). The Chromatrons Attack screens are PNG screenshots, because this effect cannot be properly seen on emulators or viewers. The Aquaplane running screen is currently stored as GIF that doesn't show the border, which is a bad choice: it should be replaced by both a SCR of screen content content, and a PNG that included the border.

Notice that I'm suggesting PNG to capture complex border images, but if there's a Spectrum file format that can do the same, it would be even better.

[moroz1999]

There is only one viewer supporting BSC format as far as I know.
The Viewer:
https://zxart.ee/eng/software/tool/medi ... the-viewer
https://spectrumcomputing.co.uk/entry/3 ... The_Viewer

It's for pentagon and TR-DOS only.

As far as I remember there is no editor for this mode. I can write a simple online converter from PNG+SCR if anyone is interested.

[pavero]

Maybe it's a little bit off topic, but I would like to know the answer for this question. How to create SCR screenshots for ZX81 titles? I don't know any ZX81 emulator which would support SCR format.

[R-Tape]

Maybe it's a little bit off topic, but I would like to know the answer for this question. How to create SCR screenshots for ZX81 titles? I don't know any ZX81 emulator which would support SCR format.

There isn't such an emulator yet. [mention]kolbeck[/mention] converts .bmp using a bespoke solution.

[Einar Saukas]

Maybe it's a little bit off topic, but I would like to know the answer for this question. How to create SCR screenshots for ZX81 titles? I don't know any ZX81 emulator which would support SCR format.

There isn't such an emulator yet. @kolbeck converts .bmp using a bespoke solution.

The ZX81 screen only contains 256x192 pixels without attributes, so nothing can be lost in a conversion to SCR (using black INK/white PAPER). Although it would be even better to store ZX81 screens as a simple sequence of 24x32=768 bytes (one byte for each character on screen). Perhaps we can convince [mention]moroz1999[/mention] to support this new format?

[R-Tape]

The ZX81 screen only contains 256x192 pixels without attributes, so nothing can be lost in a conversion to SCR (using black INK/white PAPER). Although it would be even better to store ZX81 screens as a simple sequence of 24x32=768 bytes (one byte for each character on screen). Perhaps we can convince @moroz1999 to support this new format?

Aye that would work, and I suppose we stick to .scr for the hi-res stuff.

[4thRock]

For the ZX81, a character based format makes sense ( 24x32=768 bytes ) for preservation.
If I'm not mistaken the highres modes are obtained by redefining the characters (sort of like UGDs).
So even on those cases it would be 24x32=768 bytes + redefined character data.
But I'm not a fan of "theoretical" formats that are unsupported, or require extra work - .scr is a special case since it has wide support.

For monochrome machines a 2 color PNG works perfectly and is easier to get. Thinking about the ZX80 and the Jupiter Ace
And don't forget that these machines also have a border area. If I'm not mistaken it's always white on the ZX80 and ZX81 and always black on the Jupiter Ace.

[Einar Saukas]

Aye that would work, and I suppose we stick to .scr for the hi-res stuff.

Exactly.

We will need 2 formats, that could be named as follows:

• Format ".s80": a sequence of 768 character codes from the ZX80 charset

• Format ".s81": a sequence of 768 character codes from the ZX81 charset

A converter should take a 256x192 monochrome image in BMP or SCR format, matching each 8x8 area against the corresponding charset. If any 8x8 area doesn't match any standard character, the image would be considered invalid thus abort with an error without converting anything. Ideally the converter should also be able to do the opposite, i.e convert a file with extension ".s80" or ".s81" to BMP or SCR.

Does anyone would like to implement this converter? Otherwise I will implement it myself later when I get some time.

[Einar Saukas]

For the ZX81, a character based format makes sense ( 24x32=768 bytes ) for preservation.

Exactly.

If I'm not mistaken the highres modes are obtained by redefining the characters (sort of like UGDs).
So even on those cases it would be 24x32=768 bytes + redefined character data.

Yes. However when a ZX80/ZX81 program is not using the standard charset, there's no way to reconstruct the correct redefined charset (with same character order, etc) from just examining a BMP screenshot. The converter would need to "invent" a redefined charset different from the original. IMHO there's no real advantage in adopting a new format in this case, it's better to simply store it as SCR.

For monochrome machines a 2 color PNG works perfectly and is easier to get. Thinking about the ZX80 and the Jupiter Ace

I think a monochrome SCR (black INK/white PAPER) works even better in this case.

And don't forget that these machines also have a border area. If I'm not mistaken it's always white on the ZX80 and ZX81 and always black on the Jupiter Ace.

Good point! So there's no need to store extra information for them

[4thRock]

For monochrome machines a 2 color PNG works perfectly and is easier to get. Thinking about the ZX80 and the Jupiter Ace

I think a monochrome SCR (black INK/white PAPER) works even better in this case.

Using .SCR here is a bit strange because it uses a Spectrum specific screen memory layout

And don't forget that these machines also have a border area. If I'm not mistaken it's always white on the ZX80 and ZX81 and always black on the Jupiter Ace.

Good point! So there's no need to store extra information for them

Yes, only store border colour or border effects for ZX Spectrum games that use them.
Some games change border per level (Manic Miner), so a single entry will not be enough...

[moroz1999]

The ZX81 screen only contains 256x192 pixels without attributes, so nothing can be lost in a conversion to SCR (using black INK/white PAPER). Although it would be even better to store ZX81 screens as a simple sequence of 24x32=768 bytes (one byte for each character on screen). Perhaps we can convince @moroz1999 to support this new format?

No problem! I just need a short description and one sample to test it with.

[kolbeck]

For monochrome machines a 2 color PNG works perfectly and is easier to get. Thinking about the ZX80 and the Jupiter Ace
And don't forget that these machines also have a border area. If I'm not mistaken it's always white on the ZX80 and ZX81 and always black on the Jupiter Ace.

Not completely true - take a look at https://spectrumcomputing.co.uk/entry/32034 - it generates a 320x240 display on ZX81 - also there a few other demos that goes beyond the 256pixels width. I know it's really edge cases, just to get the facts correct

/T

[kolbeck]

Exactly.

We will need 2 formats, that could be named as follows:

• Format ".s80": a sequence of 768 character codes from the ZX80 charset

• Format ".s81": a sequence of 768 character codes from the ZX81 charset

A converter should take a 256x192 monochrome image in BMP or SCR format, matching each 8x8 area against the corresponding charset. If any 8x8 area doesn't match any standard character, the image would be considered invalid thus abort with an error without converting anything. Ideally the converter should also be able to do the opposite, i.e convert a file with extension ".s80" or ".s81" to BMP or SCR.

Ideally .s80/s81 should be generated by emulator, in case the goal is to achieve 100% preservation. Converting from BMP/SCR can result in misinformation, not seen by the eye. For example print chr$ 126 gives a question mark, matching against zx81 charset would give the vaule 15 - which was not originally intended in this case.

Just something to consider.

/T

[Einar Saukas]

Ideally .s80/s81 should be generated by emulator, in case the goal is to achieve 100% preservation. Converting from BMP/SCR can result in misinformation, not seen by the eye. For example print chr$ 126 gives a question mark, matching against zx81 charset would give the vaule 15 - which was not originally intended in this case.

Not really. When you print a non-printable character like CHR$ 126, the ROM puts value 15 into screen memory. For non-hires screens, the method I described should produce exactly the same result as the emulator.

Although I agree that generating these files directly from emulators would be better!

[Einar Saukas]

Not completely true - take a look at https://spectrumcomputing.co.uk/entry/32034 - it generates a 320x240 display on ZX81 - also there a few other demos that goes beyond the 256pixels width.

Good point!

Therefore I suggest:

• Format .s80 and .s81 for standard non-hires ZX80 and ZX81 screens

• Format SCR for hires screens with regular size

• Format PNG for other screen sizes

[4thRock]

Not completely true - take a look at https://spectrumcomputing.co.uk/entry/32034 - it generates a 320x240 display on ZX81 - also there a few other demos that goes beyond the 256pixels width. I know it's really edge cases, just to get the facts correct

Thanks for the info it's important. On this case the .scr is just cropping the image, another format would be better (as Einar mentioned).
All these titles are marked as ZX81 Hi-res: WRX , right ?

Meanwhile, you might have noticed that ZX80 and ZX81 titles now display a white border by default.
There's also progress on displaying different border colours (using the existing .SCR and .GIFs), yet more work is needed.
This so that you guys know that this discussion is helpful and things are progressing in the background.

[Einar Saukas]

There's also progress on displaying different border colours (using the existing .SCR and .GIFs), yet more work is needed.

Currently all screenshots have black border by default, except ZX80/ZX81 screenshots that have white border by default.

However this information is configurable. For instance, the running screen for 10 OTHELLO has blue border, the running screens for Ad Lunam Plus have white border.

If anyone notices anything else that needs fixing, please help to fill this spreadsheet!

[4thRock]

Added a few more games to the spreadsheet!

[Einar Saukas]

Added a few more games to the spreadsheet!

Thank you!

[kolbeck]

First attempt at converting ZX81 screen dump in BMP to ASCII / ZX81 Character set.

Left is the ASCII (Unicode) Rendering, and Right is the BMP as produced by EightyOne. There are only a few characters not easily available for printing, but that's not important. The program also produces a 768 bytes file, containing values from 0-192 representing the ZX81 characters found.



/Thomas