I’m so happy to receive the letter of completion for GSoC 2021. If you have been following and replying to my PRs & messages, thank you so much for supporting me through the process.

The past week has been for something else. Hopefully tomorrow is another new day & start for working on TTS.

Time to put all the work in one place! ✊

Requirements from GSoC goes like this (only relevant guidelines are shown)

• It must be easy to identify the work you have done.
  
• Someone else should be able to use the content at (or referenced from) the target of the link to extend your work.
  • If your work is 100% complete, they should be able to use it.
  • If your work is not 100% complete, it should be clear what’s left to do

✅ My work consists of multiple independent small projects. I will present the ones that are fully functioning with links to their PR, and todos plus progress of those that are not

✅ All the changes are put together as pull requests

All the PRs can be found here

They are ranked by the order I started working on

GRIFFON: Text To Speech (TTS) for the Game #2912

#Merged April 4 – Jun 9 Most were done before coding phase

https://github.com/scummvm/scummvm/pull/2912

DREAMWEB: Text To Speech (TTS) for the game #3048

#Ready to Merge

https://github.com/scummvm/scummvm/pull/3048

SCI: Text To Speech (TTS) for Laurabow2 and Castle of Dr. Brain #3256

#More Requests

The TTS functions work, but it is requested to be done a different way

https://github.com/scummvm/scummvm/pull/3256

CGE: Text To Speech (TTS) for the Soltys Game #3155

#Merged

https://github.com/scummvm/scummvm/pull/3155

CGE: Change declaration place and descriptions #3177

#Merged

https://github.com/scummvm/scummvm/pull/3177

CGE2: Text To Speech (TTS) for the Sfinx Game #3156

#Merged

https://github.com/scummvm/scummvm/pull/3156

SUPERNOVA: Text To Speech (TTS) for the game #3267

#Ready to Merge

Aug 12 – Aug

https://github.com/scummvm/scummvm/pull/3267

👀 Comparing with initial proposal

In the initial proposal there are 4 games and 3 demos, plus an extra stretch goal to make the options more accessible.

I have 4 games that are merged or ready for merge, and 2 games plus 2 demos that are working but needs a better way to implement it and other function checks.

2 of the games that can be merged didn’t belong in the proposal, but engines that are easier and would benefit more from the feature (Supernova 1 & 2, CGE2), so we did it.

For the things that are proposed but not finished or mentioned above:

• 1 demo: Because it was difficult in its nature (LB1 demo)
• 2 games: One of the games (Sword) have speech already (the version I played before the coding period didn’t have speech). The other was not done simply because I had problem playing it for some time. So to maximize the number of games done, I switched to doing TTS for other games.
• Stretch goal: It isn’t touched, but I’ve checked and it turns out that in order to enable TTS, one can also just use the GUI option that is included in the project, and they will never have to deal with the initial problem I proposed.

📖 Overview of progress

🔥Apr – May Proposal Stage. Started Griffon PR

At this stage, I started working on giving Griffon text to speech, opening a PR and writing the project proposal. Although I have not been admitted to the program yet, the experience I have already had isn’t something easily taken for granted.

We had speech for the opening story and in game options, but in a rough way that was worked on much more afterwards.

🏃🏻May – Jun Student List Announced. Continue with Griffon and Starting Engines in the Proposal

After the proposal stage, I continued working on Griffon, and eventually Dreamweb. Griffon got merged on the first day of the coding period.

I think it would have been a better idea to raise the question about the project scope and directly discuss with my mentors. Well but you never know…or do you?

🧗🏻‍♂️Jun – July Everything “seemed” to be on schedule, even ahead of schedule, if not thinking about wrapping up

According to the proposal, Dreamweb only needs to finish the narrator part in June. However upon realizing that it makes more sense to work on one engine at a time, I proceeded to do TTS for the navigator (scheduled in August). I stopped only when there was a bug (one tts interrupting another, resulting in a tts not working, we didn’t know the cause) that wasn’t solved over a month later.

Although deep down I know that there’s still a lot waiting for me to wrap up, the first week’s progress seemed to have went well, even passing with flying colors. At least I’ve completed the face value of things.

On the following 3 weeks I was suppose to work on Laurabow2, Castle of Dr. Brain, and Laurabow1. Their code was challenging in the size of its code and complexity, but after wiggling around I was able to find lots of places that had text.

