Re: Contributing to ScummVM with an interpreter for Magnetic Scrolls?

dettus <[email protected]> Mon, 6 May 2019 07:09:18 +0200
Newsgroups gmane.games.devel.scummvm
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============0793746560762891533==
Content-Type: multipart/alternative;
 boundary="------------DDBB74DC7703DE8FF03406BD"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------DDBB74DC7703DE8FF03406BD
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

2) Splendid!

So, if you could write me code to get into this runGame() function, (and 
get me the filename ;) ) I could take it from there.


Currently, what I have downloaded from 
https://msmemorial.if-legends.org/magnetic.php is in a folder that looks 
like this:


-rw-r--r-- 1 dettus dettus  951497 Mar  3 17:59 ccorrupt.gfx
-rw-r--r-- 1 dettus dettus  177185 Mar  3 17:59 ccorrupt.mag
-rw-r--r-- 1 dettus dettus  669633 Mar  3 17:59 cguild2.gfx
-rw-r--r-- 1 dettus dettus  141766 Mar  3 17:59 cguild2.mag
-rw-r--r-- 1 dettus dettus  199160 Mar  3 17:59 fish.gfx
-rw-r--r-- 1 dettus dettus  162858 Mar  3 17:59 fish.mag
-rw-r--r-- 1 dettus dettus  212224 Mar  3 17:59 guild.gfx
-rw-r--r-- 1 dettus dettus  130858 Mar  3 17:59 guild.mag
-rw-r--r-- 1 dettus dettus  271104 Mar  3 17:59 jinxter.gfx
-rw-r--r-- 1 dettus dettus  156458 Mar  3 17:59 jinxter.mag
-rw-r--r-- 1 dettus dettus   32540 Mar  3 17:59 myth.gfx
-rw-r--r-- 1 dettus dettus   99370 Mar  3 17:59 myth.mag
-rw-r--r-- 1 dettus dettus  276612 Mar  3 17:59 pawn.gfx
-rw-r--r-- 1 dettus dettus  103466 Mar  3 17:59 pawn.mag
-rw-r--r-- 1 dettus dettus 2534113 Mar  3 17:59 wonder.gfx
-rw-r--r-- 1 dettus dettus  183916 Mar  3 17:59 wonder.mag

and the md5 sums are

323804d54bffdc57d1626752f0d66582  ccorrupt.mag
9fb0ae1574ed4ac1616d850e4041269d  cguild2.mag
1c403e3b5a9d6669b0f3f3660c6a41aa  fish.mag
3416832716a172d33855eafedcdfa1bd  guild.mag
ab1cd85a27d1418627131675140c9241  jinxter.mag
fc288c842e77f5cffd43f777346fc2c3  myth.mag
c732efef48ed4d33b03ad724e200f3dd  pawn.mag
a00f0d63e3942a63f132e988272de7a7  wonder.mag
584886e9c4218523b55190e079dc4952  ccorrupt.gfx
48e1e3da2e02c9dedfdf0693ef1077ae  cguild2.gfx
f0b61389d3cd65aeb719fba84a864f88  fish.gfx
016dc876c53e23e99e4493e8c5673f5f  guild.gfx
962c50a12cd929580dd13f57a67667f0  jinxter.gfx
8b419437a01ea36652cc3a917a22caaf  myth.gfx
342a6e73689368cc130c88ed0d8c8128  pawn.gfx
66b2865437d680829bb372f2dca0df3a  wonder.gfx



ONE MORE QUESTION THOUGH:

4) What is the policy with rookie developers like me, in general? Should 
I just clone code from the git repository, commit/push/pull my changes? 
Or do you guys create a branch? And merge the code over after a 
reviewing process or something? Or, in other words: What do I do with my 
code, once it has been written?


Thomas


On 5/5/19 11:07 PM, Paul Gilbert wrote:
> Hey,
>
> 1) You don't need to. ScummVM is built around detection entries for 
> known games. If you look at the detection.cpp and detection_tables.h 
> for the other sub-engines, you'll see how md5s are set up. Once a 
> known game for the subengine is found, the Glk base class opens it up 
> in _gameFile, which a file object you can use to read the contents. A 
> few other things. You can use ConfMan.get("path") to get a reference 
> to the current folder, which may be useful tor detecting if the given 
> game has additional graphics/sount/hint files. If you look elsewhere 
> in the engine, some of the other sub-engines already do that, so you 
> can use them as a guide. The engine also has a getFilename() method to 
> get the name of the main game filename, so you can use that as a basis 
> for figuring out whe secondary filenames for gfx/snd/hints should be.
>
> 2) Currently the Magnetic Scrolls skeleteon isn't hooked up. If you 
> have a look at glk/detection.cpp, there's a couple of places where the 
> different sub-engines are referred to, you could easily see how 
> Magnetic needs to be similarly hooked in. Just look for occurrences of 
> "Glulxe" for example. Alternatively, if you wait a couple of days, 
> I'll move onto working on the Glk Magnetic sub-engine myself, and set 
> up the necessary framework. You'll then be able to branch it to your 
> own branch, and rip out preliminary code for the engine, keeping the 
> hooked up detection framework.
>
> 3) I'm not really familiar with library/linking, sorry. I use VIsual 
> Studio,, and use the create_project tool to create a solution file for 
> the engines and core in one executable. Maybe someone else can chime in.
>
> Paul.
>
>
>
> Once you've successfully added detection for one of the games, and 
> it's added to the list of installed games in the launcher, just 
> double-clicking on the game entry
>
>
>
>
> On Sun, May 5, 2019 at 7:28 PM dettus <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     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]  <mailto:[email protected]>
>>>     https://lists.scummvm.org/listinfo/scummvm-devel
>>
>>     _______________________________________________
>>     Scummvm-devel mailing list
>>     [email protected]  <mailto:[email protected]>
>>     https://lists.scummvm.org/listinfo/scummvm-devel
>     _______________________________________________
>     Scummvm-devel mailing list
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.scummvm.org/listinfo/scummvm-devel
>
>
> _______________________________________________
> Scummvm-devel mailing list
> [email protected]
> https://lists.scummvm.org/listinfo/scummvm-devel

