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

[Max Horn]

Hi Paul,

thanks for your well-though email and arguments.

Am 20.06.2011 um 06:13 schrieb Paul Gilbert:

> Hey all,
> 
> This has all raised some interesting points, so I'd like to throw my
> thoughts in as well.
> 
> On Mon, Jun 20, 2011 at 1:40 PM, Vladimir Menshakov <whoozle at yandex.ru>wrote:
> 
>>> Albeit I think it's some nice demo of the asm->c conversion I do not
>> think
>>> that is what we want in ScummVM. ScummVM is about reimplementing the game
>>> engines or at least supporting them with the help of original source
>> code.
>>> This means to me the code should be at least somewhat proper
>> reimplementation
>>> of the original logic in C++.
>> Who do you want to reimplement this engines? What's wrong with robot
>> reimplementing the engine?
>> What if I replace gotos with while/do and register names with locals. Will
>> it be "proper" reimplementation?
>> 
> 
> 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 :).

[...]

> 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.


> 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.


Bye,
Max