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

[Eugene Sandulenko]

Hi all,

I am not going to quote you guys, sorry, nothing personal. If you have
to repeat your arguments in response to this letter, let's have a
clean discussion.

I have one request, though. Please try to give technical arguments,
neutral to personalities, and do not forget that everyone of us is
doing an excellent job in developing one of the most successful and
big open source projects.

First, let's remember that ScummVM is a reimplementation of 2d point
and click adventure _engines_. I.e. it kickstarted from SCUMM being a
VM. In time, though, we started to touch those interesting games which
are not really VMs in the sense, that their game logic is all
hardcoded.

Unfortunately this makes the border of engine/scripts rather fuzzy.
And Dreamweb is one of the extreme cases, because unlike even
Teenagent it does not use any kind of pseudo scripts in form of macro
language.

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?

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.

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.

Now back specifically to Dreamweb.

My opinion is that the work done is excellent even extraordinary. The
most complex things were implemented, and the engine runs well, game
is already completable.

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. But the main thing is that we're getting an excellent tool
with speeding up of initial kick off for the engine developers. The
trust to our project is increasing and we are getting more and more
source code, some of them being in assembly. This is a beautiful tool
giving us ease of handle original sources, even for those devs who do
not know x86.

You may ask, what is the difference from dosbox then? My answer is. We
reimplemented all hardware-specific functions, and what is in that
dreamgen.cpp is mainly what would usually sit in game scripts.
Theoretically we can put it into .dat, as pre-generated logic. This is
really what it is.

So, what I would like to see with Dreamweb engine development:
  - Get comments transferred into dreamgen.cpp
  - Get loops and conditionals detected
  - Move out some non-script logic to C++, probably suggested by profiler
  - Announce testing
  - Fix the script bugs if any
  - At this point there will be no need to rerun code generation anymore

After this engine will become stable, and there will be rare need of
ever touching it development-wise. This is what we have with majority
of single game engines. Now, if someone would like to see it in a
nicer form, we could run a GSoC task. The requirements for this task
are really low and could be performed by a student, or anyone willing
to help.

Whoozle is here with us, and he is obviously capable of supporting the
engine and fixing the bugs in it.

The game itself is pretty bug-less, especially in comparison with SCI
or SCUMM. The original developers were really high skilled. They even
wrote whole game editor in ASM too, and it is like 2x bigger than the
game engine.


Eugene