The First Visuals

The Splash Screen.

This is a short mid-week update on my work to add support to qdEngine. As I previously mentioned,  I have been working on displaying the splash screen. In this blog post I will give you details on how I managed to render my first visuals using qdEngine.

The splash screen is stored as a bitmap. The original engine was loading the bitmap from the executable. Microsoft gives you a feature where you can convert assets (like fonts, images etc) into binary and include them in your final executable. This is how the original code was loading the bitmap on the screen.

bitmap_handle_ = LoadImage(GetModuleHandle(NULL), MAKEINTRESOURCE(bitmap_resid), IMAGE_BITMAP, 0, 0, LR_DEFAULTCOLOR)
if (!bitmap_handle_) {
return false;

The splash screen in the original engine is a little fancy. They didn’t load the splash screen on the main window, which is going to be used for the game. They decided to load a smaller sub-window to load the splash screen, sort of like a popup, before loading the main game window. Instead  of taking this approach we decided to load the splash screen on the main window itself.

I re-wrote this using the Common::PEResource class. Thereafter we copied the buffer returned by the decoder to the screen. This resulted in a monochromatic splash screen, which looked something like this.

Initial Splash Screen.

To add colour to the splash screen we initialised a palette. After some minor refactoring to get the splash screen to the centre, we managed to load the splash screen with colour. This is the commit which shows the complete implementation of the splash screen.

This is a short mid-week post, to showcase my progress. I am really excited for the coming weeks, and look forward to sharing more updates.

Week2 – Getting better

This week, my main tasks were parsing the .dat files and fixing errors in the original database functions. After closely examining some .dat files, I found their format very similar to JSON, which I am quite familiar with. Thus, I only needed to perform some bracket-matching operations.

However, when I tried to port the PHP code to Python, I encountered numerous errors. The issues were due to Python’s need for additional boundary checks on strings and differences in database operations between Pymysql and PHP. Additionally, the original code contains some unnecessary transaction operations. It should only require cursor.execute() instead of using conn.commit() . After making the necessary fixes, I successfully resolved these issues.


Currently, I have replicated most of the main functionalities of the original code. Only a few minor details related to appearance and database exception handling remain, which I plan to address next week.

Week 2 Progress & Understanding QuickTime Virtual Reality

Hey everyone! 👋🏻

It’s time for another update on my GSoC journey. Week 2 brought forth numerous challenges and learning experiences. Let’s delve into the details of the work I completed.

Task 1: Line Thickness Does Not Work as Expected

While this task seemed simple at first, it turned out to be a bit more involved than expected. The issue was that lines weren’t rendering correctly when certain thickness values were set.

The fix itself was straightforward, but I needed to spend time understanding the intended behavior in Director. This involved creating test movies to compare the line rendering in ScummVM vs Director.

Task 2: Enhancing QuickTime Player with New Chunks and Opcodes

QuickTime Virtual Reality (QTVR) is a special type of file that lets you experience panoramic images and 3D objects in a more interactive way. It’s like a 360-degree photo that you can move around in and explore.

The aim is to enhance ScummVM’s QuickTime player with VR capabilities by incorporating new chunks and opcodes. But before starting with the implementation, I spent time reviewing and understanding the necessary documents and resources, which will help guide the implementation.


Week 2 is complete, but the GSoC adventure is far from over. Stay tuned for more updates on my progress!

Working on Resource loading and Misc Refactoring

The main objective of this week was to start re-writing code that was stubbed while compiling the engine. We chose to handle the methods dealing with loading assets and reading configuration files first. This could be followed by writing code to render graphics, sound and rest of the components of the engine.

I started off this week with some simple refactoring tasks. I wrote a few shell scripts to automate this process.

  1. Wrapping the entire code under the QDEngine namespace.
  2. Remove redundant files.
  3. Add our copyright headers at the beginning of each file.

This weren’t as hard, but took some time to get done with.

The initial stage of our engine looked something like this. It was a blank green screen with multiple logs in the terminal.

Initial game screen.

Here on I started writing actual code. The process to deal with each stub is quite straightforward. You track down the function where the stub is being used. There on you understand how that is being used in the context of our program, and then eventually replace it with the appropriate ScummVM API. You can take a look at this commit for reference. For the final step, I would mostly consult with sev. He would give me a rough idea about which headers to include, and which APIs to study.

The initial stub messages were quite straight forward to deal with. They didn’t really have a very deep call stack, hence tracking them down was also quite simple. However after the initial few stubs, the process got a little more complicated, and I couldn’t simply track down the exact code flow. Even if I did, it consumed a lot of my time. Hence I chose to use a debugger (lldb in my case). The debugger gives you a complete break down of the call stack and the value of the variables which helps you reverse engineer your problem much faster. I would put a breakpoint at each stub message and check the call stack to understand how did we land up here. This really sped up my process.

The call stack leading up to GetAsyncKeyState STUB.

This week, I focused primarily on initial refactoring. Over the weekend, I began working on rendering the first graphic on the screen. I am currently in the process of re-writing this functionality and aim to render the splash screen next. Following this, I will explore how the engine handles game rendering.

I am excited about the progress and look forward to showcasing actual graphics in the coming weeks.

AGOS Engine – Week 2

DISCLAIMER: I had my exams for a week, hence I could not make sufficient progress

After my previous commit my mentors had made me realize that I did not take into account the game controller players. My keymaps would not identify controller key binds. Below review shows that I had made these two major errors, rest were small like naming conventions etc.

I was able to insert the yes/no option easily into the keymap. But the issue arose on how could we check if any of the controller key binds have been pressed. First I tried to loop through the const HardwareInputTableEntry defaultJoystickButtons[] and add all button into the keyMap action but I was advised that it is not the right way as it would look too cluttered when keyMap is accessed by the user. As of Saturday I am still stuck at this and hopefully I will be able to come up with a solution by the end of the day as next week I have to focus on another engine.

PR: Github

Compiling the engine

Continuing from where I left, in this blog I will give you an overview of the progress made in the first week of GSoC. As I mentioned previously even though it has only been 1 week since GSoC has started, I have been working on this for quite some time now.

The initial phase of the project involved setting up the engine inside of ScummVM. Luckily, Sev already had the skeleton engine with him. We cloned that repository inside `engines/qdengine`. The next step involved moving the project files into `engines/qdengine` along side the skeleton engine. Since the source code of the engine was open source, this was not a challenge.

  1. This is how the skeleton engine looked like at the beginning of the project.
  2. This is the commit where I add the engine source code.

Once we had the project files inside ScummVM, our first task was to compile the entire source code. This process involved one of two simple methods: either including the “qdengine/core/qd_precomp.h” header in the files and defining unknown types or methods there, or stubbing that portion of the code with the `#if 0` directive. leaving a ‘STUB’ message behind. The end goal of this phase was to minimise the amount of code that was commented out while getting the project to compile.

After adding the majority of the project, my mentor suggested that it would be a good idea to try linking the project to find any missing pieces, and eventually add them. This would prevent us from wasting effort on redundant files. The process of linking the project was straightforward. We needed to find the entry point of the application and put that in the `engine.cpp` file—in my case, this was `qdengine.cpp`. When compiling the program, the compiler would run through all methods called, and if it couldn’t find something, it would give a linker error. I would then grep for the missing identifiers, add their corresponding files, and repeat the process until all errors were resolved.

After roughly 2-3 weeks of hard work, I managed to compile this massive engine. In the following weeks I will work on getting each individual component of the engine to work, and de-STUB those portions that were stubbed initially.


Week1 – Start

In the first week, my main task was to replace the original PHP server code with Python code. My plan was to use the Flask library to create a web server.

During the first week, I primarily focused on rewriting all the functions in the original db_functions.php file. This mainly involved operations related to MySQL and SQL statements, so I used the pymysql library to complete the rewrite. The commit record is here:


However, the appearance displayed on the web page cannot be generated as simply as in PHP using statements like echo "<h2><u>Fileset: {$id}</u></h2>";. It needs to be rendered through Flask. Therefore, my focus for the next week will be on the design of the appearance (tables, forms).

As of now, I haven’t encountered any significant technical difficulties. It’s just that there is quite a bit of code that needs to be replaced, so it will take some time.

Community Bonding Period and Week 1 Progress

Hey everyone! 👋🏻

This time around, I want to share what I’ve been up to during the community bonding period and the first week of actual coding. But before we get into that, let’s rewind a bit.

So, during the initial part of the community bonding period, I had my college exams. It was the end of the academic year, so naturally, a good chunk of my time was dedicated to preparing for those exams. After wrapping up the exams, I could finally shift my focus to the GSoC project.

My main goal during this period was to better understand the working of Director. I kicked off this process by reading the “Director 3.0 Interactivity Manual.” This manual provided  insights into how Director games work and the various functionalities it has to offer.

To get the different versions of Director up and running, I installed Basilisk II, an open-source 68k Macintosh emulator. This allowed me to use a Macintosh-based system with Director installed on it.

Comparing Movie Behavior in ScummVM vs Director

A movie in Director is a multimedia presentation that combines graphics, sound, animation, and interactivity.

One of the initial tasks involved comparing how movies behaved in ScummVM compared to Director. This comparison was important to identify any differences in how the movies functioned and looked. I noted down any differences in the functionality and visuals.This documentation was created to help fix these differences later in the development process.

Task 1: Verifying “The Apartment” Functionality

If you’re curious about “The Apartment,” it’s basically a collection of movies that serves as a showcase for different features of Lingo, which is the scripting language used in Director.

One of my initial tasks was to verify that “The Apartment,” originally created in Director 2.0 and later updated for newer Director versions (D3, D4), functions identically across all versions in ScummVM.

Task 2: Verifying “Lingo Workshop” Functionality

“Lingo Workshop” is essentially a collection of movies designed to demonstrate different functions of Lingo.

Another task involved comparing the behavior of individual movies from “Lingo Workshop” when run on ScummVM and Director.

Getting into the Coding Tasks!

Task 1: Handling Empty Text in Selection Logic

This task was straightforward. It involved handling empty text in selection logic. I added a guard clause to address the case where the text selection is empty, which prevented crashing. This fix also resolved the buildbot complaint about the failing test.

Task 2: Fixing ZoomBox Animation:

When running ScummVM in desktop mode, the zoom box animation wasn’t positioned correctly because the calculations didn’t include the stage offset. My fix added this missing factor, ensuring the animation now works properly in desktop mode.

Task 3: Fixing Copying and Pasting of Cast Member

Everything that appears in your movie (graphics, text, video, audio, etc.) is referred to as a cast member.

This task involved a significant debugging effort. The issue was that copying and pasting a cast member multiple times would crash ScummVM.

The root cause was that the copy/paste functionality wasn’t properly duplicating cast members. On the first copy, a new cast member would be created, but it would share the same memory address as the original cast member. Subsequent copy attempts would then delete this shared cast member, unintentionally removing the intended copy and leading to a crash.

With the help of debugging messages from ScummVM and debugging tools in Visual Studio, I figured out this issue and fixed the problem by ensuring that cast members were correctly copied and pasted.

Final Task for Week 1

Creating Test Movies for Various Ink Types

In Director, “inks” refer to the different ways that graphics elements can be blended with the background.

I created test movies in 1bpp (bit per pixel) format, showcasing all the ink types available in Director. The plan is to develop unit tests for these ink to ensure they render identically in ScummVM and Director.


That wraps up the community bonding period and my first week of GSoC! I’m eager to dive deeper into the project and share my progress along the way. Stay tuned for more updates!

AGOS Engine – Week 1

The easiest way to start identifying where you need to replace the Enum values is to search the word “key” in that project. This way you can narrow down which files you have to go through.

Now in terms of how to define keymaps, there is initial documentation available in ScummVM website. But that won’t be enough to start, it is important to look through previous commits in ScummVM github to find similarities in the current engine in which keymap is being integrated. This is how I identified the keys and made initial keymap, I divided the keymaps into two, Engine(AGOS) Keymap and Game keymap. Engine Keymap contains key bindings which are same throughout the all the games of that engine and Game keymaps are specific to that engine.


There were two issues I faced, in the previous commits when they were adding custom key binds, they would usually customize or replace Event object based methods for example here. But AGOS engine in most places did not use event.type to identify key binds, rather it used _keyPressed.keycode, but there was a solution, I searched previous commits thoroughly and thankfully I found SKY engine commit which would track EnumAction _action and then make necessary changes to it.

Another issue I ran into was that after I had completed my keybind was that my method wouldn’t take continuous input when key was held down, The mistake I was doing was I would reset the –
   _action = kActionNone
each time after the keys were processed, instead I should’ve  reset it when
Hence, that solved the problem.

My Commit: AGOS: Add keymapper support


It has been three weeks since GSoC results have been announced. All this while I have been working with sev to get a head start on the project. Although I started working on the project pretty early, I haven’t gotten a chance to talk about the progress we have made. since this my first post talking about GSoC, let me take this opportunity to introduce myself and bring you up to speed on our progress.

Hey, I am kunxl! currently I am third year undergraduate student at IIT Jodhpur. Lately I have been tinkering around with graphics programming using Vulkan and openGL.

Over the summer I will be working on porting the QdEngine to ScummVM. To give the readers an idea of ScummVM, it is a software that allows users to play old adventure games across all platforms. It does so by modifying the underlying engine-runtime with its in house APIs, that abstract away the operating system. QdEngine is an engine built by KD-Labs. The most popular game made using this engine is Pilot Brothers 3.

The code for the engine is open source. So far we have managed to compile most of the required project files. In the coming weeks we would be linking our code and hopefully be able to display some graphics onto the screen. I wouldn’t go into actual code changes that I made; I’ll save that for future blogs XD.

This is a hefty project, and hence I expect to make significant progress week by week. I’ll keep you posted on our progress.