New year with Californium(*)

Several months have passed since our monumental 2.5.0 release, and now the ScummVM Team is thrilled to announce the release of the bugfix release, 2.5.1 codenamed “Californium”*.

The most notable changes are: we added scalers in OpenGL mode (those AdvMame, HQ etc things), fixed several bugs in The Lost Files of Sherlock Holmes, made the sound for Sam & Max more accurate, improved graphics for some Macintosh SCUMM games, implemented more renderers for The Longest Journey, made many enhancements to Little Big Adventure and we fixed the dreaded bug on World of Xeen startup.

The comprehensive list of changes can be found here.

You may find the download at the usual place on our downloads page. Due to a slight delay regarding the release for macOS, the auto-updater will be released within the next couple of days – stay tuned!

Enjoy ScummVM in 2022!

* The average atomic mass of Californium (atomic number 98) is 251.

Trying Patreon waters

In the years I had the numerous requests to add a Patreon page. There you go: https://www.patreon.com/_sev. It is a way to support me personally (if you care) and if there will be at least several patreons, I plan to use this platform for helping me to choose the area where I spend my time. In the meantime, I will be posting assorted reports on the things I added to ScummVM. There are so many

Seek the truth

After more than 10 years of development, the ScummVM Team is pleased to announce support for the psychological-horror adventure game Sanitarium.

Grab your CD version or a digital release and immerse yourself in a story full of nightmares and mysteries.

If you don't own the game we have a demo available.

You will need the latest daily build. As always, please submit the bug reports to our issue tracker.

Twenty years ago today...

Twenty years ago today, on Tue Oct 9 16:30:12 2001, Ludvig Strigeus pushed the initial revision of the ScummVM code, which was version 0.0.1 of the project. Time flew quickly and, fast-forward to the present day, we are proudly releasing ScummVM 2.5.0 “Twenty years ago today…”

The list of changes is tremendous.

First of all, this is the first release that supports 2.5D games (almost 3D), thanks to the merger with ResidualVM. With this release we announce support for Grim Fandango, The Longest Journey and Myst 3: Exile. This is why we jumped straight to 2.5 in our versioning. Please note that only desktop platforms currently support these games and other platforms may or may not gain the support later depending on their capabilities.

In addition to these 3 games and engines, we officially support 10 more new engines and subengines that add compatibility with the following games:

  • Little Big Adventure
  • Red Comrades 1: Save the Galaxy
  • Red Comrades 2: For the Great Justice
  • Transylvania
  • Crimson Crown
  • OO-Topos
  • Glulx interactive fiction games
  • Private Eye
  • AGS Games versions 2.5+
  • Nightlong: Union City Conspiracy
  • The Journeyman Project 2: Buried in Time
  • Crusader: No Remorse
  • L-ZONE
  • Spaceship Warlock

We love localized game releases and multiple platform versions, thus with this release, we enhanced the support for Lure of the Temptress Konami release, Blue Force Spanish, Ringworld Spanish, Amazon: Guardians of Eden Spanish, Mystery House French, Russian translations of Sierra AGI games, Elvira 1 Japanese PC-98, Bargon Attack Russian, Woodruff Russian, Eye of the Beholder Japanese Sega-CD, Legend of Kyrandia Hebrew, Legend of Kyrandia 2 Hebrew, Legend of Kyrandia 3 Simplified Chinese, Inherit the Earth PC-98 Japanese, Gabriel Knight 1 Macintosh, Xeen Russian to name but a few. Notably, Macintosh b/w versions of Loom and Indy 3 are now also supported.

Besides the new games and game versions, ScummVM 2.5.0 brings many notable improvements and new features. We have completed a major rework of the GUI: We now support Unicode characters everywhere. The GUI also adapts to high resolutions used in HiDPI screens. The Nintendo DS port has been significantly rewritten. We added GOG and Steam achievements to a large number of Wintermute games and enabled KeyMapper in more games. Thanks to the work of one of our GSoC students, we have now added an option for text-to-speech to the games Sfinx, Soltys and The Griffon Legend.

You may find all of this goodness available to a number of platforms on our downloads page, or let the autoupdater kick in on Macintosh and Windows.

