[Scummvm-devel] Tony Tough: developer here

Paul Gilbert paulfgilbert at gmail.com
Fri Oct 26 10:58:32 CEST 2012

On Fri, Oct 26, 2012 at 1:27 PM, Giovanni Bajo <giovannibajo at gmail.com>wrote:

> Il giorno 26/ott/2012, alle ore 02:17, Dreammaster <
> dreammaster at scummvm.org> ha scritto:
> Yup, in fact I wouldn't have thought it to be possible to refactor
> existing code from threads to coroutines :) How long did it take you?

Several months of work in my off hours. Luckily, we already had a proven
coroutine module that was created for the Tinsel engine, another of our
game engines that runs the Discworld games. In their case, they used
coroutines rather than threads, but the way they did it was horribly
unportable, using the 'setjmp' and 'longjmp' functions to save the entire
state of execution stacks and later restore them. One of the other
developers, who I can't remember off the top of my head, adapted some C
code from the Internet to simulate them, and then did further work to
C++-ify the code, to make it easier to encapsulate local variables and have
everything saved.

As a result, I just need to add a few more methods to support Windows-style
Events (semaphores) that the game used, and it was already ready to use. Of
course, since using the coroutine framework does require each method to be
individually converted to use the macros, as you will have seen it code, it
still took a lot of work to convert everything.

I went though the pull review code and of course lots of memories sprang to
> mind, so I'm happy to post a few things.

Thanks for the recollections in your previous post. I enjoyed reading it.
Given the amount of time I spent working on the code to convert it, it was
nice to learn a bit of the history behind it.

> Given my ignorance of "advanced" programming techniques, I think I simply
> couldn't think of how one could execute a linear (blocking) piece of script
> code without recurring to multi-threading. So I think I didn't even explore
> alternatives to multithreading. Obviously multithreading programming isn't
> easy, so custom C++ functions, called from MPAL, were full of locking
> issues wrt to the main thread that redraws the screen. The game was
> developed under Windows 95 and in fact was released before Windows 2000 was
> out; on the NT kernel, the game didn't work too well and crashed often
> because of race conditions. I see that you debugged and fixed at least few
> those bugs, well done! Those simply weren't triggering on a 9x kernel.

Yes, some of them were doozies, and was part of the reason it took a while
for us to get the game running. Not only the race conditions, but also code
in places launching actions, and then having the caller presuming that the
launched action/method had reached a certain point in a certain amount of
time. I ended up having to have a bunch of explicit calls in places, for
example, to properly ensure launched 'threads' had already gotten to a
certain point. There were also several that came up during testing that
others were eventually able to track down and fix after a lot of
examination of the code in detail.

> Another issue with MPAL is that there's no way to skip cutscenes; I don't
> remember whether I couldn't think of a good way of doing it, or whether all
> methods I devised would require too much workload on scripters that were
> already quite full. I think it's my #1 technical regret when I see the
> game, and in fact I would quite love if you found a way to implement it now.

Agreed, that would be nice. One of the things we pride ourselves on is not
just fixing original game bugs, but also offering improvements, such as the
Global Save/Load dialog allowing for extra saves, with thumbnails. Support
for skipping cutscenes would be nice. Maybe we can do something that would
suppress screen updates and all waits so the game essentially runs as fast
as it can go until it returns to idle, or things like a screen change or
conversation starts.

> I think this ends my braindump of today. Feel free to ask questions of
> course.
> Thanks again for your work!

No worries. Thanks for putting so much work into creating the game in the
first place. I've got to say that, honestly, some of the puzzles were
weird.. I still think the whole thing you have to do with the worm is
bizarre, but overall, it was a fun game, both to work on the code, and to
actually play. :)

> --
> Giovanni Bajo
> My Blog: http://giovanni.bajo.it

Paul Gilbert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20121026/5b2d491c/attachment.html>

More information about the Scummvm-devel mailing list