A young physics professor named Lester conducts a particle experiment. Suddenly, something goes wrong, lightning strikes, and in a moment Lester finds himself in a strange alien world. Now he must fight for his life in this strange place. Luckily, he'll find help along the way..

The ScummVM Team is pleased to announce full support for Out of this World (aka Another World). This is particularly noteworthy, since the original version of this engine was briefly added to ScummVM over twenty years ago.

Help us test the game by grabbing a daily build. Read through our testing guidelines. Currently, only the original DOS and Windows 3.1 versions are supported, though with sounds effects only, and not the music. Also, unfortunately, the Anniversary Editions are not yet supported. Additionally, like the original, you can't save your game, but you can use the 'c' key to open an area select dialog to enter a code to resume where you left off. And please take some screenshots along the way.

Lester's fate is in your hands. You'll deal with dangerous fauna, bloodthirsty aliens, and fiendish puzzles as you flee for your life.

It's been seven months since the first few qdEngine games were supported. After further work on the engine and playtesting, we are pleased to announce support for the remaining games:

• Little Longnose (Russian: Карлик Нос, Lithuanian: Nykštukas Nosis)
• Pilot Brothers 3: Back Side of the Earth (Russian: Братья Пилоты. Обратная сторона Земли)
• Pilot Brothers 3D. The Case of Garden Pests (Russian: Братья Пилоты 3D. Дело об Огородных вредителях)
• Pilot Brothers 3D-2. Kennel Club Secrets (Russian: Братья Пилоты 3D-2. Тайны Клуба Собаководов)
• Features of National Fishing (Russian: Особенности национальной рыбалки)
• Mom Don't Worry (Russian: Мама, не горюй)
• Dog-n-cat: In the Footsteps of Unprecedented Beasts (Russian: Агентство "КотоПес": По следам невиданных зверей)
• Dog-n-cat: Island of Dr Ratiarty (Russian: Агентство "КотоПес": Остров доктора Крысарди)

To play the games, you will need a daily development build. If you encounter any issues, please submit the bug reports to our issue tracker.

We are also still looking for a Lithuanian copy of the Little Longnose game (Nykštukas Nosis). If you have a copy or know where to obtain one, it would be greatly appreciated by the team.

In the first week, I started with finishing the work on qdEngine, then began working on the SLUDGE engine.

With qdEngine, what needed to be done was to improve the performance in the game Dog-n-cat: In the Footsteps of Unprecedented Beasts. After a little investigation, it turned out that whenever the tiled animations were drawn, the uncompress() method was called. This was very costly, and the solution was to cache the already uncompressed animations.

After finishing with this task, I was assigned to finish the SLUDGE engine. The engine is almost finished, with only a couple of small things to be done. I began with implementing the support for extended saves, which turned out to be a little harder than I expected. In particular, there was a problem with the saving the files in the ScummVM format. The saves with simple names are in this format: %s.%03d, where d is slot number. At first, I didn’t know how to get the slot number from the name of a save. This was needed for loading the save files in the games. The problem was that the SLUDGE game interpreter is based on stack machine and the only thing which is pushed to stack when loadGame function is called is the name (description) of the save.

This problem took quite a while to solve, but after many unsuccessful attempts and tries, I finally came up with the solution. I realized that almost every game when loading/saving the game shows the save file list:This meant that I could create a lookup table that maps the save name to slot number of the save file and use it for saving/loading procedures. And indeed, it worked out.

There was also a little interesting task was to testing transition modes of the engine. For that, I needed to create a demo with SLUDGE development kit, run it on original interpreter and on ScummVM, compare, and see if they are different. The transition modes appeared to be the same, so there was no additional work needed from my side.

After that, I quickly implemented return-to-launcher feature, fixed a bug in thumbnail loading and wrote a code to simulate the right click of a mouse. Lastly, I made it so message box with a specific message set by a game pops up when exiting the game:

Okay, Week 1 over! Hussshh! Not how I imagined it would go.

I started the week by “trying” to work on my unfinished QTVR task. I made very minor improvements, but they were not my main goal. Basically, the QTVR decoder in ScummVM uses a two step approach to projecting a cylindrical panorama in ScummVM. First Step: Cylindrical projection correction, Second Step: Perspective projection correction. I tried to implement a warp mode 1 in it by skipping step 2. But apparently that’s not the correct solution. This introduces a wobble to the image when tilting up and down. I tried working on it, but couldn’t do it. @sev suggested I abandon it because I have to focus on my main task of saving Director files.