We wish you great adventuring, happy puzzle-solving and exciting journeys to RPG worlds, and hope to see you around in the coming years.

And by the way, GOG.com is running a special promo tied to the release and our anniversary, where you can buy many ScummVM-supported games at a discount.

ScummVM 20th Anniversary – The Survival of Point and Click Adventure Games

ScummVM, the point and click adventure game open source program celebrates its 20th anniversary.

Help us test next ScummVM version

It has been almost a year since the last release of ScummVM. We have made a truly tremendous number of changes, which you can read about in the NEWS.md file. We need your help to test this version!

Besides the list of games to test before the release, the most notable things to test are:

  • UTF-32 support in the GUI, allowing for full Japanese and Korean translations. (Also, you are welcome to help with translation into more languages).
  • Support for HiDPI (aka Retina) displays in the GUI. No more fuzzy fonts.
  • A significant rewrite of the Nintendo DS port, bringing it up to date with the latest engines and features.
  • 3D engines formerly part of ResidualVM. Games like Grim Fandango, The Longest Journey and Myst III: Exile need a playthrough.
  • In total, 12 new engines and general changes to 24 more engines.

For running the games you will need the latest stable build of ScummVM. Then, load up some games and report issues in the issue tracker and playthrough progress on this forum post so we could keep track of the progress on the Wiki.

Early Macromedia Director titles are supported now

After 5 years of active development, we are glad to finally announce the first MacroMind/Macromedia Director-based games to be supported.

Iskrich, a GSoC student, laid down the engine’s first lines of code, based on the initial reverse engineering efforts of fuzzie, which she wrote in Python as part of the continuity project. Then, the work was continued by sev in 2017 when Lingo compiler development was started and stevenhoefel started adding Director 5-related code. In 2018, there was practically no development, but in 2019, moralrecordings made some advancements for Director 4. Finally, in 2020 and 2021, there was a big chunk of development, first by npjg and djsrv, then by sheep and djsrv, while rvanlaar set up a continuous integration buildbot for the project.

Long story short, after 3738 commits, we are now announcing support for Director 2-based titles such as Spaceship Warlock. Selected Director 3-based titles may work, and in particular, we support L-ZONE.

Grab your CDs and give these titles a go. We are also actively collecting info on any Director-based (and Shockwave) titles that we catalogue on our Wiki, so, please, help us with this task.

We are actively working on deepening Director 3 compatibility, particularly the original Journeyman Project and advancing with Director 4 support, having Meet MediaBand and Chop Suey as our primary test targets.

For running the games you will need the latest daily build of ScummVM. And as usual, if you see any issues, please file them in the issue tracker.

Immersive slowness or why I added artificial loading times for Myst to ScummVM

Ever since I discovered the Myst series back in 2005, I’m in love with it. To me, the Myst series feels like an immersive trip to another world – it is truly something different compared to your average point-and-click adventure game. Needless to say that especially the first entries in the series – the original Myst and its successor Riven – are truly remarkable games.

In my opinion, the immersion these games provide is partially created due to technical limitations. The original Myst was released in 1993 on this incredible new format called ‘CD-ROM’, allowing for a whopping 650 Megabytes of storage.

At that time, CD-ROM drives were slow – like double-speed slow. This means access times of 80 to 200ms as well as a blazing transfer speed of 300KB/s under ideal conditions. Since even the largest hard drives had a capacity of around 1000 Megabytes, installing the game wasn’t an option. Furthermore, RAM constraints made any caching of the datafiles impossible.

This is where immersion kicks in

Myst uses some pretty clever compression techniques and an optimized file layout on the disc. Since each time you move through the game, your computer needs to load the next image. On the next move, it needs to load yet another image. The game basically forces you to slowly walk through the worlds of Myst.

I’m not sure if this was even part of the original design concept. However, it really feels that your are not supposed to rush through the game. Everything tells you to slowly explore while making sure not to miss any hints you need to solve the puzzles.

While many adventure games are limiting playback speed on their own (e.g. due to character movement), this does not apply to Myst. When you play the game on original hardware, then the loading times seem perfectly fine since you expect them.

