GSoD week 6


Just a quick update this week.

I'm still waiting for someone to have a look at PRs #2535 and #2499. Hopefully they can get it soon.

I have quite a bit of work done locally but I'm not in a hurry to open another PR. My plan is to open a PR around the weekend with 10 more high-priority files with added/edited doxygen comments. The files in question will be the ones from stream.h up to metaengine.h from this list.

I am still investing a significant chunk of my time into developing the knowledge of aspects of C++ used in ScummVM headers. Figuring out how streams work was the latest challenge :)

Android Love

Our new and shiny Android port for ScummVM v2.2.1 is now live on the Google Play Store. After quite a long period of dedicated work from our team developers, and a month of public beta testing by members of our community who helpfully reported quite a few issues for us to address, we are finally ready to give you the stable release for our ScummVM Android app.

This app has been significantly re-written and tested on modern Android devices, running up to Android 10+. It includes new features which bring it up to speed with the desktop ScummVM application, such as FluidSynth support, Cloud Saves and more localization choices for the UI. Also included is the Local File Server (LAN) feature, whereby your device can act as a temporary file server allowing you to download files (eg. save files and even the config file) or upload new ones (eg. game data) using a web browser from a PC or another client.

With this release we have resolved a few long standing issues such as:

  • upgrading from previous versions without losing access to your previous configuration and save files
  • folder navigation (based on storage access permission settings)
  • Working special keys on the virtual keyboard (such as F-keys) as well as handling of repeated keys

Other significant improvements have been made to the interface of the application, such as the ability to choose whether the GUI will feature filtered graphics (bilinear scaling) or not (nearest neighbor scaling), several fixes for the virtual keyboard behavior to make it more responsive and closer emulate the behavior of a physical keyboard, and support for virtual mouse control using the analogue joystick from your controller.

By upgrading to the new 2.2.1 version you will be able to enjoy support for all the game engines that have been introduced on ScummVM since 2.0.0, such as Blade Runner, Ultima IV, Quest for Glory IV, as well as all the bug fixes and improvements made to the existing ones.

Of course we continue to monitor our community’s feedback and welcome any suggestions for improvement. As always, please report any bugs you encounter on the ScummVM bug tracker site.

We thank all our beta testers for their most valuable feedback and hope that you enjoy this version of ScummVM Android.

Season of Docs: Week 6

We’re half way through the project! 6 weeks has absolutely flown by... 

This is what I ticked off the to-do list this week:

•  I re-arranged and tidied up the documentation. Each settings tab (or topic, in the case of audio) now has its own dedicated page. All the information you need to understand those settings are in one place; the first section on each page is an overview of the options, the second section goes into more detail, providing some background information and further explanation( or a how-to guide, in the case of the Cloud page). I hope that this way of presenting information is a little less confusing and easier to navigate - any feedback welcomed, as always! 

•  I added a section regarding games on the main page; where to get them, where to find which data files you need, and where to find whether they are supported/compatible.


After a discussion with @Mataniko this morning, my timeline for the next couple of weeks is as follows:

Week 7:


•  FAQ - pending feedback from the community, I will start working on a new FAQ which will hopefully be both relevant and useful. I anticipate that many questions will already have been answered in the documentation, and that I will be able to link back to this to supplement the answers. 

Ports (new section):

•  I will start using the information from the wiki to create port pages containing, at this stage, the following information:

•  Installation (not including how to homebrew)

•  Where to put the games

•  Control mapping

•  Port-specific settings

•  Known port issues - including unsupported games and unsupported features. 

I’ll start with the most active ports. According to traffic on the wiki, these are: Nintendo Switch, PS Vita and PSP. I’ll work on drafts based on the wiki information, but will reach out to porters to check that what I have is correct and up-to-date, and that nothing important is missing. 

Getting started:

•  iOS - I’m not happy with the GIFs currently on the iOS page. I will replace these with screenshots for clarity. 

Release notes (new section):

•  Add a release notes page for V2.2.0

Week 8:

•  Continue working on the FAQ and port pages, as I get more information from the community. This will probably be ongoing for the remainder of the project. 

•  I’d like to start thinking about how to set up a framework for documenting future features and releases, to ensure docs are always kept up to date! First draft. 

Docs-in-progress are available at

As always, I welcome feedback, criticism and suggestions! 

See you on Discord,


GSoD week 5


The last week has been very busy and I've spent a lot of time working on finalizing PRs #2535 and #2499. The diff is quite massive so good luck to the reviewers :)

I am slowly crawling through the high-priority header files, as defined in the spreadsheet. Some of them can be really time-consuming, I think I spent over two days on str.h. A huge chunk of this time is spent on reading, googling, and expanding my knowledge of C++: how to understand operator functions, how iterators work, streams, arrays, lists, strings...I'm surely learning a lot but it annoys that it takes so much time that is then not really reflected in the work I'm submitting.

