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

PlanetPlanet

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

April 13, 2018

Paul Gilbert (Dreammaster)

Working my way through Dark Side

I've spent the last week with an in progress working my way through Dark Side of Xeen. As of last night, I've mapped out the bulk of the southern side of the map up to the mountains, released the first stage of Queen Kallindra's castle, finished the Temple of Bark, and am just winding up clearing Sandcaster and it's sewers of enemies. I've identified and fixed multiple problems as I went, and not all of them were specific to Dark Side.

For example, one bug I'd been meaning to fix for a while was finally resolved - when monsters were triggered to hate & attack the entire party at the same time, they were originally only ever attacking the first party member. This made the Dragon Caves on the Clouds side *so* much easier.. all the dragons would wail away on my first character, even after he was dead, leaving the rest of my party to kill them at their leisure. By the time I left the dragon caves, my first party member was below -5000HP :) Another, ironically, coincidental script problem meant the dragon containers didn't tax me when I walked past them, so I didn't even have to worry about losing gold and gems.

I also fixed some bugs in the sound system that could cause crashes when multiple sound effects were played in rapid succession, and a bug in the combat system that could case a crash when recalculating the order that characters and monsters fight in based on their speed. The later I'm particularly hoping will help resolve the outstanding rare crashes I was previously getting with extended combat. It may be naive.. I'll have to wait and see whether any further crashes occur.

So yeh, things are progressing, and the engine is getting more and more stable; I'll keep working my way through the game. I've got a long weekend coming up tomorrow, but honestly, I'm not sure how much time over the weekend I'll end up playing the game. I think I'll keep the bulk of it for some R&R and doing other things. We'll see how it goes.

by Dreammaster (noreply@blogger.com) at April 13, 2018 02:56 PM

April 09, 2018

Paul Gilbert (Dreammaster)

Clouds of Xeen is now completable

Good news on the progress of the Xeen engine in ScummVM. As of the weekend, I finally finished my first playthrough of Clouds of Xeen! I finally got to give smackdown on Lord Xeen, and watch the ending cutscene. Which I've admittedly previously seen multiple times when I was first implementing the code, but there was the emotional satisfaction of seeing it properly, rather than just using the mirror cheats. Though I will confess that I got so overeager to finally finish the game, that I lacked the patience to do it properly (with well/fountain stat raises), and instead used my debugger cheats instead. But it doesn't take away from the fact that the first game is confirmed as completable. \o/

Now, it's onto Dark Side. There were actually more bugs due to changes done for Dark Side (code I'd implemented but not yet tested) than I anticipated. I already fixed multiple different bugs on the weekend that were causing hangs and crashes. Currently I'm looking into a somewhat complicated problem with how wall decorations are handled.. it causes a crash that makes Ellinger's Tower impossible to complete. So Dark Side definitely isn't completable, and needs further testing. On the plus side, though, it shouldn't take as long to test and finish Dark Side than my Clouds testing took, since Dark Side benefits from all the fixes I've already done for Clouds.

At this rate, my initial play through & tests of both Dark Side and Swords should be done within the next month, and  the game will likely be stable enough for a public testing period. Not long now :)



by Dreammaster (noreply@blogger.com) at April 09, 2018 05:47 PM

April 02, 2018

Paul Gilbert (Dreammaster)

Work on Xeen is up in the air

As tempting as it would be to write this post yesterday on April Fools, I've left it to today to make a status update on my playthrough through Xeen. Work has been proceeding well. I've fixed lots of bugs that were identified by both myself and Dark-Star, who's been assisting me with preliminary testing. As of yesterday, I've:
- Finished the Dwarf Mines
- Mostly finished Rivercity (except for the Knights behind the training area)
- Completed the Witch Tower. Hence the post title.. the levitate spell works, and I've been walking around on the clouds :)

Many of the bugs were crashes and hangs, so it highlights that the game still isn't ready for general public testing. The Witch Tower, for example, required two fixes to get it to work.. one where I wasn't setting whether the party had the key (so it was never letting you in), and one where I incorrectly implemented the "return from subroutine" script opcode, so trying to go back into the Witch Tower from the stairs in the Witch Tower clouds hung the game. Ironic that both ways into the tower were glitched. :)

I think combat is also more settled now. Previously, there were various crashes, and none of the combat spells worked. Now, though, I'm able to properly cast them, so the monsters around Rivercity are much more manageable to defeat. Though I did still experience a problem once where the party wasn't immediately registered as dead after all being killed, so obviously still needs a bit of polishing to fix such remaining issues. Speaking of spells, I decided it was acceptable, given the circumstances, to cheat to give myself extra funds to purchases all the spells for each character. There was little point in delaying matters, trying to accumulate wealth. It also meant I was able to buy pathfinding and mountaineering skills for my party so I wouldn't be constrained where I could travel. It already proved useful, as I was able to identify and fix several bugs with the close-up rendering of forests, where they weren't properly being scaled, and were drawing outside of the scene area.

From here, I'll keep on working my way through the game, fixing bugs as I go. Given I'm already significantly into the game (at least for Clouds), I don't anticipate there'll be any major impediments to my progress. Apart from tracking down remaining issues with combat, hopefully the rest of the game will just be fixing minor problems, like that which prevented me from entering the Witch Tower.