As soon as you eliminate the loading times at all, e.g. by playing the games with ScummVM, then you might notice something is off. Now, you are not forced to slowly explore, but you can simply run through the game. Even though I’m obviously not forced to take advantage of the instant loading, the feeling that I can do this is affecting the experience in a negative way for me.

The solution

Looking for a way to improve the experience, I recently implemented loading time simulation to ScummVM. After activating this feature, it adds a delay between the different screen transitions in order to simulate the loading times of a real CD-ROM drive.

In order to show you the difference, I prepared a small video. The first half of the video shows the previous without any loading times behaviour. Obviously, I’m really exaggerating here. It should be pretty obvious that this is clearly not how the game should be played. I enable the new loading time simulation at around the 50 second mark.

While the implementation was pretty straight-forward, it was not exactly easy to get the timing right. The main issue is that I don’t have really period correct hardware at the moment. The oldest system I own is a Pentium III with 500 MHz, featuring a 16x Philips CD-RW drive and a 48x “generic” drive. Fortunately, this generic drive is compatible with Jörg Fiebelkorn’s CD-Bremse. This tool allows you to throttle your CD-ROM drives by enforcing lower reading speeds. Unfortunately, I wasn’t able to go down to double-speed since the drive wouldn’t go slower than 4x.

This meant I couldn’t rely on measurements alone. Instead, I read through many, many datasheets of various CD-ROM drives. I also tried to emulate slower drives with 86Box since they allow setting transfer speeds as well. Even though I didn’t look at the code, I have the feeling that 86Box only emulates transfer speeds, but not access time.

Limitations and what’s coming up next

All in all, the current delays are pretty arbitrary and might be subject to change in future versions. I tried to be as accurate as possible, but I simply can’t guarantee I got them absolutely right. It is also noteworthy that applied delays are the same on the original Myst and Myst: Masterpiece Edition. Due to the lack of samples, I wasn’t able to verify this, but I’d expect Myst: Masterpiece Edition to have longer loading times on the same hardware due to increased file size compared to the original edition.

One option would be to make the delay a configurable option, allowing for a wider variety of ‘drives’. For now, the new option is disabled by default. Eventuelly, we’ll probably consider making this the new default. However, this will most likely not happen until the next release is out since I want to gather feedback from our users first.

Closing words

Currently, the loading time simulation is available for Myst and Myst: Masterpiece Edition. The same concept could be applied to Riven as well. There are two things to consider:

  • Timing: Internally, Riven uses some counters and timers to keep track of – well – time-based events. I need to dig deeper into the codebase to make sure that adding artificial delays between scene transitions won’t mess with the timing. This might even involve multiple playthroughs with varying conditions.
  • The installation itself: At least the version distributed on five CDs I own provides three options during the installation: Minimal, standard and full installation. Depending on which type you choose, loading times will obviously vary as well.

If you want to give this new feature a try, you need to download a current daily build from the ScummVM website and grab your copy of Myst or Myst: Masterpiece Edition. In you don’t own the game yet: Myst: Masterpiece Edition is available at GOG.com as digital download*.

After adding the game to ScummVM, you find the new feature in the in-game settings by hitting the ‘F5’ key.

myst cdrom delay option

What do you think? Any feedback is very welcome, especially when you have the chance to play the game on original hardware.

*: This link is a special affiliate link. If you visit GOG.com via this link, the ScummVM project gets a commission for any purchases you make. For you, the price is exactly the same while you are still supporting the project. Thank you ❤!

A Great Surprise

 I only realized with the turning of the new year that I have characteristically, once again, fallen behind on posting interesting news in my blog. My bad. As many of you will already know, last year I got sucked into working on the Comprehend series of games as a sub-engine under Glk. They were an interesting early series of combination graphics and text entry games including Transylvania, Crimson Crown, and OO-Topos.

As has become a bit of a custom over the last few years, over the Christmas holidays I scouted around for an existing source code project to work on integrating into ScummVM, as somewhat of a break from the various disassembly-based work I frequently do throughout the year. And behold the result of my work:


See here for a Youtube link of a screen capture I did for the game starting up. The Black Cauldron Remake is a point and click remake of the early Sierra game of the same name which I did over a dozen years ago, before I started working in earnest on the ScummVM project. Having it supported in ScummVM will be satisfying.. harkening back to my earliest days of open source work, and bringing it all full circle. And the important part of the remake is that it was done in AGS.