This week I worked on familiarizing myself with the Director 5. I started reading the Director 2 Interactivity Manual. My main task for this week was to understand how Director Movies can be embedded into other Director Movies as cast members. Currently this functionality is missing from ScummVM Director. We cannot load external Movies into the current movie. It was my task to implement this functionality. This is used extensively in startrek, a game we’re hoping to support in ScummVM, which has a main (Director) movie that loads other (Director) movies which store different things (e.g. the floor plans of different rooms on the USS Enterprise NCC-1701-D spacecraft). But so far I’ve been struggling to carry out the task.

To get acquainted with Director and to understand what the task is, @sev asked me to create a simple movie in Director 5. I had to embed an external movie into that just like startrek does using a lingo script. Although, making the movie was simple enough, I failed to see the point behind the exercise. Instead of embedding an external movie, I instead imported all the cast members of my external movie into my current movie and basically mimicked the external movie in my current movie (to not do so was the entire point). After a helping hand from @sev, I was able to make the movie. I will be using this movie as a unit test to check whether the movie cast member loader (which I will start implementing starting next week) works or not.

@sev wanted me to do another thing which was to create a loader for Score that works for all of these cast members: scores, filmloops (very similar to scores but very little or no external control using scripts) and movies (which have their own score and casts and scripts unlike filmloops).  But my progress was slow, I am getting stuck often; which lead @sev to tell me that I should immediately ask for help if I feel stuck. I have very little time to make this happen and I can’t afford to spend much time on just getting the basics done. Other students are well on their way to complete their respective tasks.

So to expedite this process @sev and I had a video call where he explained how the Director works, how its components work, how it is implemented currently in ScummVM, how are they loaded, how all of this is tied to my main task of saving movies in ScummVM, and what is it exactly that I need to do. This helped a lot. I now have a clear picture of what needs to be done. From next week I’ll start by implementing a common loader for Score, filmloop and movies in ScummVM’s Director.

I hope I’ll have better news and a better blog next week!

This week marked the beginning of my journey with ScummVM for Google Summer of Code, and I kicked things off by working on the SLUDGE engine.

For those unfamiliar, SLUDGE is an engine that enables developers to create and publish their own point-and-click adventure games. These games are highly script-driven, especially in how they handle input. Keyboard input, in particular, is passed directly to the script, and from there, it’s entirely up to the game developers to define how those inputs are interpreted and used in their game logic.

My main goal for the week was to implement ScummVM’s keymapper support in the SLUDGE engine. However, this came with its own set of challenges.

Each SLUDGE-based game defines its own key bindings for different actions. That meant I had to manually identify the default controls for over 10 supported games. This process was quite time-consuming, as there was no centralized documentation. In some cases, I found the information in the game’s source code, in others through manuals, and occasionally I had to just play through the game and note what each key did.

While this part of the task was tedious, it was relatively straightforward. The real challenge came when I had to figure out when to disable the keymapper.

Why? Because some games allow players to enter custom save file names, which means they need unrestricted keyboard input. If the keymapper remained active during such input modes, it would interfere with typing. Unlike many other engines, SLUDGE doesn’t offer a built-in pause menu or modal state, so each developer handled menus differently.

After some digging through the engine source and various game scripts, I discovered two important functions: `freeze()` and `unfreeze()`. These were used every time a menu was shown or hidden. While not all menus required full keyboard input (most only needed mouse interaction), this discovery gave me a reliable enough hook. I could safely disable the keymapper when a menu was active and re-enable it when gameplay resumed.

With that, I successfully implemented keymapper support for the SLUDGE engine in ScummVM!

Welcome to this week’s blog. Most of the time this week was spent fixing the portability of the Mac files. So the plan was to test the working of the mac files on both Python and C++ side. On checking the C++ side halfway through, we realised, that some code was broken and was giving incorrect results. So, Sev decided to take a look at it himself while I started working on the same task on the Python side.

On the Python side, the code had three main issues:

• Not all Mac file variants were being covered.

  

• Instead of using the data section of the resource fork, the entire resource fork was being used for the checksum calculations, which was different from what the C++ side was doing.

  

• There was no file filtering, which caused problems when Mac files were present – specifically, AppleDouble and raw resource fork files, which had their forks spread over multiple files. Instead of showing a single file entry with all the checksums, extra entries were incorrectly displayed as non-Mac files.

