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

Arnaud Boutonné arnaud.boutonne at gmail.com
Mon Jun 20 09:42:03 CEST 2011


Hi Vladimir,

I may understand that after 6 months working on the engine and to conversion
tool you're not eager to rewrite completely the hardcoded logic, but I also
think that a C++ implementation would be a lot more readable for everyone.
Would you keep on supporting it if someone/some people start to slowly
rewrite those functions (and give support to this new hardcoded logic, most
likely)?

If so, we could set as an objective to 'someday' rewrite the entire game
logic in C++ and in the meantime fix all the glitches in the current
implementation. It's a bit this way we act with engines not yet objectified,
after all.

And again, ... Congratulations for your impressive work, and impressive
results.

Best regards,
Arnaud

On Mon, Jun 20, 2011 at 9:13 AM, Vladimir Menshakov <whoozle at yandex.ru>wrote:

>
>
> 20.06.2011, 11:03, "Bertrand Augereau" <bertrand_augereau at yahoo.fr>:
> > I quite agree with the philosophy of having everything reimplemented in
> proper C++, but wouldn't it be a shame not allowing people to play Dreamweb
> in ScummVM if it is completable and supported properly?
> Let's face the truth - noone except engine authors will fix bugs except
> trivial/generic ones. So, I don't think that maintainability is *really* the
> case here. I think it's just form of self-preferences or so. Years ago
> people blamed computers for losing their jobs because of automation. Today
> the same people blame me for automatic rewriting the code. :)))
> I don't have another year to spend meaninglessly rewriting the code from
> c++ to c++. I will fully support dreamweb as a developer. But anyway I will
> not protest if you unmerge dreamweb, I'm pretty fed up struggling with
> windmills.
>
> > At least, now the world knows, and there is a solid basis for
> reimplementing incrementally parts of the engine from generated sphagetti
> code to clean C++. Now there is the question that Vladimir doesn't see it
> any useful.
> > Vladimir, you have to admit that reimplementing cleanly the engine would
> give a *much* better performance. You don't want to commit to memory
> everytime you touch a register and emulate flags, that's what an emulator
> does, and... watch out guys, here comes my point :)... this probably is what
> would prevent playing Dreamweb in Scummvm on a DS and possibly other slow
> platforms.
> Let's try it on DS. Usually, simple SSA, found in every compiler,
> eliminates all unnecessary  writes.
>
> >
> > Cheers,
> > Bertrand
> >
> > --- En date de : Lun 20.6.11, Johannes Schickel <lordhoto at gmail.com>; a
> écrit :
> >
> >>  De: Johannes Schickel <lordhoto at gmail.com>;
> >>  Objet: Re: [Scummvm-devel] Dreamweb code (+ general ScummVM
> focus/vision)
> >>  À: "Vladimir Menshakov" <whoozle at yandex.ru>;
> >>  Cc: scummvm-devel at lists.sourceforge.net
> >>  Date: Lundi 20 juin 2011, 8h52
> >>  On Mon, Jun 20, 2011 at 5:40 AM,
> >>  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?
> >>  Seeing that we have most of our other engines reimplemented
> >>  I am not
> >>  sure whether this is a real argument. If nobody cares
> >>  about
> >>  implementing it, when we don't have it supported. I don't
> >>  see anything
> >>  bad about it.
> >>>  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?
> >>
> >>  If you furthermore strip all the code from runtime.h then I
> >>  would
> >>  think of considering it proper.
> >>>>  Dreamweb definitly is not like that. What we have
> >>  with dreamweb is what I would
> >>>  And like that, then?
> >>  Like a proper reimplementation of the game and not just an
> >>  asm -> C
> >>  conversion utilizing a "runtime" which is basically a
> >>  register set +
> >>  memory + glue code used to display graphics etc.
> >>>>  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.
> >>  Proper in this context is a reimplementation in C++ which
> >>  makes the
> >>  logic clear to someone not knowing assembly. If you look at
> >>  the
> >>  dreamweb code in dreamgen.cpp it is not really much
> >>  different than to
> >>  look at the assembly code.
> >>>>  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.
> >>
> >>  That's right Dreamweb is not emulated strictly speaking.
> >>  But just
> >>  looking at the code in runtime.h clearly shows it is using
> >>  some kind
> >>  of "virtual machine" to execute the translated assembly.
> >>  This is what
> >>  I would not consider a proper reimplementation of the
> >>  engine anymore.
> >>>>  So is this the new way to go? Should we really
> >>  accept code like this in the
> >>>>  future?
> >>>  Why not?
> >>  Because it is not reimplemented.
> >>>>  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
> >>
> >>  That's right people do not care about how it's done. But
> >>  SucmmVM is
> >>  (or at least was) a project aimed at reimplementations of
> >>  the game,
> >>  not like some pseudo emulated translation.
> >>
> >>  // Johannes
> >>
> >>
>  ------------------------------------------------------------------------------
> >>  EditLive Enterprise is the world's most technically
> >>  advanced content
> >>  authoring tool. Experience the power of Track Changes,
> >>  Inline Image
> >>  Editing and ensure content is compliant with Accessibility
> >>  Checking.
> >>  http://p.sf.net/sfu/ephox-dev2dev
> >>  _______________________________________________
> >>  Scummvm-devel mailing list
> >>  Scummvm-devel at lists.sourceforge.net
> >>  https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110620/f5e88aac/attachment.html>


More information about the Scummvm-devel mailing list