[Scummvm-devel] Dreamweb code (+ general ScummVM focus/vision)

[Paul Gilbert]

On Mon, Jun 20, 2011 at 6:27 PM, Max Horn <max at quendi.de> wrote:

> Hi Paul,
>
> thanks for your well-though email and arguments.
>
> Am 20.06.2011 um 06:13 schrieb Paul Gilbert:
>
> ..
> It's actually a good point as to how much is enough, if we do introduce
> minimum standards.

[...]
>
> >
> > The only requirement, as I see it, would be to ensure that the C++
> generated
> > code, in such a case, were as cleanly C++ as possible. So anything like
> the
> > suggestion made above, replacing gotos and using locals, would be
> advisable.
> > Definitely getting rid of gotos would be a positive step.
>
> Yes, and I made this suggestion in two previous emails. I am still waiting
> to hear what Vladimir thinks about this idea :).
>

Hopefully he'll be able to do some improvements to the converter. Looking at
the code now, I can see that there's a lot of improvements that could be
done. Particularly, I'd like to see if the comparison forms could be
combined with the following .z() checks to be cleaner. Something like:
    _cmp(al, 198);
    if (!flags.z())
        return /* (nofog) */;

might be better presented as:

   if (al != 198)
      return /* (nofog) */;




>
> [...]
>
> > This does need discussion, I agree. From my point of view, there's little
> > difference between having a script engine that supports an original
> game's
> > scripts (like in the Discworld games), and having a script engine that's
> > based on executing game scripts in a similiar form to PC opcode
> > instructions. So long as what's being interpreted is only the game logic
> > scripts, and not the entire game itself.
>
> I agree that it is OK to support a game which has hardcoded logic -- I
> think Touche is another example for that.
>
> But I do see a major difference: We can't touch the game scripts, they are
> provided by the use via data files. If they are complicated and buggy, we
> need to implement complicated workarounds. We can't do anything to make them
> more readable, heck, we usually first have to write a disassembler /
> decompiler for them.
>
> So, *if* we included code like this, then I really would like to take full
> advanage of our possibilities. And that includes making the code readable
> and debugable.
>

Good point. I concur. I don't really think anyone is arguing that the code
shouldn't be made as clean as possible, just that whether there's some
designated 'threshold' before the code would be considered clean enough for
release status.


>
>
> > Whilst I would have preferred seeing something like that implemented with
> > the scripts dumped into a data file, I don't think having the code
> in-engine
> > is any major issue so long as, as I said above, the generator makes it as
> > much clean C++ as possible.
>
> The generator currently still does not produce code that is warning free
> for me. And as for clean... ;). Well, if I knew the generator was going to
> improve considerably, *and* if I knew I was "allowed" to recode particular
> terrible functions: That would mitigate most of my worries, I guess.
>

I guess we'll have to agree to agree :)


>
>
> Bye,
> Max
>

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