Google Summer of Code with ScummVM

 Hello! GSoC has officially ended, and I'm in the final stage - submitting my work for the entire summer to Google! When I first received the acceptance letter in May, I was very much baffled. It was exciting and a bit scary at the same time, because I have never ever worked on a project of this scale. Well, first time for everything I guess :) So, what have I been doing this past week? Last week I left off saying my U32 PR was showing some activity, and this week, @criezy helped out a lot by reviewing my U32 PR, and providing much feedback. He also helped out pretty much entirely towards the MacOS/iOS platforms, because it was quite not an area (Objective-C) I was comfortable in. It was really a huge help. Apart from that, I mostly spent the entire week looking at the PR to see what could be changed, fixing my mistakes, and making the PR ready for merge. It has improved quite a lot!  Criezy pushed an update for iOS, which led me to believe that there might be many more missin...

 Hello! Because I think I am mostly done with the new feature implementation, this week was mostly cleaning up the tree, and getting it ready for a PR! Last week, I mentioned some special engines which were ported a little differently, so let's start with those. The MetaEngines in ScummVM uses game detection to detect these games and then uses MetaEngineConnect to instantiate an engine and run it. However, if we fail at the very first step, i.e detecting a game - what happens then? For this, ScummVM uses "fallbackDetection" to approximately find the closest match to the game engine that could be used. The AGI engine was one of my first test engines because it had an additional dependency on fallback detection, which I wanted to test from the get-go. Turns out that the resources for fallbackDetection were only used by the detection features in this case, so the object file was shifted to the DETECT_OBJS variable which would eventually be linked with the executable. However...

Hello! Some very nice progress this week I can't wait to tell you about. Let's just jump right into it! So, last week I shared that even though I had something cooked up that was somewhat correct, it wouldn't really be suitable as a proper solution. I also discussed briefly on what was the approach I was taking on next. Because the new work would require cleaning up a lot, I just set up a new branch and cherry-picked some of the commits that would be relevant. The plan did work out, and after laying out the brief structure I explained last week, some engines started to show life again. For some engines, the story was a little different though.. but we'll get to that next week because these might not be final, and I used my best judgment for them. Once the few engines were working well, I got started with porting all the engines over, and this week - I managed to convert them all to the new infrastructure! 79 engines in total, including the ones that are unstable! A very...

Hello! What a busy week it has been, and I have some good things to share. In just over a little 3 days of time, I worked for a lot of time to implement the new idea I mentioned I had last week, and it was actually working quite well! I managed to implement the entire basic structure of it, as well as port over 8 of ScummVM's 79 engines to adapt to it! So, what's the deal with this, and what did I do? The "idea" was just me getting a basic understanding of how things "could" work in a way. Well, we were at the "createInstance" bridge where I left off last week. This is a member function of either a MetaEngine or an AdvanedMetaEngine class. The problem with this was this had engine code in it, so it couldn't be included in the executable. The basic idea around this was simply to remove it as a class - member function, and instead mark it as an export symbol. What we could then do, is in base class, provide a default functionality. These function...

Hello! So, this week I have done things that ranged across all my tasks. Recently I checked out our sister project, ResidualVM. ResidualVM's codebase is largely similar to ScummVM, but the main difference is the addition of capabilities to run 3D games. They also take regular snapshots from ScummVM to keep up-to-date. So, the work of RTL GUI which was merged in ScummVM was also present there. When I was running the application with the Hebrew language, some popups and drop-down buttons looked quite different from the normal GUI. Upon a little investigation, it looked like paddings were being set wrong for the RTL-widgets set in the theme. This was because back when I was on my RTL task, I temporarily set a padding of "2" as a placeholder to check, and then completely forgot about it as the difference was ever so subtle. I'm glad though, that I found this, and opened a PR to fix it. English, proper paddings Hebrew - Improper paddings Hebrew, mirrored and matching paddi...

Hello! The first few days this week, I spent trying to understand my task, and work on a small number of engines, and try to make games detect/work as a means to see if everything would work as expected. But first, some context. ScummVM has a MetaEngine and a Engine. MetaEngine A MetaEngine is responsible for, as the name would suggest, a meta-data related things before we actually start the engine. This is an abstract class, and each specific engine must inherit it and have their own implementation of it. Alternatively, we also have an AdvancedMetaEngine, inheriting from MetaEngine, which provides a default Game Detection algorithm - which saves individual engine developers the hassle of providing detection tools. The detection algorithm is an Md5 + filename check and makes game detection easier for engines. These engines can inherit from AdvancedMetaEngine and provide some other metadata/utility functions, like getting supported games, querying which features an engine has, etc. Adva...

Hello! This week, I got started with my new task - "Moving detection features to the executable". What is the task? ScummVM has over 50 engines that support many - many games. Currently, when compiled - these engines can either be compiled directly inside the scummvm executable (statically linked) or packed inside small packages of external libraries that can be loaded on demand (dynamic linking) So, why would we even opt for external libraries? Wouldn't packing everything into the executable give the best performance? Well, yes. But the thing is, ScummVM has a lot of platforms it supports ( ScummVM Platforms ) over 30! It's very portable, which is one of the really amazing features of ScummVM. With dynamic plugins, the executable sizes are lowered. Because of this, when we need to detect games - each engine is loaded by one and the relevant detection happens. This is slow. The main purpose of this task is to move the detection related features to the executa...

