[Scummvm-devel] descumm defects/patches
Max Horn
max at quendi.de
Thu Sep 24 10:49:18 CEST 2009
Am 24.09.2009 um 07:08 schrieb Laurence Dougal Myers:
> Hi all,
>
> I'm Laurence Myers (aka jestar jokin). I've been contributing
> technical
> information on SCUMM to the wiki. I have also written a tool called
> Scummbler that will compile SCUMM scripts as output by descumm.
>
> I have found a few issues in descumm that I would like to fix, but I
> first
> wanted to see whether these changes would be acceptable, before I do
> too
> much work. The issues are all related to versions of SCUMM < 6,
> since I
> imagine the new bytecode decompiler would handle SCUMM >= 6.
Just to clear that up: There is no new bytecode decompiler. One was
started during GSoC, but the project was a failure.
> Here are
> issues that I would like to fix, with the benefit of making descumm
> scripts easier to parse by a machine:
> - Inconsistent usage of semicolons.
> - Some instructions have an extra closing parenthesis, or a missing
> closing parenthesis.
> - Instructions like "beginOverride" and "beginCutscene" do not have
> any
> parentheses.
Well, one could argue that these are not "instructions" in the sense
of calls to the kernel, but rather parts of the language. So maybe one
should write them as
override {
}
cutscene {
}
to match while, if/else, etc.
> - "startScript" does not output enough information (it's missing flags
> indicating if the script should be recursive or freeze-resistant)
> - Some SCUMM functions are poorly named. I would like to remove
> question
> marks from all function names. I would also like to rename roomOps
> sub-op
> 0x07 from "Unused" to "setRoomScale", and also add the 5 expected
> arguments for it.
> - "findObject" looks for words or vars, whereas ScummVM looks for
> bytes or
> vars. I have only ever seen this function used with vars, but I
> would like
> to change it to match ScummVM anyway.
All sounds fine so far.
>
> I would also like to make the following change for my own reasons:
> - Output extra object metadata for SCUMM V3-4 object scripts, such as
> object ID, x- and y-positions, width & height, etc. I want to do
> this so a
> script output with descumm can be compiled using Scummbler and
> result in a
> file that is bit-identical to the original script block.
Feel free to, although I fail to see the point -- this data is not
really part of the script block, it is only in there out of laziness:
It was easier not to remove it when dumping the script, that's all.
>
> -------
>
> I've also encountered an actual bug with the creation of if/else
> blocks.
Not surprising. Well, maybe the fact you found only *one* bug... :).
The whole "block structuring" code in descumm is one huge hack. That
was why we wanted (and still want) to write new decompilers. But
writing good decompilers is *hard, sadly.
Improvements are welcome.
[...]
> If you all are happy with these changes to go ahead, should I submit
> the
> patches to this mailing list?
Fixes for these issues are welcome. But, no, don't send them here,
patches belong to the patch tracker!
Cheers,
Max
More information about the Scummvm-devel
mailing list