by Dreammaster (noreply@blogger.com) at April 02, 2018 03:12 PM

March 31, 2018

ScummVM News Headlines

IDA Disassembler

A recent discussion about the most recent IDA Disassembler freeware 7.0 revealed that it no longer supports disassembling older DOS and Windows executables. This is obviously a problem for potential contributors, as well as potential GSoC students wanting to reverse engineer an old adventure game or RPG for their project. The obvious solution is to provide an earlier freeware version that still supports them.

Consulting with Hex-Rays, they're kindly consented for us to host one of the earlier IDA freeware versions, for those in the future who wish to use it. After reviewing the earlier versions, we've settled on IDA Freeware Version 5.0. IDA 5.0 was the first version of IDA that added the convenient graph view, and this freeware version has both it as well as the ability to disassemble DOS executables. It's also not time limited like the demo versions, it's the most convenient for enthusiasts to try their hand at reverse engineering old games.

Considering how many of our game engines have been created by reverse engineering the original games, hopefully we will continue to see people interested in re-implementing games in the future.

The more the merrier :)

by DreamMaster (nospam@scummvm.org) at March 31, 2018 05:00 PM

March 23, 2018

Paul Gilbert (Dreammaster)

Xeen playthrough in progress

The Xeen playthrough is finally in progress, having been restarted last night. And by the time I went to work this morning, the first town of Clouds, Vertigo, was completable. Huzzah. \o/. I did identify and fix some further problems, such as armor not equipping, reading the note in the Vertigo warehouse, and getting the experience from the mayor. Next stop will be the Dwarf Mines, which I don't anticipate having much, if any, problems. Particularly since I've done some previous testing in them, though I've not yet been beyond the first level.

This is a good omen for completing the rest of the game. Particularly given the amount of care I've already given to fixing bugs I'd introduced in my reimplementation of the combat system. And the fact that all the various towns share the same code base for implementing the different tavern, guild, etc. locations. I'm expecting/hoping that the rest of the game will be straightforward. Indeed, most of the fixes I did last night were fairly straightforward to fix once I'd identified the bugs in question.

Of course, it's been years since I played the game, and honestly I only really remember some of the highlights of the Dark Side. So this playthrough will be a chance to re-experience the games once again. And my unfamiliarity will ensure I go poking into every nook and cranny. Though the downside is that I may not notice minor things not working, such as searching specific locations not giving the expected items, monsters, or loot. Once I've finished my first playthrough, hopefully some more experienced Xeen players can be enticed to play through the game as well.

Well, better get back to work. It may be Friday, but I still have the entirety of the work day to get through before I can get back to my playtesting :)

by Dreammaster (noreply@blogger.com) at March 23, 2018 01:51 PM

February 14, 2018

ScummVM News Headlines

Another year, another Summer of Code

GSoC Logo

Two days ago, Google announced the organizations that have been accepted for this year's Summer of Code, and we are very pleased to announce that ScummVM is one of them, together with our sister project ResidualVM. The Summer of Code is a yearly event organized by Google to encourage students to contribute to open source projects. Open source organizations provide mentors and projects to work on, while Google give some money to participating students. You can find more information on the official web site. We also have some information on our wiki, and in particular project rules that applicants will need to follow.

Are you a motivated student? Are you available between May 14 and August 6? Do you want to be a contributor to one of the largest game preservation projects? Then ScummVM and ResidualVM are waiting for you! Have a look at our ideas page or bring your own idea! Students have until March 27 to write and submit proposals for the project they want to work on. The accepted proposals will be announced on April 23, and there will be a few weeks for community bonding before the start of the 12 week coding period on May 14.

In any case, don't hesitate to chat with us on IRC! One place: Freenode. Two channels: #scummvm and #residualvm

by Criezy (nospam@scummvm.org) at February 14, 2018 05:00 PM

December 30, 2017

ResidualVM News Headlines

ResidualVM 0.3.0 is here

ResidualVM 0.3.0 is released. Go grab it. Let's get it over with, this new version does not have any new supported games to offer. But that does not mean there is nothing interesting in there. It's packed with almost three years worth of fixes and improvements. Most notably:

  • Better compatibility with newer operating systems thanks to switching from SDL 1 to SDL 2.
  • A multilingual user interface.
  • A widescreen mode for Myst III.
  • Both Grim Fandango and Myst III have received a lot of awesome user play testing, and as a result many bugs have been fixed.

Detailed release notes can be browsed in our NEWS file.

What's next? The development version of ResidualVM contains two additional work in progress games, Escape from Monkey Island and The Longest Journey. A lot of work remains before they can make their way into a release. But if you are interested in helping, contact us!

We at ResidualVM wish you a happy new year!

by bgK (nospam@residualvm.org) at December 30, 2017 12:00 AM

December 17, 2017

ScummVM News Headlines

To: You. From: Release team. Subject: ScummVM 2.0.

