Today I have released my Inherit the Earth Soundtrack (version 1.1). As usual, my soundtracks are intended for use with the ScummVM software so you can relive the wonders of classic point and click adventure games with my version of the music. Thanks to the original publishers for allowing a ‘fan made’ edition to be released.

This version includes a Flac Lossless option, improved audio mastering and slightly reduced reverb.

LINK: Inherit the Earth ‘Fan Made’ Soundtrack for ScummVM

FLAC lossless audio has been a requested feature of my ScummVM Music Enhancement Project for many years and I am happy to announce that my Beneath A Steel Sky enhanced soundtrack now includes this as an option for download.

Version 1.2 includes FLAC lossless audio as well as the standard Ogg Vorbis option and features improved audio mastering with slightly reduced reverb.

You can download the update from my website:
LINK: Beneath A Steel Sky External Music Download

Following on from the recent release of version 2.2 of this soundtrack, version 2.3 includes much improved audio mastering so you hear far more of the detail within the tracks.

FLAC lossless audio has been a requested feature of my ScummVM Music Enhancement Project for many years and I am happy to announce that my Simon the Sorcerer enhanced soundtrack also includes this as an option for download.

Version 2.3 includes FLAC lossless audio as well as the standard Ogg Vorbis option.

You can download the update from my website:
LINK: Simon the Sorcerer External Music Download

Today I am very happy to release version 2.1 of my enhanced soundtrack for you to use within the game, which will give everyone higher quality sounding music and not just those with powerful MIDI equipment.

Version 2.1 includes FLAC lossless audio as well as the standard Ogg Vorbis option and features improved audio mastering with slightly reduced reverb. I am still searching for the complete MIDI soundtrack at the correct slightly slower tempo, so if you have any assets that would help – please contact me.

A big thank you for the countless emails I have had about this particular release and of course to Terry Pratchett for allowing my enhancements to be released for your enjoyment.

To install, extract the music from the zip file and copy it to your Discworld folder on your hard drive. Make sure you have the latest version of ScummVM (minimum v1.0). For best quality (although not mandatory), start the ScummVM program and select Discworld. Now select [Edit Game], switch to Audio tab and set Sample Rate to 44kHz.

If you would like to consider donating, please click the button below:

To download the soundtrack, click one of the links below:

• FLAC Lossless – Stereo (662MB)
  Discworld – Full Soundtrack Version 2.1 (4th May, 2013) (65 hits)
• OGG Vorbis – Stereo (174MB)
  Discworld – Full Soundtrack Version 2.1 (4th May, 2013) (78 hits)

Previous versions…

• High Quality – OGG Vorbis – Stereo (129MB)
  Discworld – Full Soundtrack Version 2.0 (17th August, 2009) (5725 hits)
• Low Quality – OGG Vorbis – Mono (24MB)
  Discworld – Full Soundtrack Version 2.0 (17th August, 2009) (892 hits)

Webmasters: Please do not link to the files directly, instead link to this page!

Greetings, fellow adventure gamers! We have finally come to the point when ScummVM 1.6.0 testing starts.

This release adds support for a number of new games that need to be tested:

• 3 Skulls of the Toltecs
• Eye of the Beholder
• Eye of the Beholder II: The Legend of Darkmoon
• Hopkins FBI
• Tony Tough and the Night of Roasted Moths
• The Journeyman Project: Pegasus Prime

In addition, if you have Macintosh version of Discworld, please give it a try as well.

A daily build should be used for testing these, and if something goes unexpectedly wrong, please report it to our bug tracker. The completed games need to be reported on our forums and we will update our release testing page. For a usable test report, we need you to provide the version, language, and platform of the game you're testing. And, of course, please stick to the testing guidelines.

This release also has another interesting aspect. Depending on how intensively games are tested, we will add support for one more game: Hopkins FBI. For support to happen, we need test results on several platforms using several variants of the game, which includes the BeOS, OS/2, Linux and Windows versions.

