[Scummvm-devel] Contributing to ScummVM with an interpreter for Magnetic Scrolls?

[Paul Gilbert]

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 <dettus at dettus.net> 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 <dettus at dettus.net> wrote:
>
>> Sounds like a compromise. How fast is it? Would it be able to handle
>> animations?
>>
>
>
> _______________________________________________
> Scummvm-devel mailing listScummvm-devel at lists.scummvm.orghttps://lists.scummvm.org/listinfo/scummvm-devel
>
>
> _______________________________________________
> Scummvm-devel mailing listScummvm-devel at lists.scummvm.orghttps://lists.scummvm.org/listinfo/scummvm-devel
>
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.scummvm.org
> https://lists.scummvm.org/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20190506/5325f900/attachment.html>