Just in time for the holidays, the final release of ScummVM 2.0 is here! This version adds support for 23 brand new old games, including almost all of the 32-bit Sierra adventures:

  • Cranston Manor
  • Full Pipe
  • Gabriel Knight
  • Gabriel Knight 2
  • King's Quest VII
  • King's Questions
  • Leisure Suit Larry 6 (hi-res)
  • Leisure Suit Larry 7
  • Lighthouse
  • Mixed-Up Mother Goose Deluxe
  • Phantasmagoria
  • Phantasmagoria 2
  • Plumbers Don't Wear Ties
  • Police Quest 4
  • RAMA
  • Riven: The Sequel to Myst
  • Shivers
  • Space Quest 6
  • Starship Titanic
  • The Dark Crystal
  • Time Zone
  • Torin's Passage
  • Ulysses and the Golden Fleece

There’s more than just new engines, too! Many existing games have been improved, a lot of work has been done to improve the overall audio and video systems, and some players will also enjoy improved joystick support and various small enhancements suggested by other users. A more complete list of changes in this release can be found in the ScummVM 2.0 release notes.

And now, a big round of thanks and congratulations to everyone who made this release happen.

Our super cool code contributors, who wrote all the things which went into this release: Aaryaman Vasishta, Alexander (Tkachov), Alexander Reim, Alexandre Detiste, Alyssa Milburn, angstsmurf, Arnaud Boutonné, Bastien Bouclet, Ben Castricum, Bendegúz Nagy, Cameron Cawley, Colin Snover, cpasjuste, D G Turner, Daniel Plakhotich, Dario Scarpa, David Fioramonti, Donovan Watteau, Einar Johan Trøan Sømåen, Eugene Sandulenko, Fedor (fedor4ever), Ferdinand Thiessen, Filippos Karapetis, Frank Richter, Hein-Pieter van Braam, Hubert Maier, iskrich, Ivan Avdeev, Joseph-Eugene Winzer, Kirben, kmar, Lothar Serra Mari, Lyubomyr Lisen, Marcus Comstedt, Martin Kiewitz, Michael Drüing, Nick Renieris, Omer Mor, Ori Avtalion, ottogin, Pala, Patrik Dahlstrom, Paul Gilbert, Peter Kohaut, Retro-Junk, Robert Crossfield, Robert Göffringmann, rsn8887, Ruud Klaver, Ryper_Zsolt, Schrijvers Luc, Simei Yin, stevenhoefel, Sven Hesse, Sven Kochmann, Tarek Soliman, Thierry Crozat, Thomas Fach-Pedersen, Tobia Tesan, Torbjörn Andersson, upthorn, vanfanel, VelocityRa, Vincent Bénony, Vincent Pelletier, Walter van Niftrik, Willem Jan Palenstijn, and Zbyněk Schwarz!

Our extra awesome community members and testers, who kindly banged on ScummVM and reported issues which were fixed during this cycle: ADeadTrousers, albadross, AlessioR, Alien-Grey, AndyILC, Arjak89, badungu, Bakhtosh, Bastien Bouclet, Ben Castricum, Benjamin Hodgetts, Bill Niakas, bramvandijk, carquinyoli, Colin Snover, counting_pine, ctoroman, cyberskull, d3p4z, dafioram, Daniel Wolf, danieljaeger, David Dew, david_corrales, dch216, dego93, Derek Warren, dominus, DustyShinigami, elaseela, Eliot Lash, enclume, EricOakford, esziarko, exmensa, Farmboy0, Filippos Karapetis, forge017, g5ppc, garethbp, gatesbillou, GeekZolda, George Kormendi, GermanTribun, greencis, Gualtiero, Hein-Pieter van Braam, henke37_2, hkzlab, Hubert Maier, Ignaz Forster, ilya13, Indy4-Fan, IntEmu, Ivan Lukyanov, Jan Sperling, Jarosław Jaworski, JCaesar13, jcmanciot, joachimeberhard, jomalin1, kervala, Kurufinwe21, Laylia27, legluondunet, legoking831, Lothar Serra Mari, Lyubomyr Lisen, macca8, maplesyrup, Markus Mahlstedt, Matan Bareket, Max Tabachenko, mcknallski, mthreepwood, MusicallyInspired, oddfff, Omer Mor, Ori Avtalion, Paul Gilbert, pegasusepsilon, PetrCejpek, Petter Sjölund, pliesenfeld, Quietust, r-alf-the-alf, Robert Megone, rsn8887, SeanW1975, Sergey, sluicebox, softwarespecial, Stefan Seeland, Stephane Lapie, Sven Hesse, Tarek Soliman, telanus, tgfmfc, Thierry Crozat, tobiatesan, Tomasz Grzegurzko, Torbjörn Andersson, Uukrull, vonmagnum, vorph999, Walter van Niftrik, Willem Jan Palenstijn, Windle Poons, zaurak, and zorbid.

