[Scummvm-devel] Contributing to ScummVM with an interpreter for Magnetic Scrolls?
dettus
dettus at dettus.net
Wed May 1 10:09:20 CEST 2019
Oh!
I see. So, in other words: GLK would be the interface we should use that
we can come together? Great! I'll have a look. Thank you!!
Thomas
On 5/1/19 5:10 AM, 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,
>
> Paul.
>
>
> On Wed, May 1, 2019 at 2:55 AM dettus <dettus at dettus.net
> <mailto:dettus at dettus.net>> wrote:
>
> Hello.
>
>
> I must admit that I have not heard about Gargoyle or GLK before.
>
> Judging from the github repository, the Gargoyle engine for
> Magnetic Scrolls is using the original magnetic interpreter from
> Niclas Karlson. What he did was, as far as I know,
> reverse-engineer the C64 ports of the Magnetic Scrolls games in a
> painstaking process to make them run on DOS. What I did was
> starting from scratch and using his code as a reference. His code
> is probably more settled than mine. Plus, I'd hate to step on
> somebody's toes who has already invested copious amounts of time
> and energy into a project, so if you prefer to use his code:
> Please, please do so!
>
> What I can offer you is an engine using a more modern coding
> style. Even though it is C, I am sure that it can be integrated
> easily with C++ projects. I have worked with projects that use
> both languages and I am experienced in designing APIs for that.
>
>
> Thus far, I have the following function pointers for callbacks:
>
>
> typedef int (*cbLineAOutputChar)(void* context,char c,unsigned
> char controlD2,unsigned char flag_headline);
> typedef int (*cbLineAOutputString)(void* context,char*
> string,unsigned char controlD2,unsigned char flag_headline);
> typedef int (*cbLineAInputString)(void* context,int* len,char*
> string);
> typedef int (*cbLineADrawPicture)(void* context,tPicture*
> picture,int mode);
> typedef int (*cbLineASaveGame)(void* context,char* filename,void*
> ptr,int len);
> typedef int (*cbLineALoadGame)(void* context,char* filename,void*
> ptr,int len);
>
> As well as those API functions:
>
> // configuration functions
> int lineA_getsize(int* size);
> int lineA_init(void* hLineA,void* pSharedMem,int
> *sharedmemsize,void* pMag,int magsize,void* pGfx,int gfxsize);
> int lineA_getVersion(void* hLineA,int* version);
> int lineA_setCBoutputChar(void* hLineA,cbLineAOutputChar pCB,void
> *context);
> int lineA_setCBoutputString(void* hLineA,cbLineAOutputString
> pCB,void* context);
> int lineA_setCBinputString(void* hLineA,cbLineAInputString
> pCB,void* context);
> int lineA_setCBDrawPicture(void* hLineA,cbLineADrawPicture
> pCB,void* context);
> int lineA_setCBSaveGame(void* hLineA,cbLineASaveGame pCB,void*
> context);
> int lineA_setCBLoadGame(void* hLineA,cbLineALoadGame pCB,void*
> context);
>
>
> You typically initialize the engine with pointers to the game
> binaries, set the function pointers, and let it run. When it
> reaches a point where an input is required, the engine generates a
> callback and pauses until the callback returns.
>
>
> Regarding pictues: They are also being rendered internally, and
> another callback is triggered. An upper layer must draw it in
> whatever way it deems appropriate. So, it does not really care
> where it sits, or if it will even be displayed. The data format
> itself is very basic, almost .xpm.
>
>
> typedef struct _tPicture
> {
> unsigned int palette[16];
> int height;
> int width;
> char pixels[65536];
> } tPicture;
>
>
> I am sure I can design an extra function for animations, such as this:
>
> typedef int (*cbLineADrawAnimation)(void* context,tPicture*
> frames[],int mode,int framenum,int delay);
>
>
>
> Please let me know if this is of interested to you.
>
> Thomas
>
>
>
> On 4/30/19 2:20 AM, Paul Gilbert wrote:
>> Hi guys,
>>
>> Thanks for the excellent summary of the current status, Filippos.
>> As he said, I'm currently in the middle of working my way through
>> converting all the Gargoyle engines to ScummVM, cleaning them up
>> and making them conform to our coding requirements, as well as
>> making them proper C++ classes. If you do decide to work on the
>> Gargoyle sub-engine, please let me know.. I'll hold off working
>> on it until after I've converted the remaining sub-engines.
>> That'll give you plenty of time.. the TADS & Hugo sub-engines are
>> big enough that that'll likely take me a while to finish
>> converting :).
>>
>> If you have any questions about the Glk engine specifically, feel
>> free to drop me a line. There's also the technical forums at
>> intfiction.org <http://intfiction.org>. Though my schedule is a
>> bit packed for the next few weeks, so if you do email, I may take
>> a bit to get back to you.
>>
>> As far as music and animation goes, music at least should be
>> easy, so long as it's a standard format ScummVM understands.
>> Currently the engine supports raw sound, wav files, aiff, and
>> mp3. As for graphics, that's somewhat straightforward as well, as
>> long as the graphics can be segmented into completely separate
>> windows than the text, and it looks like the Magnetic Scroll
>> games do.. when you create windows in Glk, you can specify what
>> portion of the screen each will use (for text vs graphics). I've
>> had a lot of trouble with the Frotz sub-engine, but only because
>> graphics and text can intermingle in the same windows, which Glk
>> doesn't allow.
>>
>> Regards,
>>
>> Paul Gilbert (aka DreamMaster).
>>
>>
>>
>>
>>
>> On Mon, Apr 29, 2019 at 7:18 PM Filippos Karapetis
>> <bluegr at gmail.com <mailto:bluegr at gmail.com>> wrote:
>>
>> Sorry, forgot to say that the glk engine in ScummVM can be
>> found here:
>> https://github.com/scummvm/scummvm/tree/master/engines/glk
>>
>> There are currently subengines for the alan2, frotz, glulxe,
>> magnetic, scott, and tads interpreters, in various stages of
>> development. dreammaster is mainly working on these. You can
>> also find information about the glk engine in our wiki:
>> https://wiki.scummvm.org/index.php?title=ScummGlk
>>
>> Regards
>> Filippos Karapetis
>>
>> On Mon, Apr 29, 2019 at 12:14 PM Filippos Karapetis
>> <bluegr at gmail.com <mailto:bluegr at gmail.com>> wrote:
>>
>> Hello, and glad to hear about your interest in ScummVM,
>> and your work on the Magnetic Scrolls games!
>>
>> It's great that you are working on this. Bear in mind,
>> though, that there has been extensive work on the
>> Magnetic Scrolls games, which has been integrated into
>> the Gargoyle interpreter:
>> http://ccxvii.net/gargoyle/
>>
>> Gargoyle is being integrated as a subengine into ScummVM,
>> in the glk engine. The glk engine is a port of the
>> Gargoyle engine into ScummVM. There's an extensive wiki
>> for Gargoyle, here:
>> http://ifwiki.org/index.php/Gargoyle
>>
>> So, my advice would be to make your engine part of the
>> glk engine, and base your work on the already working
>> Magnetic Scrolls interpreter from the Gargoyle engine.
>> The interpreter is open source, and can be found here:
>> https://github.com/garglk/garglk/tree/master/terps/magnetic
>>
>> The list of supported Magnetic Scrolls games can be found
>> here:
>> https://github.com/garglk/garglk/blob/master/terps/magnetic/Generic/games.txt
>>
>> And there's an archive about interactive fiction games,
>> where a lot of resources about the Magnetic Scrolls games
>> can be found, here:
>> http://www.ifarchive.org/indexes/if-archive/magnetic-scrolls/
>>
>> Thanks for your interest in these games! It would be
>> great to see your work on them :)
>>
>> Regards
>> Filippos Karapetis
>>
>>
>> On Mon, Apr 29, 2019 at 10:08 AM dettus
>> <dettus at dettus.net <mailto:dettus at dettus.net>> wrote:
>>
>> Hello.
>>
>>
>> My name is Thomas, I am a big fan of ScummVM.
>>
>> Currently, I am in the process of writing an
>> interpreter for classic
>> text adventures from Magnetic Scrolls, such as "The
>> Pawn" or "The Guild
>> Of Thieves".
>>
>> Even though I am not saying that it SHOULD be
>> integrated into ScummVM, I
>> would like to think that it COULD. It is WAY to early
>> to really start
>> integrating it, but I like to be prepared.
>>
>>
>>
>> So, the reason why I am writing this mail is because
>> I would be
>> interested as on how I would have to design my code
>> to make it possible.
>> Currently, my interpreter needs a couple of hooks
>> into any form of GUI:
>>
>> - Initialization, where pointers to the original
>> binaries are being provided
>>
>> - Callbacks for textual input (strings)
>> - Callbacks for textual output (strings)
>> - Callbacks for textual output (characters)
>> - Callbacks for drawing a picture (XPM)
>>
>> My code is purely C, so callbacks I am using function
>> pointers. Said
>> functions are, at the moment, doing nothing more than
>> just a simple
>> printf() and fgets(). The games I can play so far are
>> "The Pawn", "The
>> Guild of Thieves" and "Jinxter". HOWEVER, later
>> games, such as
>> "Corruption", "Myth", "Fish!" and "Wonderland" added
>> features such as
>> animation and music.
>>
>> SO MY QUESTION is this: How would I best design the
>> callbacks for
>> animation and music in way so that it MIGHT be
>> integratable into ScummVM?
>>
>>
>>
>> Dettus
>>
>>
>>
>> P.S.: My interpreter is available at
>> http://www.dettus.net/dMagnetic.
>>
>> (Hopefully this link, and the fact that this is my
>> first email will not
>> make this spam. ;) )
>>
>>
>>
>>
>>
>> _______________________________________________
>> Scummvm-devel mailing list
>> Scummvm-devel at lists.scummvm.org
>> <mailto:Scummvm-devel at lists.scummvm.org>
>> https://lists.scummvm.org/listinfo/scummvm-devel
>>
>>
>>
>> --
>> "Experience is the name every one gives to their
>> mistakes" - Oscar Wilde
>>
>>
>>
>> --
>> "Experience is the name every one gives to their mistakes" -
>> Oscar Wilde
>> _______________________________________________
>> 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/20190501/6c8d097d/attachment-0001.html>
More information about the Scummvm-devel
mailing list