In conclusion, if you want Hopkins FBI in ScummVM 1.6.0, grab your originals and contribute to this new testing period! We are also in need of screenshots too! Please submit them to our patch tracker.

James Woodcock has today released his enhanced music for classic point & click adventure game Touché: The Adventures of the Fifth Musketeer, as part of his 'ScummVM Music Enhancement Project'.

By adding the external digital music files provided for free by James and with our ScummVM software, users can enjoy the updated soundtrack within the actual title as it is played.

Using modern MIDI hardware, James edits the original MIDI information and records them as external digital music files. Developers of ScummVM then add code so the newly created files will work within the titles.

"ScummVM has always inspired my involvement and although I am not a programmer, I hope my ScummVM Music Enhancement Project adds a little extra enjoyment to users of this fine point and click adventure software." says James Woodcock, creator of the enhanced soundtrack.

James has previously released other enhanced soundtracks for titles including:

• Beneath A Steel Sky
• Discworld
• Inherit the Earth
• Simon the Sorcerer
• The 7th Guest

To download the enhanced soundtrack, click there.

ScummVM has been accepted for the Google Summer of Code 2013!

We're hoping to find another group of students who want to help out the ScummVM project and get paid for 12 weeks of coding work over the summer.

Maybe you'd like to help us improve support for games, or enhance our user interface? Perhaps you'd like to revamp our OpenGL support and accelerate the rendering of some engines? Or do you have even bigger ideas, like starting support for yet more games?

If any of this seems like a good way to spend your summer, take a look at our ideas list, or drop into our IRC channel (#scummvm on irc.freenode.net) and have a chat with us!

Beware: the application period is from April 22 to May 3, so be sure to talk to us in time! We know from previous years that it's really helpful to apply early, and to get involved with the ScummVM community so we can help to revise your application.

It's been so long since the last post that Blogger completely changed their editing interface (OK, not really a joke since Google seems to change their GUI with everything at regular intervals to confuse the public at large).

A few things for this update:

1) The Journeyman Project: Pegasus Prime is now supported in daily builds of ScummVM. Rejoice! And stay tuned for more news!

2) ScummVM April Fools Jokes™ will return next year with a vengeance (blame DrMcCoy, probably).

3) If you're able to recall when posts happened more regularly than yearly, you might remember this post, which I followed up saying I uploaded modified ScummVM code to a branch. Then last year I wrote a small player for the videos so I didn't have to hack directly in ScummVM anymore -- and then added support for Outlaws (proper 1/4 sized raw frames), Mysteries of the Sith, and (partially) Rebel Assault SegaCD.

LordHoto's favorite level (Sega CD version)

Mysteries of the Sith, Level 1 Opening

Oh, and I apologize if your comment didn't show up over the past few months. I screwed up with the admin settings on the blog and it never forwarded me e-mails! Sorry!

It's the year 2318; you're part of an agency created to protect the integrity of the timeline after time travel has been invented. After it is detected that someone has changed the past, it's up to you to repair the time stream!

The ScummVM Team is proud to announce support for the Macintosh version of The Journeyman Project: Pegasus Prime. So go grab the latest daily build of ScummVM and play through the game to assist us in testing!

If you find any bugs while playing, please report them to our bug tracker following our bug submission guidelines. For information on how to extract the data off the disc, follow instructions listed on our wiki.

Is there an engine that can resist the love in these hands?

Some time has passed since doomsday, and we're still around to see the aftermath, the time since then has not been wasted however. Today we release ResidualVM 0.1.1 which is a service-release bringing you roughly 40 gameplay-fixes, varying from very minor fixes to quite visible bugs, 14 of these fixes were also in the original game as it was released back in 1998.

For a list of what has been fixed, see the NEWS-file.

So, head on over to our downloads-page and grab a fresh copy of ResidualVM 0.1.1 to enjoy the best possible Grim Fandango experience we can offer to date.

The day is finally upon us, after 9 years, 4 months and 6 days, we are proud to announce the first stable release of ResidualVM, and what day would be better for this occasion, than the end of the world as we know it. (or so the Mayan Mechanical Gremlins told us).

