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.

October 10, 2017

ScummVM News Headlines

Three new games about aliens

Go to an alien world, go to an alien world on an alien spaceship, or gehe zu einem fremden Raumschiff (go to an alien spaceship)! There are three alien worlds to choose from in our newest batch of adventures, now ready for testing in the latest daily build of ScummVM:

The Datafiles page has been updated with instructions on how to install these games. If you don’t own one, go to our where to get the games page to buy them!

Before you start your test run, for Lighthouse and RAMA, please read the instructions on our SCI testing page, and take some screenshots along the way. For Starship Titanic German, you’ll need an extra required titanic.dat file, which should be put in the same folder you copy your game files to.

Please keep in mind for Starship Titanic German that we're not all German speakers, so bug reports will need to be in English. Also, if any bugs you find involve text that's entered in the conversation tab to one of the bots, it will make things easier if you can replicate the problem using words that don't include letters outside of the English alphabet.

Have fun!

by snover (nospam@scummvm.org) at October 10, 2017 01:00 AM

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

    August 01, 2017

    ScummVM News Headlines

    You're gonna need a SCI-cologist!

    Go on a cruise, sort out some mixed-up nursery rhymes, or spend some time in a mental ward! The second batch of 32-bit DOS/Windows Sierra adventures are now ready to be tested in the latest daily build of ScummVM:

    The Datafiles page has been updated with instructions on how to install these games. If you don’t own some, go to our where to get the games page to buy them!

    Before you start your test run, please read the instructions on our SCI testing page, and take some screenshots along the way.

    Have fun!

    by snover (nospam@scummvm.org) at August 01, 2017 01:00 AM

    July 31, 2017

    ScummVM News Headlines

    Defeat the ruler of the Fifth Age

    Right after the ending of Myst, you are promptly sent to another Age by Atrus, where his wife Catherine is stranded. Riven is the fifth Age written by Atrus' father, Gehn, which he rules as a cruel self-proclaimed god. Your dual mission is to rescue Catherine and imprison Gehn. To be successful you will have to carefully explore the five islands of Riven and solve the intricate puzzles they hide.

    The ScummVM team is proud to announce that Riven: The Sequel to Myst is finally ready for its testing period. If you want to help with the tests, use the latest daily build of ScummVM to play the Windows or Mac version of the game. Please report the issues you encounter on our bug tracker. Be sure to follow our testing and bug reporting guidelines.

    As a warm up before playing Riven, you may want to play Myst. If you do so, please use a daily build of ScummVM. Major changes were made to the game engine to remove situations where the game feels unresponsive. Some bugs may have escaped our attention. As with Riven, please report the issues you notice during your play-through.

    by bgK (nospam@scummvm.org) at July 31, 2017 01:00 AM

    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

    July 02, 2017

    ScummVM News Headlines

    Trapped on a luxury cruise ship.. In Space!

    Explore a broken-down luxury cruise liner, try to convince the Deskbot to give you an upgrade, and eventually track down and fix the ship's governing computer, Titania. Or you're never going to get home. We're pleased to announce the testing period for the late '90s game Starship Titanic. At this time, only the English version is ready for testing. So break out your copy, and grab the latest daily build of ScummVM. You'll also need an extra required titanic.dat file, which should be put in the same folder you copy your game files to.

    Before you start your test run, please be aware there is one specific kind of Indeo encoded AVI video we haven't yet figured out how to decode transparency information for. In a few areas, such as the SGT Stateroom and Titania's closeup, amongst others, you'll see objects with jagged black areas around them. Please just ignore the problem for now. But all other graphics or gameplay issues should be reported on our Issue Tracker.

    by Dreammaster (nospam@scummvm.org) at July 02, 2017 01:00 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

    June 11, 2017

    Paul Gilbert (Dreammaster)

    The player is finally home.. the long way round

    It's taken so many nights spent slowly debugging the original executable versus my ScummVM implementation, but the final starfield puzzle of Starship Titanic is finally working.

    I'm not 100% happy with how the starfield rotates to selected markers when you've locked them in, but frankly, given that I've spent multiple months on disassembling, implementing, and fixing just this one puzzle, I'm just happy at this point that it works at all.

    So now with the starfield puzzle finally completable, I was able to initiate the endgame, and see the ending video and credits:
    I have to say, there were times when I grew weary of implementing and testing all the matrix code that the puzzle required. But I guess I'm just too stubborn not to see it all the way through.

    So what's happening next? Firstly, there are various minor bugs that I was aware of, but hadn't previously gotten around to fixing. I'm currently working into fixing them now For example, I fixed some jerking of text in the end credits, and some black boxes that briefly appeared over the flames in the canal. I've got some outstanding issues with NPC idle animations to look into. The Bellbot also won't currently bugger off if you tell him goodbye :) Once that's done, I'll give it another playthrough just to make sure before it's announced for public testing. So expect it to be soon. For those of you that don't have the game already, the current GOG sale has it discounted. So it's a very opportune time to pick it up.

    On a final note, there are couple of things associated with the game that I don't have any immediate plans to spend time on:
    * The QSound library the game uses for simulating sounds in a 3D space using standard stereo output. Many know my distaste of working sound code. So I'll leave it as a future exercise for someone else to work on. I've implemented the low level sound calls using mostly the same interface as QSound exposes, so it should prove convenient for anyone who chooses to do so
    * The Indeo 4 decoder still doesn't handle cases where transparency information is embedded directly into the video frames, rather than as a separate video track. Since codecs are installed directly into Windows, I'm not even sure which DLL implements the decoder. I'll try and spend a bit of time trying to figure it out, but worst case, it may be something the game just has to live with. The game currently has "best guess" code that estimates what the transparencies should be. It's not perfect, but it's reasonably servicable for now.
    * I don't have any near-term plans to do any further work on the German version. I'm simply too burned out over the game, and want to move on from it. I may return to it one day; I'd also welcome anyone else who wants to look into it themselves.

    DreamMaster.



    by Dreammaster (noreply@blogger.com) at June 11, 2017 10:26 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

    March 07, 2017

    ResidualVM News Headlines

    Welcome to Google Summer of Code 2017

    GSoC 2017 Logo

    We are happy to announce that we are participating in this year's Google Summer of Code under the umbrella of our sister project ScummVM.

    Have a look at the list of ideas or bring your own idea!

    If you want to participate or have questions about GSoC, come talk to us on IRC Freenode channels #residualvm or #scummvm.

    by aquadran (nospam@residualvm.org) at March 07, 2017 12:00 AM

    February 28, 2017

    Alexander Tkachev (Tkachov)

    GSoC: ScummVM new look (idea)

    Recently I've thought to try designing a new fresh look for ScummVM. This is what I came up with:

    As you might've noticed, it's a little bit inspired by Steam: games listed on the left and current game displayed on the right. Saves are available right from the very first screen.

    Options dialog stayed pretty much the same, but tabs are replaced with a list. That allows to add more tabs without any scrolling and makes it look similar to main screen.

    I was unable to add the familiar orange color into this scheme without ruining it, so I replaced it with pale green. The whole look is kind of minimalistic: no gradients, borders, rounded angles and such. The similar approach could be used to redesign ScummVM site.

    These sketches show a 1024x768 desktop look, while not doing anything about platforms with smaller resolutions. I think it's OK to go with a simple skin for those, meaning the layout stays the same and only the colors/fonts/images change.

    I worked with ScummVM GUI system, so AFAIK it wouldn't be too hard to change those layouts to correspond these sketches. That couldn't be achieved with a simple skin, because some minor changes needed to place saves dialog in main dialog or to replace tabs with a list.

    P.S. It's not about GSoC, but my site is configured to show only those posts which has "GSoC" prefix in the RSS feed Planet is aggregating.

    by Tkachov at February 28, 2017 09:00 PM

    November 24, 2016

    Sven Hesse (DrMcCoy)

    xoreos Not-Thanksgiving 2016

    xoreos is a FLOSS project aiming to reimplement BioWare’s Aurora engine (and derivatives), covering their games starting with Neverwinter Nights and potentially up to Dragon Age II. This post gives a short update on the current progress.

    Note: This is a cross-post of a news item on the xoreos website.

    And again a year is nearing its end. Like last year and the year before, I’d like to turn my gaze inwards.

    A lot of things happened with xoreos this past year, albeit most of them hidden and “under the hood”:

    • I wrote about disassembling NWScript bytecode. The tasks I mentioned there are still open, too. If anybody wants to take them up, I’d be happy to explain them in more detail :).
    • We released xoreos 0.0.4, nicknamed “Chodo”. That was the only release of xoreos in 2016. xoreos 0.0.4 included some minor fixes and features for Neverwinter Nights, and the xoreos-tools package included the new NWScript disassembler.
    • In April, I reached a streak of a full year of daily xoreos commits. Due to some real life things, I had to take a break there, though. I’m now again at three months of daily commits, but there is a three-month “hole” between April and August.
    GitHub contribution graph in April

    GitHub contribution graph in April

     

    GitHub contribution graph in November

    GitHub contribution graph in November

    • Farmboy0 fleshed out the Jade Empire engine a bit, mostly in the scripts department.
    • Supermanu implemented a huge chunk of the character generator for Neverwinter Nights.
    • Farmboy0 fixed a glitch in the Neverwinter Nights animation system that has plagued xoreos for quite some time: the animation scaling in various creature models was off. This lead to, for example, the head and arms of elves detaching from the body during the yawn animation.
    • I then implemented a few more animation script functions, too, which is especially noticeable in the intro animation for Hordes of the Underdark. I also fixed a mistake in the keyframe interpolation. This takes care of another glitch in Neverwinter Nights: model nodes rotating the wrong way around.
    • smbas added support for Lua scripts in The Witcher. A lot of the initialization code that sets up the classes and functions The Witcher expects to find is still missing, so nothing obvious is visible as of yet.
    • Farmboy0 moved the window handling from the GraphicsManager into a new WindowManager class, making the code more readable.
    • I fundamentally restructured our build system, or at least the autotools part of it (xoreos can be built using either autotools or CMake). Previously, we used a recursive autotools setup, where make recurses into each subdirectory. This is, unfortunately, pretty slow, among other drawbacks. I changed it to be non-recursive now, with the top-level Makefile instead being created using (recursive) includes.
    • I then introduced various smart pointer templates into the codebase, making it easier to read and easier to keep track of memory allocations.
    • berenm added AppVeyor integration. Like Travis CI (which we already use as well), AppVeyor is a continuous integration service. This means that every single commit to the public xoreos repository will now be built on Microsoft Windows, using Microsoft Visual Studio 2015, in addition to gcc and clang on GNU/Linux (via Travis CI). This ensures that any compilation breakage on these systems is immediately visible and can be fixed at once.
    • GitHub added a new feature, “Projects”, that provide Kanban-like boards of tasks. I took the time to fill the xoreos Projects page with boards for tasks from our TODO list.
    • There were of course also various clean-ups, minor fixes and expanded code documentation.
    Animation with glitch

    Animation with glitch

    Animation without glitch

    Animation without glitch

    Animations in the HotU intro

    Animations in the HotU intro

    Additionally, there are several tasks currently being worked on, among them:

    • Supermanu is looking into pathfinding.
    • mirv is still working on rewriting the OpenGL renderer.
    • I am currently writing unit tests for the xoreos codebase, using Google Test. I already found multiple issues, bugs, and corner cases while adding them.

    From my side of things, my current plan is to make my unit tests branch public some time in December. I’ll write a small announcement here about it then. A new release of xoreos, 0.0.5, should follow early next year.

    As always, this all wouldn’t have been possible without a lot of people. For them I am thankful.

    • Farmboy0, for various fixes, implementations and file format spelunking.
    • Supermanu, for his character generator work and pathfinding research.
    • mirv, for continuing to work on the OpenGL rewrite.
    • smbas, for his work on Lua and The Witcher.
    • berenm, for the AppVeyor integration and CMake knowledge.
    • TC01, for writing a Fedora specfile for the xoreos projects.
    • CromFr, for taking a stab at the walkmesh structure in NWN2’s TRN files.
    • clone2727, for invaluable ideas and corrections.
    • The folks at GamingOnLinux, who continue to be a great resource for all things related to Games on Linux.

    I am also thankful for all the people who take the time to explain things to others, people who write interesting, useful or needed articles, and people who provide mentoring and help. Relatedly: a week ago, Stephanie Hurlburt published an article with engineers who are willing to mentor or answer programming/engineering questions. I for one think that’s a really great idea. Please take a look at that article.

    And now, let’s see what the next year has in store for us. If you, however, found all this terribly interesting and would like to help with our little project, then please, feel free to contact us! 🙂

    flattr this!

    by DrMcCoy at November 24, 2016 05:31 PM

    November 04, 2016

    Paul Gilbert (Dreammaster)

    There's been a Titanic amount of progress

    Since my prior posting earlier in the year, there's been a great deal of progress in Starship Titanic. I decided to put aside the problem of reverse engineering all the Star Map classes until I had the rest of the game working better. In that respect, I've made great strides since, as of last weekend, I was able to complete the entire "prologue" of the game  That included using the computer, experience the crash, talking to the Doorbot, entering the ship, and viewing the Credits. Huzzah. \o/

    I was going to prepare a video showing the intro, but with the most recent changes, there seems to be some instability showing up. It seems like something that was already present, just coincidental that the newer changes result in more frequent crashes. It's kind of hard to narrow down the cause, as there's also a problem with the implementation of the Indeo video decoder we're using for NPC videos like for the Doorbot, where it's reading past the end of the frame data. So it's difficult to track down the memory corruption, as warnings about the decoder are completely overwhelming everything else.

    So for now, I'll present a screenshot of the amazing multi-color Doorbot :)



    After thinking over matters, I've decided to keep progressing into the game, and come back to look at the problem later on. Part of the trouble I'd been having with the code was the sheer length of the intro as I got further and further into it.. requiring me to wait through several minutes of cutscene & conversation every time I made any changes or bugfixes. Even if the intro has suddenly become unstable, I still have savegames I made from beyond it, so I'm using them as a starting point to make further progress testing into the game.

    Speaking of testing, I've had a major boon to my efforts to track down bugs in the code. I was previously stymied trying to test the original Windows executable in the IDA debugger, since it kept crashing on me. Plus running in compatibility mode full-screen didn't help either. And without the ability to see "valid" values in the original executable, I anticipated it would be difficult to track down errors in my code, since I wouldn't know whether values/state at any point in time were already wrong on not.

    Luckily, though, I stumbled on a solution. Using the Visual Studio "Attach to Process" allowed me to attach to the game executable without it crashing, unlike IDA. At least, for the majority of the time. Though switching from the game to the debugger and back again caused severe corruption of the full-screen display. Luckily, though, there had been some previous discussions about running the game in a window - I was able to use a utility called DXWnd that intercepted the game's DirectX calls and forced it to run a window. The result wasn't perfect, in my opinion, for anyone wanting to play through the game, but it's worked well enough for my purposes, in conjunction with Visual Studio.

    As a result, I'm now making much better progress than I had anticipated, and hunting down bugs is in general much easier than I'd anticipated. Let's hope that stays the case.. my next major gameplay milestone is to complete more extensive conversation with the Deskbot to get myself a room. The basic yes/no detection for the Doorbot worked pretty smoothly first time I tried it. The Deskbot, though, is using more of the conversation parser - I've already located and fixed some problems with it. Let's hope that there won't end up being too many.

    On a final note, the one downside of my surging progress with Titanic is that I'm currently spending less time working on finishing my Xeen engine. I'd originally anticipated the frequent roadblocks trying to hunt down bugs in Titanic would have me growling in frustration, and switching to Xeen for awhile to unwind a bit. Now with the ability to debug the original executable, that hasn't really happened so far, and hopefully won't happen. I'll probably end up spending more time right now focused solely on Titanic, and see if I can't get the bulk of the game with the exception of the final starmap working by the end of the year. Then I'll be in a better position to alternate between working on Xeen and trying to disassemble the remainder of the Starmap classes.

    DreamMaster.

    by Dreammaster (noreply@blogger.com) at November 04, 2016 05:11 PM

    August 24, 2016

    Bendegúz Nagy (WinterGrascph)

    Alas, the end

    And so it has come to this, all things must end. But it is nothing to be sad about for me, this has been a great addition to my experiences and I welcome the change for it has been something short of 3 and a half months that I've been working on DM. Not that I won't be working on it from now on, but I'm definitely taking a few days off, lest I come to dislike it for looking at the codebase for too long.

    The pull request to merge the engine is due next week as it still doesn't compile with GCC (strangerke has been working on it relentlessly (think 127kbs of error log reduced to 9)). Relatedly, the code is not particularly compliant with the coding conventions at ScummVM (strangerke is working on it, I'll soon start feeling ashamed and will have no choice but to help him).

    As for the future of this blog, it is possible that I will post updates for when something major gets incorporated into the engine (think support for other versions).

    Almost forgot about the new stuff, if I remember correctly it's convenient loading/saving from the launcher and from the inventory. And also there are debugger commands like godmode, noclip, set pos/map and the aptly named, gimme, which spawns items. Entering the commands without arguments will output their usage, call 'help' for a list of them.

    Gimme can be used like this: call 'listItems', if you are looking for something enter any part of it in caps like this 'listItems OF FEAR'. Once you found what you are looking for, call gimme with its name: 'gimme HORN OF FEAR'.

    Setting the map is slightly broken. For best results, teleport to an adjacent map, then use pos to set your position next to some stairs and off you go. Avoid using noclip.

    PS.: So long, and thanks for all the fish

    by Bendegúz Nagy (noreply@blogger.com) at August 24, 2016 08:34 AM

     

    curved edge   curved edge