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.

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!