This initial stable release of ResidualVM now opens the world of Grim Fandango to a modern audience, whether you are using Windows, Linux or OS X, you'll now be able to take your 4 year journey of the soul, and find out if that compass in the handle actually WILL come in handy.

We would like to note that, while we have tested ResidualVM quite thoroughly, there MIGHT be cases where you end up in a situation where the game is incompletable, some of these were actually also existent in the original game (while the game itself is designed to be dead-end-free, the bugs in it weren't, nor were our own). So, please follow the old adventure-game mantra of "save early, save often".

Over the past few years a lot has happened, even though the code base didn't reach a mature state until the past year. Lots of bugs have been fixed, even quite a few bugs left in the original game have been resolved. The team would like to thank all those that have been involved with getting ResidualVM to this point for their efforts.

Finally, we would like to thank:

• The LUA developers, for creating a nice compact script interpreter.
• Tim Schafer, for obvious reasons, and everybody else who helped make Grim Fandango a brilliant game; and the EMI team for giving it their best try.
• Bret Mogilefsky, for managing to create a SPUTM-style 3D LUA engine, and avoiding the horrible hack it could have been.

So, jump on over to our downloads-page, and grab a copy of ResidualVM 0.1.0 (but don't forget to download the 1.1-patch for Grim Fandango while you're there).

As I've been a bit busy the past few months, the Wintermute-engine port for ScummVM hasn't seen as much progress as I would have liked, but I still think it's time to get the ball rolling a bit again: 

One of the games I tested against this summer was Chivalry is not dead. So far I haven't had any issues with this game, BUT, this game is also very open-ended, and thus a bit hard to test thoroughly. 

Thus any help testing this game would be greatly appreciated. 

Just grab a copy of the game from the link above, and a nightly build of ScummVM, and test the game. Report any issues to the ScummVM Bug-Tracker, in the group "Wintermute". I would also love to hear in this thread if you played through the game without any issues at all. 

Note: Chivalry uses the Arial-font currently, which we haven't yet worked around (eventually a similar FreeFont will be used), so to get decent fonts in the game, you'll have to put arial.ttf in the game's folder (on macs you can find it in /Library/Fonts, on Windows it should be in C:\Windows\Fonts, linux-users can either download a replacement from FreeFonts/OpenFonts, or get some solution involving Microsoft Core Fonts.)

As you may know if you read dreammaster's blog, I'm currently giving a hand to dreammaster on Hopkins FBI, which is a gore adventure game. Thanks to the cartoon-ish look of the cutscenes, it's not too shocking though (at least for us)...

As you may imagine, this is an excellent excuse to avoid working on the engines "rotting" on my repository... Here is a little point concerning those.

- Adventures of Robin Hood:
The engine is more or less complete for the DOS version of the game. The game is scripted. Almost everything is scripted, even: the intro, the menus... Everything! So rewriting the game was pretty easy, as the engine was particularly small. It's currently possible to watch the intro, walk around, interact with objects and characters... and die, of course! The dragon is pretty efficient for that... Yes, there's a dragon in Robin Hood :).

There are some glitches and minor bugs left, but the really blocking part is the sound and music of the game. Peres kindly broke the compression/obfuscation used so I have now MID files, but some commands are still problematic, and SylvainTV and I were not (yet) able to hook something working. After sound support, a huge refactoring would be required before we may consider discussing about a merge. As I hate sound maybe even more than Dreammaster does, it may takes forever though :/

The Amiga and Atari ST versions of the games, sadly much more common than the DOS version, are booters and are currently not targeted by the engine.

- Mortville Manor:
We received the sources of the French DOS version of this game months ago, after some discussions with Lankhor right owners and DotEmu. They were in Pascal and Assembly code. After some a lot of work on it with Dreammaster, the game is now completable with almost no glitch left. Several things are blocking a merge discussion though: No sound support and only DOS French version supported.

