Re: Contributing to ScummVM with an interpreter for Magnetic Scrolls?
Paul Gilbert <[email protected]> Mon, 6 May 2019 07:07:26 +1000
| Newsgroups | gmane.games.devel.scummvm |
|---|---|
| Message-ID | <CAEkg9RMyiEOOCYkXkLioZqUceVbXYqZKNNQCieWTP8wj2j4fPA@mail.gmail.com> |
--===============0799789472056490347==
Content-Type: multipart/alternative; boundary="000000000000711e3f05882a604d"
--000000000000711e3f05882a604d
Content-Type: text/plain; charset="UTF-8"
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]> 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]> wrote:
>
>> Sounds like a compromise. How fast is it? Would it be able to handle
>> animations?
>>
>
>
> _______________________________________________
> Scummvm-devel mailing [email protected]://lists.scummvm.org/listinfo/scummvm-devel
>
>
> _______________________________________________
> Scummvm-devel mailing [email protected]://lists.scummvm.org/listinfo/scummvm-devel
>
> _______________________________________________
> Scummvm-devel mailing list
> [email protected]
> https://lists.scummvm.org/listinfo/scummvm-devel
>
--000000000000711e3f05882a604d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"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 yo=
u 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 u=
seful tor detecting if the given game has additional graphics/sount/hint fi=
les. If you look elsewhere in the engine, some of the other sub-engines alr=
eady do that, so you can use them as a guide. The engine also has a getFile=
name() method to get the name of the main game filename, so you can use tha=
t as a basis for figuring out whe secondary filenames for gfx/snd/hints sho=
uld be.</div><div><br></div><div>2) Currently the Magnetic Scrolls skeleteo=
n 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 co=
uld 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 bran=
ch it to your own branch, and rip out preliminary code for the engine, keep=
ing 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 c=
ore 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 add=
ed 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></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On S=
un, May 5, 2019 at 7:28 PM dettus <<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);p=
adding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#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=3D"gmail-m_5380532693640484030moz-cite-prefix">On 5/5/19 11:=
20 AM, dettus wrote:<br>
</div>
<blockquote type=3D"cite">
=20
<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!=C2=A0 <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=3D"gmail-m_5380532693640484030moz-cite-prefix">On 5/5/19 1=
0:58 AM, Paul Gilbert
wrote:<br>
</div>
<blockquote type=3D"cite">
=20
<div dir=3D"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 likel=
y
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=3D"gmail_quote">
<div dir=3D"ltr" class=3D"gmail_attr">On Sun, May 5, 2019 at
5:06 PM Thomas Dettbarn <<a href=3D"mailto:[email protected]=
et" target=3D"_blank">[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">
<div>
<p>Sounds like a compromise. How fast is it? Would it be
able to handle animations?=C2=A0</p>
</div>
</blockquote>
<div>=C2=A0</div>
</div>
</div>
<br>
<fieldset class=3D"gmail-m_5380532693640484030mimeAttachmentHeader"=
></fieldset>
<pre class=3D"gmail-m_5380532693640484030moz-quote-pre">___________=
____________________________________
Scummvm-devel mailing list
<a class=3D"gmail-m_5380532693640484030moz-txt-link-abbreviated" href=3D"ma=
ilto:[email protected]" target=3D"_blank">Scummvm-devel@lists=
.scummvm.org</a>
<a class=3D"gmail-m_5380532693640484030moz-txt-link-freetext" href=3D"https=
://lists.scummvm.org/listinfo/scummvm-devel" target=3D"_blank">https://list=
s.scummvm.org/listinfo/scummvm-devel</a>
</pre>
</blockquote>
<br>
<fieldset class=3D"gmail-m_5380532693640484030mimeAttachmentHeader"><=
/fieldset>
<pre class=3D"gmail-m_5380532693640484030moz-quote-pre">_____________=
__________________________________
Scummvm-devel mailing list
<a class=3D"gmail-m_5380532693640484030moz-txt-link-abbreviated" href=3D"ma=
ilto:[email protected]" target=3D"_blank">Scummvm-devel@lists=
.scummvm.org</a>
<a class=3D"gmail-m_5380532693640484030moz-txt-link-freetext" href=3D"https=
://lists.scummvm.org/listinfo/scummvm-devel" target=3D"_blank">https://list=
s.scummvm.org/listinfo/scummvm-devel</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Scummv=
[email protected]</a><br>
<a href=3D"https://lists.scummvm.org/listinfo/scummvm-devel" rel=3D"norefer=
rer" target=3D"_blank">https://lists.scummvm.org/listinfo/scummvm-devel</a>=
<br>
</blockquote></div>
--000000000000711e3f05882a604d--
--===============0799789472056490347==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU2N1bW12bS1k
ZXZlbCBtYWlsaW5nIGxpc3QKU2N1bW12bS1kZXZlbEBsaXN0cy5zY3VtbXZtLm9yZwpodHRwczov
L2xpc3RzLnNjdW1tdm0ub3JnL2xpc3RpbmZvL3NjdW1tdm0tZGV2ZWwK
--===============0799789472056490347==--