--------------DDBB74DC7703DE8FF03406BD
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>2) Splendid!</p>
    <p>So, if you could write me code to get into this runGame()
      function, (and get me the filename ;) ) I could take it from
      there.<br>
    </p>
    <p><br>
    </p>
    <p>Currently, what I have downloaded from
      <a class="moz-txt-link-freetext" href="https://msmemorial.if-legends.org/magnetic.php">https://msmemorial.if-legends.org/magnetic.php</a> is in a folder that
      looks like this:<br>
    </p>
    <p><br>
      -rw-r--r-- 1 dettus dettus  951497 Mar  3 17:59 ccorrupt.gfx<br>
      -rw-r--r-- 1 dettus dettus  177185 Mar  3 17:59 ccorrupt.mag<br>
      -rw-r--r-- 1 dettus dettus  669633 Mar  3 17:59 cguild2.gfx<br>
      -rw-r--r-- 1 dettus dettus  141766 Mar  3 17:59 cguild2.mag<br>
      -rw-r--r-- 1 dettus dettus  199160 Mar  3 17:59 fish.gfx<br>
      -rw-r--r-- 1 dettus dettus  162858 Mar  3 17:59 fish.mag<br>
      -rw-r--r-- 1 dettus dettus  212224 Mar  3 17:59 guild.gfx<br>
      -rw-r--r-- 1 dettus dettus  130858 Mar  3 17:59 guild.mag<br>
      -rw-r--r-- 1 dettus dettus  271104 Mar  3 17:59 jinxter.gfx<br>
      -rw-r--r-- 1 dettus dettus  156458 Mar  3 17:59 jinxter.mag<br>
      -rw-r--r-- 1 dettus dettus   32540 Mar  3 17:59 myth.gfx<br>
      -rw-r--r-- 1 dettus dettus   99370 Mar  3 17:59 myth.mag<br>
      -rw-r--r-- 1 dettus dettus  276612 Mar  3 17:59 pawn.gfx<br>
      -rw-r--r-- 1 dettus dettus  103466 Mar  3 17:59 pawn.mag<br>
      -rw-r--r-- 1 dettus dettus 2534113 Mar  3 17:59 wonder.gfx<br>
      -rw-r--r-- 1 dettus dettus  183916 Mar  3 17:59 wonder.mag</p>
    <p>and the md5 sums are</p>
    <p>323804d54bffdc57d1626752f0d66582  ccorrupt.mag<br>
      9fb0ae1574ed4ac1616d850e4041269d  cguild2.mag<br>
      1c403e3b5a9d6669b0f3f3660c6a41aa  fish.mag<br>
      3416832716a172d33855eafedcdfa1bd  guild.mag<br>
      ab1cd85a27d1418627131675140c9241  jinxter.mag<br>
      fc288c842e77f5cffd43f777346fc2c3  myth.mag<br>
      c732efef48ed4d33b03ad724e200f3dd  pawn.mag<br>
      a00f0d63e3942a63f132e988272de7a7  wonder.mag<br>
      584886e9c4218523b55190e079dc4952  ccorrupt.gfx<br>
      48e1e3da2e02c9dedfdf0693ef1077ae  cguild2.gfx<br>
      f0b61389d3cd65aeb719fba84a864f88  fish.gfx<br>
      016dc876c53e23e99e4493e8c5673f5f  guild.gfx<br>
      962c50a12cd929580dd13f57a67667f0  jinxter.gfx<br>
      8b419437a01ea36652cc3a917a22caaf  myth.gfx<br>
      342a6e73689368cc130c88ed0d8c8128  pawn.gfx<br>
      66b2865437d680829bb372f2dca0df3a  wonder.gfx</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>ONE MORE QUESTION THOUGH:</p>
    <p>4) What is the policy with rookie developers like me, in general?
      Should I just clone code from the git repository, commit/push/pull
      my changes? Or do you guys create a branch? And merge the code
      over after a reviewing process or something? Or, in other words:
      What do I do with my code, once it has been written? <br>
    </p>
    <p><br>
    </p>
    <p>Thomas<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 5/5/19 11:07 PM, Paul Gilbert wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEkg9RMyiEOOCYkXkLioZqUceVbXYqZKNNQCieWTP8wj2j4fPA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">Hey,
          <div><br>
          </div>
          <div>1) You don't need to. ScummVM is built around detection
            entries for known games. If you look at the detection.cpp
            and detection_tables.h for the other sub-engines, you'll see
            how md5s are set up. Once a known game for the subengine is
            found, the Glk base class opens it up in _gameFile, which a
            file object you can use to read the contents. A few other
            things. You can use ConfMan.get("path") to get a reference
            to the current folder, which may be useful tor detecting if
            the given game has additional graphics/sount/hint files. If
            you look elsewhere in the engine, some of the other
            sub-engines already do that, so you can use them as a guide.
            The engine also has a getFilename() method to get the name
            of the main game filename, so you can use that as a basis
            for figuring out whe secondary filenames for gfx/snd/hints
            should be.</div>
          <div><br>
          </div>
          <div>2) Currently the Magnetic Scrolls skeleteon isn't hooked
            up. If you have a look at glk/detection.cpp, there's a
            couple of places where the different sub-engines are
            referred to, you could easily see how Magnetic needs to be
            similarly hooked in. Just look for occurrences of "Glulxe"
            for example. Alternatively, if you wait a couple of days,
            I'll move onto working on the Glk Magnetic sub-engine
            myself, and set up the necessary framework. You'll then be
            able to branch it to your own branch, and rip out
            preliminary code for the engine, keeping the hooked up
            detection framework.</div>
          <div><br>
          </div>
          <div>3) I'm not really familiar with library/linking, sorry. I
            use VIsual Studio,, and use the create_project tool to
            create a solution file for the engines and core in one
            executable. Maybe someone else can chime in.</div>
          <div><br>
          </div>
          <div>Paul.</div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>Once you've successfully added detection for one of the
            games, and it's added to the list of installed games in the
            launcher, just double-clicking on the game entry</div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div><br>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sun, May 5, 2019 at 7:28 PM
          dettus &lt;<a href="mailto:[email protected]"
            moz-do-not-send="true">[email protected]</a>&gt; 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 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="gmail-m_5380532693640484030moz-cite-prefix">On
              5/5/19 11:20 AM, dettus wrote:<br>
            </div>
            <blockquote type="cite">
              <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="gmail-m_5380532693640484030moz-cite-prefix">On
                5/5/19 10:58 AM, Paul Gilbert wrote:<br>
              </div>
              <blockquote type="cite">
                <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 &lt;<a
                        href="mailto:[email protected]" target="_blank"
                        moz-do-not-send="true">[email protected]</a>&gt;
                      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="gmail-m_5380532693640484030mimeAttachmentHeader"></fieldset>
                <pre class="gmail-m_5380532693640484030moz-quote-pre">_______________________________________________