The sound support is a nightmare. The only sound available in the original is generated speech based on phoneme synthesis. At the time, they were clever enough to add subtitles, so it was possible to understand something... But it didn't age really well, and what was extremely impressive in 1987 is now absolutely terrible, to the point that the game sounds much better without sound support!

The language support is of course the second problem. I created a partial English translation based on Atari and Amiga texts, but the dialogs are missing: in those versions, the speeches are not dubbed, and are not using phoneme analysis, so we have to translate it ourselves. Criezy started a translation, but it's a long and hard work, particularly considering he doesn't have much time for that. (Any help would be appreciated at this point!). A German DOS version also exists, but is currently not supported, and I haven't yet looked at the Amiga and Atari versions. All the other platforms are ignored on purpose, as the engine is too different (Amstrad CPC, Sinclair QL, C64, Apple 2E, ...)


So... If you want to give a hand on those engines.... Drop me a line! Translation doesn't require technical skills, everybody can help!

Ok, so GSoC is over, I passed and a few things has happened since then:

Some games had issues with interlaced PNGs and TGAs, this should be less of an issue, as I posted pull-requests for using libpng (instead of the internal variation that was in use before), as well as a TGA-loader, both of which have been accepted and merged now. (This means that Five Magical Amulets and Five Lethal Demons now atleast start).

The Wintermute-engine was opened as a pull-request, which after some adjustment and discussion, ended up getting merged into the master-branch for ScummVM. This means that the Wintermute-engine is available in the latest daily builds, although it is still marked as unstable, and no specific games are officially supported at this point. (BUT, from personal experience atleast Dirty Split and Chivalry is not Dead should be completable). The development of the engine will continue there instead of in my own fork.

Speaking of which, I am now joining the ScummVM-team as a developer, to continue working on the Wintermute-engine (and hopefully getting a few games release-worthy). The road ahead for Wintermute isn't short, as there are plenty of bugs left to squash, and plenty of performance left to improve upon, so I guess I'll have my hands full for a while longer.

So, if you want to try out the results of this summer's work, go ahead and grab a daily build if you are on Windows, or build your own if you are on OS X or Linux.

Oh, and while I won't be accepting bug-reports for specific games for a while yet, feel free to send me detection-entries for the multitude of games I haven't gotten around to adding yet.

Einar Johan

This has been a rather slow week, my exams are starting up, and I only got in some time to start looking into the slowness that still persists with this engine.

The major source of slowness at the moment, stems from the fact that the SDL-backend in ScummVM seems to want to down-convert 32bpp to 16bpp, and since the engine is still doing full-screen updates, that means a full-screen down-conversion for every frame, which takes quite a bit of time. The problems from this can be avoided by using the OpenGL-backend, although that still has problems of it's own (like not supporting the PixelFormat I originally started out with (RGBA)), it does a decent job as a way of testing the other parts of the drawing pipeline without drowning them out in conversion.

Getting the down-conversion out of the way, revealed that the single blitting-function I'd been using was indeed rather heavy, and I'd split it out earlier to two separate functions, where one supported colour-masking, and the other didn't, making it easier to see in a profiler how much of the drawing actually used colour-masking (very little). I added in an additional function for handling opaque drawing, which helped quite a bit on the speed (skipping atleast 3 multiplications, 3 shifts and 6 additions per pixel).

For Dirty Split the numbers I get on my computer are roughly (Using the OpenGL-backend):
27 % Opaque-draws
20 % Scale
9 % Alpha-blitting

Where percentages are of the total CPU-load for the process (which now actually can be different from the CPU-load for the entire core it runs on, at max FPS). Now, there is obviously room for improvement here, in particular, the scaling, which as a result of the changes I did to implement dirty rects, ended up being done for every draw (basically, the non-dirty rect version would create renderTickets that were instantly drawn, and then discarded, and since the renderTickets were responsible for keeping the scaled copies, they were rescaled every frame). Thus I ended up partially adding renderTickets to the full-screen update system:

