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

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

One option for dealing with such engines would be to come up with an
assembly to script converter that could save all the scripts in a separate
.dat file. This is what I've been doing (albeit very slowly) for Rex Nebular
- for that game too, the scripts are hardcoded into the executable, and I've
come with a complicated process to convert routines from the disassembly
into a script equivalent. I'm not sure if this is convenient for DreamWeb; I
presume not (not having looked at the source code for it yet much).

The other is, as has been suggested, converting the entire game's script
logic into full blown clean C++. This is the route Strangerke and I went
with Ringworld, A lot of this code, however, does have very generic names
like 'Hotspot11', simply because we don't want to take the extra time to
match every code entity to it's hotspot on screen and come up with
appropriate names and/or code comments.

I think Whoozle's comment is pertinent; I don't think there's any
requirement to have everything properly named. As soon as the 'interpreting'
part is confined to just executing game scripts (even if the scripts are
hardcoded into the engine), I don't see much difference between that and the
script engines all the other engines use.

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.


> >
> > Dreamweb definitly is not like that. What we have with dreamweb is what I
> would
> And like that, then?
> >
> > Also like Max, I have the feeling that people are discouraging that we
> > reimplement it properly due to it being a "waste of time" and having a
> big
> > chance of causing "regressions". That is IMHO bad too, we want a proper
> C++
> > reimplementation IMHO.
> Again, define "proper" please.

>
> > Thus before other people will start to use similar techniques in their
> engines
> > and hope that we will include them too, I wanted to express that I think
> we
> > should not accept any of this in the future. And honestly we should not
> have
> > accepted it in the case of dreamweb too IMHO.
> Again, why shouldn't we? No real argument, just emotion.
>

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.

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.


> >
> > I do not say we should remove it from master right now! We should rather
> talk
> > about what we really want with ScummVM (or in ScummVM). IMHO the merging
> shows
> > that we really do not live up to our standards anymore when it comes to
> > supporting new games.
> Please tell what's wrong the dreamweb, beside "you don't like it". Dreamweb
> is not emulated, but translated from original source.
> >
> > So is this the new way to go? Should we really accept code like this in
> the
> > future?
> Why not?
> >
> > And also what are we going to do about the dreamweb code? Personally I
> think
> > we should not support it officially till we have reimplemented it
> properly.
> Again, no real arguments, just emotions. You think. We should not. Why not?
> It's playable, completable. People who uses scummvm really don't care about
> how this game got supported
>

Well, I think there does need to be some level of control beyond a game just
being completable from a user perspective. There have been previously
created engines that are not included, such as Another World or *cough*
Gargoyle *cough*. Those were more for not being point-n-click adventure
games than code cleanliness, but the point remains relevant. In any case,
though, I don't see any major problems in this particular instance.


> >
> > I am happy to hear your views on this. And I want to point out again that
> I
> > value that whoozle worked on dreamweb. If someone involved in getting
> dreamweb
> > to wrok on ScummVM is offended by this mail then I am deeply sorry about
> this.
> >
> > // Johannes
>

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