Scummvm-devel mailing list
<a class="gmail-m_5380532693640484030moz-txt-link-abbreviated" href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>
<a class="gmail-m_5380532693640484030moz-txt-link-freetext" href="https://lists.scummvm.org/listinfo/scummvm-devel" target="_blank" moz-do-not-send="true">https://lists.scummvm.org/listinfo/scummvm-devel</a>
</pre>
              </blockquote>
              <br>
              <fieldset
                class="gmail-m_5380532693640484030mimeAttachmentHeader"></fieldset>
              <pre class="gmail-m_5380532693640484030moz-quote-pre">_______________________________________________
Scummvm-devel mailing list
<a class="gmail-m_5380532693640484030moz-txt-link-abbreviated" href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>
<a class="gmail-m_5380532693640484030moz-txt-link-freetext" href="https://lists.scummvm.org/listinfo/scummvm-devel" target="_blank" moz-do-not-send="true">https://lists.scummvm.org/listinfo/scummvm-devel</a>
</pre>
            </blockquote>
          </div>
          _______________________________________________<br>
          Scummvm-devel mailing list<br>
          <a href="mailto:[email protected]"
            target="_blank" moz-do-not-send="true">[email protected]</a><br>
          <a href="https://lists.scummvm.org/listinfo/scummvm-devel"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.scummvm.org/listinfo/scummvm-devel</a><br>
        </blockquote>
      </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]">[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>

--------------DDBB74DC7703DE8FF03406BD--


--===============0793746560762891533==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU2N1bW12bS1k
ZXZlbCBtYWlsaW5nIGxpc3QKU2N1bW12bS1kZXZlbEBsaXN0cy5zY3VtbXZtLm9yZwpodHRwczov
L2xpc3RzLnNjdW1tdm0ub3JnL2xpc3RpbmZvL3NjdW1tdm0tZGV2ZWwK

--===============0793746560762891533==--