That's right. There's now an AGS engine for ScummVM that's at least capable of playing one AGS game through in it's entirety. Late last year I broached the subject of ScummVM integration on the AGS Forums, and the response was positive. AGS is currently in transition between 3.5 and a major redesign for 4.0, so there wasn't a rapidly moving codebase to try and keep up with. This engine, like the standalone interpreter it's based on, should eventually support all the AGS games from 2.5 to 3.*. Luckily, this covers the majority of the popular AGS games The ScummVM implementation will be just another implementation of AGS, so it'll be an alternative to the standalone interpreter, rather than a replacement.

The engine isn't yet available on Buildbot, so don't yet go rushing to grab a daily build just yet. I plan to do a pull request shortly, so it'll likely be merged into master in a few weeks once it's approved. There's still a lot of cleanup work to be done, bugfixing for other games, etc. so work on the engine will be ongoing. I added detection already for a few other games, but they crash on startup due to other unimplemented methods.. Rather than importing Allegro and other libraries used by the AGS interpreter in their entirety, I created a mockup layer that either remaps Allegro calls to ScummVM equivalents, or implements a bare-bones equivalent for the project from scratch. But so far I've only focused on what Black Cauldron needed, so other parts will be implemented as I gradually test other games.

On a side note, for all the AGS games to work on non-Windows/Linux/Mac systems, all the various plugins games used will also need to be re-implemented in C++.. I can't just have ScummVM loading in DLLs like the original interpreter does. Thankfully, I've already been able to obtain the original source for the AgsCreditz plugin from it's author,  Hopefully other plugin authors will be likewise generous when I get to them. When done, this'll mean AGS games will be playable on more systems that AGS wasn't previously available for.

One day in the near future, expect to play some of the classic AGS games like the AGDI Sierra remakes in ScummVM :)


Red Comrades in ScummVM (not GSoC*)

(* my site puts a post into RSS only if it has «GSoC» in it, so I kinda had to)

One of my favourite adventure games from my childhood are Red Comrades — these, actually, might even be the reason why I liked the genre. So, I’ve been keeping my eye on it after it was announced that the engine will be added by one of the GSoC students. Finally, there was a support announcement, and I’ve decided to play the games during the holidays.

This post is some kind of a less-formalized-than-bugtracker feedback. I’m going to actually submit some reports later, providing comparison with how the actual game worked, with screenshots, saves and probably even videos. For now it is only my experience compared with the impression of the game I remember.

Overall, the support is good. Both games are fully playable and there are no gamebreaking bugs — you can play it from the start to the end. Now onto my grumbling.

The Fonts

First thing that caught my eye: the fonts. I’m not sure why I’ve always played the game with subtitles, but now for me the game is incomplete if subtitles are off. I didn’t compare screenshots of the font yet, and IIRC it was just a usual Arial — but it looked a little bit off to me. To be more precise, there are multiple microissues with fonts/subtitles that I have.

First: I can see subtitles «jump» and I don’t remember that in the original game. Meaning that line height is different for different glyphs: for example, if line has «p», it will draw higher than a line without it. It can be easily seen in the dialogs how such lines go after each other and show up on different position. If the subtitles text is long, it will appear in two or three lines on the screen, and you could also see sometimes that these lines have different line height, as if one line is glued too close to another.

Second: there was a different font for inventory descriptions. ScummVM uses the same as in subtitles.

Third: when player is prompted to select an option in a dialog, these options have no outline or something. I don’t remember how exactly it looked in the original game, but for some reason I believe it was easier to read than in ScummVM.

The Walking

A really long time ago I and some other folks were making a fan continuation of the Red Comrades on Wintermute Engine. We were tinkering with original game resources, and ripped off all the backgrounds, music, sounds, animations, text lines and even walking regions. Now I don’t remember exactly if the original game also had some anchor points or did we add these in WME — but I remember that in original you could see heroes walking along some curved roads in the backgrounds pretty naturally. In ScummVM, however, this behaviour seems to be broken sometimes. I will prepare some save files to illustrate that in issues, but for now I will try to describe it. Again, there are two small issues that might (or might not) be independent.