Hello! This week, I don't have a lot of updates. A while after I created my last post the previous week, I cleaned up the history a little and opened a PR. Then, the week was mostly spent on cleaning up more code and trying to keep the changes to a minimum basis - because I was modifying a large number of files (~280). Right now, I am trying to combine String and U32String into a template, because they have a lot of similar functionalities. Reviews for the PR should be soon, so I will mostly be addressing those and working on the templated classes. This week has been rather busy though because my final project from college had some documentation work pending and I self-reviewed my PR many times. It is exhausting to review so many files! I picked up many mistakes though as I reviewed them again and again, and the fixes were pretty simple. That's it from me for now. I hope to wrap my work this week and get a little more understanding of my next task, which is moving dete...

This week there was slow progress on my task. I was also doing some miscellaneous things that related to my task. The very first thing I want to say:  My RTL-GUI PR has been merged into the master branch of ScummVM! Hooray! Since the previous work was also related to GUI, I had to rebase my branch to even out with master and merge the RTL-GUI work into my own. There were many merge conflicts, but I was able to solve them all! Now that I think about it, merge conflicts are not as scary as I thought they were before. They are pretty simple! I've set up Travis-CI to build my branch. I did this because continuous building on my machine was very slow, and with Travis, it is very easy to catch up on errors, correct them, and so on. After rewriting history several times, I was able to solve all errors (~50) that didn't appear on my local machine. I use MSVC, so many instances of errors don't appear on my machine - even though it builds and runs completely fine. This week,...

Domain Problem: The domain problem is very simple. RTL language users read their texts in a right-to-left manner, and GUI for these languages is also specialized in a way that they will find intuitive along with their native language. ScummVM did not have such GUI before. My first task (now near merge) introduces RTL based GUI, which will be useful for native RTL users. PR:  https://github.com/scummvm/scummvm/pull/2265 How I solved it: To begin with, sev provided a proof of concept by ZvikaZ , which gave me a very good overview of how things "should" look like when finished.  I began with that proof of concept and slowly worked my way up. For example, after the proof of concept, I reversed the mouse coordinates. Then I checked each menu in the main dialog and worked there. Afterward, I worked with the stacked dialogs and positioning them correctly, reversing the tabs and contents, etc. After good progress on GUI, I worked on flipping individual widgets. Th...

Hello! I was not as close to finish as I had estimated before. However, I have some more good progress on my task! Right after my blog the previous week, I found the problem which was making me very concerned about my code. Whenever I ran ScummVM, it took about 20-30 seconds to start. I was worried that some of my code could be troublesome, but then I found out my configuration file was a little too big. The configuration file (scummvm.ini) stores some useful information and is often low in size (~10KB) or so. In code, we interact with this file using "ConfMan". For my previous task, I configured this to get a boolean from the .ini file to force the RTL-based GUI. I think some of my temporary code would have caused this issue. The ini file was around 150MB big! I was curious to see what it contained, so I opened it in sublime. It took ~15 minutes to open and it had this: 15 minutes! For my own amusement, I have saved this file in another location. I simply dele...

This week, I got started with my new task - Moving GUI to U32Strings.  Before I tell more about it, some miscellaneous things that happened this week: A team-member of ScummVM had previously worked on adding the achievements for some Wintermute games. He was very nice to offer me a game copy to test out the achievements for my task, but I had some steam credit so I thought there was finally a use for them! This way, I have bought my first ever steam game! I have run out of games - pre-2011 - that I can play on potato pc, so I never really bought anything from Steam. I have yet to try out the game, maybe sometime soon! While cleaning up the history and adding more code, I came across a merge conflict. Previously, I would just find a way around them, but this time I tried to solve it following step-by-step. This way, I learned how to solve merge conflicts! It was quite simple (at least for my small changes), and not as complicated as I thought it would be. I will try to ...

This past week, I spent the majority of my time polishing the GUI, adjusting spacing and padding so that it matches the original (LTR) GUI well, solved my PR review issues, cleaning up my history. I have to say, I did not know before how important and time-consuming polishing things take in the context of GUI. I solve one thing, there's a new thing discovered and needed to solve, a new bug discovered and so on. One example, a bug, for which I was a little confused: I implemented a way to fetch an "RTL" boolean flag from the theme. If this is true and GUI is also using RTL, the widget will be flipped. One of my mentors has a Mac, and I was surprised to see my implementation did not work on their system. I didn't know what was causing the issue, but my mentor found the root of it. It was because the RTL flag of the object was uninitialized, which caused the issue. I use windows and MSVC - and my environment didn't have a problem with it. The problem quickly...

Hello again, it's been a while! The last time I wrote this, I felt like I was getting pretty close to the completion of my first task. But, whenever I'd complete one thing, another thing popped up and so on and so forth it went. These past 3 weeks, - I worked on the positioning of tabs and dialogs which overlapped each other. - I then worked on some individual widgets and added the support to flip them internally. Have a look at some of them! DropDownButtons: Orignal Flipped Lists: Orignal Flipped Sliders: Orignal Flipped These involved majorly working with the XML theme-based layout system that ScummVM uses, and it feels so awesome that all of them now have the support to be viewed as in RTL! - I worked on extending this RTL based support to the 3 existing themes, as well as extending support for RTL based on the resolution. Have a look! High res: 960x600 Small res: 320x200 If you've ever played IG...