Upon a render call, the render-queue is checked for a matching render-ticket, if one exists, that ticket is used for drawing, otherwise, a new ticket is generated, drawn and added to the render-queue. Any unused ticket in the queue (a misnomer really, as it's really a list, but hey...) is deleted when the screen-buffer is flipped onto the screen.

This gives the benefit of not having to rescale every frame, now the results after doing that weren't exactly comparable, as I didn't exactly set forward a specific enough test (simply watching a bit of the intro movie, and then letting it settle for a while in the first frame), but, atleast the scaling is almost nowhere to be seen:
26.6% Opaque-draws
25.8 % Alpha-blits
2% Scale

This makes for quite an improvement, and should possibly make the games playable on a bit slower computers than what has been the case so far.

The XmlShader specification allows for multiple fragment shaders, the output of one being piped into the input of the next. Unfortunately, the existing XML parser  has difficulty with dynamic xml structures (or I had no idea how to read a variable structure). So I wrote a new XML parser. It parses arbitrary XML structures and produces an easy-to-use tree.

Then I altered my existing OpenGL backend modifications to allow multi-pass rendering. This requires the framebuffer object extension, which is widely supported, but it may not be supported. I will have to add some compatibility options later.

In the meantime, almost all of the shaders in the bsnes repository work (https://gitorious.org/bsnes/xml-shaders). Some of them are quite interesting. They scale to arbitrary sizes, although some look better at certain resolutions (scale2x, 5xBr, etc.). Ctrl Alt 9 and 0 switch shaders.

Right now, I am in the middle of nowhere. I'll be back home next week, but until then I will have very limited connectivity. Feel free to send me an email or leave a comment, and I'll read and reply when I get a chance.

The past week has seen quite a few deletions from the codebase, I've removed the debugger, the registry and a lot of smaller pieces here and there in the code, all stuff that isn't really necessary in a ScummVM-version of the engine (like in-engine fullscreen-switching-handling).

I've also found time for quite a bit of cleanup, with the assistance of the nifty astyle tool I added braces to all if-, for- and while-statements, breaking single-line ifs that looked like this:
if (conditional) doStuff();

into:
if (conditional) {
    doStuff();
}

which made for quite a bit more readable and consistent code.

I've also removed Base as super-class for a few classes that didn't really need to reference BaseGame (formerly CBGame), thus easing the cross-file-dependencies that were making the compile-times horrible.


File Management


The package management in the file manager has been refactored into a subclass of Common::Archive, which at this point means that it's quite close to being able to be added to SearchMan, and then just using SearchMan directly, one of the blockers for that is the filename-handling for absolute paths (i.e. redirecting C:\Windows\fonts somewhere usefull, another is that quite a few classes use the "readWholeFile"-function (those that just got a bad case of "endianness"-itch, can relax, it's only used for text files)).

Save games
Where formerly save games were taking ages and ages to load/save, they now should take quite a bit shorter, the speed-issue here came from the fact that the "load-progress-indicator" was drawn for every instance of every class that was loaded/saved, this in turn made a full screen update (as everything does for the moment, for lack of fully working dirty rect-updates). This meant that for every millisecond of usefull load/save-work, the engine would be doing hundreds of milliseconds of work updating the screen just to possibly move a progress bar another pixel.

