Does it exist a PC program that does BMP to SCR2 conversion

1) optimizing the X allignement of the BMP in order to reduce the colorclash
2) genarting and displacing the sprites in some otptimal way in order to reduce the colorclash by masking the backgound?

The SW should start from a 16 color BMP with X size =< 256

The optimization problem is far than trivial, as sprites have a lot of limits
and the two steps (X allignement with sprite displacing) could interact.

Adding a palette matching algorithm and enhanced multicolor sprites,
such a program could be used to get best scr4 eva files
(D&D& demo et similia)

It is a difficult task (both as math problem and as programming problem)
but maybe could lead to nice results

BMP2MSX does all graphical screens afaik.. but without sprites.

sprites does the difference

Yep, well, have a single codeday and make a converter. bmp->sc2 with sprite converters are typical specialist-tools ppl tend to make themself..

Dunno, doesn't sound like something you'd code in a day. To properly implement a routine that can scan for 'colorclash' artifacts and the best way to mask them using he very limited sprite capabilities of the MSX1 does not sound like an easy task. The MSX2 sprite capabilities aren't that much better, so I doubt even on SC4 it'd really be easy, unless the picture was made with SC4 in mind. Anyhow... good luck!

I made such a tool (which stays an in-house tool) for smaller images, with various image-modifiers and sprite settings. In one day Well, two in total, but that includes making the insane parameter editing and the colormatch routines (started HUE-based but that's totally not required at all, so I went back to a simple RGB-based matcher).

That's the thing, for smaller images it becomes easier to determine where and when to use the sprites... Don't forget you have only a few of those...

Well, best would be to just accept sc2 for what it is, and don't expect miracles from a generic converting algo. The best results come from pixelmeisters spending hours on pixels and sprites manually..

wolf_: three days, right? One extra for all the buttons, right?

I once saw such a tool for the color gameboy. It used a genetic algorithm to determine the best match:
It "simply" tried all kind of random conversions filtering out bad ones and combining the good ones. after a few hunderds of iterations the conversion was verry close. they claimed to have an in-house version that also used sprites to even enhance the image.
To bad I don't remember the name of the proggy

The masking using the sprites is an optimization problem that seems very hard

0) do scr2 conversion using only tiles (not easy by itself)
1) find all the scr2 errors due to colorclash
2) define a set of elementary shapes to mask errors (one for error)
3) select and merge the shapes in 16x16 sprites according to where they are and to the color they have, taking into account the sprites limits

Now think again to the whole thing considering that somewhere you could get better results at step 0
doing tile definitions knowing that the sprites can mask some errors !!

I see that the sole statement of the problem is quite hard and that the coding cannot neither start without a solution.
All the stuff isn't very linear nor "easy go"

Step 0 and 1 aren't that hard to optimise. The max possibilities for color clash optimisation is 8 (2 colors per line per 8 pixels). All to do is try the 8 possibilities and count the color clashes.

As for the colorclash.... that's a lot harder. Depending on what you're converting; black is the best color most of the times (for cartoonish images).

If you want to convert animations/video perhaps the colorclash isn't a major problem as it will be visible for only a short period of time.

Actually, that would not be the ideal way to go about it... The real difficult part is that steps 0 - 3 should actually be a single step. Since a single sprite can cover as many as 9 tiles (albeit partially) there is a distinct possibility that the 'best result' can be obtained by *not* choosing the most logical colors for the tiles, in order to allow the sprite to cover a larger area (in a manner of speaking). The first step would therefor probably be to determine *where* the sprites should be located, most likely based on the areas of the screen where the color-count per tile-line is highest. Only after knowing where the spites are needed the most, does calculating colors make any sense. Needless to say the recursiveness (or plain old l00pn3ss) of such a routine is going to cause quite the headaches... Not something I'd like to attempt...

@mr.T.:Errrrrhhhhh you're right.