Skip to main content

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.

AdvancedMetaEngine provides a means for engines to detect games. But, how does it know that a specific game belongs to a particular engine? Each engine provides a set of detector tables i.e a list of games it can support. Then, the default game detection algorithm checks each engine's detection tables for a match. These files are often separated into a new file, and it is called "detection_tables.h"

So, each engine's implementation of their own version of AdvancedMetaEngine (or MetaEngine) and other detection-related code is located in detection.cpp. This file includes the detection_tables header file, so the resulting object file generated has all the necessary information which it would need for detection.

Engine

An engine is the actual game engine, which is created when we try to run a game.

So, what is the task exactly? 

I gave a very brief overview in my last post, but basically, the detection related code - which lives in detection.cpp, will need to be isolated in a way that actual detection related code goes to the executable, while the other kind of functions will be available as-is, on-demand at runtime.

So, the detector-tables, and other detection related code - like fallback detection moves in and is linked against the scummvm executable. So, the ScummVM executable depends on these (detection) object files.

Fallback detection is a way for engines to provide a means to find a "closest" match if the detector found no matches in the directory.

So, I have a little progress this week! It's not much, but I worked towards the most basic thing as a few of small steps:
- For makefiles, introduce a variable for Detection Objects and add it as a dependency for the scummvm executable. This way, before scummvm.exe is built, these are compiled and linked with scummvm.exe
- For engines, isolate MetaEngine code and temporarily comment a bridge function - createInstance. Creating an instance means we actually try to instantiate an engine. This is a method of MetaEngine and connects an Engine with MetaEngine.

That's it! I did the above for 3 engines - AGI, CINE, PLUMBERS. I had no need for the latter two though, but I wanted more than one engine as part of the preview? or whatever I was doing.

A while back, Eugene had given me a link, which had a huge number (197 or so!) of AGI (fanmade) Games. I thought it would be a good point to see if the above steps worked correctly or not. It worked well, and the result from before/after the work was the same. Fallback detection worked too!

Perhaps it was not a big deal, but I finally had something to share! I'm taking a lot of time to think and understand this task, and many days had passed by without me sharing any update. I could finally share a small update and make a few commits for my mentors or community to check out, so that was good. It feels a little weird that I'd check-in and out without showing code progress for so many days, so for me to actually show something was good.

Detecting 197 AGI-fangames, statically


I also took a small test, I uncommented code in createInstance where engines were being instantiated and added plugins as a dependency for the executable.

That means all engine.dll's depend directly on the executable i.e implicit linking. This type of linking would mean a .dll file to be present for the executable to run. If it does not exist, the application would crash.

That's not really how it should work - engine.dll's are explicitly linked i.e they're not dependent on executable. It's loaded on-demand and if not present, the application would not crash.

However, I just did the test to see if engines could instantiate and run properly - and they did, indeed!

Eugene recently reviewed my newly made commits and left a lot of comments. I made some mistakes, or rather - didn't correctly understand why some things were the way they were. A small discussion in the group took place, and I think I know the way to move forward now and incorporate the changes in a better way. 

Overall, I think I have the basic idea of the end goal, as well as a temporary piece of code that achieves this (with a few incorrect assumptions). Now, I need to implement everything in a correct manner and maintain the engine changes in a clean and maintainable manner.

Though I think there are still some key things I don't fully understand, but the discussion recently should be enough to guide me in the right direction. 

Lastly, my finals were scheduled to start tomorrow, but it was postponed again. I am glad about it, because I can work till the end of summer without taking a break of 1-2 weeks. Phew!

That's it for this week! My previous PR has some more comments now, which I will have a look now, review it myself and make the necessary changes.

This next week, I want to accomplish the changes (for the new task) in a way that my mentors expect and have a few more commits and enable a few engines regarding that. Once I have the "go" for that / everything seems ok, I can start going engine by engine to incorporate the changes on a bigger scale.

 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 …