First: a hero might ignore the walking region. Sometimes you could see how they are walking on the air or on the wall — obviously, outside the walking region. Sometimes I could see «Walk bug: Point doesn’t belong to any convex» message in the ScummVM terminal window, but I guess that only happened if heroes were spawned outside the walking region after fast travelling via the map. But when that happened, they just jump to the closest point which is in the region, so I’m not sure that’s the reason.

Second: pathfinding is a little bit strange. For example, we have three buildings on the screen: on the left, on the top and on the right. Say, our hero is at the top building entrance. We click at the right building. The hero starts walking towards the left building, and when they reach the left building entrance, they turn around and walk to the right building where we asked them to go. Not really critical, as they go where we want to in the end, but seems pretty strange, and, again, I don’t remember that in the original game.

The Rendering

I only remember that in the first game, and it’s not like that was happening all the time, but there were a few places where animations could «glitch» a little. What I mean is that a part of the sprite is not erased, so, for example, we could see two heads of the same character.

In some cutscenes there could be some «rainbow rubbish» pixels at the bottom. Not frequently, and I’m not sure that is easily reproduceable, but I’ve seen it happen.

The Cutscenes

Sometimes (mostly in Red Comrades 2?) there was just a lag instead of an animation/cutscene. For example, a hero walks towards an object and must play a unique animation of picking up or something, but instead your game freezes for a moment and then continues after (as if the animation was played and nothing happened).

Another variation: no animation is playing, but you can hear the sound effects, and the game continues after cutscene «has played». Most striking example is in the beginning of «Part 3» in Red Comrades 1, and I even have a save file for it. It shows a pretty long cutscene, but all you see is a static background.

In Red Comrades 2 there was another issue once: the game shows you that something has changed on the other screen, but in ScummVM this animation is very short, so you could even miss it.

Finally, there was an audio desync in the first cutscene in Red Comrades 2: you already seen the action on the screen, and only then you hear the corresponding sound effect.

The only almost-gamebreaking bug

In Red Comrades 1 I once had a strange dialog situation (maybe it activated twice or something): the dialog has stopped, as if it was waiting for me to choose an option, but there were no options on the screen, no cursor and no context menu available. So I couldn’t walk away or select an option to stop the dialog or pretty much do anything at all. But I think I just pressed Escape and dialog finished, so I didn’t lose any progress because of reloading.

The Speed

OK, another thing that was one of the first I’ve encountered, is walking speed. It is configured on the same screen you can turn subtitles on, so I’ve made it a little bit faster, and got a very fast walking heroes. I’ll have to compare that with the original, but I think I’ve got the max speed while it wasn’t on max in the options. I’ve just lowered it and played normally, so that’s not much of an issue.

The loading speed, however, is. It wasn’t painfully slow while I was playing, but when I’ve launched the original game, I was surprised how fluent it was. When switching screens, or loading animations, or loading some assets like inventory suitcase and options screen, you can easily see that ScummVM loads it, because it takes some time. In the original game it is barely noticeable. This might be the reason of some issues I’ve mentioned up there — such as audio desync or lags instead of the animations. TODO: I think the game was able to work with unpacked archives, and maybe ScummVM would work faster if I’d unpack its archives manually.

The Saves

Almost forgot about these! It was a little bit strange to see that you can’t use ScummVM own saving dialog. The cloud sync is not triggered when game is saved (or loaded via in-game menu), which is also a little bit unusual. And there are no autosaves, which could’ve been useful for me, because I didn’t save really frequently and thus I was lazy to play through the entire sequence again just to reproduce a bug I have just seen. Otherwise I would’ve have more saves to demonstrate these issues with.

Some technical information

I’ve used a daily build, ScummVM 2.3.0git11675-ga455b4c84a (Dec 31 2020 04:59:17).

I’m aware of two versions of the Red Comrades 1 game (which have different .exe files), but the only important difference between these is probably that one version has a compressed audio. I believe I’ve been playing the lossless version, and the game .exe version is 1.0.0.1.

I’ve been mostly playing on a laptop with Win 10 1909 (x64), and I also did a few quick runs on a desktop with Win 7 (x64).