I corrected all these issues. For filtering, I added 7 different categories for each file – NON_MAC, MAC_BINARY, APPLE_DOUBLE_RSRC, APPLE_DOUBLE_MACOSX, APPLE_DOUBLE_DOT_, RAW_RSRC and ACTUAL_FORK_MAC.

Fig. 4 shows consistent output for the all the mac file variants. Next task is to create proper test suites for its verification and check the workflow with the C++ side.

Thank you for reading.

Introduction

The first week of GSoC is over, and I’m fairly happy with how it went. My TeenAgent PR was merged, and I’ve opened two new PRs: one adding TTS to WAGE and one adding TTS to Cine. They’re still under review, with Cine requiring more testing and translation verifications, and I imagine that there will be more work to be done with them, but the hardest parts – getting familiar with the engines and adding TTS to most of their text – are over.

WAGE

I started this week with WAGE, which was a relatively simple engine. There was an abandoned PR adding TTS to this engine that I picked up, but while it provided a base for me to work with, it was buggy and unfinished, meaning there was still a significant amount of work to be done. As for the engine itself, WAGE’s games were almost entirely text-based, with few graphical components. For me, this had its benefits and disadvantages. On the positive side, I didn’t have to worry much about hovering over objects, and finding where text was output to the screen wasn’t too difficult: nearly all of the text was in the form of the action log, which was modified by only a small number of functions. On the negative side, the greater quantity of text meant that there was more to look at and be aware of.

For the most part, adding TTS to WAGE was simple. It was a matter of adding a toggle, identifying the small handful of methods that displayed text, and feeding it through the TTS manager. There was no need to clean up any of the text. I soon encountered a caveat, however, with how WAGE handles its command menu. Rather than being embedded into the engine, WAGE uses the MacWindowManager class to manage its menu, including submenus and dialogs. My first approach was to identify and process this text inside WAGE’s Gui::processEvent method by retrieving the menu item that the mouse is over from the MacWindowManager and voicing its text. This worked fine initially, until I tried to voice the buttons: once a MacDialog is open, it pauses the loop inside of WageEngine::run, which is what runs Gui::processEvent. Without Gui::processEvent running, I couldn’t check for the mouse hovering over a button from it. At this point, I realized that it would be difficult to keep everything exclusively in WAGE itself, so I added TTS code to MacWindowManager, which worked much better. I did end up restoring some of my original code to Gui::processEvent for menu items, since MacMenu didn’t seem to have a trigger for hovering over a menu item (only for clicking one, and I wanted to voice the menu item as soon as the user hovers over it). The end result was TTS working as expected for the command menu.

Ultimately, WAGE wasn’t particularly difficult, but the fact that it used MacWindowManager for much of its GUI was an initial challenge. With a little extra code, however, it functioned fine.

Cine

After WAGE, I worked on adding TTS to Cine. Cine’s games, Future Wars and Operation Stealth, have much less text than WAGE games, and much of it is displayed through a few methods. Voicing the majority of the engine’s text was as simple as feeding the text into a small handful of methods, mainly drawMessage, drawMenu, and drawCommand. From there, all that was necessary was making sure it all behaved in a user-friendly way, like voicing the “USE” and “INVENTORY” commands when using the F3 and F4 keys and vocalizing inventory items.

Unfortunately, Cine came with a rather large problem: it has a lot of text in the form of images. Just about any text in Future Wars and Operation Stealth that isn’t directly related to gameplay (i.e. commands and menus) is an image. This includes credits, some cutscene text in Operation Stealth, and everything in the copy protection screens. Two problems resulted from this issue. For one, much of Cine’s work is handled by global and object scripts built into the files, which meant that there was no easy location to find where these images are displayed. As a result, I had to go to the methods that render general images and catch the exact conditions (PRC name, object index and frame, background name, and so on) under which they display. For another, I needed to know the text of these images in all supported languages and versions, so I could hardcode it. This meant a mixture between looking through videos on YouTube and asking the community (thanks to my mentor, criezy, for providing the copy protection images in French, and eientei for providing the German, Spanish, and Italian copy protection fail texts for Operation Stealth). It also meant keeping track of exceptions: Future Wars has two different copy protection screens, one for DOS and one for Amiga and Atari ST; Operation Stealth’s opening credits has a credit for the IBM version only for the DOS version, but its end credits has this credit in all versions; and Future Wars has a different opening title screen for the French version (“Les Voyageurs du Temps: La Menace” as opposed to “Future Wars: Time Travellers” for Amiga and Atari or “Future Wars: Adventures in Time” for DOS). Accounting for these exceptions meant more checks and more text to include, but it has been done.

