ScummVM logo ScummVM website - Forums - BuildBot - Doxygen
Contact us - Buy Supported Games:
curved edge


Welcome to the ScummVM planet - This aggregates the personal blogs of developers, teams members and active participants from all around the ScummVM community.
If you wish to subscribe to updates to the planet or individual blogs please use the links on the right hand side.
To add your blog to the planet contact DJWillis.

May 29, 2017

Thierry Crozat (criezy)

Mission Supernova - A look at the music

Earlier this month we announced two projects for this year Google Summer of Code to add support for the Sludge engine and for the Mission Supernova games in ScummVM. I am a co-mentor for the Mission Supernova project (the other mentor being Strangerke). We were lucky enough to be provided with the original source code for Mission Supernova (for which we have to thank the rights owner). With the coding period for GSoC starting officially tomorrow we spent the last month looking at this original source code. Interestingly, in addition to the source code for the game we were also given the source code for some tools. One of those converts a MOD music file to a game data file. And I though it would be interesting as a side project to reimplement it so that it works on modern computers, and to then extend it to perform the reverse conversion from game file to the original MOD file (which we don't have).

I thus spent a few days working on this in the past two weeks.

We have been asked not to share the original source code (and anyway you would have to be a bit of a masochist if you want to see C code from over 20 years ago). But I will show a small extract to give you an idea of the work involved. The original source code is in C and for DOS.

The source code for the mod conversion tool is very compact and starts with these two functions:

For anyone familiar with supporting both big endian and little endian platforms, what they do is obvious. They swap bytes to convert between big endian and little endian representations.

If you are wondering what big and little endians are, go read my first post in this blog on adding support for the mac version of Broken Sword (you can also read the third post in that series about fixing speech for some mac versions of Broken Sword).

Conversion between big endian and little endian should come as no surprise. The MOD format was originally developed for Amiga, which are (or at least were at the time) big endians computers. Looking at the specifications of the MOD format shows that it is indeed using the big endian convention. On the other hand the DOS operating system was working on little endian computers. Using a little endian format for the music in Mission Supernova thus made sense to avoid having to swap bytes during runtime. Every little helped at the time to get good performances...

Another thing visible in the code above and that should come as no surprise (at least for developers dealing with old platforms) is that an unsigned int is coded on two bytes (and not on 4 bytes as you would expect nowadays) and a long int uses 4 bytes.

The last point we can note is that functions and variables have German names. Fortunately for me I did study German at school and could understand most of the code straightaway without having to ask Google translate (or my German sister in law) for help.

The first step of my work was to rewrite the code of that tools so that it works on modern computers, whether they are using big endian or little endian conventions, and can be understandable by others.

  • I replaced the byte swap function from the original source code with code we already have in ScummVM that handles byte swapping depending on the platform on which the code is run (so that for example reading a MOD file would only swap bytes when the code is run on a little endian computer).
  • I replaced data types such as unsigned and long with types provided by ScummVM such as uint16 and int32.
  • I rewrote the code to use ScummVM Common::File API instead of the low level DOS file access code.
  • I translated variable and function names to English.
  • I objectified the code a bit adding a ModReader class.
At this point, without the original MOD file, I had no way to know if the code I wrote was correct. Writing this code however helped me understand the differences between the MOD format and the format used by the Mission Supernova game.

The two formats are very similar, but besides the different endianness, there are a few other differences. Actually the format for the two parts of Mission Supernova  is slightly different.

Here is a description of the MOD file header:

And one of the Mission Supernova part 1 data file header:

For the Mission Supernova part 2, there are only 15 instruments stored and not 22.

Note how some information is missing in the Mission Supernova data file. That means that we have to guess what that information should be when converting that data file back to a MOD file. Fortunately none of that missing information is really important. For example for the song name I just decided to use the name of the MOD file that was hardcoded in the original source code.

Some other information is just formatted in a different way, such as the Mission Supernova instruments data having a loop start and loop end instead of a loop start and loop length.

Also the Mission Supernova data file stores explicitly the number of patterns and the offsets of the samples data. Those have to be computed from other informations in the MOD format.

The other difference not seen above between the two formats is in the pattern data. Both are using 32 bit values, but they are not coded in exactly the same way. For details on the differences just look at the source code and comments in the rewritten tool.

This knowledge of the MSN music data file might be useful when we have to work on supporting the music in the game engine reimplementation. For now I used it to write some code to do the conversion the other way around: from the game data file to a MOD file.

This allowed me to check that the code is correct:
  • By checking that the converted MOD file I am getting is played correctly in a player supporting that format.
  • By doing a round trip conversion: converting from MSN data file to MOD and then back to MSN data and checking that I get back the original file.
My first round trip test actually resulted in the original and converted MSN data file having a one byte difference (every bytes were identical except one). The offset of that bytes indicated it was the second byte of the order list length value, coded on two bytes in the Mission Supernova format. And then I realised that  I was using a char variable  (that uses one byte) since in the MOD format the order list length is coded on one byte. Writing that variable on two bytes meant the second byte was garbage.

The final source code is available at At some point I might merge it in the main ScummVM repository.

Implementing this reverse conversion also allowed me to listen to the music without waiting for the games to be supported in ScummVM. And to let you enjoyed that music as well, here are recordings for the music of the first and second parts of Mission Supernova converted to MOD and played back in an OpenSource ProTracker clone.

Mission Supernova part 1 music

Mission Supernova part 2 music

by Thierry Crozat ( at May 29, 2017 04:32 PM

May 28, 2017

Simei Yin - GSoC

GSoC Week 1

GSoC 2017: Sludge Engine Week 1

Week task conclusion

In general, my first week of working for GSoC project was going smoothly. And a huge thank you to my mentors _sev(Eugene Sandulenko), t0by(Tobia Tesan) and all scummvm team members that has helped me during this week.

Due to my project plan, my task for this week was originally :

Task 1-1 Read game data file, initialization, timer , main_loop:

  1. Use Common:File to read and slice game data file to init game objects and get index of sources in data file
  2. Main loop: checkInput, playAnimation, handleInput, display, wait_frame
    1. Use TimerManager for timer
  3. Define macros and built-in functions

We have modified the plan, though, because it’s not to rewrite the whole engine bit by bit as I originally thought, but to add whole engine files at first and stub all the parts calling libraries and functions forbidden by scummvm, then gradually unstub them using scummvm functions, till we have the whole engine.

To make a brief conclusion about what we have achieved and changed for this week :

Achieved :

  1. Add all sludge engine files into the scummvm and make it compile under Linux
  2. Replace original data reading functions by Common::File/SeekabbleReadStream
  3. We are moving to make graphics work for sludge

For later (They don’t have much effects for now):

  1. Timer, input, …
  2. File writing stuff

Some problems left to be solved :

  1. There is an segmentation fault due to the incomplete data loading of image files and animations whenever animation or sprite variables are referenced, at not initialized yet.
  2. The code don’t compile yet for Mac or Windows at present

What’s for next week: Graphics

Generally, what we will do next week is :

  1. Get backdrop (background) reading and displaying work
  2. Get the sprite system up based on 1
  3. Get spritebank up to have animations

We have started a little on making graphics works, hopefully the “segmentation fault” could be fixed then if we would be able to load animations.

Some findings about sludge

How game data works

Find out how do they parse the game data file and try to adapt engine objects

Inner structure of .slg file:

A string here is composed of:

  • 2 bytes to indicate the string length
  • a series of chars for the string

A resource block is like: (same for text, sub, object, data)

  • Text is a string.
  • Sub contains functions used and defined by user
  • Object (items that can be put into inventory and combined and characters)
  • Data (image, audio, video)

In Sludge, we stock the beginning position of the index of resources (startOfObjectIndex, startOfDataIndex, startOfDataIndex) to access them.

Built-in function

In sludge, not only the events, but also all resources are integrated through built-in functions and everything except raw bitmaps and waveforms is handled through a constructor in the scripts. To take a simple script for example :

sub init () {

addOverlay (‘image.tga’, 0, 0);

playSound (‘tada.wav’);

pause (60);

quitGame ();


We can see that the background and sound are all added through built-in functions called in these game scripts.

The whole game interpreter is basing on a stack machine to work. For built-in functions as well. That is to say, when a built-in function is called, all its attributes will be pushed into a stack which will be pop() inside the function for using.

by yinsimei at May 28, 2017 01:08 PM

May 11, 2017

Joseph-Eugene Winzer (Joefish) - GSoC


There have been many games I enjoyed over the last decades and some of them would have been already lost if it weren't for enthusiasts writing emulators or go as far as rewriting engines themselves.
Personally, I haven't done much in that regard other than poking memory for infinite gold or a simple reversing challenge. However, when the organizations for this year's GSoC were announced one particular project caught my attention.

I have fond memories diluted by nostalgia, of point and click adventures like Day of the Tentacle, Loom and others. Despite the genre's revival it has been mostly off of my radar for quite some time. So far it has been a great experience contributing to the project. Not only can I finally put my DOS knowledge and reverse engineering to use but the community has been welcoming, helpful and overall a great place. The ScummVM project ports point 'n' click and since recently also RPG game engines to their ecosystem so that they can be played on a variety of platforms.
(shoutout to criezy going through 30 revisions of my PR deep into the night..)

I have been fortunate to be selected to port Mission Supernova over the summer and translate the game from German to English. Anyone interested in the progress of my work, keep an eye on my repo and this blog where I will write about the progress of the project, its difficulties and technical details I find interesting.

Thanks again to the ScummVM team and Google for giving me this amazing opportunity.

by Joe Winzer ( at May 11, 2017 04:39 PM

May 10, 2017

Simei Yin - GSoC

Journey with ScummVM starts

This blog is created for the ScummVM project I’m involved as a GSoC student.

I’m quite thrilled to become one of the accepted participants in this program and what I’m going to work on for the next few months is to add a new 2D point & click game engine Sludge Engine and full support for the game Out of Order into ScummVM, which is an award-winning game released for free to show case the engine.

According to my project planning, I’m getting started to work on the first tasks this week and my following blog posts will give more details about them.

That’s it for now.

Again, thanks for the trust that have been put in me and I’m looking forward to working with ScummVM team.

by yinsimei at May 10, 2017 05:20 AM

May 05, 2017

ScummVM News Headlines

GSoC 2017 projects announced!

GSoC Logo

Today Google announced the accepted projects for this year's Summer of Code. We are pleased to say that ScummVM will be mentoring two wizard students who will have one mission: casting the Super Sludge Nova spell. Effects include adding support for two new engines, and the cooldown period is 12 weeks:

  • Joseph-Eugene Winzer (a.k.a. Joefish) will be working on adding support for the Mission Supernova game.
  • Simei Yin will work on porting the Sludge engine to ScummVM.

We extend a warm welcome to our students for what we hope will be a productive and interesting summer! You can follow their progress throughout the summer on the ScummVM Blogs.

by Criezy ( at May 05, 2017 08:00 PM

April 28, 2017

ScummVM News Headlines

Blinding you with SCIence

Explore a haunted museum, hunt a serial killer, mop the floor, descend into madness, find your true love, find your “true love”, travel to lands below, solve the Voodoo Murders, rediscover a lost opera—or do it all! The first batch of 32-bit DOS/Windows Sierra adventures are now ready to be tested in the latest daily build of ScummVM:

The Datafiles page has been updated with instructions on how to install these games. If you don’t own some, go to our where to get the games page to buy them!

Before you start your test run, please read the instructions on our SCI testing page, and take some screenshots along the way.

(If you have been itching to play some of the earlier SCI games, please take this time to run through them again too, as changes to the engine may also affect some 16-bit SCI games!)

Have fun!

by snover ( at April 28, 2017 08:00 PM

April 01, 2017

ScummVM News Headlines

We are changing our name!

Update: we were unable to reserve the domain and thus, with a heavy heart, we decided to abandon our rebranding effort and go back to our old name. Long live ScummVM!

The issue of the name of ScummVM has been raised many times since we started to add engines for non-SCUMM games. Until now we decided to keep the original name. However, the addition today of an engine for Plumbers Don't Wear Ties changes everything. Due to its fame and reputation for being one of the best video game ever, it naturaly becomes the flagship of what we stand for. Thus we have finally decided to change our name. We are now PlumberVM!

We used the name ScummVM for over 15 years, and this is with sadness that we say goodbye to it. It is a well known name and we do not underestimate the effort it will take to get the same recognition for our new name. Thus we are calling on your help to spread the news. In the short term this will inevitably lead to some disruption and confusion. But in the long term we are convinced that this is the right decision. With your support we will conquer the world! Starting from the sewers.

With the change of name we have also decided to expand even more the scope of our project. Last year we decided to accept engines for RPG games in addition to adventure games. Now we are also accepting any games that feature a plumber. Work has already started on the little known Super Mario Bros., and we have big plans for the future. We will have a big announcement soon, so stay tuned.

On a final note, it will take time for us to update all the places where our name appears. We have started today with our main website and you will notice in the next few days the change spreading to our social media accounts, wiki, forum and the pages not yet updated on our web site. We are also working on releasing PlumberVM 2.0 with the addition of two new supported games: Plumbers Don't Wear Ties and Full Pipe. This will happen as soon as the last few bugs in our engines for Plumbers Don't Wear Ties and Full Pipe have been squashed. Hopefully we won't find mutant turtles during testing. Squashing those is a real pain!

by Criezy ( at April 01, 2017 08:00 PM

Take off your tie and become a plumber!

We are very proud to announce that Retro-Junk has been working on ScummVM support for one of the most important games of Video Game History: Plumbers Don't Wear Ties!

Over the past few years, we've had a constant stream of requests asking us to investigate support for this genre-defining masterpiece. It changed the gaming industry forever, by introducing (among many other innovations) an awesome negative-filtered intro (with karting pandas), FMP as a genre game (Full Motion Pictures), and even to this day remains the only game which uses 42nd degree humour.

The engine reflects the astonishing complexity of the game, with 500 lines of code - at the time of writing, it would be one of the largest engine (62nd largest to be precise) in our tree. As you can imagine, it will take us some time to review and get it merged.

However, you can already grab the source code from this pull request on GitHub, build a copy and play it (only PC version supported currently). And remember, we are always interested in new screenshots!

We'd also like you to join us and give a very special thank you to two of our developers, uruk-hai and t0by. They've continued to relentlessly push for support of this game, keeping everyone motivated. This work may not have been possible without them!

Before you start your test run, we encourage you to read through our testing guidelines, and please take some screenshots along the way.

Now, go! Grab your copy of the game and the code, and enjoy this historical moment!

Update: If you thought it was an April Fool's Day joke, you have been trolled. The Pull Request on GitHub is genuine, and ScummVM will really support Plumbers Don't Wear Ties if it gets merged.

by Strangerke ( at April 01, 2017 08:00 PM

March 10, 2017

Alexander Tkachev (Tkachov)

GSoC: ScummVM site new look

I've posted this picture on IRC yesterday:

It inherits that green/white scheme of mine. The navigation menu from the side moved in dropdown lists on the top panel. ScummVM description is a bit shorter, shows an actual application screenshot and calls to download the newest version. Then goes the two-column layout, and the right column can contain not only screenshots section, but also Contribute and Donate sections.

Making of logotype & color scheme

As my original idea was to make a clean minimalistic look, not to change familiar colors, let me show you how exactly I came to what I have now:

So, let's try designing a logotype!

Step 0. Open an editor.

Step 1. OK, what's the most important part of ScummVM logo? Green "Scumm" and gray "VM" parts, for sure! As we're trying to achieve the minimalistic look, borders and stuff would be left out:

Looks good for me!

Step 2. So, the other part of logo is background color, which is familiar ScummVM orange:

Oh. Probably gradients did all the job. Or the borders. May be try different tones?

Not really better.

Step 3. OK, so they say that you could make a solid color scheme not only of complementary colors, but also of analogous. Let's try replacing orange with green:

Hey, it's not that bad. And it's not exactly green, it has some yellow tones in it. The closest to orange I could achieve =)

by Tkachov at March 10, 2017 09:00 PM

March 07, 2017

ResidualVM News Headlines

Welcome to Google Summer of Code 2017

GSoC 2017 Logo

We are happy to announce that we are participating in this year's Google Summer of Code under the umbrella of our sister project ScummVM.

Have a look at the list of ideas or bring your own idea!

If you want to participate or have questions about GSoC, come talk to us on IRC Freenode channels #residualvm or #scummvm.

by aquadran ( at March 07, 2017 12:00 AM

February 28, 2017

Alexander Tkachev (Tkachov)

GSoC: ScummVM new look (idea)

Recently I've thought to try designing a new fresh look for ScummVM. This is what I came up with:

As you might've noticed, it's a little bit inspired by Steam: games listed on the left and current game displayed on the right. Saves are available right from the very first screen.

Options dialog stayed pretty much the same, but tabs are replaced with a list. That allows to add more tabs without any scrolling and makes it look similar to main screen.

I was unable to add the familiar orange color into this scheme without ruining it, so I replaced it with pale green. The whole look is kind of minimalistic: no gradients, borders, rounded angles and such. The similar approach could be used to redesign ScummVM site.

These sketches show a 1024x768 desktop look, while not doing anything about platforms with smaller resolutions. I think it's OK to go with a simple skin for those, meaning the layout stays the same and only the colors/fonts/images change.

I worked with ScummVM GUI system, so AFAIK it wouldn't be too hard to change those layouts to correspond these sketches. That couldn't be achieved with a simple skin, because some minor changes needed to place saves dialog in main dialog or to replace tabs with a list.

P.S. It's not about GSoC, but my site is configured to show only those posts which has "GSoC" prefix in the RSS feed Planet is aggregating.

by Tkachov at February 28, 2017 09:00 PM

November 24, 2016

Sven Hesse (DrMcCoy)

xoreos Not-Thanksgiving 2016

xoreos is a FLOSS project aiming to reimplement BioWare’s Aurora engine (and derivatives), covering their games starting with Neverwinter Nights and potentially up to Dragon Age II. This post gives a short update on the current progress.

Note: This is a cross-post of a news item on the xoreos website.

And again a year is nearing its end. Like last year and the year before, I’d like to turn my gaze inwards.

A lot of things happened with xoreos this past year, albeit most of them hidden and “under the hood”:

  • I wrote about disassembling NWScript bytecode. The tasks I mentioned there are still open, too. If anybody wants to take them up, I’d be happy to explain them in more detail :).
  • We released xoreos 0.0.4, nicknamed “Chodo”. That was the only release of xoreos in 2016. xoreos 0.0.4 included some minor fixes and features for Neverwinter Nights, and the xoreos-tools package included the new NWScript disassembler.
  • In April, I reached a streak of a full year of daily xoreos commits. Due to some real life things, I had to take a break there, though. I’m now again at three months of daily commits, but there is a three-month “hole” between April and August.
GitHub contribution graph in April

GitHub contribution graph in April


GitHub contribution graph in November

GitHub contribution graph in November

  • Farmboy0 fleshed out the Jade Empire engine a bit, mostly in the scripts department.
  • Supermanu implemented a huge chunk of the character generator for Neverwinter Nights.
  • Farmboy0 fixed a glitch in the Neverwinter Nights animation system that has plagued xoreos for quite some time: the animation scaling in various creature models was off. This lead to, for example, the head and arms of elves detaching from the body during the yawn animation.
  • I then implemented a few more animation script functions, too, which is especially noticeable in the intro animation for Hordes of the Underdark. I also fixed a mistake in the keyframe interpolation. This takes care of another glitch in Neverwinter Nights: model nodes rotating the wrong way around.
  • smbas added support for Lua scripts in The Witcher. A lot of the initialization code that sets up the classes and functions The Witcher expects to find is still missing, so nothing obvious is visible as of yet.
  • Farmboy0 moved the window handling from the GraphicsManager into a new WindowManager class, making the code more readable.
  • I fundamentally restructured our build system, or at least the autotools part of it (xoreos can be built using either autotools or CMake). Previously, we used a recursive autotools setup, where make recurses into each subdirectory. This is, unfortunately, pretty slow, among other drawbacks. I changed it to be non-recursive now, with the top-level Makefile instead being created using (recursive) includes.
  • I then introduced various smart pointer templates into the codebase, making it easier to read and easier to keep track of memory allocations.
  • berenm added AppVeyor integration. Like Travis CI (which we already use as well), AppVeyor is a continuous integration service. This means that every single commit to the public xoreos repository will now be built on Microsoft Windows, using Microsoft Visual Studio 2015, in addition to gcc and clang on GNU/Linux (via Travis CI). This ensures that any compilation breakage on these systems is immediately visible and can be fixed at once.
  • GitHub added a new feature, “Projects”, that provide Kanban-like boards of tasks. I took the time to fill the xoreos Projects page with boards for tasks from our TODO list.
  • There were of course also various clean-ups, minor fixes and expanded code documentation.
Animation with glitch

Animation with glitch

Animation without glitch

Animation without glitch

Animations in the HotU intro

Animations in the HotU intro

Additionally, there are several tasks currently being worked on, among them:

  • Supermanu is looking into pathfinding.
  • mirv is still working on rewriting the OpenGL renderer.
  • I am currently writing unit tests for the xoreos codebase, using Google Test. I already found multiple issues, bugs, and corner cases while adding them.

From my side of things, my current plan is to make my unit tests branch public some time in December. I’ll write a small announcement here about it then. A new release of xoreos, 0.0.5, should follow early next year.

As always, this all wouldn’t have been possible without a lot of people. For them I am thankful.

  • Farmboy0, for various fixes, implementations and file format spelunking.
  • Supermanu, for his character generator work and pathfinding research.
  • mirv, for continuing to work on the OpenGL rewrite.
  • smbas, for his work on Lua and The Witcher.
  • berenm, for the AppVeyor integration and CMake knowledge.
  • TC01, for writing a Fedora specfile for the xoreos projects.
  • CromFr, for taking a stab at the walkmesh structure in NWN2’s TRN files.
  • clone2727, for invaluable ideas and corrections.
  • The folks at GamingOnLinux, who continue to be a great resource for all things related to Games on Linux.

I am also thankful for all the people who take the time to explain things to others, people who write interesting, useful or needed articles, and people who provide mentoring and help. Relatedly: a week ago, Stephanie Hurlburt published an article with engineers who are willing to mentor or answer programming/engineering questions. I for one think that’s a really great idea. Please take a look at that article.

And now, let’s see what the next year has in store for us. If you, however, found all this terribly interesting and would like to help with our little project, then please, feel free to contact us! 🙂

flattr this!

by DrMcCoy at November 24, 2016 05:31 PM

November 04, 2016

Paul Gilbert (Dreammaster)

There's been a Titanic amount of progress

Since my prior posting earlier in the year, there's been a great deal of progress in Starship Titanic. I decided to put aside the problem of reverse engineering all the Star Map classes until I had the rest of the game working better. In that respect, I've made great strides since, as of last weekend, I was able to complete the entire "prologue" of the game  That included using the computer, experience the crash, talking to the Doorbot, entering the ship, and viewing the Credits. Huzzah. \o/

I was going to prepare a video showing the intro, but with the most recent changes, there seems to be some instability showing up. It seems like something that was already present, just coincidental that the newer changes result in more frequent crashes. It's kind of hard to narrow down the cause, as there's also a problem with the implementation of the Indeo video decoder we're using for NPC videos like for the Doorbot, where it's reading past the end of the frame data. So it's difficult to track down the memory corruption, as warnings about the decoder are completely overwhelming everything else.

So for now, I'll present a screenshot of the amazing multi-color Doorbot :)

After thinking over matters, I've decided to keep progressing into the game, and come back to look at the problem later on. Part of the trouble I'd been having with the code was the sheer length of the intro as I got further and further into it.. requiring me to wait through several minutes of cutscene & conversation every time I made any changes or bugfixes. Even if the intro has suddenly become unstable, I still have savegames I made from beyond it, so I'm using them as a starting point to make further progress testing into the game.

Speaking of testing, I've had a major boon to my efforts to track down bugs in the code. I was previously stymied trying to test the original Windows executable in the IDA debugger, since it kept crashing on me. Plus running in compatibility mode full-screen didn't help either. And without the ability to see "valid" values in the original executable, I anticipated it would be difficult to track down errors in my code, since I wouldn't know whether values/state at any point in time were already wrong on not.

Luckily, though, I stumbled on a solution. Using the Visual Studio "Attach to Process" allowed me to attach to the game executable without it crashing, unlike IDA. At least, for the majority of the time. Though switching from the game to the debugger and back again caused severe corruption of the full-screen display. Luckily, though, there had been some previous discussions about running the game in a window - I was able to use a utility called DXWnd that intercepted the game's DirectX calls and forced it to run a window. The result wasn't perfect, in my opinion, for anyone wanting to play through the game, but it's worked well enough for my purposes, in conjunction with Visual Studio.

As a result, I'm now making much better progress than I had anticipated, and hunting down bugs is in general much easier than I'd anticipated. Let's hope that stays the case.. my next major gameplay milestone is to complete more extensive conversation with the Deskbot to get myself a room. The basic yes/no detection for the Doorbot worked pretty smoothly first time I tried it. The Deskbot, though, is using more of the conversation parser - I've already located and fixed some problems with it. Let's hope that there won't end up being too many.

On a final note, the one downside of my surging progress with Titanic is that I'm currently spending less time working on finishing my Xeen engine. I'd originally anticipated the frequent roadblocks trying to hunt down bugs in Titanic would have me growling in frustration, and switching to Xeen for awhile to unwind a bit. Now with the ability to debug the original executable, that hasn't really happened so far, and hopefully won't happen. I'll probably end up spending more time right now focused solely on Titanic, and see if I can't get the bulk of the game with the exception of the final starmap working by the end of the year. Then I'll be in a better position to alternate between working on Xeen and trying to disassemble the remainder of the Starmap classes.


by Dreammaster ( at November 04, 2016 05:11 PM

August 24, 2016

Bendegúz Nagy (WinterGrascph)

Alas, the end

And so it has come to this, all things must end. But it is nothing to be sad about for me, this has been a great addition to my experiences and I welcome the change for it has been something short of 3 and a half months that I've been working on DM. Not that I won't be working on it from now on, but I'm definitely taking a few days off, lest I come to dislike it for looking at the codebase for too long.

The pull request to merge the engine is due next week as it still doesn't compile with GCC (strangerke has been working on it relentlessly (think 127kbs of error log reduced to 9)). Relatedly, the code is not particularly compliant with the coding conventions at ScummVM (strangerke is working on it, I'll soon start feeling ashamed and will have no choice but to help him).

As for the future of this blog, it is possible that I will post updates for when something major gets incorporated into the engine (think support for other versions).

Almost forgot about the new stuff, if I remember correctly it's convenient loading/saving from the launcher and from the inventory. And also there are debugger commands like godmode, noclip, set pos/map and the aptly named, gimme, which spawns items. Entering the commands without arguments will output their usage, call 'help' for a list of them.

Gimme can be used like this: call 'listItems', if you are looking for something enter any part of it in caps like this 'listItems OF FEAR'. Once you found what you are looking for, call gimme with its name: 'gimme HORN OF FEAR'.

Setting the map is slightly broken. For best results, teleport to an adjacent map, then use pos to set your position next to some stairs and off you go. Avoid using noclip.

PS.: So long, and thanks for all the fish

by Bendegúz Nagy ( at August 24, 2016 08:34 AM

August 15, 2016

Alexander Tkachev (Tkachov)

GSoC: Project Summary

What I was working on during GSoC is Cloud storages support in ScummVM. Describing this feature in my proposal (mirror), I mentioned that it would include an API to interact with supported storage providers (which are Dropbox, OneDrive, Google Drive and Box), saves syncing mechanism, functionality to upload and download games data, and, of course, GUI for all of these. Proposal also has some extra tasks mostly making user experience better.

Some things were rediscussed during my work, but the main idea remained intact. The work is done and pull request already awaits final review before getting merged. API for all four announced storage providers works fine, saves are syncing and games data could be easily downloaded. Not only described extra tasks were complete, but also some functionality not mentioned in the proposal was added.

Saves sync is probably the main reason why Cloud storages support is needed at all. It allows users to easily continue playing the game on another device by simply connecting both to the same storage and doing the sync. It’s automatically started on ScummVM launch, on games saving (including autosaves) and when user opens Save/Load dialog. This dialog was updated to show a progress bar while syncing and also to «lock» slots which are being synced. To indicate that there is a sync in progress, small Cloud icon is shown in the corner.

To use the feature, users must connect a storage first. To do so, they should navigate into Cloud tab of Options dialog, select a storage provider and press «Connect» button. It opens a special Storage Connection Wizard, which provides the instructions on connecting. It has different variations depending on set of libraries ScummVM was compiled with. In the most simple case it says users should navigate to a special short link (to, which redirects them to provider’s page. When they allow ScummVM to use their storage on that page, they are redirected back to, where the code is shown. This code should be typed in the wizard dialog. It’s used by ScummVM to connect to the storage and use provider’s REST API then.

ScummVM page makes the code that way so wizard could check that code has no mistakes in it. If there is a mistake, it notifies user where it probably is. If ScummVM was built with SDL2, pasting from clipboard is supported. Wizard also has «Open URL» button, which makes it easier to navigate to provider’s page on platforms where URL opening was implemtented (these are Windows, Linux, Mac OS X, Android — iOS and Symbian are coming).

But it’s much easier to connect a storage when ScummVM’s built with SDL_net support, because then ScummVM runs a local webserver. In this case users are not redirected to ScummVM site from provider’s page — instead, they navigate directly to webserver’s page. No code typing is needed then, because ScummVM automatically gets it from user browser’s HTTP request. This webserver makes connecting a storage really fast and simple.

Another thing Cloud storage might be used for is games data download. Users can put their games into storage and then easily download on all their devices. A special «Download» button in Cloud tab opens Download Dialog, where users can select a remote directory to download and a local directory to download into. It shows a progress bar there and automatically tries to detect a game when download is complete. Users are also free to run download in background: no detection will happen, but a message will appear on the screen to notify them of finished download.

Both storage connecting and game downloading are shown in a video I’ve recorded. I’ve also posted information about my progress in the blog every week. Feature is documented on the wiki pages, with some diagrams included.

And, finally, we’ve decided that I should do a big extra task. Local webserver, which I originally proposed to simplify storage connecting process only, has been extended to be used for «Wi-Fi Sharing» feature. It means that while ScummVM’s local webserver is running, one can use browser on another device to navigate through directories, download files, create new directories or upload files!

Users can specify server’s port and their ’/root/’ directory within the same Cloud tab. Only files under specified directory and ScummVM’s saves directory are available, so users secure data is safe.

by Tkachov at August 15, 2016 09:00 PM

August 12, 2016

Bendegúz Nagy (WinterGrascph)

Finest colours mankind has to offer

Yay! The color palette is FIXED once and for all! No more radioactive green snot on every object and champion and door and what not! The GUI looks fabulous with it's newfound colours, it's just so much more pleasant to click on it now.
Now, the original game uses copper to stretch those few colours the Amiga platform could offer at any given moment and given that ScummVM has no support for something like that (and why would it?) I shied away from even coming close to trying to fix it. Now as the end is nigh, it had to be fixed, and so it was! Phase one, double the palette and offset the pixel colours. Phase two ???. Phase three, profit!
Relatedly the engine is almost complete. What's missing is correcting some display functions, hunting down a few annoying bugs and making sure the game can be finished and then all will be well. The later, so I gather, is not yet achievable. The fluxcages spawned to trap Mr Chaos cannot be seen, because the function drawing them is missing, and that particular function happens to be in assembly (... ehh) and so I can't really test if anything is happening at all, gonna have to make it draw some dummy image.
As always, here's a nice GIF, basking in it glory:

by Bendegúz Nagy ( at August 12, 2016 03:04 PM

August 10, 2016

Bendegúz Nagy (WinterGrascph)

Nice cursor, nice spells

Cursor got fixed, seems like googling Amiga hardware sprites is all it needed. Also found the bug with the spell symbols, a petty toUpper call in the text drawing method, dunno what is was doing there in the first place. Long story short, dungeon looks a lot nicer now, palette needs a fix and then it will truly look splendid (sans some scrabbled textures). Here, have nice GIFshot:

by Bendegúz Nagy ( at August 10, 2016 09:45 AM

August 06, 2016

Alexander Tkachev (Tkachov)

GSoC: Cloud security, WAGE updates

This week I’ve worked on some security-related updates for LocalWebserver. It now has a «minimal mode» — no Files Manager features are available, only redirect_uri. It’s used automatically in Storage Connection Wizard, and server goes offline the moment it gets the code.

Paths are now dealt with more strictly: «../» is forbidden to use, ScummVM has some «blacklisted» directories and user can define where the «/root/» is. Files outside that folder are not available through Files Manager. Plus, if no rootpath specified, «/root/» is not even listed — only «/saves/» is available then. GUI for changing rootpath is added to the same Cloud tab.

One other thing I did was rebasing. Travis checks PRs by merging with master and then building. Titanic, which wasn’t there when I started, was using OutSaveFile as if it’s typedefed WriteStream. But in my Cloud PR OutSaveFile is a real class (which starts saves sync when finalized). So, I had to rebase and add a simple fix in Titanic, and now Travis checks are passed again.

In order to update WAGE saves, I had to add pos() into WriteStream class. Managed to break a few builds that way.

Also, fixed a few crashes in WAGE games. One was because code tried to copy pixels outside of the Surface, and I added checks, so copied rectangle is clipped to always be within surface area. The other was because operator[] was used on an empty String, and now that code uses it only when String it not empty.

by Tkachov at August 06, 2016 09:00 PM

August 05, 2016

Bendegúz Nagy (WinterGrascph)

Sounds and slightly better blitShrink

The title says it all. There are now sounds in the game, it is the first thing that worked on the first try, or so I hope. One can now indulge in the angry grunts the champions make when you bump them into the walls. Makes one wonder if they want to be there in the first place. Why would they follow an order to go headfirst into the wall?
Also, blitShrink function has been dusted and adjusted and thus the dungeon looks a lot nicer. It seems that after hours of searching for broken code, I realized that nothing is broken, but the original blitShrink method works a bit differently than what I tried to simulate it with. So it seems I can't avoid the assembly after all.

by Bendegúz Nagy ( at August 05, 2016 04:29 PM

July 27, 2016

James Woodcock

My Enhanced Beneath A Steel Sky Soundtrack Mentioned in Adventure Afterlife Series

It was a lovely surprise today to notice that writer Rebecca McCarthy mentioned my enhanced music for classic point and click adventure game Beneath A Steel Sky, which I spotted on the Giant Bomb forum under part 3 of her Adventure Afterlife series.

The enhanced soundtrack, which can be used with ScummVM to be played within the game and has also recently been part of the Revolution’s 25th Anniversary Box Set, is a free download for fans of the game.

One of my all time favorite games, if cyberpunk or science fiction interest you I encourage you to play the game. It is available legally for free from SCUMVM or GoG as is James Woodcock’s ( Fan made) enhanced soundtrack, which I recommend you use. Mobile versions are also available if you want to support the dev.
Rebecca McCarthy – Giant Bomb

Make sure you read her entire Adventure Afterlife series on her website.

by James Woodcock at July 27, 2016 08:55 PM

July 16, 2016

Paul Gilbert (Dreammaster)

PET is PrETty much done

Hi all. Been a while since my last posting; and a hectic last couple of weeks. After flying down to Florida for a 4th July long weekend getaway, I was barely back before I had to get ready for a work trip to the west coast. Then I get back to two days of company photo-shoots, which kind of disrupted getting back to normal work; but no sooner than they were done, I come down with a cold and had to stay home for several days. And was too sick to even really use my computer until now. :(

Nevertheless, despite all of that, work has been progressing on Starship Titanic since my last posting, and I've made a lot of progress. Firstly, there's the PET User Interface. This was one of the major areas that still had to be investigated last time. Since then, I've spent a lot of time figuring out how everything works, and re-implementing it all in my ScummVM engine. Behold the fruits of my labor:

Code for all the various areas has been pretty much all implemented. You can enter text in the conversation tab, and click stuff in all the others. There's just a few minor visual and functionality glitches here and there, such as the dials in the above image. Some of the tabs, like the Remote and Rooms tabs, are mostly untested at the moment.. it will be easier to test when I have more of the game logic implemented, and can properly test them with live data. Saving and Loading is also waiting on me to finish the saving and loading code.

As before, I was aided somewhat in implementing the PET by how clean the class hierarchy was designed, and the fact there were various internal error messages scattered about the code to give an indication of the classes' original names and purposes. For example, the code has a single common class CPetGlyph for the square glyphs used in all the different PET tabs, and CPetGlyphs for the collection of glyphs, with all the logic for scrolling and rendering. Individual PET areas simply derived from that, and instantiated whatever glyphs were needed, be they action icons like for Save, Load, and Quit, or inventory items that can be selected.

Once the PET was pretty much done, I started looking into the conversation handling and text parsing. To begin with, I worked one of the easier, self contained areas of vocabulary loading. All the vocab data for Starship Titanic is held in a resource inside the game executable called STVOCAB.TXT. It holds the data for an impressive 4700 words! A lot of these come down to synonyms for common words, and in fact even includes foreign language words, like "ein" as a synonym for "a". Each word entry in the file also contains data for what kind of word it is (such as action, adjective, etc.), as well extra information that is used by the parser to uniquely identify the words. The vocabulary loader builds up  the data for each word in turn, building a master list of overall words support by the game, and a linked list of synonyms for each word.

Once I did that, I started looking into the input processing code that gets called when a line of text is entered in the PET. First of all, the game calls some pre-parse methods. These take care of a bunch of standard processing of the line, including:

  • lowercasing everything and removing extra spaces between words
  • Conversion of numbers from textual formats into decimal. That was surprising.. the game has special code in place so you can enter numbers like '42', 'forty two', or even 'LXXIII'. That's right.. the parser is so sophisticated, it even handles roman numerals. :)
  • Expanding common contractions like "it's" to "it is".

Once preprocessing is done, it then breaks down the entered sentence into a series of words. Each word is checked against the word synonym lists to identify the known word for each entered word. Here again, the parser has extra complexities that surprised me. It can not only find word matches based on exact word matches, it has two fairly complicated routines that can identify various forms of pluralization, as well as common word prefixes like 'super', 'anti', 'counter', etc. and find matches on the word without the prefix. At the end of this process, the entire input has been broken done into a linked chain of recognized words, and the real handling of figuring out the player's input can be done using custom logic for each NPC script.

At this point, whilst I had made some inroads on NPC script handling, I somewhat started drifting on what area I worked on. Strangerke had been looking at some of the core game scripts to add me in writing game logic, so to make things simpler in the long-run I went back to the main CGameObject base class, and spent some time figuring out all the remaining unknown methods. Quite a few of the methods were basically stubs calling PET Control methods, so my prior work on the PET was a great help.

Next, there was a bunch of CGameObject methods calling movie code, so I decided it was finally time to figure out what it was doing. I was able to properly implement the game's OSMovie class which handles movies, and it's AVISurface which handles the low level AVI files. It was actually interesting in that some videos have a second video track - I haven't 100% disassembled the movie drawing code, but my impression is that pixels in one are transparent, and in the other are not.  This required me to add an extension to our AVIDecoder to allow a callback method for selecting which streams the AVIDecoder would use. That way, I could set up two decoders in the AVISurface class, one with the audio and first video track, and the second with the second video track, if present. This neatly avoids the limitations of one video track per decoder. The replacement movie code is all implemented now, but apart from cursor loading working (the cursors are stored frame by frame as a video), movie playback is still crashing, and will have to be debugged further. But at least I know what the bulk of the movie methods are now.

Finally, I moved onto the Star Control class. This is what implements the game's starmap control.. with PET mostly implemented, NPC scripts partially implemented, and movie handling more or less done, only it and sound are left unlooked at. And as I've mentioned previously, sound handling has a lot of spatial processing for sounds that I may simply not implement - the AVIDecoder already handles video sound, and I'm hoping to hook up the other sound methods to simply use standard ScummVM sound decoders. So that makes the star control the only remaining large area to look into.

Oh boy, and what a large area it is. Even basic identification of classes was already bumping up to nearly 30 classes all specific to just the star control. I felt greater and greater dismay the further I looked into it. Honestly, it was like Hopkins FBI all over again, where they included a full Wolfeinstein 3D style minigame in the PC release. In that case we were lucky, and could simply ignore it. Not so much in this case - all the classes will have to be implemented.

As I've looked into it further, and worked on classes that don't depend on others (so are self contained, and in theory easier to figure out), some of them have started to make sense. There's matrix and vector classes.. somewhat surprisingly, two versions of each, one for floating point numbers and one for doubles. I can only assume back in the day there was space vs speed considerations for having both types; I've not yet reversed all the methods, so I don't know if they can be merged in the future. I've also identified two "star points" classes that use large lists of spatial data that was hard-coded in the executable. Hopefully, the other remaining classes won't be too hard to figure out likewise.

So, all in all, things are going good. I'm starting to feel better, and I'm making inroads on the last major area of the game. Once I get that out of the way, it'll be a matter of finishing off the NPC scripts, implementing miscellaneous methods here and there such as sound handling, and then implement the game logic. Which, with all the core engine implemented, will hopefully be a straightforward, if slow process.

by Dreammaster ( at July 16, 2016 06:31 PM

July 01, 2016

Dmitriy Iskrich (iskrich)

GSOC Resume.

My exams were over, I now have to turn my attention back to Director engine. I continued to work 5 days ago. And next things have emerged:

Little/Big Endian

Starting from Director 4, RIFX containers can have little-endian byte order, specifically for this, regular ReadStream was amended to ReadStreamEndian and now engine can work with both orders. In so doing, byte order is determined by first tag (“RIFX” or “XFIR”)

Shared casts

In the majority of the movies, casts not stored directly in the movie. There is a special file, with a special name (surprising!) that stores, common to all movies in folder, sounds, images, texts. For this situation, renew shared casts immediately after jumping to new folder was written. Shared may be some regular buttons for game.

For example: (Spaceship Warlock in our engine)


But determine shared cast movie name still a problem.


Significant progress has been made by sev : storing local/global variables, Lingo macros, built-in-functions and more… On my part, were introduced execution go to loop, go to next/previous commands.


Reading text resource realized a long time ago, and it time to deal with rendering issues.  Director font map has been reviewed by sev. And it was decided to use classic mac fonts data file for drawing our text. Future target: rendering with box shadow, borders (if needed)

by iskrich at July 01, 2016 07:13 PM

June 18, 2016

Dmitriy Iskrich (iskrich)

GSOC pause

As it happens, I needs to complete some work related to my student status. It’s about my exams. In this regard, in the coming week my time should be given to questions about tropical geometry and information models/processes.

At the end of week, I will continue to work on Director engine.

by iskrich at June 18, 2016 07:40 PM

June 17, 2016

Dmitriy Iskrich (iskrich)

Director: New week – new challenge

And once again I’m writing about my GSOC progress.

This week:

  • Loading transition info and implementation of some movings (8/52).
  • Imitation 2 track sound system (such as in Director).
  • Rendering trail sprites (it works like background images)
  • Parsing new kind of scripts  – movie scripts.

Speaking of scripts,  there is a work on the Lingo compiler by sev.  There is, at present execution some media interface commands like play part of sound files and the processing of alias map. Also put/set commands have been added.

Were reviewed, Director ‘go to movie (label)‘ commands. In many games this is main command, with this you can simulate  walking across levels. But this transition using special name of movie, and because of that movie loading was redesigned.

I know I promised to show The Journeyman Project movie files. But right palette still got trouble.

Specifically for this post, I’ve copied in my local code, palette, which contuinity uses as fallback. And some of JMP movies seems more or less pretty.


by iskrich at June 17, 2016 09:01 PM

June 10, 2016

Dmitriy Iskrich (iskrich)

Director: Initial Lingo, events.

A week went by, engine changes, but slowly. Now is the moment when differences in Director versions are important.

Under the supervision of sev, I started to learn life cycle of the playback/draw system, it’s important because it can tell about when causes local events, such as frameEnter, frameExit, idle. In other words, we want to achieve event order, same as in Director. For me personally, it was hard to figure out what order is correct, sev advised me to check it right in Director. Because our target game is Journeyman Project, I looked in 4.0 version. By writing a simple script, I have found right positions in my code for calling this events.


It is worth noting, that in other versions the order differs, part of the problem is new events (D6: stepFrame, prepareFrame, beginSprite …).

Maybe you have already guessed that, this events are necessary for our feature Lingo interpreter. In addition to the system events, I’ve also added mouse events, this event are sent to clicked sprite on top layer.

Simple sound wrapper had been written, in JMP we’ll see .wav and .aiff formats. ScummVM audio decoders deal with this.

Decoder for 1bpp pictures was also added. This pictures are sometimes used instead text.

There is now some issues with 256 color palette loading. I hope problems will be solved, and in the next report I can show movies from The Journeyman Project.

by iskrich at June 10, 2016 06:17 PM


curved edge   curved edge