Re: Contributing to ScummVM with an interpreter for Magnetic Scrolls?
dettus <[email protected]> Sun, 5 May 2019 11:28:10 +0200
| Newsgroups | gmane.games.devel.scummvm |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============5722514290210208253== Content-Type: multipart/alternative; boundary="------------204351C489DE1CFD553E16A0" Content-Language: en-US This is a multi-part message in MIME format. --------------204351C489DE1CFD553E16A0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Oh, sorry... THREE QUESTIONS! 1. STARTUP: How do I tell my engine where the binaries are? I would assume that Magnetic::loadGameData(strid_t file) has been added for that purpose. However, looking at the code in detection.cpp, I fear that it is not such a straight-forward process? Plus: I would be needing two files for each game? (.mag and .gfx) 2. How do I get to Magnetic::runGame()? 3. BUILDING: My engine can be encapsulated in a static library. That would require to add it to the makefile, so that the final linker could do an -ldMagnetic, and a -I for the include path. Where would be the best place to do so? On 5/5/19 11:20 AM, dettus wrote: > > Hello. > > > Don't worry. I do not think that would be necessary. > The way I currently envision it, is that animations are merely a bunch > of pictures. Lets say pic55.raw-pic67.raw. And that the magnetic > engine would instruct ScummVMGLK every 100ms to draw an individual one > of those. Or something. > > > > So... I cloned ScummVM yesterday, and I started looking into the > engine/glk directory. You already prepared a Magnetic::runGame(), how > lovely! > > My plan is that I use your frotz engine as a guideline and work my way > up from there. The .raw format for pictures seems pretty straight > forward, I can easily convert into that format. Not a problem!! > > > > > TWO QUESTIONS: > > 1. STARTUP: How do I tell my engine where the binaries are? I would > assume that Magnetic::loadGameData(strid_t file) has been added for > that purpose. However, looking at the code in detection.cpp, I fear > that it is not such a straight-forward process? Plus: I would be > needing two files for each game? (.mag and .gfx) > 2. BUILDING: My engine can be encapsulated in a static library. That > would require to add it to the makefile, so that the final linker > could do an -ldMagnetic, and a -I for the include path. Where would be > the best place to do so? > > > > Thomas > > > P.S.: I would also prefer to forget about xGLK as frontend, and > concentrate on supporting scummVMGLK. > > > > On 5/5/19 10:58 AM, Paul Gilbert wrote: >> 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] >> <mailto:[email protected]>> wrote: >> >> Sounds like a compromise. How fast is it? Would it be able to >> handle animations? >> >> >> _______________________________________________ >> Scummvm-devel mailing list >> [email protected] >> https://lists.scummvm.org/listinfo/scummvm-devel > > _______________________________________________ > Scummvm-devel mailing list > [email protected] > https://lists.scummvm.org/listinfo/scummvm-devel --------------204351C489DE1CFD553E16A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p>Oh, sorry...</p> <p>THREE QUESTIONS!<br> 1. STARTUP: How do I tell my engine where the binaries are? I would assume that Magnetic::loadGameData(strid_t file) has been added for that purpose. However, looking at the code in detection.cpp, I fear that it is not such a straight-forward process? Plus: I would be needing two files for each game? (.mag and .gfx)<br> 2. How do I get to Magnetic::runGame()?<br> 3. BUILDING: My engine can be encapsulated in a static library. That would require to add it to the makefile, so that the final linker could do an -ldMagnetic, and a -I for the include path. Where would be the best place to do so?</p> <div class="moz-cite-prefix">On 5/5/19 11:20 AM, dettus wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <p>Hello.</p> <p><br> </p> <p>Don't worry. I do not think that would be necessary.<br> The way I currently envision it, is that animations are merely a bunch of pictures. Lets say pic55.raw-pic67.raw. And that the magnetic engine would instruct ScummVMGLK every 100ms to draw an individual one of those. Or something.</p> <p><br> </p> <p><br> </p> <p>So... I cloned ScummVM yesterday, and I started looking into the engine/glk directory. You already prepared a Magnetic::runGame(), how lovely! <br> </p> <p>My plan is that I use your frotz engine as a guideline and work my way up from there. The .raw format for pictures seems pretty straight forward, I can easily convert into that format. Not a problem!!<br> </p> <p><br> </p> <p><br> </p> <p><br> </p> <p>TWO QUESTIONS:</p> <p>1. STARTUP: How do I tell my engine where the binaries are? I would assume that Magnetic::loadGameData(strid_t file) has been added for that purpose. However, looking at the code in detection.cpp, I fear that it is not such a straight-forward process? Plus: I would be needing two files for each game? (.mag and .gfx)<br> 2. BUILDING: My engine can be encapsulated in a static library. That would require to add it to the makefile, so that the final linker could do an -ldMagnetic, and a -I for the include path. Where would be the best place to do so?</p> <p><br> </p> <p><br> </p> <p>Thomas<br> </p> <p><br> </p> <p>P.S.: I would also prefer to forget about xGLK as frontend, and concentrate on supporting scummVMGLK.<br> </p> <p><br> </p> <p><br> </p> <div class="moz-cite-prefix">On 5/5/19 10:58 AM, Paul Gilbert wrote:<br> </div> <blockquote type="cite" cite="mid:CAEkg9ROuujV3HGpqKUX=EduCFaAhos663Vmrp6BsD1xNGfeRHQ@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> <div>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.</div> <div><br> </div> <div>Paul.</div> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">On Sun, May 5, 2019 at 5:06 PM Thomas Dettbarn <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> <p>Sounds like a compromise. How fast is it? Would it be able to handle animations? </p> </div> </blockquote> <div> </div> </div> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ Scummvm-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a> <a class="moz-txt-link-freetext" href="https://lists.scummvm.org/listinfo/scummvm-devel" moz-do-not-send="true">https://lists.scummvm.org/listinfo/scummvm-devel</a> </pre> </blockquote> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ Scummvm-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="https://lists.scummvm.org/listinfo/scummvm-devel">https://lists.scummvm.org/listinfo/scummvm-devel</a> </pre> </blockquote> </body> </html> --------------204351C489DE1CFD553E16A0-- --===============5722514290210208253== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU2N1bW12bS1k ZXZlbCBtYWlsaW5nIGxpc3QKU2N1bW12bS1kZXZlbEBsaXN0cy5zY3VtbXZtLm9yZwpodHRwczov L2xpc3RzLnNjdW1tdm0ub3JnL2xpc3RpbmZvL3NjdW1tdm0tZGV2ZWwK --===============5722514290210208253==--