In the end, getting the copy protection screen and credits to be voiced was the bulk of the work for Cine. Finding the different translations, deciphering the best place to voice them, and adding a new method to recognize hovering over buttons in the copy protection screens was time-consuming, but entertaining.

Conclusion

WAGE and Cine weren’t too difficult to add TTS to, and it was fun to implement it. The most time-consuming was working with Cine’s copy protection screens. There were some difficulties, but through enough investigation, they’ve been resolved. However, as of this blog post, a fair number of translations in Cine need to be verified, and other versions of the game have to be tested.

Next week, I’ll be focusing on adding TTS to the cruisE engine. I’m looking forward to exploring it.

Hi everyone! I’m Prime, a third-year computer science student and lifelong gamer. This summer, I’ll be working with ScummVM as part of Google Summer of Code 2025.

My project, “Add Keymapper to More Games,” focuses on integrating ScummVM’s keymapper system into more of its supported game engines. This will allow players to customize controls across a wide range of classic games — making gameplay smoother and more accessible on different input devices like keyboards and gamepads.

Over the summer, I plan to add keymapper support to over 20 engines. For each engine, I’ll analyze its input system, replace hardcoded key handling with keymapper logic, and thoroughly test the changes to ensure everything works as expected.

A huge thank you to my mentors, the ScummVM community, and the GSoC organizers. I’m looking forward to contributing to the preservation and improvement of these classic games!

In this post I would like to go over some of the highlights of the changes I made to qdEngine.

Adding support for RGBA8888 format

At first, there wasn’t any intent to add a support a 32bpp color format. The engine was using RGB565, and it was pretty much fine with most of the games. However, when I began playtesting Pilot Brothers 3D, and got to a specific place in the game, I quickly noticed that something was off:

When looking more closely, you can see that the shadows under actor’s bodies are dark green:

This problem took quite some time to solve. I was checking every line of the drawing functions, comparing with the original source code, but was unsuccessful. Then, I tried to change things, in particular, tried to remove alpha_blend_565() inside the methods, and realized that it was responsible for the shadow color. I looked again at the the original, it saw that it was RGB888. But we were using RGB565, which of course has less bits and a thus created noise for the shadows. Since there is an extra bit for green channel, the shadow was a little greenish. Thus, I proceeded with adding the support for this color format, and indeed got the shadows fixed:

Although it took about 2 days at the time of fixing that, I now much understand to engine’s drawing functions and learning few things about color formats. Here is the PR for the fix: https://github.com/scummvm/scummvm/pull/6552.

Checking different game (engine) versions and learning Ghidra

One of the aspects of working on QdEngine was comparing the code across different engine versions. The engine developing over time, which meant that because of the changes made to the engine, things such as pathfinding, inventory selection and collision system could work different across different the games. We had sources for multiple versions of the engine, so once the sources are compared and the change is found, a typical fix could be like this:

here the date (number against which g_engine->_gameVersion) indicates the engine version where the a certain change was introduced.

When the sources were unavailable, we had to rely on reverse engineering. For example, we didn’t have the sources for the engines of two games. To find the exact cutoff date, I would write the exact the method and how it was changed to Sev, and he would reverse and tell me the date. Thanks for his help, we were able to fix a decent amount of bugs and make the games completable to the end.

In beginning of May, I started with playtesting Brother Pilots 3D-2 game and could not even run it. This was because one of the tags in the script specific to this game (engine) version was missing. At the time, Sev couldn’t help me, as his laptop was in repairment. So I thought to myself, maybe I could try fixing it myself. I downloaded Ghidra and uploaded three games (including Brother Pilots 3D-2) with consecutive engine versions. Then I found the place where the the tags registered:

After that I took decompiled code of this function, pasted to my editor and diffed between the games:

In the image above, I compare the code for Brother Pilots 3D-2 and the game that came before it. As can be seen from the image, rotation_angle_per_quant tag is added, so the I adjusted in the code the date and was able to run the game. This was a small change, but quite useful for me, as I learned a little about reverse engineering and Ghidra.

Fixing file loading and adding support for advanced minigames games

