wow so interrupts are disabled during loading - i guess they woudl be that makes sense - that was why the masterbasic audio routine sort of slowed down during loading stuff then!
On 31/05/2011, Leszek Chmielewski <retr...@gmail.com> wrote: > 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 <rogerjow...@gmail.com> > >> 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 <retr...@gmail.com> 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 <stefan.dris...@gmail.com> >> > >> >> 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: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] >> On >> >> Behalf Of Roger Jowett >> >> Sent: zaterdag 28 mei 2011 01:56 >> >> To: sam-users@nvg.ntnu.no >> >> 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? >> >> >> >> >> > >> >
