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

[Johannes Schickel]

> So, what should we do in such cases? Before you answer, consider
> Broken Sword 1 & 2 where we have all script sources, should we rewrite
> them in C++ too?
> 

No because Sword 1 & 2 script resources are interpreted by a VM we support by 
"day by day" C++ code.

> I consider such cases as VM being an x86 processor. So in my opinion
> setting up environment to run those chunks of hardcoded scripts is
> allowable. This is what we were doing with M4 engine, just taking a
> bit more complicated route, i.e. we generate pseudocode for imaginable
> VM from .asm output of IDA and then interpreting this code. Dreamweb
> just removes this layer of interpretation.
> 

Rewriting the logic in C++ would furthermore remove any layer needed for 
executing the game scripts.

Next we can not use the ASM->C conversion for non open source engines, since 
that will be violation of copyright IMHO.

> Take a look at history of 'Igor: Objetivo Uikokahonia'. Cyx just got
> fed of a tedious work of translating countless room scripts into C++,
> the engine got stalled and eventually was moved out of the tree.
> Recently Gregory renewed the work, but did it in a similar to Dreamweb
> approach. You may find the results here: http://cyxdown.free.fr/igor/
> Fortunately the Turbo Pascal compiler is quite dumb, so it uses only
> tiny subset of x86 instructions, and as such the x86 interpreter is
> under 500 lines of code (file script.cpp). Now the question. Will the
> engine in its form be allowed to be merged to ScummVM? I personally
> see no problem with that, and script errors could be patched exactly
> in the manner we do it for SCI and Tinsel engines.
> 

When I talked with Max I actually pointed at igor and wondered whether we want 
to accept that code now too.

But actually since cyx does not seem to work on igor inside ScummVM, I would 
say cyx probably had the feeling this wasn't right for ScummVM *or* he just 
doesn't care about ScummVM anymore. But I doubt the latter... but we can just 
make guesses here without asking him...

> There are certain tools for letting rewriting of individual functions
> into C++ (the blacklist), and any part could be rewritten at any time
> just working with generated code, not with assembly. The development
> has not stopped yet, and I hope whoozle will implement loop detection
> and conditionals which will add tons of readability to the generated
> code and eliminate majority of those gotos which everybody seems to be
> hating. 

Let's quote whoozle from a mail on this thread:

"Honestly, I cannot provide any information about future plans of generator 
improvements, because it could be rather complicated task."

> The trust to our project is increasing and we are getting more and more
> source code, some of them being in assembly. 

That's nice, but how is that related to the thread's topic?

> This is a beautiful tool giving us ease of handle original sources, even for
> those devs who do not know x86.

Since we still need someone to implement all the hardware layer functions, a 
developer would still have to work with x86 assembly. Furthermore if one needs 
to fix bugs in the assembly code instead of the C++ conversion, one would also 
need to know x86 assembly. So all in all I do not see how this tool will help 
people without x86 knowledge. And seeing that the tool eases all that 
translation, I doubt a dev knowing x86 assembly will need someone else to use 
the tool for him...

// Johannes