This was supposed to be my of the main tasks for this GSoC. I needed to change how the interface for “advanced” minigames worked. Not that they are called advanced, but they are complex in comparison to the ones in other games, and added more things to previous interface.

To understand the problem better, I first tried to run the games, and see where I crash, or where things are supposed to not work. I took the first game, Dog-n-cat: In the Footsteps of Unprecedented Beasts and tried to run it and noticed that I can’t get past the logo image. What’s more important, the memory usage panel in Visual Studio was showing 3.8 Gigabytes:

That was quickly fixed by adding back early end-of-stream check from the original sources:

But something was still missing. I was still getting this warning: MinigameManager::init(): Game could not be initialized. This meant that state (file) loading was unsuccessful and returned false. The code for reading from file looked something like this:

At this stage, the method could only return false only from code branch I just introduced. So it was reaching the end of stream every time. I did not realize ScummVM’s ReadStream::eos() would return true only when reading beyond file size. In the original, however, their eof() would return true once file size bytes are read, and of course the code in this section relied on that. But once I figured out and adding small fixes, the minigames started showing up. We first though that more complex approach and rewiring would be needed, however, it was much simpler. After that, unstubbing the constructors the each minigame was quite easy and I was able to finish the work early.

In this post, I would like to share a story of solving one of the recent bugs I had in qdEngine.

First, let me tell you about the bug. The problem was with the minigame in the game called “Dog-n-cat: In the Footsteps of Unprecedented Beasts”. In the minigame, players swap and move around triangle pieces to assemble the picture of an animal. The problem was that when swapping triangles, the triangles would move to swapped positions, instead of folding/unfolding in place. And the animation itself had artefacts. This is how it looked before the fix:

and how it looks now, after the fix:

I first thought the problem was with the code logic of this minigame. Even though we already had the sources of the minigames, as it turned out, some of the parts of code were not present there. This led me to think that maybe some crucial piece of code responsible for the rotation was absent. I told this to my mentor – Eugene Sandulenko (aka sev), and he provided me with the decompiled code of the dll for the minigame. But, it turned out to be the same. Then, he went with reversing the several games which were developed in later versions of the engine to see if important differences were introduced. Again, differences that could help were not found.

We started to lose hope on this, so I started to think about the problem from beginning and try a different approach. Sev adviced to look again at what exactly was responsible for rotation and tranformation of the triangle. And I looked very closely at qdScreenTransform::change(), the method that changes object’s angle and scale when transformation happens. In our case, it was called when triangle is transformed during swapping. I noticed that the angle was always 0.0 (wasn’t changing), but the scale in y-axis was decreasing. What’s important is that I was testing it by swapping the triangles vertically. And then, it really came to my mind, that no rotation should not even be happening in this case. Turned out, to simulate the effect of folding, the game was only scaling down the y-component of the triangle object. This meant that I only needed to check the drawing methods with scale parameter. And indeed, after comparing with the original source code, the issue was in the wrong conditional operator:

This bug a took quite some time to solve, because of wrong a wrong assumption I had. However, with the help of my mentor and an insight that came to me eventually, the problem was successfully solved.

Thanks for reading.

Hello! I’m Ellen, a second-year undergraduate computer science student. Over the summer, I’ll be adding text-to-speech to several ScummVM engines to enhance their accessibility and assist language learners. I’ve already worked on adding TTS to two engines (Drascula and TeenAgent), and I hope to continue the process for other engines. I’m excited to work on this project!

Hi everyone!

My name is Alikhan and I am one of the GSoC students of this year. The task in my proposal was finishing the implementation of QdEngine. However, I’ve been working on the engine since March, and the task to implement interface for minigames appeared to be easier than was thought initially. Thus, there is only one task left for me to finish, so I plan to work on other engines after that.

In these blog posts I’ll be sharing my progress of each week, post about problems I faced, how I dealt with them and things a learnt along the way.

That’s all for now. Thanks for reading.

Hi, I’m Shivang Nagta, a pre-final year Computer Science undergraduate. I’ll be sharing my weekly blogs here, with updates on my GSoC project — “System for Checking Game Files Integrity.”

My mentors for this project are Sev and Rvanlaar, and I’m really grateful to have them guiding me. This project has been part of the last two GSoC years, so a lot of work has already been done. Here’s the current status:

Work done by the previous developers :
1. Server Side – 
The server has been written in Flask. There’s a dashboard for proper visualization. The database schema and logic for feeding/updating the database have been implemented.

2. Client Side / ScummVM App :
There’s a Check Integrity button in the ScummVM application, which hits the server endpoint for validation with the checksum data of the game files.

Work done by me previously :
1. Client Side / ScummVM App :

• Fixed the freezing issue in the Check Integrity dialog box. It was caused by the MD5 calculation of large files, which blocked synchronous screen updates. I solved it by implementing a callback system.
• Engines like GLK and Scumm don’t use the Advanced Detector, so I worked on implementing a custom system to dump their detection entries. Some verification is still needed, as the current logic of these engines introduces complications in the implementation of the custom dumping systems.

2. Server Side :

• I worked on two particular tasks: Punycode names and the different Mac files portability. Both tasks require final verification and testing. I’ve already mentioned them in the last section of the blog.

Work plan for Official Coding Phase:
1. Testing all the workflows on the server side :

• Initial seeding by scummvm.dat (checksum data from the detection entries)
• Uploading set.dat (checksum data from some old collections)
• Uploading scan.dat (checksum uploaded by developers by scanning the local files using a command line utlility provided on the server)
• user.dat from api (checksum coming from the client by the Check Integrity feature added on the ScummVM application)
• Reupload scummvm.dat / set.dat

2. Moderation features :

• Review the user submitted fileset
• Have a list of unmatched fileset
• Manual merge with search feature for a particular fileset ID followed by a merge screen
• Remove filesets / undo changes, on a new upload (roll back feature)
• Easy searching and filters of filesets by different field

3. Some fixes :

• Different types of Mac files (like Appledouble, Macbinary, and Rsrc) have forks represented differently for the same game data. The checksums of Resource forks and Dataforks need to be extracted separately to create correct entries.
• Often, filenames from one OS are not supported on another. To tackle this, Sev built a method on top of the classic Punycode encoding method (used for URL encoding), but it needs proper integration and testing in this project.

Tomorrow marks the beginning of the offical coding phase. Thank you for reading.

Hello!

I’m Malhar. I got selected to work on a Macromedia Director task (large variant) for GSoC ’25. I’m a computer engineering student, currently (at the time of writing this) in the third year (Junior if you will) of my Bachelors degree. My GSoC Proposal should give you a detailed rundown of what I’ll be doing for my project. I think that should be enough for a formal introduction.

Okay… so let’s start from the beginning…

Ever since I got into programming and found out about GSoC, I’ve always wanted to be a part of it. This year I was determined to at least send a proposal. The entire idea behind open source sounds… awesome. A bunch of people who are so passionate about a project that they are willing to spend time on it without any other incentive but their own love for it. That is very admirable. Maybe it’s the prestige of getting selected for GSoC (at least in my university) that drew me to it. But I’d like to believe that I was also passionate about working on ScummVM.

I started contributing pretty late; after the list of organizations was declared. I joined the ScummVM discord server on 10th March. Starting contributing was as easy as introducing yourselves. @sev (sorry, too used to discord tagging convention at this point) took notice, helped me compile the project and assigned me a task. And that was it! I started contributing. I struggled a bit in the beginning, but the project is pretty well written. It was much easier to understand than some of the other open source projects. I mostly worked on the QTVR decoder in ScummVM. It was messy but fun. Seeing my first PR being merged felt amazing.

@sev suggested that I should work on saving director files which is currently missing from the director engine for GSoC so that’s what I chose. I started working on the proposal pretty late as well. I wanted to complete the QTVR PR before I focused on the proposal. I continued working on QTVR even after submitting the proposal up until my exams started.

The entire goal of the project (apart from some minor improvements to Director engine) is to redo the file loading logic of the current Director engine so that they will be read in a way that preserves the on-disk structure, which will make saving .dir files much easier. Thank you @djsrv for such a great reference ProjectorRays. Although, it hasn’t been much time since I started looking into this, but I feel confident.

I was pretty thrilled to have been selected for GSoC, when the news came on 8th May. A lot of people congratulated me. One of our professors – who is a pretty vigorous advocate of Open Source software and faculty advisor for the Open Source club at our university (CoFSUG) – personally called and congratulated me. I felt validated! My parents who don’t know the first thing about programming or open source were relieved that their son got an “internship” and a pretty good one at that. I tried correcting them on the “internship” but to no avail. Every single one of my classmates is doing an internship at some big shot multinational corporation where it will be harder for them to enjoy the work they do. For me though, its going be so much fun.