I also realized that the 3 games were all ran by the same engine (SCI), so it makes a lot of sense to extend the project scope to not only giving TTS to the demo, but also the games.

However I know that there are lots of corners (or new worlds) that is not done with TTS. So I paused after getting Laurabow2 and Castle of Dr.Brain to work, and leaving Laurabow1 with its problems (speech continuing after text box vanishes)

Bearing this in mind, I started doing CGE earlier. It was a much easier TTS task, and I felt very happy about having the experience with SCI, because of that engine I was able to take CGE as an easy task.

Meanwhile, dreamweb got its breakthrough, and the functions were done eventually.

🚵🏻‍♀️July – Aug Dreamweb & SCI both takes time to wrap up. Opening new games to try maximize number of games with TTS

CGE2 is added to the project scope because it was a lot like CGE. The difficulty was also similar. Although there was trouble during the process, they eventually became the first to games to get merged.

We had a discussion over combining all the TTS code in dreamweb to one function in dreamweb.cpp. This task started and then stopped because I couldn’t find a simpler way to do that.

Later on after getting in touch with SCI engine developers, I realized that that the barriers in Laurabow1 can’t be overcame. So I started wrapping up to created the PR for SCI.

At the same time, I decided to do TTS for more games, and ended up making changes to Beneath A Steal Sky, Dragon History, and Supernova (1 & 2), for which the third became successful with getting TTS.

Dreamweb got wrapped up around the same time as Supernova.

On the SCI side, we needed things to be more tidy, so the next thing is to combine all TTS features to a new class.

🧘🏼 Reflections

1. I though that it would take up less and less time to teach me

I really wanted every time I learn something to be sort of an investment, and one day I would be able to do everything without facing big problems

What happens though is that I get faster at making progress, and we see new things in new engines, so the amount of reaching out doesn’t decrease significantly 😅

2. A big thing that’s holding me back is myself.

Getting into work mode is like going to the gym, or getting up with an alarm. It’s so easy to give up.

Sometimes I get a lot done, and the happiness with last through what’s left of the day. Accomplishments, however, can never be foreseen, and it does take practice to convince the brain to sit down, concentrate, and put in the hours.

Surprisingly, it has been easier to calm myself to work than it was before. Probably because my strategy is that I would book the same time everyday for doing this project. Eventually, other alarms in life don’t try to compete my attention with TTS reserved time.

This is something really valuable, and I plan continue to work like this for a while, to better make sure I will finish this.

3. Accepting software development as an IQ test may not be the best attitude

Lot’s of times I try to figure out things by basing on what I know about C++, and thinking what it does, and testing it to see how it behaves. Only during the last week did I try to pick up a book and try to build a better picture.

Nevertheless, it has been quite an experience. It’s challenging and makes me a braver person than I usually am.

🙏🏻 Thank You

It would not have been possible if not for the mentorship I’ve received. Thank you to all the developers that have helped me out with all the problems and reviewed my code.

Whole-hearted thanks to my mentor criezy, who made the 5 months here a rewarding journey that is not lonely; my mentor Kesha, who has spent time guiding me on dreamweb and other games. I had the best time possible while working with my mentors.

I’m also extremely grateful to sev, who is my superman and enlightener, and every developer that has shared their time and attention with me, sluicebox, bluegr, mgerhardy, lephilousophe, felsqualle, frac, Strangerke, SupSuper, and ZvikaZ.

Thank you for reading this blog and visiting the gsoc-t-tts channel, too.

This is my last summer project as an undergrad (or even as a student), and I will remember it.

I took up the task of developing a grid based GUI for displaying games for ScummVM as my GSoC ’21 project.

Work done

