Re: Contributing to ScummVM with an interpreter for Magnetic Scrolls?
Paul Gilbert <[email protected]> Sun, 5 May 2019 18:58:40 +1000
| Newsgroups | gmane.games.devel.scummvm |
|---|---|
| Message-ID | <CAEkg9ROuujV3HGpqKUX=EduCFaAhos663Vmrp6BsD1xNGfeRHQ@mail.gmail.com> |
--===============8426571244996784119== Content-Type: multipart/alternative; boundary="0000000000003eb8e90588203285" --0000000000003eb8e90588203285 Content-Type: text/plain; charset="UTF-8" It doesn't add any significant delay. An individual picture is only decoded when a ".raw" file is opened, and the virtual filesystem pretty much simply wraps the results of the Infocom decompression code in a stream so that all file reads read from that memory buffer. As for animations, that'll be an interesting question. The Glk code only deals with drawing static pictures by frame number. So it's likely the existing Magnetic engine does it's own manual handling of animations currently. If so, I could probably add code to present the animations as if they were a graphics format that supports frames, like APNG or GIF, then have the core Glk handle drawing the animation when an animated picture number is specified for drawing. Maybe.. I'll have to see how it goes. Paul. On Sun, May 5, 2019 at 5:06 PM Thomas Dettbarn <[email protected]> wrote: > Sounds like a compromise. How fast is it? Would it be able to handle > animations? > --0000000000003eb8e90588203285 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>It doesn't add any significant delay. An individu= al picture is only decoded when a ".raw" file is opened, and the = virtual filesystem pretty much simply wraps the results of the Infocom deco= mpression code in a stream so that all file reads read from that memory buf= fer. As for animations, that'll be an interesting question. The Glk cod= e only deals with drawing static pictures by frame number. So it's like= ly the existing Magnetic engine does it's own manual handling of animat= ions currently. If so, I could probably add code to present the animations = as if they were a graphics format that supports frames, like APNG or GIF, t= hen have the core Glk handle drawing the animation when an animated picture= number is specified for drawing. Maybe.. I'll have to see how it goes.= </div><div><br></div><div>Paul.</div><br><div class=3D"gmail_quote"><div di= r=3D"ltr" class=3D"gmail_attr">On Sun, May 5, 2019 at 5:06 PM Thomas Dettba= rn <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote= :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u> =20 <div><p>Sounds like a compromise. How fast is it? Would it be able to handl= e animations?=C2=A0</p></div></blockquote><div>=C2=A0</div></div></div> --0000000000003eb8e90588203285-- --===============8426571244996784119== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU2N1bW12bS1k ZXZlbCBtYWlsaW5nIGxpc3QKU2N1bW12bS1kZXZlbEBsaXN0cy5zY3VtbXZtLm9yZwpodHRwczov L2xpc3RzLnNjdW1tdm0ub3JnL2xpc3RpbmZvL3NjdW1tdm0tZGV2ZWwK --===============8426571244996784119==--