The problem I am already starting to see is that reviewing my PRs will take quite a bit of time. Every doxygen comment that I am adding there needs to verified, simply because my understanding of the function/type/attribute might have been wrong. And as my PRs are getting verified, the header files that they are massively editing are being changed on master by other developers, which produces some nasty merge conflicts. I guess fighting merge conflicts might become one of the main challenges in the remaining part of the project.

I'm going back to my files, you can track my progress in the Google spreadsheet if you are interested. I usually put a green 'Reviewed' field next to the files that I have already gone through and included in a PR.

Season of Docs: Week 5

 I’ve had a very productive week, now that my personal life has calmed down a bit. I added v2.2.0 information, and finished off the audio and graphics pages. I also created first drafts of the new “saving and loading games” page, as well as contacts, bug reporting, known problems, games notes and copy protection pages. 

A catch up with @Mataniko this morning has been very helpful to determine the path forward for the rest of the project, now that the bulk of the information is there. We spoke about what belongs in the documentation, and what doesn’t - and it was decided that things like “Games notes” from the readme, which I experimented with this week, will remain in the wiki, or will be added to the wiki if not there already. 

We also spoke about the user experience when navigating the documentation, so for the next week or two I will be tweaking the structure to make sure that the user gets the best possible outcome:

Week 6

Re-arranging the docs :

•  The settings pages as they are now have become much more involved than I realised they would be, and they are becoming challenging to navigate successfully on a single page. They will now have their own section in the docs - possibly even split into a section for global settings and a section for game-specific settings. Each settings tab will have its own page, containing full explanations of the relevant settings, instead of linking to explanatory pages (such as the audio/graphics pages currently).

•  The Using ScummVM section will be all about the user experience - how do I use the software to play the games.  Any information that doesn’t fit with this goal will be moved into other sections or pages. 

•  I’ll be adding a page (or pages) to point users to the appropriate places to find information about:

•  Where to get the games

•  Game compatibility/supported games

•  Data files

These subjects are not, by themselves, within the scope of this documentation project.

Week 7

•  The FAQ - I want to focus on the troubleshooting section of the FAQ, and I will probably name it as such in the Help section of the docs. Here I will need some help! 

Can I please get feedback on 1. What ARE the most common issues that people have? and 2. How a user would go about solving these problems? I haven’t had the opportunity to spend much time on the forums, but I suspect these most common questions probably come up a lot on the forums. Please tell me what they are! 

My hope is that the documentation will answer a lot of these questions, and I will just be able to link to the appropriate docs for the most part (and add information to the docs to cover the issue). 

Docs-in-progress are available at, merged docs at

As always, I welcome feedback, criticism and suggestions! 

See you on Discord,


GSoD week 4


