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

dettus dettus at dettus.net
Mon May 6 07:09:18 CEST 2019


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 <dettus at dettus.net 
> <mailto: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 <mailto:dettus at dettus.net>> wrote:
>>>
>>>         Sounds like a compromise. How fast is it? Would it be able
>>>         to handle animations?
>>>
>>>
>>>     _______________________________________________
>>>     Scummvm-devel mailing list
>>>     Scummvm-devel at lists.scummvm.org  <mailto:Scummvm-devel at lists.scummvm.org>
>>>     https://lists.scummvm.org/listinfo/scummvm-devel
>>
>>     _______________________________________________
>>     Scummvm-devel mailing list
>>     Scummvm-devel at lists.scummvm.org  <mailto:Scummvm-devel at lists.scummvm.org>
>>     https://lists.scummvm.org/listinfo/scummvm-devel
>     _______________________________________________
>     Scummvm-devel mailing list
>     Scummvm-devel at lists.scummvm.org
>     <mailto:Scummvm-devel at lists.scummvm.org>
>     https://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/5779b6f0/attachment-0001.html>


More information about the Scummvm-devel mailing list