VDPENC

Page 4/13
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9

Par ARTRAG

Enlighted (6862)

Portrait de ARTRAG

15-05-2007, 12:33

It is incredible how quality improves using an adpted palette,
if we switch to screen 4 you get...

http://ragozini.googlepages.com/francesco_scr4.rar

(Expand in a disk and run on MSX2)

Par jltursan

Prophet (2619)

Portrait de jltursan

15-05-2007, 16:26

Amazing! oO

It's really incredible the amount of detail of the video. The SC4 restrictions are nearly invisible!

Par ARTRAG

Enlighted (6862)

Portrait de ARTRAG

15-05-2007, 16:33

And at 768bytes per frame...;-)

Par pitpan

Prophet (3152)

Portrait de pitpan

15-05-2007, 16:41

If you move it, it is never a problem. Do you remember the DRAGON'S LAIR demo by Nyyrikki? AFAIK, it is pure SC4 (or SC2+MSX2 palette).

I wonder what would be the result of using VDPENC on DRAGON'S LAIR videos... Applying the frame-change technique, it think that the whole game would be feasible as a *BIG* MegaROM for MSX1/2.

Par ARTRAG

Enlighted (6862)

Portrait de ARTRAG

15-05-2007, 17:24

Well, video quality is a matter of trade off.
The more frames you encode using the same tilesets, the lower is the quality of the result.

Moreover, for long videos, finding the good sequences to be encoded jointly is an open problem by itself that needs a tool ad hoc.

Actually, due to memory limitations, I do not think that we can encode more than 50 frames jointly
(maybe up to 150 moving from matlab to C) .

At 10fps this means from 5 to 15 secs of uninterrupted video.
After this period you need to update the tilesets and this implies a short pause of few frames.

Now, each uncoded frame takes only 768 byte (the PNT), so the z80 can spend its time in other tasks,
like decoding compressed frames or playing PCM audio.
(Differential encoding across frames is on the to do list.)

BTW a nice idea is to develop an algorithm where a given amount of tiles can change from
one frame to the next....

Provided that all the update must be restricted to the Vblank, we could update up to 48 tiles each
frame -e.g. 16 per tileset.

This solution would require an higher z80 load (it moves 1536 bytes at each frame change)
but we get a better adaptation to the frame, and theorically, an uninterrupted replayer
- provided that the scene has no large discontinuities across frames.

This seems the same problem of changing color palette each line...
http://www.msx.org/forumtopic7311p30.html
Anyway it is for later ;)

Par ARTRAG

Enlighted (6862)

Portrait de ARTRAG

15-05-2007, 18:37

new video in src4 added
http://ragozini.googlepages.com/vdpenc2
(i.e. a new encoding of the same video)

Par [WYZ]

Champion (448)

Portrait de [WYZ]

15-05-2007, 20:52

Great! Also you can try to RLE compress every frame and a fast dump to vram.

Par ARTRAG

Enlighted (6862)

Portrait de ARTRAG

15-05-2007, 21:18

As now the z80 stays idle for 9 and half frames out 10, we can do much more than RLE
Wink

Par ARTRAG

Enlighted (6862)

Portrait de ARTRAG

16-05-2007, 11:43

Now online, new tests on an video sequence of 43 frames, with and without dithering.

http://ragozini.googlepages.com/vdpenc2

Definitely, I would like to have an efficient and optimized way to pass from a 8x8 bitmap block (24 bits RGB)
to screen2 (with an assignet palette) with and without dithering.

Par ARTRAG

Enlighted (6862)

Portrait de ARTRAG

16-05-2007, 11:55

Now, without dithering my converter works like this:

function [ OUT ] = quantize( T )
%QUANTIZE Summary of this function goes here
%  
% T is NVx192 matrix encoding NV 8x8 blocks 
% each row vector correspondes to a 8x8 block in RGB - i.e. 8x8x3=192
% columns 1:64 are red, columns 65:128 are blue, columns 129:192 blue
% the 8x8 block is scanned by row
%
% OUT has the same structure of T and returns the NV 8x8 blocks
% encoded in screen 2 of a TMS9918

% RGB palette of the TMS9918
pal = [ 0, 0, 0
        0, 0, 0
        0, 241, 20
        68, 249, 86
        85, 79, 255
        128, 111, 255
        250, 80, 51
        12, 255, 255
        255, 81, 52
        255, 115, 86
        226, 210, 4
        242, 217, 71
        4, 212, 19
        231, 80, 229
        208, 208, 208
        255, 255, 255 ];



% number of blocks to be converted
NV = size(T,1);

C = uint8(zeros(size(T)));

R = T(:,1:64);
G = T(:,65:128);
B = T(:,129:192);

% encode each block individually
for j=1:NV
    r = uint8(zeros(1,64));
    g = uint8(zeros(1,64));
    b = uint8(zeros(1,64));
    
    % encode each block line by line
    for n=0:7
        t = [(n*8):(n*8+7)] + 1;
      
        p = [ R(j,t)' G(j,t)' B(j,t)'];		% this is 8x3 matrix representing a line

        % scan all possible couples of colors for each line
	  % the couples of backgound-foreground colors are numbere 
        % avoiding duplications  - there are 105 possibilities
        dold=1e41;
	for c1=2:16;
     		for c2=(c1+1):16;
	            c = [pal(c1,:) ; pal(c2,:)];	% this is 2x3 matrix with the 2 tentative colors
      	            [x,i]=min(distfun(p,c)');	% associate the 8 points to the closest of the 2 colors
            	    d=sum(x);
	            if d

any suggestion to improve this routine or on the way to introduce dithering within the 8x8 block?

Page 4/13
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9