I changed this behaviour to only update the exact region of the screen where the indicator is, and only as far as the indicator has progressed (and, only when the progress bar has changed at all). This might result in minor differencies in how the progress bar looks (as it isn't redrawn on top of itself for every single instance any longer). But that's a cost I think most users will be willing to take when the end result is a decrease in save/load-time by a factor of 10.

Lazy loading of images
The engine used to take a few seconds to startup a game on my computer, the reason for that was simply that all the images in the entire game would be loaded. I looked into this, and the only reason most of these images were loaded, was simply that their width and height was needed to set the default size of _rect in BaseSubFrame. I changed _rect to private and made ALL access to it use getters and setters (even internally in the class). Then I added the field _wantsDefaultRect, that kept track of whether _rect should have the width/height-values or something else. When getRect is triggered, and _wantsDefaultRect is true, the image will be loaded, to get at those values.

Now, this might sound like a rather odd approach for a simple getter, but the end result is that the state of the class is preserved WITHOUT loading every single image on startup, thus reducing both the load time and the memory footprint by quite a bit. (For Dirty Split I halved the memory footprint of the first screen, and reduced the load-time to between a fifth and a tenth).

One side-effect of this that might prove this solution quirky, is that there is no guarantee that all frames of an animation reside in memory now, which might result in some animations being slow or late the first time they are played.

Singleton and separation
Instead of passing the File Manager around to everyone and everything, it's now moved to a singleton that is supposed to keep it, and other stuff that survive between loading savegames. Since BaseGame is already quite a bit on the heavy side (clocking in at over 4 KLOCs), I think it's appropriate to try to move as much functionality as possible OUT of that class and put it elsewhere.

Minor stuff

• I had forgotten to add the space-bar as a "printable" key in the events-checks, which made typing anything but rather long words in i.e. save-game titles impossible. That is fixed now.
• Sounds that were playing when saving now resume properly on load.
• Screen-fading now works.
• Save game thumbnails now scale properly (thanks to some scaling code I got from clone2727), where before they would repeat the first column in the last few rows, owing to some integer-division gone haywire.
• The settings that were formerly in the settings.xml-file have now been moved to ConfMan, which is responsible for the ScummVM-settings-file (.scummvmrc/ScummVM Preferences/scummvm.ini), any game-specific settings will be stored there with the prefix priv_ (for instance the subtitles-flag in Dirty Split is stored as priv_Subtitles).

I've added some support for multiple shaders using XmlShaderFormat. It looks for all *.shader files and tries to parse and compile them. However there isn't a good way to change shaders. So far, all changes have been in the base OpenGL backend. However, in order to expose the shaders through the graphics mode settings, changes may possibly be made to the SDL backend. Right now, it queries a static class function to figure our the supported graphics modes. However, OpenGL calls to compile the shaders cannot succeed before the OpenGL context is created. So either the class needs to be initialized before the SDL backend queries the graphics modes, or the static class function can guess about what shaders will eventually be compiled (For instance if "CoolFilter.shader" exists in the current directory, but is not a valid XmlShader or it does not contain valid GLSL programs, then it would still be reported as a valid graphics mode.).

My work on scaler plugins has slowed down. I want to get it incorporated into the main project, so the things I need to consider are

• How will the plugins work with existing backends that used the old scalers?
• How will they work with future backends?
• Do more formats need to be supported? Can they be detected at runtime or compile time (Or probably both)?
• How can they be integrated with the build system?
• Options to disable formats (e.g. 32 bit formats which are not used)
• Options to disable plugins. Currently the Edge2x/3x plugin shares the HQ scaler compile option (USE_HQ_SCALERS).

I have added some very basic support for shaders into the OpenGL backend. Right now, it looks for a "vertex.glsl" and a "fragment.glsl" to load as vertex and fragment shaders respectively. Eventually I want to have some manifest file that stores the properties of shader programs, but I have not done that yet.

Right now, two uniforms are passed to the shaders. The first is the texture to use called "texture". The second is a vec2 containing the width and height of the texture in pixels called "textureDimensions". This is useful since texture coordinates are in the range [0..1] so it is difficult to tell where one pixel ends and another starts. I have attached a shader program that implements scale2x (Advmame2x) by finding the position within a pixel using these uniforms. It duplicates the functionality of the scaler in the SDL backend, but it looks kinda funky with scale factors != 2. It can probably be modified to use a combination of Advmame3x and Advmame2x depending on subpixel position.

What is great about this is that no development tools are required to change the shader programs. So users can create and load shaders without having to configure build environments and compile ScummVM. Hopefully this can lower the barrier to making some creative works.

Advmame2x shader: https://gist.github.com/3161079
ScummVM branch with enabled shaders: https://github.com/singron/scummvm/tree/opengl