#63 Missing option to select sprite size for MSX screens

[mi-chi]

RECOIL may fail to display MSX screens correctly if 8x8 sprites were used:
When converting MSX screens, it seems as if RECOIL always assumes a 16x16 sprite size.
The MSX, however, has two different sprite sizes, 8x8 and 16x16.
Images with 8x8 sprites will be converted wrong (see attached images).

Note that there is no way of telling from the contents of the input file which sprite size is currently active - it is only defined in the screen mode parameter.

While it is difficult to implement such an option in the image viewers, maybe this can be added to the command line converter "recoil2png.exe" (e.g. "-s 8" and "-s 16", where 16 is the default).

Please find attached 3 files:
- The original MSX Screen 2 image - LOTUSF3.SC2
- The image as shown on a MSX with 8x8 sprites selected (SCREEN <n>,0) - LOTUSF3_good_8x8.png
- The image as shown in RECOIL (and on a MSX with 16x16 sprites selected, SCREEN <n>,2) - LOTUSF3_bad_16x16.png</n></n>

[Piotr Fusik]

If the option would be triggered by a filename pattern (such as "_8x8" suffix), this wouldn't need any user interface, manual switching every time and would be compatible with all RECOIL ports.

[SD Snatcher]

The _8x8 suffix would make it complicated for the real MSX machines, that are limited to 8.3 filenames.

IMHO, the easier solution would be an alternative extension for the screen-2 images with 8x8 sprites, like .S82

[mi-chi]

Now THAT's an excellent idea!!! Take my vote for that!

[mi-chi]

Good point by SD Snatcher. Only I wouldn't want even more extensions.
Here's a more descriptive proposal:
Look for an accompanying text file with the same base name but a generic extension (e.g. ".txt" to make it obvious that this is a text file).
That file contain meta-information that belong to the image, e.g. specifications like"SPRITE_SIZE=8x8".

So for the example:
LOTUSF3.SC2 <- image
LOTUSF3.TXT <- meta-data file with the sprite size

Pros:
extensible - more specifications may be added in the future, for any format that may require it
obvious - to anyone who opens the text file.
* compatible - file names can still be 8.3) and could even be parsed on the MSX, if required.

Cons:
* You have to copy the text file together with the image...

[SD Snatcher]

The text file has some other contras:

1) A 720KB floppy disk can store around 51 screen-2 images. The number of files is doubled to 102 with text files, meaning that only 10 FAT directory entries would be free. This complicates the situation for picture disks, for example.

2) A real MSX can use at most FAT16. With large MSX Pixel Art collections on massive storage, the cluster size would cause the TXT file to occupy 8KB to 16KB on disk due to the slack space. IOW, a 50% to 100% increase in disk usage

But the we have to stop to think that there are very few images (in fact, just this one AFAIK) that use 8x8 sprites. And one easy alternative solution could be just to convert the 8x8 sprite data to the 16x16 format, since no information would be lost on static images. At most 32 sprites can be shown simultaneously on screen on both cases. A tool could be written to perform this conversion.

[mi-chi]

Hmmm, getting a bit theoretical now. Considering 16x16 sprites to be the default (as is now with RECOIL), you would only need the text file for screens that require an 8x8 sprite.
On the other hand, MSX uses 8x8 sprites as the default, unless otherwise specified.

And - for the sake of completeness, getting very MSX-technical now - think about the 4 sprites per line limit. This prevents an accurate conversion from 8x8 to 16x16 sprites lossless. The following code shows 8 (eight) 8x8 sprites in 8x8 sprite mode.

5 COLOR 15,1,7
10 SCREEN 2,0
20 SPRITE$(0)=STRING$(8,255)
30 FOR I=0 TO 7
40 PUT SPRITE I,(I*8,I*2),I+2,0
50 NEXT I
60 A$=INPUT$(1)

Change line 10 to "SCREEN 2,2" to switch to 16x16 sprites and you see only 4.
Change the Y in line 40 to "I * 3" to see the remaining 4 partial sprites.

OK, I think we now made Piotr lose any interest in resolving that for good. ;-)

[SD Snatcher]

On the other hand, MSX uses 8x8 sprites as the default, unless otherwise specified.

For the MSX-BIOS you're right, it's the default. But RECOIL is not an emulator, nor a BASIC interpreter. 😉 It's meant to be easy to use for the most common use case, that's by far 16x16 sprites.

The following code shows 8 (eight) 8x8 sprites in 8x8 sprite mode.

I tried to test it here, but unfortunately it only shows a black screen with a cyan border. No sprites at all.

OK, I think we now made Piotr lose any interest in resolving that for good. ;-)

😂
I hope he keeps interested as long as we come to a good conclusion.

[mi-chi]

Ah, typo, replace the parameters at the end in the line:

40 PUT SPRITE I,(I*8,I*2),I+2,0

I updated the post above.

[SD Snatcher]

Ok, got the idea. Since only 8 lines are drawn on 8x8 sprites, another sprite can be shown earlier than with 16x16 sprites.

One crazy simple idea could be to use the offset +5 as an extension to store extra info, since the MSX-BASIC ignores this byte contents.

bit0: 0=16x16 sprites, 1=8x8 sprites
bit1: 0=212 lines, 1=192 lines. This bit meaning would be inverted on screens <5.