[Scummvm-devel] Adding Frotz engine to ScummVM

Paul Gilbert paulfgilbert at gmail.com
Mon Sep 7 01:28:52 CEST 2009


On Sun, Sep 6, 2009 at 11:42 PM, Stuart George <yakumo9275 at gmail.com> wrote:

> On Sat, Sep 5, 2009 at 1:01 AM, Paul Gilbert<paulfgilbert at gmail.com>
> wrote:
>


> Paul, does this mean you adapted the GLK interface than 99% of all
> opensource infocom interpreters use to scummvm? or did you just
> hack the frotz code IO to use scummvm?
>
> Using a scummvm glk bridge would mean any GLK capable
> interpreter could be mated in without any issue...
>
> food for thought.
>
>
I adjusted the core I/O of the frotz code . This was, in a sense, a test
project for me that's been on-going for years - the Frotz code was fairly
well defined, so it provided a good basis for creating an engine around.
Somewhat ironically, for most of the time period the engine didn't actually
try executing any Frotz code.. I used it more as my own 'already registered
test engine' where I could try out various things.It's only recently i
bothered actually getting the Frotz code to run. :)

I can understand the concerns raised, so for now may see simply about
creating some kind of website and/or download for those that are interested.
But John Willis does raise an interesting point - ScummVM is becoming more
and more attractive as a flexible generic base for cross-platform games, so
we should give consideration as to what, if anything, we want to do to
encourage this.

I'm considering, for example, have a separate SourceForge project 'ScummVM
Misc', providing a collection of engines deemed not in scope for the main
ScummVM. We already have one such project with the Tinsel v3 / Discworld
Noir (although if it ever gets anywhere may be acceptable for Residual), and
Another World has been raised as another such example. So it would be better
to have a central repository for any such engines.

Although, the move to DCVS does sound intriuging - particularly if allowed
for separate 'branches' that could host such 'extra' engines unofficially,
yet share and keep up to date with the latest changes to OSystem. After all,
I think peoples' only real objection is to including such engines in the
official ScummVM distributions, and not against the games/engines
themselves.

Something to think about. :)

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090907/ab793bba/attachment.html>


More information about the Scummvm-devel mailing list