Skip to main content

ScummVM plugins - The new task

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 executable, i.e statically link them. The main advantage of this will be that users could be able to detect games without loading an engine. This would make game detection faster and not dependent upon the external libraries.

So, that's the task.

This week:

I got started, but I haven't made much progress yet. I would say that this task is more complex than the previous two, but slowly and step by step I am understanding more things.

I also learned many things about build automation and particularly the "make" system. The GNU Make manual is a pretty good resource that I learned a lot from. ScummVM has a pretty neat and modular design of makefile ranging over several files, and I enjoyed looking around and seeing how everything tied together.

On Thursday, I had a video chat with John - one of my mentors. I haven't really video-called much before so I was a little nervous. On the other hand, John was quite comfortable and relaxed, and talking with him made me relax too! We introduce ourselves, talked about my new task, and so on. I have no idea how an hour or so went by, but it was fun!

As a side note, this chat also made me realized that I had something to work on constantly. It has been on the back of my mind, but I haven't really put much thought into it. In my day to day life, I read-write-hear English and consider myself decent in it. However, even though I know how to speak - I don't really speak much. Thus, I don't really have the practice to speak well. I mean, I don't think I speak terribly, but it could surely be better and I should speak more often and get more practice.

Anyways, that's it for this week! I hope to have some progress to share with my mentors by next week, because this week has gone by without me doing anything. Honestly, there are many things about the task I still don't understand, but I'm getting there. Okay, see you next time!

Thanks for reading!

Comments

Popular posts from this blog

The (official) end of an amazing journey!

 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...

Touching upon all 3 tasks

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...

Getting a better understanding & a little progress

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...