Screenshots

Broken link? Feature request? Anything related to the Spectrum Computing website here.
lfaria
Dizzy
Posts: 85
Joined: Fri May 29, 2020 3:50 pm

Screenshots

Post by lfaria »

While browsing through the archive, I couldn't help noticing that (almost) all screenshots have a black border, both the "loading" ones and the "in-game" ones.
But that's not correct for some titles:
Although during loading the border is used for the usual (or less-usual) loading stripes, the current SCRtoImage.php usage only allows for 256x192 pixels screen capture, missing the border altogether,
during "in-game", the programmer had free reign on what should the border color be, or even if some fancy border effect was in place (aquaplane comes to mind). In this case SC is using a 256x192 GIF surrounded by a "fake" (i.e. generated on-the-fly) black border for most titles.

While for the former, I guess the current state is not too bad (as all titles will only show some more-or-less-common stripes, and the border is not supported by the .scr form),
in the latter, I think some more flexibility is needed: Some titles may be running with a different colored border, or even one of the titles listed as having "Border Effects" will surely display a more elaborate effect.
Again, using Aquaplane as example: The border shows a continuous horizon line during play. Luckily, this change just implies that the GIFs for these titles be re-created / captured and the "fake" border inhibited during browsing.

Is this doable?

It seems so, because some demos (for example BorderTrix) are already including the border in the image (i.e. a 320x240 png) and omitting the "fake" border.

What is needed? Identify the titles in question? Capture and provide the corresponding screenshots?
The referred Aquaplane would become, in GIF: Image and PNG: Image formats, respectively.
User avatar
4thRock
Manic Miner
Posts: 415
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal

Re: Screenshots

Post by 4thRock »

Currently, ZX-Image is set to output at 640x480 to match Spectrum Next screenshots - these come from an emulator at 640x480 and preserve some border area. Other machines (ATM) also use similar resolutions so it's a good compromise.
It also allows us to display screens with the same relative scale.

Of course missing border information now becomes apparent on some titles.
Check "Advanced Lawnmower Simulator" and compare Spectrum and Next screens.
The Spectrum screenshot really needs the green border! ;)

The easiest solution for these titles is to capture screenshots with the full border.
A good example is Sedge Warbloader
https://spectrumcomputing.co.uk/zxdb/si ... load-1.gif
At 352x296 it captures the full image raster.

There's a format for this ( .bsc ) that ZX-Image handles, but I don't know if any emulator supports it.
So PNG screenshots with the border will do I think - that's what we are doing for Next titles.


I'd say that identifying the titles would help. Not only border effects but also titles that have a non-black border.
Then yes, capture as PNG and provide the corresponding screenshots.

But please wait for Einar (and others) to comment before doing captures.
I don't know how this could be handled in ZXDB and across other sites using it.
User avatar
druellan
Dynamite Dan
Posts: 1466
Joined: Tue Apr 03, 2018 7:19 pm

Re: Screenshots

Post by druellan »

yeah, I agree that even without an effect the border is an important part of a ZX Spectrum game (Jet Set Willy my preferred example), but IMO we can't use PNG for a couple of reasons: there is no standard border width, every emulator seems to do their own thing, but more important, we might lost information on pixels that have the same ink as the paper, another very Speccy thing that worth to be preserved.

That .BSC format sounds interesting if we can find a way to capture it.
User avatar
4thRock
Manic Miner
Posts: 415
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal

Re: Screenshots

Post by 4thRock »

Yes, this has been discussed and there's no good universal solution.

For preservation we need the .scr because of hidden pixels and flash effects. No question there.
But we should preserve border information, therefore a PNG also makes sense. We can have both I think.

Standard border width is known. The Spectrum pixels are considered to be square, and the Spectrum is a PAL computer.
Digital square pixel PAL is 768x576 at full resolution, or 384x288 at half resolution ;)
Unfortunately not all emulators pay attention to this.
akeley
Dynamite Dan
Posts: 1025
Joined: Sat Feb 01, 2020 5:47 pm

Re: Screenshots

Post by akeley »

There is a very simple solution of course: take a photo of the original output on the CRT :)
lfaria
Dizzy
Posts: 85
Joined: Fri May 29, 2020 3:50 pm

Re: Screenshots

Post by lfaria »

4thRock wrote: Wed Jul 22, 2020 12:21 pm Standard border width is known. The Spectrum pixels are considered to be square, and the Spectrum is a PAL computer.
Digital square pixel PAL is 768x576 at full resolution, or 384x288 at half resolution ;)
Unfortunately not all emulators pay attention to this.
Isn't it 625 lines/frame, split in two 312.5 line fields (the speccy generates video in one but not on the other)?
Chris Smith detailed in his ULA book that the video generated by the speccy is 48+256+48 pixels wide, giving a 352 total.
User avatar
4thRock
Manic Miner
Posts: 415
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal

Re: Screenshots

Post by 4thRock »

Yes, those are analog PAL timings. But remember that only 576 lines were supposed to be visible.
https://en.wikipedia.org/wiki/576i

You are right mentioning that the pixels are not 100% square. 352 total "pixels" are not 384.
To account for this, you'd need to display 256x192 screens at 279x192, right ? :lol:
But the slightly non-square pixels are ignored by all software, including the BASIC Circle command.

For the sake of discussion 704x576 or 352x288 are valid DVD and broadcast resolutions.
So I have no problem in accepting them as correct for preservation purposes.
But 768x576 or 384x288 are the closest square pixel equivalents for display....

