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

[dettus]

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
> https://lists.scummvm.org/listinfo/scummvm-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20190505/905786ef/attachment-0001.html>