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? > >