Our exceedingly fantastic translators, who have helped bring ScummVM 2.0 to the users of 24 different Earth languages: Alex Jakovleff, Alexandre Folle de Menezes, Arius, Ben Castricum, Carlos, edward, Einar Johan Trøan Sømåen, Erik Zubiria, Ettore Atalan, Eugene Sandulenko, Fernando Sarmento, Filippos Karapetis, George Kormendi, Gilles, Hampus Flink, Ivan Lukyanov, JanShing, Jennifer McMurray, jepael, jeroen klop, John Doe, Jordi Vilalta Prat, Jose Roses, Joseph-Eugene Winzer, lorz, Lothar Serra Mari, Luis, Lyubomyr Lisen, Manuel, Martin Schoenmakers, Max von Werner, Michael D., Milo Casagrande, mézes gergely, pablobecerra, Paolo Bossi, Pavel Kungurtsev, Pere Orga, Peter Johansson, Petter Sjölund, poulsen93, Purple T, rafaelmessias, Rafał Będźkowski, Rafał Rzepecki, Rodrigo Vegas Sánchez-Ferrero, Rossano, Rouven Bauer, Santiago G. Sanz, Santiago Sanchez, selmiak, Sergio Carmona, Simon Sawatzki, Steffen Nyeland, Thierry Crozat, Timo Mikkolainen, Timofonic, Tobia Tesan, TomasM, Vitor Santos, Víctor Martínez Pajares, Walter Agazzi, wreednumero2, and Zbyněk Schwarz.

Our extremely good looking porters and packagers, for turning ScummVM into something you can actually run: Bastien Bouclet, Cameron Cawley, Colin Snover, Joost Peters, Keith Scroggins, Luc Schrijvers, Manuel Alfayate, Marcus Comstedt, Tarek Soliman, Thierry Crozat, and Willem Jan Palenstijn.

Our very wonderful technology sponsors, easyname, who provide us with servers and bandwidth so we can actually manage and send these releases to you.

And, finally, thank you to you, exceptional user, for using ScummVM, and (with deep apologies) to everyone else whose names I could not dig out of a database. Your support means a lot. You rock!

(And remember—shameless plug—if you want to see your name here, all it takes is one contribution to improve ScummVM!)

With no further ado, download ScummVM 2.0, our gift from us to you this holiday season.

Release team, signing off until next time!

by snover (nospam@scummvm.org) at December 17, 2017 05:00 PM

November 22, 2017

ScummVM News Headlines

ScummVM 2.0 Release Testing Has Begun

The day has finally arrived to wrap up the current ScummVM release cycle! ScummVM 2.0 is one of our biggest new releases to date and adds support for 23 games:

  • Cranston Manor
  • Full Pipe
  • Gabriel Knight
  • Gabriel Knight 2
  • King's Quest VII
  • King's Questions
  • Leisure Suit Larry 6 (hi-res)
  • Leisure Suit Larry 7
  • Lighthouse
  • Mixed-Up Mother Goose Deluxe
  • Phantasmagoria
  • Phantasmagoria 2
  • Plumbers Don't Wear Ties
  • Police Quest 4
  • RAMA
  • Riven: The Sequel to Myst
  • Shivers
  • Space Quest 6
  • Starship Titanic
  • The Dark Crystal
  • Time Zone
  • Torin's Passage
  • Ulysses and the Golden Fleece

This release also includes significant new enhancements and bug fixes across many engines, so go ahead and play through an old classic you’ve been missing even if it’s not on this list!

Grab a daily build of ScummVM for testing, and make sure to follow our guidelines for release testing. Windows users, please use a Kirben daily build instead of a Buildbot daily build. Report any bugs you encounter to our bug tracker, and once you’ve finished a playthrough, fill out our test results form. You can track testing progress on the wiki as it happens.

Happy gaming!

by snover (nospam@scummvm.org) at November 22, 2017 05:00 PM

November 21, 2017

Thierry Crozat (criezy)

So, when is the supernova going to explode?

With all the progress made on the supernova engine in ScummVM since the last post, I decided it was time to post an update. And in case you can't wait to know the answer to the question asked above, watch the video at the end of this post. But it would be a shame not to read first about the amazing work done lately ;)

Translations

Thanks to the many suggestions from JenniBee, and some help from Joefish who reviewed all the translations for which I had a doubt, the first pass of the translation for the first Mission Supernova game is now completed. And I even had time to do a second pass for the first half of the game while testing the engine, and so improve the translation with the help of the context.

Now what would help the most to get the translation completed is for native English speakers to play the first half of the game and suggest improvements on our translations web site.

We also already have a lot of suggestions for the second game, but it is a bit early for me to review those as I would like to focus on completing the engine for the first game.

As a reminder, the game is available for free on the original developer web site and the source code for the scummvm engine is on GitHub. To play the game you will also need to get the supernova.dat file that contains the game text (both German and English). I have uploaded a version on my dropbox, but you can also compile the devtools/create_supernova tool yourself (available from the same repository as the game engine) and execute it to generate the data file.

Engine

With Strangerke we made a lot of progress on the engine, getting to a point where more than half of the game is fully playable without any major issues, and this includes the supernova explosion! To get to this point, we needed to:
  • Implement the dialog system. In the early game there is no dialog (you will understand why when you play the game), so the dialog system had not been implemented yet. But it was required to progress beyond the first scene where the protagonist meets a fellow creature capable of speech.
  • Implement the event callback mechanism. There are a several events in the game which are on a timer, the supernova explosion being the first of those. I am not a fan of timed event, but it kind of make sense in the context of the game. And we are not going to change the game anyway ;)
  • Fix the graphics pipeline. There was some minor graphic issues, so major ones, and some catastrophic ones (causing a random crash due to out of bound access when trying to access the image at index -1 in the image array).
  • Fix a palette brightness glitch that caused some rooms to be entirely black. This made it quite hard to progress.

