Yes, but it will produce "jumps" between Frames and interlacing will also stop when loading (loading will switch the interrupts off) unless you code own loading routines. And again: Delta method will decompress on the fly, unless you are talking about decompression of additionaly compressed delta chunk.
2011/5/31 Roger Jowett <[email protected]> > so interlaced video could just display the same two frame for any > number of frames until it had loaded or decompressed another tow > frames... > > On 30/05/2011, Leszek Chmielewski <[email protected]> wrote: > > That is how delta compression (in Retro-X) works. It stores the > difference > > between two screens in s interleaved sequence of unchanged and changed > byte > > sequences (omniting 1 and 2 unchanged bytes so save more space and gain > > speed, so copy them to screen even if unchanged). > > You can store e.g.: > > 50 bytes are unchanged, so skip these 50 bytes by increase pointer of > > current screen adress by 50 > > 14 bytes are changed, so copy these 15 bytes from memory to screen > > 96 bytes are unchanfged, skip! > > 67 bytes are changed, copy... > > You can see, it is primitive, but allows to store many frames if there > are > > only small differences. You even do not need a flag byte becaues it is > > always the same sequence: Skips with size data and blits with size data > and > > bytes data. > > I wrote a decoder for Spectrum only (allowing ca 50 fps if the frame size > is > > below 2 kb), but I cannot code that good on SAM in Assembler, with all > the > > bank management. I think, the SAM can display 50 FPS Delta animations > with > > frame size of 3 KB (166 Frames stored on SAM 512=3.25 seconds animation > at > > 50 FPS) or 6.5 Seconds at 25 FPS. At 10 FPS (still fluid, 16,5) Seconds > can > > be stored) > > > > Best regards > > LCD > > > > > > > > 2011/5/30 Stefan Drissen <[email protected]> > > > >> All you need are the differences (without compressing anything). Instead > >> of > >> saving raw screen$ data, you generate the difference between two frames > as > >> optimized machine code that only updates the screen addresses that need > >> updating. There is a tipping point at which it would be quicker to > simply > >> refresh the entire screen. You may also want to insert entire screen > >> refreshes every X frames to allow a fast forward. > >> > >> This cannot be that difficult. > >> > >> Regards, > >> > >> > >> Stefan > >> > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] > On > >> Behalf Of Roger Jowett > >> Sent: zaterdag 28 mei 2011 01:56 > >> To: [email protected] > >> Subject: Re: Loading stuff from machine code with the ROM functions > >> > >> ok this is it my last daft email to the gang of 4! > >> please > >> as i dont have a clu > >> if masterbasic compresses a screen when it saves it > >> what would happen if you take two screens from my animation > >> if you compress them both and look at teh two compressed screen fils > >> surely the difference between teh two comrepssed screens is teh tiny > >> onscreen difference between one screen$ and teh next - no i didnt > >> think so either but still clutching at straws is fun > >> surely once you have decompresed teh first screen the rest only really > >> need to be the tiny differences that are made to that first image > >> though > >> i realise ol z80b is sturgling to get 4kb into video ram and that is > >> jsut with copying not reading from a port whichshe has to do to read > >> teh atom > >> is there no other way of ziping things up a bit please? > >> > >> > > >