I'm doing this blog post a bit late when week 5 has already started. I've had some busy, tough days recently due to sick family (autumn and kids generally don't go well together) and couldn't devote as much time as I would like for my GSoD project. I'm a bit behind on the timeline right now but not really worried as I'm sure I can catch up with everything.

Right now PR#2499 is open with some more reviewed header files from the common folder. This is something I would probably like to get merged as soon as possible.

I've recently had some very good discussions with Eugene about the scope and priority of my work. You can check out this spreadsheet that contains a list of most headers from which we build doxygen documentation. The scope has been set for 114 files, most of which (75) reside in the common folder. Three levels of priority have also been assigned to the files.

Due to all this, I will be changing my approach to how I am working with the files. My assumption so far was that I would be going folder-by-folder, reviewing files alphabetically. My project timeline was also built around this idea, assigning particular weeks to work in particular folders. However, as there is clear priority now set on each header file, I am going to thouroughly review high-priority files first (there are 33 of those), then move to medium priority, then to low. This approach will assure that my GSoD project brings as much value as possible to ScummVM.

Stay tuned for PRs with some high-priority files in them!

Season of Docs: Week 4

It’s been a crazy week; sold the boat, moved in with my in-laws, found a rental, moved out of my in-laws’, and moved into the rental.  All in the space of about 4 days! I think it’s time for a nap!

Nevertheless, I made a little progress this week, albeit not as much as I’d hoped:

•  I combined the install pages for Windows, Linux and Mac into one, at the suggestion of @Mataniko. I agree that this is a better way to do it.

•  First, second and third drafts of the Audio page. By far this is the most confusing subject for me, and I am forever indebted to @NMIError (and everyone who contributed this week) for all the information and corrections! I spent a fair bit of time on this one, as predicted, and there is still some information missing. I will continue with this next week. 

•  First draft of the Cloud and LAN page.

•  I took screenshots of the new v2.2 Launcher, although these are yet to be uploaded and changed on the Launcher/adding and playing games pages. I will most likely get this done tonight.

My timeline for the next couple of weeks, which unfortunately has some carryover items:

Week 5

_Advanced Options:

•  Audio - add sections about output sample rate and using compressed audio files.

•  Graphics - add information about OpenGL  

•  Configuration file - I think there are some audio options missing here, add these and split into [scummvm] and [game] categories. 

Using ScummVM:

•  Global/game settings - add v2.2 keymaps information.

•  Saving and loading games - new page, first draft.

Week 6


•  FAQ - first draft.

•  Known problems - first draft.

•  Reporting a bug - first draft.

•  Contacts

Docs-in-progress are available at, merged docs at

Thanks for all your support and as always, see you on Discord.


“Manny, until now we scraped along the ground like rats, but from now on, we soar! Like eagles! Yeah! LIKE EAGLES...ON...POGO STICKS!!!”

Today is ScummVM’s birthday; 19 years ago they had their very first release. A few years later, in 2003, Residual followed suit, on the 15th of August. It has been a long and interesting ride for these two sister-projects, where one has served the 2D point-and-click community, and the other has aimed at the residual games, namely the 2.5D and 3D games. After a few more years, partially due to the need for a domain-name, Residual changed its name closer to its sister-project, and became the ResidualVM we know and love today.

We haven’t just shared suffixes, we’ve also shared a lot of code between the projects, to the point that apart from the specific game engines, it was mostly the graphics code that differentiated ResidualVM from ScummVM. Keeping these code bases in sync has taken a fair bit of effort, an effort that we’ll no longer have to keep up, because today we’re announcing perhaps the biggest change in ResidualVM’s history, namely its merger into ScummVM.

That’s right, from today, ResidualVM is no longer a separate project, but instead now fully a part of ScummVM. This means that you will eventually be able to run ScummVM with our theme, as well as run games like Grim Fandango straight from ScummVM. For the Wintermute-fans, this also means that there will not be any need for splitting your gaming across ResidualVM and ScummVM, as there will be a single, 3D-supporting engine in ScummVM.

From a technical perspective, the code base has already been merged, and in the days to come we’ll be merging our forums and look into consolidating things like bug trackers and Discord-servers etc.

It’s been a fun ride as a separate project, but we think it will be just as fun going forward.

“You know, sweetheart, if there's one thing I've learned, it's this: nobody knows what's gonna happen at the end of the line, so you might as well enjoy the trip.”

- Grim Fandango

A merger

“Sorry for the wait Mr. Flores, I’m ready to take you now”– Grim Fandango.

Today is a special day, special in a number of ways. First of all, we hit a milestone with 19 years of ScummVM. Our first-ever public release, ScummVM version 0.0.1, happened on October 8th, 2001. And second, something else finally happened, something which has been in the talks for a long time: The ScummVM project is officially merging with the ResidualVM project.

For a long time ScummVM limited itself to 2D point-and-click adventure games, and so ResidualVM was born as a sister project to support 3D games. But from now on, there will be no more confusion about which project a game belongs to. ScummVM now embraces adventure games and RPGs, whether they are 2D or 3D, point-and-click or not. It is a natural step for both projects which have been developed alongside each other and cross-pollinating each other with ideas, patches and design decisions. Moreover, several developers belonged to both projects.

With this merger, ScummVM adds several games to our supported list: Grim Fandango, Escape from Monkey Island, Myst III - Exile, The Longest Journey and an unfinished engine for In Cold Blood, as well as Wintermute 3D engine.

We’re excited to embrace most of the ResidualVM team and will continue development together.

Of course, there are still more things to do and, in the coming weeks, you will see more project resources merging like forums, wikis, etc.

Stay tuned and go 3D!

GSoD week 3


Work is ongoing and I am still mostly focusing on reviewing doxygen blocks in the header files of the 'common' folder.

In the meantime, some things have been merged:

- PR#2361 - documentation generated from the 'common' folder is now nicely structured and divided into groups. Grouping will ultimately be applied to all header files in the project.

- PR#2457 - everyone can now easily build the doxygen documentation using a make command or the provided .sh script (big thanks to Thierry for his help with the scripts)

- PR#2467 - doc edits in header files

- PR#2488 - doc edits in header files

The last two PRs are merged but if you look into them, you'll be able to find my summary of the missing documentation which we haven't yet worked on. There is a lot to add and I can't do it on my own so any kind of help from the development team will be greatly appreciated. Creating developer documentation is always a cooperation between an SME and a tech writer so without you guys my powers are limited :)

During this week I also had a very interesting checkpoint call with my mentor Eugene where we clarified certain aspects of my GSoD project. I won't bore you with details but the scope and priority of tasks is now much better defined and I'm sure it's going to positively affect my progress.