The graphics is an interesting aspect, so I will now give a bit more details about that point. It will also give me a good opportunity to add some much needed illustrations to this post. In the supernova engine, images contain multiple layers. The first layer always contain an image for the full screen (minus the inventory area, except for a few images that really are fullscreen) and then additional layers can be displayed or not for example to make animations, or depending on the context (door open or closed, object taken on not by player). Each room has an associated image and an array of boolean that indicates which layers are visible. When we render the room we thus iterates on all the layers and render the visible ones.

During animations though, we only render a layer and all those above it or "unrender them". To unrender a layer, we simply render the room starting from the first layer, for the area previously occupied by the now hidden layer.

The first graphical glitch found was due to setting the layer visibility flag in the wrong place when showing a layer, which caused the flag to be set not only for this layer, but also for all the layers above it. And we ended up with layers drawn in cases where they should not be.

What is this brown thing in the toilets?
Cleaned version.

Another minor issue with similar circumstances is that there was a logic bug that caused a single layer to be drawn in some places without redrawing layers above it.

I also introduced graphic glitches myself when rewriting the code to reduce memory usage. Initially the code had been implemented by using a surface of the full screen size for each layer. But most layers are a lot smaller and I rewrote the code to only use a surface only as big as needed for each layer. I got the surface pitch wrong however in the code bitting the background layer to screen when "unrendering" a layer. That resulted in some interesting animations...

I know he is ugly, but was that a reason to censor his face?
Also, two more hours before what?
Then more recently I stumbled upon a more serious issue that required rewriting a big chunk of the way images were rendered. The issue was that the wrong image was being rendered, and with the way the engine had initially been implemented in ScummVM there was no way to tell the rendering code to use the correct image. This caused the random crash mentioned above (when trying to render image -1), and when the crash did not occur (which happened more often than you might think), an interesting cutscene mixing layers from two images.


Flight cutscene, before and after fix
Rewriting the graphics code to fix this last bug gave me the opportunity to also easily change the way the graphics data are loaded. The initial engine implementation in ScummVM was loading all the graphics data when starting the game. Now they are loaded on demand, which should reduce considerably the memory usage (and speed up a bit engine startup on slow platforms).

Conclusion

And now, finally, enjoy the supernova explosion!
But I won't tell you when it occurs so that you have to watch the full video of me playing the game (but at least I recorded it with the English text and not the original German one, and I slightly edited it to make it a couple of minutes shorter).


by Thierry Crozat (noreply@blogger.com) at November 21, 2017 10:55 PM

October 01, 2017

Thierry Crozat (criezy)

Supernova - translation to English

As you may be aware I was a mentor for the ScummVM organisation for the Google Summer of Code this year. I was supervising the work by Joefish on the Mission Supernova game. The engine has not yet been merged into the main repository, but work is continuing in Joefish's GitHub fork.

At the end of the GSoC coding period the first chapter of the game was completable. However the game is only available in German. One of our aim is not only to make it possible to play this game again on all platforms supported by ScummVM, but also to play it in English. And this is what I have been focussing on in the past week.

I have actually been working on the translation for a while with the help of Joefish. We are using the ScummVM translations website to handle the translation. With previous games when working on a translation we would use more rudimentary tools, such as a shared Google Doc spreadsheet. Thus using our translations website to translate a game is an experiment, but so far I have found it a positive one. And I expect it will also allow participation from the community to complete or improve the translation (this has not been the case yet as we did not advertise this translation until now).

