MSX Screen Conversor 0.7

again: newspost when changelog comes in (and when some MRC crew member's got the time to post about it).

I was proposing to Rafael a standalone application too.
As local compiled application should work even faster.

In addition I was also proposig to develop a differential encoding for animated gif or multiframe images
The encode should produce only the PNT and the tile that canged w.r.t. the previous frame.
Providing an output format like

frame 0
VRAM address, Data len, raw data
VRAM address, Data len, raw data
VRAM address, Data len, raw data
ect.
endframe 0
frame 1
VRAM address, Data len, raw data
VRAM address, Data len, raw data
VRAM address, Data len, raw data
ect.
endframe 1
ect.
endframe X
end frames

should lead to a strigthforward decoder for SCR2 animations.
Using this solution something like D&D demo would be possible even
on MSX1, as you move only areas where there are changes.
Moreover the fix palette should help to not change too much
the still graphics around the animated part of the screen.

http://ragozini.googlepages.com/showPreview.php.png/showPreview.php-full.jpg

excellent converter for scr2 and mexs1 palette

Why not releasing the converter as standalone application?

Like this ?
http://ragozini.googlepages.com/CRAB.ROM

;)
(it doesn't respect the i/o timings of msx1, only for emulators and msx2)

It is from one of the many Metal Slug XXX
It comes from a web page, so I do not know which one

Jannone, you're the man!

Congrats, budy!

@dvick
what about my proposal to do a sort of differential encoding between adjacent frames ?
This could reduce the amount of tiles to be transferred.
It could work updating tiles only partially (e.g. only half a tile
There are two ways to do this encoding:

1) encode each frame independently, find the differences between VRAM dumps and store them in "player ready" format

2) try to encode couple of frames, in order to maximize the common tiles between frames, and than find the differences between VRAM dumps and store them in "player ready" format

Option 2) can work well even without suboptimalities. I mean,e.g., that in case of a 8x1 area you can have two equivalent
representation with the same result by reverting foreground/background and bits in the shape.

For differential encoding, this is an unusefull waste of bandwidth that could be avoided with joint encoding.

Moreover, introducing some suboptimalities, you could "control" the datarate to the VRAM