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

[dettus]

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
>> 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/20190505/35811564/attachment.html>