Re: Contributing to ScummVM with an interpreter for Magnetic Scrolls?

--===============2175472266201280981==
Content-Type: multipart/alternative; boundary="000000000000f36af90588173405"

--000000000000f36af90588173405
Content-Type: text/plain; charset="UTF-8"

HI Thomas,

Not directly for libxglk, I'm afraid. What I did for the ScummVM
implementation was to utilize a nifty feature of the ScummVM framework that
allows the creation of virtual file systems that expose files as if they're
standard files you can open with a Common::File just like files in the game
directory. Using this, in the engines\glk\frotz\pics.cpp I create a virtual
archive of all the pictures that the original Infocom games had, and expose
them as a really simple "raw" format, like pic1.raw, pic2.raw, and so on.
The Glk core has then been enhanced so that when you request to, for
example, draw picture #1, in addition to looking for pic1.jpg, pic1.png, it
also looks for pic1.raw, and if it finds it, loads it up and displays it
just like it would JPG & PNG.

This way, I didn't have to put Frotz specific rendering code in the core
Glk layer. So I'll do something similar when I implement the existing
Magnetic Glk engine. Maybe you could do something similar for libxglk if
you keep using it.

Paul.





On Sat, May 4, 2019 at 8:40 PM dettus <[email protected]> wrote:

> Hello.
>
>
> So, I looked into GLK. As you can see from the screenshot at
> http://www.dettus.net/dMagnetic/xglk_pawn.png , I made some progress.
> However, pictures seem to be handled quite archaic by this.
> Or at least with the libxglk frontend. Apparently, there are two ways:
>
> 1. Draw the rectangles yourself (Which is what I did. Which is
> slooooooooow.)
> 2. Store the image as an .png or .jpeg file, load it, display it.
>
> Personally, I would have preferred an interface where I could hand over
> a memory pointer, and let the GUI figure out the best way to render it
> on screen.
>
>
> On top of that: The libxglk library itself is outdated.
>
>
> Any hints?
>
>
> Thomas
>
>
>
> _______________________________________________
> Scummvm-devel mailing list
> [email protected]
> https://lists.scummvm.org/listinfo/scummvm-devel
>

--000000000000f36af90588173405
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">HI Thomas,<div><br></div><div>Not directly for libxglk, I&=
#39;m afraid. What I did for the ScummVM implementation was to utilize a ni=
fty feature of the ScummVM framework that allows the creation of virtual fi=
le systems that expose files as if they&#39;re standard files you can open =
with a Common::File just like files in the game directory. Using this, in t=
he engines\glk\frotz\pics.cpp I create a virtual archive of all the picture=
s that the original Infocom games had, and expose them as a really simple &=
quot;raw&quot; format, like pic1.raw, pic2.raw, and so on. The Glk core has=
 then been enhanced so that when you request to, for example, draw picture =
#1, in addition to looking for pic1.jpg, pic1.png, it also looks for pic1.r=
aw, and if it finds it, loads it up and displays it just like it would JPG =
&amp; PNG.</div><div><br></div><div>This way, I didn&#39;t have to put Frot=
z specific rendering code in the core Glk layer. So I&#39;ll do something s=
imilar when I implement the existing Magnetic Glk engine. Maybe you could d=
o something similar for libxglk if you keep using it.</div><div><br></div><=
div>Paul.</div><div><br></div><div><br></div><div><br></div><div><br></div>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Sat, May 4, 2019 at 8:40 PM dettus &lt;<a href=3D"mailto:[email protected]=
et">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">Hello.<br>
<br>
<br>
So, I looked into GLK. As you can see from the screenshot at <br>
<a href=3D"http://www.dettus.net/dMagnetic/xglk_pawn.png" rel=3D"noreferrer=
" target=3D"_blank">http://www.dettus.net/dMagnetic/xglk_pawn.png</a> , I m=
ade some progress. <br>
However, pictures seem to be handled quite archaic by this.<br>
Or at least with the libxglk frontend. Apparently, there are two ways:<br>
<br>
1. Draw the rectangles yourself (Which is what I did. Which is <br>
slooooooooow.)<br>
2. Store the image as an .png or .jpeg file, load it, display it.<br>
<br>
Personally, I would have preferred an interface where I could hand over <br=
>
a memory pointer, and let the GUI figure out the best way to render it <br>
on screen.<br>
<br>
<br>
On top of that: The libxglk library itself is outdated.<br>
<br>
<br>
Any hints?<br>
<br>
<br>
Thomas<br>
<br>
<br>
<br>
_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Scummv=
[email protected]</a><br>
<a href=3D"https://lists.scummvm.org/listinfo/scummvm-devel" rel=3D"norefer=
rer" target=3D"_blank">https://lists.scummvm.org/listinfo/scummvm-devel</a>=
<br>
</blockquote></div>

--000000000000f36af90588173405--


--===============2175472266201280981==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU2N1bW12bS1k
ZXZlbCBtYWlsaW5nIGxpc3QKU2N1bW12bS1kZXZlbEBsaXN0cy5zY3VtbXZtLm9yZwpodHRwczov
L2xpc3RzLnNjdW1tdm0ub3JnL2xpc3RpbmZvL3NjdW1tdm0tZGV2ZWwK

--===============2175472266201280981==--