My exams lasted till 15th and I promised that I will start working from that very day. But alas! Something kept coming in between. Being part of our college’s annual magazine, I had a lot of responsibility for the last two weeks. Something or other kept me from continuing. A couple of times I resurfaced to work but couldn’t do much. Made @sev worry about whether I was stuck at my task. I felt pretty guilty about going back on my promise.

But it’s 31st March, 2:15 AM here in India. No more excuses. The next 12 weeks, I’m going to drop everything else, and make sure that I do a good job, something I’ll be proud of. Let’s make this an outstandingly successful GSoC project…

Oh! One last thing. I like to read and I like to write (secretary of Magazine Club ;)). I’m a fast typewrite as well (100wpm). Don’t ask me how much time I took writing this, though… but expect long blogs on this page in the future. 🙂

Get ready to jam and slap da BASS!

Yes, it is this time of the year again! Please welcome the first ScummVM release of the year: ScummVM 2.9.1.

This maintenance release mainly focused on fixing bugs that our developers and users have uncovered since our last stable release.

As usual, several engines and platforms received their fair share of bug fixes and improvements: AGI, AGS, Asylum, BAGEL, Bladerunner, Hopkins, MADS, NGI, SCI, SCUMM, Sky, Sword1, Tetraedge, Tinsel, Tucker, TwinE, and TWP.

Our porters also went on a bug-hunting spree, so all we can provide is a small summary of the latest and greatest fixes!

The Nintendo 3DS (yes, we do not care about end-of-life dates!) has the GUI appropriately displayed if it is configured to use the top screen only.

Android now provides an option to save and restore your configuration file and save games, and the vast majority of older Android devices will see increased performance thanks to the ARM NEON optimizations, which are now enabled by default. And the Beneath a Steel Sky game is not crashing in the intro anymore!

The Atari port received some internal backend, GUI, and audio fixes. Speaking of audio: iOS/iPad will now always properly recognize FluidSynth soundfonts, macOS has support for Audio CD playback from original discs on Snow Leopard and earlier, and Windows 9x (yes, EOL…) can use FLAC files again!

The detailed list of improvements is available here.

Head over to our downloads page and grab it while it’s hot! As usual, macOS and Windows users can update ScummVM with our integrated, magical auto-upgrade solution.

Robert Ripley, a famous traveler and collector of rarities. One day, during a trip in Egypt, Ripley is attacked by mysterious Chinese assassins. The trail will lead him and his Chinese girlfriend Mei Chen on a chase around the world, in a race against time to prevent the greatest theft of all time, the First Emperor's seal, which could plunge the world into chaos.

The ScummVM Team is pleased to announce full support for Ripley's Believe It Or Not! The Secret of Master Lu, the other classic game, besides Orion Burger, by Sanctuary Woods. As with Orion Burger, it adds a few niceties that the original didn't have, such as mouse wheel handling, and using the spacebar to skip walk animations.

Help us test the game by grabbing a daily build. Read through our testing guidelines. The game's logic was all hardcoded, and proved even more complicated than that of Orion Burger, so we really need people to try all sorts of weird actions, and make sure the game handles everything correctly and matches the original implementation. And please take some screenshots along the way.

Good luck. If you fail to prevent the seal falling into evil hands, it could be used to unite all Asia under a single ruler, thirsty for conquest.

Are you ready for more sleuthing with everyone’s favorite teenage detective? We’re excited to announce that Nancy Drew: Secret of the Scarlet Hand and Nancy Drew: Ghost Dogs of Moon Lake are now ready for public testing! Furthermore, it's now possible to enable the ScummVM save/load screens instead of the original ones, to take advantage of additional features when saving or loading.

In Nancy Drew: Secret of the Scarlet Hand, Nancy takes on the role of an intern at a Washington D.C. museum, where a mysterious theft sets off a series of clues leading deep into the secrets of ancient Maya artifacts.

In Nancy Drew: Ghost Dogs of Moon Lake, Nancy finds herself investigating a haunted cabin surrounded by eerie howls and ghostly canine apparitions.

The games are available for purchase through HeR Interactive’s website or Steam. Or if you already own a CD copy of the games, their English and Russian variants will also work. To play them with ScummVM, you will need a daily development build. As always, if you encounter any issues, please submit a bug report to our issue tracker.