[Scummvm-devel] Tony Tough: developer here

Alex Bevilacqua alexbevi at gmail.com
Mon Nov 5 20:34:27 CET 2012


I think it was really awesome of Giovanni to share his experiences with the
development process for the game, and i've thrown it together into a blog
post at
http://www.alexbevi.com/blog/2012/11/02/developer-braindump-tony-tough-and-the-night-of-the-roasted-moths/
.

Personally, I'd love to see this (and more like it) posted on the main
project pages so it reaches the widest possible audience (I think maybe 4
people in total read my blog :P)


On Fri, Oct 26, 2012 at 4:58 AM, Paul Gilbert <paulfgilbert at gmail.com>wrote:

> 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.
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> 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/20121105/95ecfe26/attachment.html>


More information about the Scummvm-devel mailing list