What I was focussing on this week is writing a tool to generate an engine data file, as we do with other engines. Until a few days ago all the text was hardcoded in the engine. But the idea is to have the text in this engine data file instead and to have the engine load all the strings when it starts. This has two main advantages:

  • The strings being into a separate file instead of being in the engine, the ScummVM executable ends up being smaller and using less memory when the engine is not running (for example when playing another game).
  • We can store the strings in several languages in this engine data file and the engine will load the strings for the language selected by the user when the game was added to ScummVM. This means we can provide translations for the game.

    Format of the engine data file

    The data file starts with a 3 byte identifier ('MSN') that can be used to identify the file, and a 1 byte version number so that we can change the format in the future without breaking everything.

    The rest of the file is a collection of blocks, with each block having a 12 byte header and a variable size data section:
     byte 1-4   marker, for example 'TEXT' for the game text
     byte 5-8   language code, for example 'de' for German
     byte 9-12  block data size in byte
     byte 13-N  block data

    This file structure means that we can easily add other types of data in the future if needed, such as the font data (that is currently hardcoded in the engine) or the mouse cursors (also currently hardcoded in the engine). The marker tells us what type of data we will find in a block. Currently the markers used are 'TEXT' (game strings), 'IMG1' and 'IMG2' (for newspaper bitmaps).

    With this file format we can also easily add translations to more languages.  Currently we have data for German and English.

    Generating the engine data file

    The German text is hardcoded in the tool that generates the engine data file. All other data however are provided with supporting files. The tool has a list of languages for which it will look for those supporting files. Currently for each language we can have 3 files:

    • strings-xx.po
    • img1-xx.pbm
    • img2-xx.pbm

    (where 'xx' is a language code)

    For each file found a corresponding data block will be added in the engine data file.

    The strings-xx.po file is typically generated and updated by our translations web site and contains the translation in a given language for each German string. The German strings are defined in a specific order, and when generating the TEXT block for another language the tool iterates on the German strings, for each string looks for a translation in the po file for this language, and if found write this translation and otherwise write the original German string. This means that untranslated text will appear in German when playing.

    The ppm files are bitmap images in portable bitmap format for the two newspaper article images in the game. They can for example be generated with gimp. Other than the header, the ppm format happens to store the data in exactly the same format as the game does for the original bitmaps in German. So the tool simply reads the header to do some sanity checks on  the format and image size and write the rest of the file to the engine data file.

    So adding a new language simply means adding its code to the language array in the tool source code, and dropping some pbm and po files in the directory where we execute the tool.

    I didn't paste any source code in this post, but you can see the source code for the tool here: https://github.com/Joefish/scummvm/tree/supernova/devtools/create_supernova

    Status

    The game contains 655 strings. Currently 281 of those have been moved to the engine data file, and this includes the name and description for all the objects. A lot of strings are still hardcoded in the game engine though, such as all the dialogs, and they will be moved to the engine data file as well eventually.

    The progress on the translation to English is similar, as 279 strings are currently translated, although some of those are for strings that have not yet been moved to the engine data file, and can thus not yet been seen translated in the game.


    by Thierry Crozat (noreply@blogger.com) at October 01, 2017 11:20 PM

    August 29, 2017

    Joseph-Eugene Winzer (Joefish) - GSoC

    Summary of GSoC 2017


    Overview
    During the last three months I have worked on porting the game Mission Supernova to ScummVM, a project aiming to reimplement engines of point and click adventures for cross-platform support.

    For the latest changes, see the commits to my fork.
    Besides porting I also worked on the ScummVM launcher and fixed theme related bugs

    Goals
    The following lists features that are implemented:
    • Image and Text rendering
    • Audio playback of sounds and music
    • Animation system
    • GUI
    • Saving and restoring game state
    • Game logic converted to engine reimplementation

    TODO
    Most crucial engine components work but there is still work left to be done:
    • Translate the remaining strings to English
    • Implement dialog system
    • Fixing pesky bugs
    • Make it all work together in harmony


    While this may be the end of GSoC 2017, my journey has just begun.
    Thanks to everyone involved sharing their knowledge and providing help whenever needed. Also thanks to Google for giving the incentive and exposure to all those incredible projects. The experience of staring at hexdumps, deciphering disassembly and the communal effort has been invaluable to me.
    I will keep contributing to the ScummVM project in the future beyond finishing my project (just you wait, Chewy!) and hope that some of you out there will find entertainment in my work.

    by Joe Winzer (noreply@blogger.com) at August 29, 2017 05:03 AM

    Summary -- Week 11

    SPOILERS IN VIDEO! (0:22 - 0:31)

    As announced last week, the timer bugs are no more!
    The original game used ticks of 18.2Hz instead of milliseconds for example, so while this little helper converted ticks to milliseconds it was not always easy to recognize what number actually represented a time value.
    For instance, I assumed that a variable named time would most likely be the perfect candidate. Oh, how wrong I was. It actually stored the remaining days until the ship arrives at its destination. Do not ask how long it took me to figure this out although comparing time with energy should have made me wary.. (1,2,3)

    Adjusting the brightness of the palette was more an issue of rendering order. While the function worked fine it either did a buffer swap too early or the brightness was restored to its previous state by the following draw call.
    By removing most special cases it not only simplified the function but also fixed most issues. I did a side by side comparison with the original game and couldn't find any difference. (1)

    What was different though is that I couldn't interact with anything in the ship's hold anymore. Apparently it hasn't been working for a while.. Originally an uninitialized object was identified by checking if its name string points to NULL but I misread it as a check if the first char is 0 (empty string). Unfortunately, objects without a name can still be valid what messed up the traversal of objects in a room. (1)

    After running in circles for a while a few important features like RTL and save/load support were implemented. Unfortunately, state serialization still shows puzzling behavior that I haven't figured out how to solve yet. (1,2,3)




    by Joe Winzer (noreply@blogger.com) at August 29, 2017 03:20 AM

    August 28, 2017

    Simei Yin - GSoC

    GSoC 2017 Summary

    GSoC 2017: Sludge Engine

    Summary

    Project description

    During GSoC 2017, I worked for the org ScummVM, which is a program that allows running some classic graphical point-and-click adventure games on multiple platforms (Win, MacOS, Linux, Android, etc.), with game data file provided.

    My project has been importing the Sludge engine into ScummVM and adding full support at least for the game Out Of Order. At the start, I had Sludge engine source code as base to work on, which is an open source project licensed under GNU LGPL version 2.1.

    Goals achieved

    Now I’d like to make a summary of what I’ve achieved:

    1. Sludge engine

    Sludge engine has largely been imported into ScummVM now with capability to run the games below:

    • Out of Order
    • Frasse and the Peas of Kejick
    • The Interview
    • Life Flashed By
    • The Game That Takes Place on a Cruise Ship
    • Cubert Badbone, P.I.
    • Robin’s Rescue (Tutorial game for sludge engine)

    I tested the game Out Of Order from the beginning to the end and the first scenes in other games. There doesn’t seem to be serious problems.

    2. Other features

      1. CMD :
        • As the entry barrier for GSoC program, I made a PR for the command line to get games detected and added. This feature has been polished and enriched by two other summvm members criezy and tobiatesan later.
      2. GRAPHICS :
        • I added Multiply blend mode for Transparent Surface: PR.
        • I fixed a minor bug about off-screen clipping handling for Transparent Surface : PR
      3. IMAGE :
        • I made a small modification to make it possible to write png from surfaces of 4-byte pixel format : commit 1 2

    Future work

        • Unimported Sludge features :
          • Play movie
          • Color transition animation
        • Continue to track down game bugs
        • Code objectifying for sludge
        • I’m still working on adding support for .mod .s3m and .xm tracker sounds in my own fork.

    Code

    The code for sludge engine is in an individual folder in the repo:

    https://github.com/scummvm/scummvm/tree/master/engines/sludge

    The commits that I made :

    https://github.com/scummvm/scummvm/commits?author=yinsimei

    by yinsimei at August 28, 2017 05:44 PM

    August 25, 2017

    Joseph-Eugene Winzer (Joefish) - GSoC

    Summary -- Week 10


    • The biggest change this week was fixing the terminal next to the sleeping pods and the clearing of previous input. (1,2)
    • Also, the game text was converted to it's original encoding (CP437) to correctly render special characters. (1
    • A long standing rendering bug that caused certain sprites not to be rendered was finally found and fixed. (1)

    There were a few smaller commits that will help to finally fix timing issues and a few rendering problems with dimming the ship's light next week.

    by Joe Winzer (noreply@blogger.com) at August 25, 2017 03:25 PM

    August 20, 2017

    Simei Yin - GSoC

    GSoC Week 12

    GSoC 2017: Sludge Engine Week 12

    Week task conclusion

    Generally, this week is still focused on bug fixing and primary study of sound decoder.

    Again, thanks to my mentors _sev(Eugene Sandulenko), t0by(Tobia Tesan) and all scummvm team members that has helped me during this week.

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

    1. Bugs Fixed :
      1. Sprite darkness level bug
      2. Save&load looping sound bug
      3. zBuffer bug when burn sprites to backdrop
    2. A local branch in my fork for sound decoder has been created

    As for the sound decoder, we’ve decided to use the the library micromod for it, which is a library including a converter from s3m, mod, xm to wav format. We find it impressive for its size and its capability to create a common loading structure for all three formats.

    (Link to the repo on github : https://github.com/martincameron/micromod)

     

    What’s for next week: Importing micromod sound decoders & Bug fixing

    Tasks for next week :

    1. Import the micromod sound decoder into scummvm
    2. make the 3 win-only games work

    by yinsimei at August 20, 2017 11:15 AM

    August 13, 2017

    Joseph-Eugene Winzer (Joefish) - GSoC

    Summary -- Week 9



    The remaining game logic has been implemented with a few exceptions but still needs to be thoroughly tested. (1, 2)
    Speaking of testing, there are still bugs in the first act that need to be ironed out before a pull request can be issued like rendering artifacts and problems with the terminal next to the sleeping pods.

    For next week, it is planned to fix up act 1 and to finish implementing the dialog system as the second and third act are now available for testing. 

    by Joe Winzer (noreply@blogger.com) at August 13, 2017 08:10 PM

    Simei Yin - GSoC

    GSoC Week 11

    GSoC 2017: Sludge Engine Week 11

    Week task conclusion

    Generally, this week is focused on further bug fixing for the game Out Of Order and we are able to play from the begin to the end now.

    Again, thanks to my mentors _sev(Eugene Sandulenko), t0by(Tobia Tesan) and all scummvm team members that has helped me during this week.

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

    1. Bugs Fixed :
      1. Sprite depth
      2. Add thumbnail
      3. Save & load interface
        1. Add thumbnail
        2. Add saved file list
    2. Lightmap: 1 2 3
    3. Multiply blend mode for transparent surface

    Things not achieved yet:

    1. Bugs left to be solved:
      1. Sometimes the menu can’t be called out by esc. This can be solved by restarting scummvm. Not sure when this bug will occur yet.
      2. The character sprite can be too dark sometimes.
      3. Save&Load game can cause some loop sound that shouldn’t be played there played
      4. When the credits show in the end, the zBuffer of the last scene remain
      5. At the beginning of the game, there is a moment the zbuffer doesn’t work. Don’t know why it is.
    2. The end of the game Out Of Order contains a short movie, so we’ll also need to see how to play it in scummvm
    3. By the way, the parallex is not used anywhere in any game. So I think it’s not necessary to implement it now.
    4. Still don’t know why the windows-only games don’t work.

    What’s for next week: XM, IT, S3M Sound decoders

    Tasks for next week :

    1. Fix the bugs that remain
    2. XM, IT, S3M sound decoders

    by yinsimei at August 13, 2017 03:20 AM

    August 08, 2017

    Arnaud Boutonné (Strangerke)

    Kingdom on hold

    I've finally reversed the whole hardcoded logic again for the demo (because BinDiff wasn't able to handle small changes in giant functions). The positive part of that is that it made me point some small bugs I fixed in the full version.

    At this point, the engine is only missing the MVE video player. I don't think I'm able to handle that myself despite TMM pushed the missing opcodes in ffmpeg. So, the engine is on hold undefinitely (at least until someone is willing to help me with that player).

    I'm still tossing a coin to decide what I'll work on next.

    by Arnaud Boutonné (noreply@blogger.com) at August 08, 2017 07:15 AM

    August 05, 2017

    Simei Yin - GSoC

    GSoC Week 10

    GSoC 2017: Sludge Engine Week 10

    Week task conclusion

    Since I didn’t have time to work on Sludge last week, I make this week the 10th week of GSoC Generally, this week is focused on bug tracking for the game Out Of Order. As the objectifying took longer than planned, we decided to back to it when we have time later and concentrate on bug fixing.

    Again, thanks to my mentors _sev(Eugene Sandulenko), t0by(Tobia Tesan) and all scummvm team members that has helped me during this week.

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

    1. Bug Fixing
      1. Backdrop bug :
        1. Clear screen
        2. Fix backdrop loading
        3. Fix crash when loading game
      2. zBuffer :
        1. zBuffer order bug
        2. Reset zBuffers when blank back drop
      3. Fix Off-screen cliping handling for Transparent Surface (in PR at present)
      4. Others :
        1. Quit game buit-in
        2. Correct pixel format for png writing
    2. New game situations :
      1. Out Of Order : Bugs concerning backdrop and z-Buffers are fixed
      2. The Interview : The crashing bug has been fixed with the update
      3. Life Flashes By: The bug concerning save & load file detection is unsolved, as it is not related to the built-in function FileExists as I expected. So still need to track down this problem.

    What’s for next week: Bug fixing & Lightmap & Parallax

    Tasks for next week :

    1. Test Out Of Order thoroughly and fix the bugs that remain
    2. Test other games and track bugs
    3. Add lightmap shader effect to sprite displaying
    4. Test and add parallax in Out Of Order (haven’t seen it in Out Of Order till now, maybe it is used in the scenes later)
    5. If time permits, try to figure out why the windows game doesn’t work. This may be something convoluted, the reason is still unknown

    And for the week after the next, we will focus on making the decoder for multi-track sounds

    by yinsimei at August 05, 2017 07:08 PM

    July 03, 2017

    Arnaud Boutonné (Strangerke)

    Kingdom - Day 22

    1 week has passed... Here are the most noticeable changes in the code since the last post:
    - Implement PlaySound
    - Add code for savegames
    - Implement the timers
    - Implement SaveAS and RestoreAS which are used to save/restore parts of the screen when switching to/from some specific game areas (inventory, map...)

    At this point, there's only 1 function which is still stubbed, used for displaying some icons (I'll look at it this evening most likely). As soon as the video player will be implemented, I'll start a playthrough to see if there are bugs in the hardcoded logic. I expect some in the first group, as it was the first one I reversed.

    Special thanks to waltervn and to SylvainTV for their help on the timers and the weird way it's hooked in the original on int 8h

    (and sorry, no fancy screenshot this time again...) :)

    by Arnaud Boutonné (noreply@blogger.com) at July 03, 2017 11:24 AM

    June 26, 2017

    Arnaud Boutonné (Strangerke)

    Kingdom - Day 15

    Another milestone has been reached! After only 15 days of development, the engine contains now the complete hardcoded logic of the DOS version. We still have to compare it to the DOS Demo version, and we expect differences of course... but still, it's an important milestone for this little project :)

    The map input has been implemented too, which means the game is now somewhat playable without videos and sound. Yes, it's a bit annoying for a FMV game, but we're working on that :P

    Expect more news soon, with new screenshots this time!


    by Arnaud Boutonné (noreply@blogger.com) at June 26, 2017 09:22 AM

    June 20, 2017

    Arnaud Boutonné (Strangerke)

    Another milestone reached

    The past week has been spent on stabilizing the current code (on my side) and on contributing a patch to ffpmeg so it handles correctly the previously undocumented opcodes we encountered (that's for TMM). I also spent some energy on the user input, which is composed of several large hardcoded logic functions. After a couple of fixes this morning, a step has been reached: the game starts (no video player nor sound yet).

    Main Menu:


    First screen of the game:


    Hopefully we'll have soon another milestone to announce! :)

    by Arnaud Boutonné (noreply@blogger.com) at June 20, 2017 01:01 PM

    May 29, 2017

    Thierry Crozat (criezy)

    Mission Supernova - A look at the music

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

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

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

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


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

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

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

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

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

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

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

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

    Here is a description of the MOD file header:


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




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

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

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

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

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

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

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

    The final source code is available at https://github.com/criezy/scummvm-tools/tree/supernova/engines/supernova. At some point I might merge it in the main ScummVM repository.

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

    Mission Supernova part 1 music

    Mission Supernova part 2 music


    by Thierry Crozat (noreply@blogger.com) at May 29, 2017 04:32 PM

    March 10, 2017

    Alexander Tkachev (Tkachov)

    GSoC: ScummVM site new look

    I've posted this picture on IRC yesterday:

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

    Making of logotype & color scheme

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

    So, let's try designing a logotype!

    Step 0. Open an editor.

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

    Looks good for me!

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

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

    Not really better.

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

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

    by Tkachov at March 10, 2017 09:00 PM

     

    curved edge   curved edge