All of the weekly progress reports are available on my blog [https://blogs.scummvm.org/av-dx], the single PR (237 commits) containing my work is linked here [https://github.com/scummvm/scummvm/pull/3135]. In this post, I will provide a summary of the work done, and what is the state of the Launcher as of this PR.

Themes

All of the themes have been upgraded appropriately to include the information for the grid and grouping, and include a special low-res variant of the grid display to maximize space efficiency.

Grouped List [Launcher : List View]

The Launcher has an addition to the list view, by providing a grouping option, to group entries on fields which are read in from metadata XML files.

The groups are drawn as group headers with a different formatting, and can be folded or expanded by clicking on them. A triangle icon indicates the status of the group.

There are several fields to set the grouping field, namely “Engine”, “Series”, “Publisher”, “First Letter”, “Language”, and “Platform”.

Grid Widget [Launcher : Grid View]

The main focus of this project, I have implemented a grid widget to display the games with their game icon, language and platform as well.

Several aspects of the grid are customizable through the theme files, including the spacing, background color of the thumbnails, flag and platform icon size, whether or not titles are visible under the entry, and the grid can even be turned off entirely through the theme, if so desired.

The icons are distributed in a .zip file (which one can obtain from my previous post). If the user does not have the icon available for a game, a placeholder containing the title is displayed instead.

There are two buttons to switch between the list and the grid views. The Grid view is only enabled on supporting devices, and can be manually turned off from compilation in the build configuration.

The grid supports the same grouping methods as the list.

You may notice the absence of Start Game, Edit Game and Load Game buttons from the launcher, which have been moved to a quick access tray which opens when a game is clicked.

Apart from this, several intuitive features are present, like highlighting the hovered grid item with a border, double-clicking the game entry to start the game (skip the tray icons), auto closing the tray when the mouse exits the entry, auto scroll to a partially out-of-view element if it is clicked, etc.

Miscellaneous / Bugfixing

Apart from the above, code was written to fix or add to various modules of ScummVM like fixing the recursive draw() calls from parent to children to grandchildren widgets, improper scaling of images and contributing to the ScummVM wiki.

Thank You GSoC ’21

And with this, my work during GSoC has come to an end, and I will shift my attention to my college, which resumed classes a week ago.

I have achieved almost all of the objectives that I outlined in my application for the project. Which is quite surprising as I had significantly underestimated some tasks, while also overestimating others in my proposal.

Working on the project has left me with even more ideas for features and even more ideas for refinement than I initially had planned in my proposal.

It will be hard to make the same summer commitment for the few upcoming years, as I will be working on research projects at my college, a stipulation of my program. While I may not be able to dedicate my full time and effort to the project anymore, I will try my best to continue contributing to ScummVM. This summer was no joke the most productive summer of my life 😛.

Thanks to my mentors and all developers from the ScummVM team who helped with design decisions and suggestions in the Discord channels, sev and somaen for their continued support during the program, my friend Suyash for motivating me to participate in GSoC in the first place and Paul for the support and encouragement in the blog comments.

The TODO list that is longer than the list of goals in my project application

Code related fixes / improvements [Highest priority]

These are all the things which either I left unfixed or picked the suboptimal solution because I wasn’t willing to spend more time on the problem, or the problem involved messing with the existing code too much, or I just spotted a bug way too late.

Most of these will require some context from and some understanding of the code. I have written here the relevant locations in the code, and there are comments in the code pointing to these errors. But if anybody is willing to fix these and some of the code is poorly documented or ambiguous, they can freely approach the Discord channel of ScummVM and tag me @avdx , or write to my email aashwin.vaish@research.iiit.ac.in .

1. GroupedListWidget::sortGroups() at groupedlist.cpp:163 – This line keeps pushing back _listColors.front() to the _listColors, which not only breaks if _listColors is empty (not sure if it could reach this state, though), but also just keeps increasing the size without bound.
   
2. Add BMP support to the loadSurfaceFromFile() at grid.cpp:289 – Currently BMP support is completely missing, because no icons are in BMP format.
   2 (a). Refactor the loadSurfaceFromFile() and ThemeEngine::addBitmap() code because a lot if it is similar.
   
3. Add ability to load icons from all types .svg, .bmp, and .png for any purpose – Currently the GridWidget::reloadThumbnails(), GridWidget::loadPlatformIcons() and GridWidget::loadFlagIcons() are hardcoded to load game icons and platform icons in .PNG, and the flag icons in .SVG.
   3 (a). Once the above is accomplished, it should be trivial to outfactor the loadPlatformIcons() and loadFlagIcons() [related to 2(a)], and possible to also outfactor reloadThumbnails() as well.
   
4. Improve the performance on scrolling – There is noticeable jitter when scrolling the grid. It is very apparent when one compares the scenario of scrolling when screen has lots of grid items on screen at once, versus when only a few of them are, like a sparse group layout.
   This needs to be looked into. Will a different draw() method work? Do we need to do away with GridItemWidget::drawWidget() and do the batch drawing within GridWidget::drawWidget()? It may be better to first render all we need to a single GraphicsSurface, and then render that to the screen? Whatever the case may be, this is one of the highest priority TODO.
   
5. Consider margin and padding for grid item widgets – Currently, the margin and padding are very poorly defined for a grid item widget. Typically, the margin and padding are considered properties of an item. But in the code, the “margin” for grid items is defined within GridWidget, and the padding is non-existent. A possible solution to this is to define margin and padding within GridItemWidget class.
   
6. Find a different solution to drawing selection borders – Currently, in order to display a selection border around hovered / selected elements and to remove the selection border, a “cover up” rectangle has to be drawn to “overwrite” the selection border, and then the entire item has to be redrawn on top of this rectangle. There is a FIXME describing this in GridItemWidget::drawWidget() at grid.cpp:99. Ideally, we should only have to draw the border, maybe this can tie in with the batch rendering approach of (4).
   Also some observation – If we try and render the grid on a gradient background, like in ResidualVM theme, the coverup rectangle and the background color around the title text, is very significantly visible as it is a solid color. Another reason to fix this.
   
7. Edit mode feature of grouped list widget – GroupedListWidget is derived from ListWidget, which features an Edit mode. Due to time limitations, I wasn’t able to test this mode for GroupedListWidget. My hunch is that it doesn’t work, and currently Edit Mode must not be used with GroupedListWidget. This is not very troubling since nothing really uses grouped list in the ScummVM code except the new launcher, which sets the edit mode to off. But nevertheless, this feature should be explicitly disabled within GroupedListWidget.
   
8. Numbering mode feature of grouped list widget – GroupedListWidget also derives the Numbering mode from ListWidget, but it isn’t equipped to number the elements in groups. The way it could work is that the groups are labelled “1”, “2”, “3”, … and the items within it could be “1.1”,”1.2″,”1.3″, … and there may be two parameters selecting the major and minor index numbering types.
   
9. Remove linear traversal after binary search in scroll logic – In GridWidget::calcVisibleEntries() in grid.cpp:516, there is a linear traversal to get the first item in the row, as the binary search returns the last item in the row. This can be removed and replaced with a static calculation because the width of the grid items are fixed.
   
10. Avoid unnecessary steps – There are a few instances in code where reflowLayout() is called even when only certain subset of steps is necessary, which can be refactored into a function. These instances are in GridWidget::setEntryList(), GridWidget::toggleGroup()

Essential Features related TODOs [Medium Priority]

These are either addition of much required features, or fixing or redesigning or refinement of some implemented feature. It is difficult to pinpoint a single relevant function or code line, so that is not mentioned.

1. Sort entries beginning with an article correctly – Currently, the sorting of entries under the “First Letter” grouping method does not work correctly when the title begins with an article. So for instance, “The Beast Within”, “The Dark Crystal” are classified under “T…” instead of “B…” and “D…” respectively. This needs to be fixed.
   
2. Add a distinction between EGA and VGA entries – Some games which have EGA and VGA versions are stored as different game entries, but the difference is reflected in the title in the list view as additional info within parenthesis. But in the grid view, we currently strip the title of this extra info using pattern matching, so the EGA/VGA distinction is lost. Add some way to bring this info back.
   
3. Group the game variants of the same title under one entry – Let’s say that the user has installed the DOS and the Amiga versions of the game, then these two will appear as two distinct entries in the grid, same when different localized versions of the game are installed (where the games only contain one language), these version will all be their separate entry. For example, if one installs all the (5) localizations of “Lure of the Temptress” game from the ScummVM downloads page, they will end up with 10 separate entries in their grid, 2 (VGA + EGA) for each of the 5 languages (English + Spanish + French + German + Italian). So there can be a grouping system and a switching system to manage these, and this functionality can be added to the existing Options menu.
   
4. Add more layout variables – Despite my best efforts to expose all grid layout parameters to the theme, there are still several parameters which are hardcoded, and should come from the theme. Here I mention a few of them, but there may be more:
   3 (a). The maximum number of lines allowed to display the title (Currently hardcoded to 2).
   3 (b). Layout of the icon tray should come from the theme.
   3 (c). Background color of the group headers (Currently is the same as the list selected item highlight color).
   
5. Complete the iconset – While the game logos will be a much longer task, the platform and language icons are exhaustive, and running the application will notify in the command line which icons are missing. These need to be added.
   4 (a). Particularly in language, all flags are in place, but EN_ANY requires a special icon in which the US and UK flags are diagonally joined. But the .SVG from Wikimedia (https://commons.wikimedia.org/wiki/File:English_language.svg) does not render properly in the application. This either requires a new flag or a look at the SVGBitmap class.
   4 (b). In case the icon is missing, it should be better to draw a placeholder text in its place simply saying either the language code, or platform code.
   4 (c). Speaking of placeholders, there needs to be a consideration for putting a placeholder icon for engine, in case the game icon is missing. For example, display an AGI icon if KQ3 icon is missing.
   
6. Icon Layout on the Grid Item – Currently the platform and language icons are displayed within a fixed size rectangle which comes from the theme files. However, some platform icons are rectangular, and don’t have any official square logos, which means they are harder to read when fitted to a square (since they will get scaled down to fit). So let’s say we try scaling the icon only to the desired height, with the width only limited by the thumbnail width. If the icons are scaled by height, the width of the icon may be too wide, and cover the entire bottom of the thumbnail. Another possible solution is creating “unofficial”, but “recognizable” square icons.
   Anyways, this is a design problem more than a programming problem.
   
7. Distribute the icon set – There are much more knowledgeable people in the community regarding this, but my current understanding is that there needs to be a “Default” icon pack supplied with the application that contains platforms + language + only a few games icons, and a “Full” version with high quality platform and flag icons, and all of the games icons.
   
8. Test on non-desktop systems – Self explanatory, nothing except PC (Linux + Windows + Mac) builds have been tested.
   
9. Non-modal dialogs – Popups which do not block the input to the lower dialog. The icon tray should be one. There is noticeable jittering and seldom graphical glitches that can occur, when opening and closing the tray.
   
10. Add quick select to grid view – Similar principle to how it works in the List view, start typing keys to go to the game whose title has that prefix.
    
11. Save grouping and grid status to the config – Save variables like the last grouping method to the config. Additionally save and retrieve the last selected game from the scummvm.ini config file, and scroll to it in the beginning in the grid view.
    
12. Dealing with <default> – Sometimes games don’t specify which platform or language they are for in the scummvm.ini config file. Which means that the grid cannot display platform / language icon, and fails to group when grouping on platform / language.
    
13. None in GroupedListWidget is just ListWidget – In “None” grouping, currently a “All” group is created in which all of the elements are put. But there might be a separate rendering method, where in “None” grouping method, no groups are shown, only the entries, and it looks and behaves like ListWidget in case of list view, and a more compact Grid in grid view.

Ideas for some future work

These are potential ideas that have come up in discussion over on Discord, but the ideas are not fully fleshed out in design yet or have much more prerequisite work than the other TODOs. I encourage further discussion on these, and it would be great to see them in the application.

1. Icons on group headers – It could be good if there was an icon as a prefix to the group header, so for example, if sorting by “Language” the icon would be the flag, “Platform” would be the platform icon, “Engine” would be the engine icon (mentioned in 4 (c) in the last section), “Publisher” could have the company logo, “Series” could feature custom icons and so on.
   
2. Update metadata and icons from the Internet from within the app – There could be a downloader within the application which can fetch and auto update the metadata (used for sorting) and the icons from the Internet.
   
3. Upgrade the list view to a table view – There can be addition to the current list view, where the view is constructed of columns of various fields.
   
4. Asynchronous loading of thumbnails – The thumbnails can be loaded separately from the grid scrolling. Although the images aren’t super high resolution, and only a few of the supported devices are slow enough to lag in this regard. Maybe useful if the thumbnails are streamed from the Internet in the future? But that’s probably not going to happen. I am not sure if this is quite a good TODO or not 😛, but I would like this feature.
   
5. Abstract, general purpose Grid – The GridItemWidget class was made when there was only one kind of grid item, the game entries. After the grid was made to support variable height elements, and the group headers were also displayed using GridItemWidget, one flag isHeader was added. But what if this could be abstracted and the rendering method could be made more extensible to support more types of elements. Perhaps so that this GridWidget could replace the one in Save/Load dialog? Again, not a very fleshed-out idea, but something to think about.
   
6. Animations – There is an animation class in the GUI code that is sitting unused. It may be used to add some flair to the transitions like collapsing expanding groups, opening tray, etc.

This list of tasks is larger than even what I proposed in my project application document, and definitely a lot more items will come up with time and more review of the code, bug reports and feature requests.

This is the end to the TODO list, for now.

In 2021, my second and final year as a Google Summer of Code student, I made 416 to commits to ScummVM, largely to the Macromedia Director engine. You can browse all of my commits here or see my full git log on one page here. Summaries of each week’s work are available on my blog.

These are my major contributions this summer:

• I contributed many bug fixes and stability improvements, helping to bring the Director engine to its first official release in the near future.
• I rebuilt the engine’s Lingo compiler from the ground up, allowing it to more gracefully handle context-sensitive Lingo features and greatly improving its maintainability.
• I implemented missing Lingo features from Director 2 and 3, including manipulation of chunk expressions.
• I began some preliminary work on Director 5 support, changing cast member IDs to support multiple castLibs.
• I implemented font mapping, allowing the engine to correctly handle fonts in movies authored in Director for Windows.
• I added support for text encodings other than Mac OS Roman, refactoring the engine to use UTF-8 internally. This allows the engine to support Japanese and other non-Latin character sets.
• I created a directory-separator-agnostic Path abstraction, which is now used in common file functions instead of Unix-style path strings. This allows the Director engine to properly support classic-Mac-OS-style paths, which can contain many special characters including ‘/’.
• I made significant progress on improving the playback of Meet MediaBand, a Director 4 title. Here’s “House Jam”, one of the interactive music videos from that CD-ROM:

My GSoC contributions this year have greatly improved support for Director 2-4 titles. I plan to keep contributing after this summer, extending the engine to support Director 5 and beyond. I initially planned to begin work on Director 5 this summer, but there is still work to be done to ensure that Director 3 and 4 are stable, which I hope to help complete soon.

While our engine currently only has official support for two games, Spaceship Warlock and L-Zone, a huge number of titles were made in Director. With each bit of work, we are able to run more and more of them. This portable, open-source reimplementation of Director will help to preserve this media for generations to come.

Beginging or the Ending – GSoC Summary

Hi, Crane here. Also know as sheep in ScummVM. Here i’m going to make a summary of my work during GSoC time.

I’ve make about 500 commits. As you can see on this picture

The first commit in the official GSoC period is this one fdc5e88e30751285ac4f0fcc936c5ccb0b01eae4

After sev give me the permission of the codebase, i started to commit to master branch directly. And before that, i mostly use the pull request to arrange my codes.

This is the link to my pull requests

And this is the link to all of my commits, so anyone can check it at anytime.

With the help of sev, djsrv, rvanlaar and other guys in the director group. I’ve managed to make a big progress for developing and fixing director.

For the milestones that i’ve achieved and the time those tasks consumed. Let me describe more precisely here.

First is for fixing the bugs that already exists. During the community binding period before GSoC officially started, sev have gave me some tasks in trello card for me to get familiar with director. This didn’t takes much time, maybe a week or less.

Then i’ve head to the apartment, fixing the existing bugs and implementing the stuffs we lacked. This takes me about one month. And also gives me a better view of the whole director. While doing this task, i’ve also continue reading the blog post of the students who have developed director previously. Since my taks is mostly related to the rendering part, those blog posts gives me a great sight of the rendering part of director.

As you can see on the picture, i’ve fixed the parts in the red box, which is nearly the most of the rendering parts of director.

After done with the task about apartment, i think i’ve enough ability to test and fix the director in real games.

So next task is about fixing the director to run the real director based games.

I started fixing warlock first, which is a fantastic D2 game. It took me about 3 weeks to test and fix warlock. During that time, i’ve help to enhance the sounds in director. Fixing the graphics part of game, including texts and images.

Here are some screenshots of warlock

green girl in the bar of stambul. I’ve implemented the stretched bitmap images to fix this.

At that time, the rendering code of director is kind of good, and we won’t be able to find some big issues related to the graphics. I think maybe we’ve finished 90% of it. And for the rest part, we still need more games to test.

So then the next week, i started to fix l-zone, which is a another sci-fi game in D3. And after testing l-zone, there is only few bugs related to D3 image decoding and videos. Thanks to the help of sev, i didn’t take much time to fix it.

Then for the last part to complete D3, we have a big guy waiting to solve, which is JourneyManProject. Since the time is not enough, i’ve only fixed the part of JMP now. But we have solved most of the issues in JMP, and i believe we will announce support that game soon.

Pictures in L-zone, this one is related to the video overflow problem.

Screenshot in JMP, look this beautiful interfaces

And while i was fixing those games i mentioned above. I’ve also been fixing the movies in dictionary. Whenever i have the problems about behaviour, i will refer to dictionary. We have the documents about it, also we have Basilisk to run the original one. So it’s very convenient for us to implement the correct behaviour.

Yes, that’s nearly all of it.

Another excited thing is last night, sev, djsrv and me, we have had a meeting with John Henry Thompson, who is the inventor of lingo. By this meeting, i’ve recognized that our project is very meaningful. Also when we are supporting director games, there are guys come in our channel, discussing about the engine and games. I noticed that director really support many games, and to complete it is really a hard work. But challenging works is more interesting and meaningful. With our work, people can play games from the very beginging. Those are the inheritance of predecessors, and we need to protect it.

And at the time i realized, we are actually doing things. It’s not the toy programs we made in school, we are making the actual stuffs. Here are all the OSS enthusiast. We gathered here to develop, to create. And we can coding here, solving problems, meet more friends who has the same interest like us.

At last, again, thank you so much. The guys in ScummVM, and the guys in the director group. Without your help, i couldn’t proceed so far like today. I may not express much by words, but i think the action is more important. This will be the last of GSoC, but only the begining of my developing life. Thanks you guys in ScummVM, this community have broaden my view and makes me feel like, yes this is coding. And i will continue contributing to ScummVM on the director, and also other engines.

See you guys. 🙂

Hello. My name is Yuri Guimaraes (nick: a-yyg), a student at ScummVM for the Google Summer of Code 2021.

Starting on May 17th and continuing up to August 17th, I’ve made about 500 commits to the master branch of the ScummVM repository, most of which focused on implementing the SAGA2 engine within ScummVM, an engine made for the game Faery Tale Adventure II.

The development during GSoC started on commit 62e5f32dd8ff36e63e5d5be598bd352cf745a8b6 and ended on commit 994ac18c52785e69213e2312f435f73fa76ef75b.

You can see all of the commits during this timeframe HERE. (Also linked at the bottom of the page in case of hyperlink failures.)

The development is not over, but the game (FTA2) is playable and completable (one can acquire all of the endings).

Here is a list of milestones:

• Made the code compilable within ScummVM:
  • Converted custom error/warning methods to ScummVM’s error/warning methods.
  • Converted FILE usage to OSystem’s Common::File.
  • Replaced OS-specific drawing code with OSystem’s drawing methods.
  • Replaced proprietary audio code with OSystem’s audio interface.
  • Replaced custom input scheme with OSystem’s input interface.
• Made the code more portable:
  • Removed dangerous pointer arithmetic designs.
  • Converted non-endian-portable code to be endian-portable.
  • Fixed various portability related warnings, such as global constructors.
  • Made the save system be compatible with the original.
• Integrated it with other ScummVM internals:
  • Saved option values with ConfMan.
  • Integrated the save system with ScummVM’s so that one can load a save from the launcher.
  • Implemented various console commands to ease debugging.
• Removed dead code.

I should thank sev, my mentor for this project, and NMIError for their contributions to the audio system and various other contributors for fixing various warnings and letting me know when the builbot broke. Additionally, sev helped immensely with debugging, writing the skeleton code for many of the engine parts I was unfamiliar with, fixing compilation warnings, and fixing minor errors caught by the group’s static analysis tool, Coverity. I should also thank him for writing the sprite unpacking and other assembly routines.

Thanks to the above contributions, I was able to achieve the original project goals set out for SAGA2. However, there is still plenty of work left to do. Below are a few examples:

• Further playtesting.
  • Debug and fix portability issues on several platforms.
  • Debug the original executable binary to fix some of the issues still present (e.g. limit of Tasks being reached), as well as to extract still undefined methods.
• Refactor the codebase.
  • Rename the variables so they conform to ScummVM’s naming conventions.
  • Get rid of global/static variables.
  • Reduce code complexity by making use of more of ScummVM’s classes.
• Implement more MetaEngine features.
  • e.g. Return-To-Launcher, Subtitle Options…

With the contribution everyone has granted to this project, SAGA2 will hopefully soon be able to stand as a mature engine. It currently only supports FTA2 on a limited number of devices, but some of the code may serve as a foundation for other games developed by The Dreamers Guild, such as Dinotopia.

Link to the commits: https://github.com/scummvm/scummvm/commits/master/engines/saga2?since=2021-05-17&until=2021-08-17

Note: You need to possess a copy of the original game’s files to test the engine.