[Scummvm-devel] Better place for decompilers

[Laurence Dougal Myers]

Hi all,

Speaking as a regular user (i.e. not a ScummVM developer), I think hiding
the decompiler tools away in a section for ScummVM developers is a bad
idea. I enjoy hacking around in the SCUMM games, and I've written a tool
called "Scummbler" that actually compiles SCUMM scripts based on the
output from "descumm". Scummbler has now been used to aid in translating
games, and is being used for a fan-modified "ultimate" edition of some
games.

If descumm is hidden away from normal end users (who I assume are using
Windows), they will need to set up an entire C++ development environment,
which limits the potential userbase to programmers with C++ experience,
just so they can build the tools (obviously not such an issue for Linux or
OS X users).

>From a selfish perspective, I'd have to provide my own builds of descumm,
just so that Scummbler is somewhat useful. I'm lazy, so I'd rather not
have to ;)

Stifling user's curiosity in exploring how these games are scripted, just
because the users are not ScummVM developers, seems like a backwards step.
However, I agree they are not tools that everyday users would commonly
use.

Why not just move the decompilers into a new sub-directory under the
current user tools directory?

Cheers,
Laurence

>   On 10/16/2010 12:47 AM, Travis Howell wrote:
>> Regular builds of the current engine tools (in scummvm/tools) doesn't
>> make sense, since they are all directly related to building ScummVM. So
>> anyone working with those tools, would need to be building ScummVM too,
>> for testing of their changes or work.
>>
>> There are far too many assumptions on this topic, removing the
>> decompilers doesn't offer any advantage to the average user. There are
>> people interested in using the decompilers, but not coding. And the
>> average user isn't forced to use every bundled tool.
>>
>
> Hi,
>
> while I think that some separation might be nice, I agree with Travis
> here that moving the decompilers to scummvm/trunk/tools is rather a step
> backwards from the user's perspective. I have seen some people talking
> about SCUMM scripts (and posting code lines which looked like descumm
> output IIRC, like this one:
> http://forums.scummvm.org/viewtopic.php?p=61533#61533) in the forums and
> I can't say those are developers (in the ScummVM team sense). So I guess
> it seems there's partial user interest.
>
> Of course we might separate the tools somehow, so it's obvious what is
> exactly is targeted at the daily/occasional ScummVM user, mostly the
> compression tools and *some* extraction tools come to mind here, and
> what is rather targeted at the people curious about certain "internals",
> I guess that's what is called "developer tools" in this discussion.
>
> // Johannes
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>