Skip to main content

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 padding to English


Last week I left off saying Eugene had some comments about my U32 task, so this was what I worked on next. After solving the review issues, I decided to review my PR more carefully once again, because many issues were being raised. 

This time, I picked up on many things that could also be done and saw some things I had left out.

For example, when a user wants to add a game, they can choose a folder from a file browser. This file-browser can also be a native system open dialog, or a ScummVM custom browser.

Native-windows dialog. The title, and the buttons for "Choose/Cancel" are in english.

So, for windows, ScummVM implements a small layer of Win32 API to implement this. The dialog has some labels which are also set to the GUI language.

Before, I had written some sloppy code (1 line of code change) and expected it to work to as it used to, without thinking too much about it. It was clearly very wrong, and the translations in the dialog were broken. Nevertheless, I worked on adding support to it properly. I already had text in UTF-32, but our Windows wrapper code didn't have anything to convert the text to an LPWSTR (16-bit Unicode characters). I looked up documentation online and followed it, implementing a UTF8ToUnicode. We have a conversion function for UTF32 to UTF8, and then by using the above function (internally calls MultiByteToWideChar for UTF-8 encoding), it was converted properly to LPWSTR. The implementation now looks proper.
Russian translations for dialog title and "OK" button (The OK button has the label - "Choose")
 


One of the issues raised was that I was converting a Unicode string back to a normal string because a class called StringTokenizer was involved. I don't know how I missed that, so I implemented a Unicode string tokenizer.

A StringTokenizer simply takes in a string and some delimiting characters and separates the words based on the delimiters present. So, If I have the string "Hello, World - Welcome.... to ScummVM" and provide the delimiters as - " ,-." - I will get the individual words ("Hello", "World"....), which I can simply search, for example, in a list - if it contains those words or not.

One example where they're used is in the game search filter. Let's say I have a game - "Reversion: The Escape, PC" in a list of 100+ games. If I type in either of those words, the search list should show this game. With everything going Unicode, now what would happen is if you have a game title with non-ASCII chars, like かわい- and you start typing in , the game with the title かわいwill show up in the search list. I'm not sure if we really support typing in with any other languages in ScummVM right now, but it is now future-proofed I guess!

Those were pretty much the main things I did for the U32 task. I also cleaned up the PR quite a bit, reviewed it with care so small things get out of the way. 

Yesterday and today I was able to shift focus again to the detection task. The very first thing I did was to drop the previous few commits because the approach was wrong.

So, each engine has an overall engine template. Anything related to detection, the "MetaEngine" or any other related function is supposed to be defined here. It also contains function definitions from classes not declared here. So, my first guess was to restore the function definition to the original files. Say, "example.h" had the declarations, so "example.cpp" will have all the definitions. That's what I did, but I failed to recognize that functions were not defined in the so "example.cpp" for a reason. All detection related code from any classes is grouped over at detection.cpp, so the code overall has a nice structure to it. This also makes it easier for engine maintainers.

After a discussion, what I will now try to do is take code from "detection.cpp" and split it into another file - "detection-static.cpp", which the name suggests, will always build into the executable.

Finally, once again I arrive at the "createInstance" bridge. If you don't remember from last week, a small recap: createInstance is basically a function inside a MetaEngine - which instantiates the proper engine. So, if I am trying to launch the "Plumbers" game, it will instantiate the "Plumbers" engine.

The difficulty with this is that the function itself contains code that is not available in the executable. What I mean by that is,

Say I have an engine, which is used to run the game "exampleGame". This engine is named "exampleEngine".

When we request ScummVM configuration to build this engine as a dynamic module (explicitly linked run-time library), all code in "exampleEngine" goes into the "exampleEngine.dll" file.

Now, the previous dynamic system, everything was in the external library, so we could just load it, and then have "createInstance" instantiate the proper engine. i.e in this case, "engine = new exampleEngine". But now, the MetaEngine is always included in the executable, so that's a problem.

Why a problem? If I include "createInstance" class method inside the executable, it also has the line
"engine = new exampleEngine();"

What is exampleEngine? How will the compiler/linker recognize that, if the engine itself is in an external library? That's the issue of why this particular method cannot live in the executable.

So, what I am doing now, is basically making the createInstance method live outside the executable, and inside the .dll, while still making everything work as it used to.

I tried to approach this in various ways, but most of them had a flaw somewhere. Yesterday, I thought of a good approach, which will make minimal changes across engines and should work correctly. It's still a work in progress though, and no point in expanding on something that could be wrong. So, more on this next week!

I'll basically be focusing on implementing a way to bridge this gap for the next week, & That's it for this week!

Thanks for reading!

Comments

Popular posts from this blog

I got accepted into GSoC!

Hello World GSoC!A start of a wonderful journey, and I'm a part of it! I'm pleased to announce that my proposal has been accepted to GSoC 2020! 
From coding "Hello World", to making small projects, to being a part of ScummVM's GSoC student is fascinating. You know, honestly speaking, I didn't think I would make it. I started my GSoC proposal late, around 19th March. I sent in the first mail to my potential mentor then - and crafting a great proposal usually takes many days. Regardless of the proximity to the deadline, I worked as hard as I could to make a decent proposal, and on 4th May - that hard-work reflected an essential part of my life!
This is my first ever professional experience, and things look a little scary but I have fantastic mentors. Eugene "sev" Sandulenko - the current project lead of ScummVM & John "DJWillis" Willis - team member of ScummVM since 2006. In fact, they're so qualified that it's almost overwhelming! …

My first week experience and my first task!

Hello, it's nice to talk to you again! This is my first week after being accepted into ScummVM and I have a lot to talk about, so let's get started. A little sidenote - Originally, I thought to update my blog once every two weeks and that it would be a good idea, but I just really wanted to update you guys with my exciting first week! 
I was reading my fellow GSoC student's introductory blog post when I realized that the introductory blog post is also meant to introduce a person, something I completely forgot in my first post.
Yes, that's right, I forgot to introduce myself - in my introductory blog post. You read that right - but I hope that you didn't find it rude, I was just really excited to be a part of ScummVM for this summer, and somehow forgot what I was supposed to write! Let's do it right this time before we move on to my first week's experience!

Introduction Hiya! I am Aryan Rawlani, a Computer Science student in Ahmedabad, India. I am 19 years o…

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 …