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

Wed May 1 17:34:46 CEST 2019

Hello.

Since I did not have any access to the original data files, I got some 
binaries from https://msmemorial.if-legends.org/memorial.php

As far as I understood, they repackaged the MS data files into their own 
format. That included the CD Collection versions for "Corruption", "The 
Guild of Thieves" and "Wonderland".

Save for a couple of glitches/bugs, my engine is capable of handling all 
the games in that format. I am also in contact for strandgames (Which is 
Hugh Steers). He likes what I am doing. :D

*As for the windowing system:*

The way I see it is that there are three layers: GAME, ENGINE and GUI.

So, for example: When the GAME gets to a point where it wants to present 
a picture, it triggers a callback to the ENGINE. My engine is 
pre-rendering the picture into a more manageable format, and in turn 
triggers a callback to the GUI. The same goes for textual output and for 
input. (I thought it would be easier to port this way)

Reading your emails, I suppose the GAME actually triggers callbacks for 
the compass rose and the inventory box. However, since I did not need 
those for finishing the game, my engine actively ignores them.

*As for GLK:*

So far I was able its project page https://www.eblong.com/zarf/glk/ , 
and compile the ncurses example. When I tried the example for X, i 
realized that this is probably outdated, since I was not able to compile 
it on the first try.

I will have to familiarize myself with it, if you say that this is the 
way forward. Here, I'd take any help I can get. ;) But other than that, 
I do not see why my callback hooks should not be adaptable to it. 
Currently, they end in a printf() and an fgets().

Thomas

On 5/1/19 5:13 PM, Torbjörn Andersson wrote:
> The Legend games split the screen into fixed areas, though. The 
> Magnetic Windows GUI was basically a window manager (in 640x480 
> pixels), with movable, resizable, potentially overlapping windows. 
> Here is an admittedly horrifying screenshot of what it could look like 
> if you opened all the possible windows:
>
> http://www.update.uu.se/~d91tan/magnetic-windows.png
>
> I defy anyone to find a sensible layout for all of that! You may think 
> you can do it, if you close the "Compass", "Inventory", and "Items in 
> room" windows, and for a while you can... and then you realize that 
> not every image is the same size, and you have to move the "Graphpics" 
> window out of the way...
>
> Torbjörn Andersson
>
> On 01/05/2019 08.53, Paul Gilbert wrote:
>> Thanks for information Torbjörn. It doesn't sound like the missing 
>> screen elements are things I'd miss all that much. Though maybe some 
>> of it could eventually be reintroduced as an option. Whilst Glk 
>> doesn't currently have any "listbox" window types, I do have an 
>> already implemented listbox control for my stalled Legend engine that 
>> could probably be adapted. And a main menu implementation could be 
>> useful for Frotz v6 as well as the Magnetic engine.
>>
>> It will be nice if they do release the original versions alongside 
>> the remastered versions. Being away from home, I'm not sure how many 
>> Magnetic Scrolls games I have, if any.. comes from having too large a 
>> collection.. I'm sure Strangerke among others can empathize :), So if 
>> I don't have all of them; it would be nice to eventually have a 
>> legitimate source to get any missing ones.
>>
>> Paul.
>>
>>
>> On Wed, May 1, 2019 at 4:00 PM Torbjörn Andersson 
>> <eriktorbjorn at telia.com <mailto:eriktorbjorn at telia.com>> wrote:
>>
>>       From what I remember, the main feature not supported by the 
>> Magnetic
>>     interpreter is some of the "Magnetic Windows" interface 
>> (on-screen map,
>>     compass rose, separate windows for inventory and room objects, 
>> horribly
>>     cluttered windowing system, ... oh, sorry, that last thing isn't 
>> really
>>     a feature, is it?) used by Wonderland and the Magnetic Scrolls
>>     Collection.
>>
>>     At least as long as the front end implements the necessary hooks for
>>     displaying static and animated pictures, etc. I'm not sure if it 
>> loads
>>     the original data files, or if they have to be specially 
>> prepared. (The
>>     files on my Magnetic Scrolls Collection CD certainly don't look like
>>     anything the emulator would recognize.)
>>
>>     Also, it doesn't try to emulate the original look of the games 
>> with its
>>     animated menus and pull-down graphics. Which is a bit of a shame
>>     or,, in
>>     the case of the Magnetic Windows interface, a huge relief.
>>
>>     When I asked [1] on the Strand Games forum (the company in the 
>> process
>>     of remastering the Magnetic Scrolls games, after the source code was
>>     recovered from a backup tape [2]) if they were planning on 
>> release the
>>     original versions as well, just for nostalgia, I got a reply from 
>> Hugh
>>     Steers referring me to Stefan Meier's "Magnetic Scrolls Memorial" 
>> for
>>     data files for the emulator.
>>
>>     Since "Strand Games was started by Hugh Steers - a founding 
>> member and
>>     core developer of Magnetic Scrolls and Stefan Meier, curator of
>>     if-legends.org <http://if-legends.org>" and they claim to have the
>>     support of "several members
>>     of the original Magnetic Scrolls team" [3], I guess those files are
>>     kiiind-of officially endorsed...? It's probably worth asking them 
>> again
>>     later.
>>
>>     [1]
>> https://strandgames.com/community/discussion/65/the-original-versions
>>     [2]
>> https://strandgames.com/blog/magnetic-scrolls-games-source-code-recovered
>>     [3] https://strandgames.com/about
>>
>>     Torbjörn Andesson
>>
>>     On 01/05/2019 05.10, Paul Gilbert wrote:
>>      > Hi Thomas,
>>      >
>>      > I'm not sure of the status of the Gargoyle Magnetic Scrolls
>>     sub-engine,
>>      > and I don't currently have any Magnetic Scrolls games handy to
>>     test it
>>      > on. But unless it's significantly lacking in support for the
>>     later games
>>      > that your own work adds support for, it'll likely prove easier to
>>     work
>>      > on converting it, I'm afraid. Since, after all, someone else has
>>     already
>>      > done the work of hooking it up to Glk as well. So it'll be easier
>>     to do
>>      > minimal work (relatively speaking) to hook it up to the ScummVM
>>     version
>>      > of the Glk layer. And then I can keep testing it as I properly
>>     objectify
>>      > everything to make sure I don't break anything along the way.
>>      >
>>      > Though I'll be unlikely to be spending much time beyond basic
>>     polishing
>>      > up of the sub-engine afterwards. So based on your experience with
>>     the
>>      > games & engine involved, there might be opportunities afterwards
>>     for you
>>      > to contribute if you're interested, and to do pull requests to
>>     improve
>>      > the functionality of the engine based on your work.
>>      >
>>      > Regards,
>>      >
>
> _______________________________________________
> 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/20190501/672b7fc1/attachment-0001.html>