That's why I say... it's a complicated issue :D
User avatar
druellan
Dynamite Dan
Posts: 1466
Joined: Tue Apr 03, 2018 7:19 pm

Re: Screenshots

Post by druellan »

I wonder if the .scr format has the flexibility to add an extra byte somewhere to preserve the border color. I know for example that FUSE extended the format to accommodate Timex screen modes.
If this value exist, is up to the renderer or the final app to display a border.
lfaria
Dizzy
Posts: 85
Joined: Fri May 29, 2020 3:50 pm

Re: Screenshots

Post by lfaria »

druellan wrote: Thu Jul 23, 2020 11:25 am I wonder if the .scr format has the flexibility to add an extra byte somewhere to preserve the border color. I know for example that FUSE extended the format to accommodate Timex screen modes.
If this value exist, is up to the renderer or the final app to display a border.
AFAIK, there is no .scr file format as such, a .scr file is just a VRAM memory dump, with no header, footer, formatting, meta-data or anything else.
The loader application has to assume how to interpret the data.
If it only contains standard speccy screen data or anything else in addition is only visible from the file size (standard screen would be 8192 bytes).
User avatar
4thRock
Manic Miner
Posts: 415
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal

Re: Screenshots

Post by 4thRock »

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...
lfaria
Dizzy
Posts: 85
Joined: Fri May 29, 2020 3:50 pm

Re: Screenshots

Post by lfaria »

4thRock wrote: Fri Jul 24, 2020 9:11 am 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.
User avatar
4thRock
Manic Miner
Posts: 415
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal

Re: Screenshots

Post by 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
Manic Miner
Posts: 208
Joined: Wed Jul 08, 2020 8:42 am

Re: Screenshots

Post by zup »

lfaria wrote: Fri Jul 24, 2020 9:24 amAnd 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.
User avatar
druellan
Dynamite Dan
Posts: 1466
Joined: Tue Apr 03, 2018 7:19 pm

Re: Screenshots

Post by druellan »

4thRock wrote: Fri Jul 24, 2020 9:11 am 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.
User avatar
Guesser
Manic Miner
Posts: 639
Joined: Wed Nov 15, 2017 2:35 pm
Contact:

Re: Screenshots

Post by Guesser »

Animated png is widely supported now https://caniuse.com/#feat=apng
User avatar
Einar Saukas
Bugaboo
Posts: 3070
Joined: Wed Nov 15, 2017 2:48 pm

Re: Screenshots

Post by 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.
User avatar
moroz1999
Manic Miner
Posts: 329
Joined: Fri Mar 30, 2018 9:22 pm

Re: Screenshots

Post by 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.
User avatar
pavero
Dynamite Dan
Posts: 1569
Joined: Sat Dec 09, 2017 11:49 pm
Location: The Czech Republic
Contact:

Re: Screenshots

Post by 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.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Screenshots

Post by R-Tape »

pavero wrote: Fri Jul 24, 2020 9:12 pm 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.
User avatar
Einar Saukas
Bugaboo
Posts: 3070
Joined: Wed Nov 15, 2017 2:48 pm

Re: Screenshots

Post by Einar Saukas »

R-Tape wrote: Fri Jul 24, 2020 10:24 pm
pavero wrote: Fri Jul 24, 2020 9:12 pm 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? :)
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Screenshots

Post by R-Tape »

Einar Saukas wrote: Sat Jul 25, 2020 12:30 am 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.
User avatar
4thRock
Manic Miner
Posts: 415
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal

Re: Screenshots

Post by 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 :D
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.
User avatar
Einar Saukas
Bugaboo
Posts: 3070
Joined: Wed Nov 15, 2017 2:48 pm

Re: Screenshots

Post by Einar Saukas »

R-Tape wrote: Sat Jul 25, 2020 1:49 pmAye 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.
Last edited by Einar Saukas on Sun Jul 26, 2020 3:03 am, edited 2 times in total.
User avatar
Einar Saukas
Bugaboo
Posts: 3070
Joined: Wed Nov 15, 2017 2:48 pm

Re: Screenshots

Post by Einar Saukas »

4thRock wrote: Sat Jul 25, 2020 2:53 pmFor the ZX81, a character based format makes sense ( 24x32=768 bytes ) for preservation.
Exactly.

4thRock wrote: Sat Jul 25, 2020 2:53 pmIf 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.

4thRock wrote: Sat Jul 25, 2020 2:53 pmFor monochrome machines a 2 color PNG works perfectly and is easier to get. Thinking about the ZX80 and the Jupiter Ace :D
I think a monochrome SCR (black INK/white PAPER) works even better in this case.

4thRock wrote: Sat Jul 25, 2020 2:53 pmAnd 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 :)
User avatar
4thRock
Manic Miner
Posts: 415
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal

Re: Screenshots

Post by 4thRock »

Einar Saukas wrote: Sun Jul 26, 2020 3:02 am
4thRock wrote: Sat Jul 25, 2020 2:53 pmFor monochrome machines a 2 color PNG works perfectly and is easier to get. Thinking about the ZX80 and the Jupiter Ace :D
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 ;)

Einar Saukas wrote: Sun Jul 26, 2020 3:02 am
4thRock wrote: Sat Jul 25, 2020 2:53 pmAnd 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...
Post Reply