Month: July 2022

This week, I mostly worked on the 2 issues that I mentioned in my last week’s blog post.

I started off with the resource checksum implementation in ScummVM. VWCF Resources in D4 and later have a checksum and use an algorithm to check that. The algorithm was reverse engineered by djsrv and sev. These changes have been merged to master.

This functionality is important for implementing saving and loading of movies in D4 and later movies. There was a prior discussion with sev and djsrv (though it was very brief), but we would be implementing movie save and load in the engine too. sev said that he will see whether it will fit into my GSoC time line or not. Given that there are a lot of weeks left, this might happen.

The next issue I picked up (and am working on currently) is loading the resources based on the parent-child mapping given in the KEY* resource instead of just loading the first resource in the map.

Have a look at here. In one of my previous posts, I had mentioned about the multiple casts in D5 and later movies, where the concept of shared casts is obsolete. Currently, we are assigning Chunk 1D 1024 to the current movie. So children of 1024 are actually children of the current movie. Taking the case of castmembers, castmembers owned by parent ID 1024 are actually castmembers in the _loadedCast.

I plan to remove the usage of getFirstResource and change them all to the indices read by the KEY* parent-child mappings. This would be an improvement to the resource loading of the engine.

I have some tests going on at my uni, so I might have erratic work hours on some days. But I would continuously work the issues and push my work.

Looking for a great week ahead of me!

This week started with me finishing the Windows fonts changes. It required some changes in a lot of assorted places. In the process, I broke the desktop mode of director engine (It gives a black screen with a warning now), I am taking a look at that.

My older PRs also got merged this week, with the offset rect one still being open (I didn’t do the changes. I am also having a look at that now)

After this, I had informed sev that I won’t be able to do a lot for a couple of days, as I was travelling back to my university. I am here again.

After this, I picked up working on the window properties: https://trello.com/c/g1BaUzXz/292-missing-window-properties
I had wrestled with this in the past for a brief period of time, but I didn’t have any success. Thankfully, sev had directed me towards the code that made the first property I worked on, the titleVisible, fairly straightforward. Then I followed suit for modal, fileName and windowType (the last two still need some work)

I am not able to test my changes with the window properties as I have run into some issues with BasiliskII, where it is not opening other dictionary movies. But I can get this fixed, or maybe make my own movies for testing, while having the changes as draft PRs 🙂

I plan to pick up Calculate Movie Checksum (https://trello.com/c/BpdScbbQ/501-calculate-movie-checksum) and Use KEY* More (https://trello.com/c/sHMquaRS/500-use-key-more) next. According to sev, Movie Checksum calculation would be fairly easy to implement. And using KEY* chunk mappings would solve a lot of missing resource issues we currently encounter in ScummVM.

This week’s progress was mediocre at best. I had to travel and was not in the best of health, but I hope to (I must) have better progress in the coming weeks.

Looking ahead to another exciting week!!!

The title might seem a bit vague. Don’t worry, I am listing what I did and what the week was like.
First thing I did this week – Remove all instances of _loadedCast outside of the Cast namespace. I had been indiscriminately using it, and there were some places where it was already there (although fewer instances than what I had introduced). sev told me that this is something wrong. Till D4, we have a single cast for each movie, and a shared cast for all the movies in the project. But starting from D5, the concept of shared cast became obsolete, and a movie can have more than 1 cast. I did the required refactoring for this. Now we have barebones support for multiple casts (barebones = just an array a hashmap of casts with the first one being the loadedCast).

Next, we had The Apartment movies. sev asked me to look into this, as this would give me a better idea of how to tackle issues for other targets (like Meet Mediaband).
The issue was unintended navigation. while D2 movies worked fine, D3 and D4 apartment movies, (particularly the Pattern Viewer movie) would navigate to the help screen on pressing the next button, even when they were not supposed to.
This turned out to be a pretty interesting issue. Here is an image to help understand what was happening:

I hope it is readable. This is the D4 messaging hierarchy. Specific events are passed to the various scripts in a specific order.
Now there are these 4 scripts that can act on an event -> movie script (Applied to the whole movie), frame script (a score script applied to a whole frame), sprite script (a score script applied to a certain cell to a sprite) and the castmember script (script attached to a castmember).

Turns out, there were some quirks of both D3 and D4 about handling these messages. Explaining theme here would be a lot (these blogs are meant to be a quick summary of what I was up to), but I made 2 test movies as sev said it would be important in understanding exactly how things work and what is wrong with our implementation. You can check them out at github.com/scummvm/director-tests and load them in Director 3.1 and Director 4 to play around.
djsrv had also done some digging with the message hierarchy, and she seemed to quickly understand what was wrong. She sent a patch to be applied and see if it works. Turned out that code worked (it basically rectified our event handling). So the code that solved this issue was djsrv’s.

Next, QuickDraw shapes were not showing up in D4 apartment movies. This one had a very easy fix, but I went looking for the cause in a completely different direction, checking potential resources we might not be loading, why the shapes didn’t have a CastMember assigned (as they were QuickDraw sprites, duh)

Now, QuickDraw sprites don’t have a castmember assigned as they are dealt with in the channel (That’s how I perceived it). While looking at the code for instances of handling QDShapes, I found that something was changing the spriteType of QDShapes from Shapes to CastMemberSprite. I looked deeper, and it turned out that we changed the spriteType od sprites based on their associated castMember for Director 4 and above. As QD sprites have no castmember assigned, their spritetype falls back to the default.

After this was done, I took up loading Windows Font for the mcluhan-win target.

This target used 3 fonts in .FON file format. First issue was – we use a fallback font when we can’t find the specified font. But we don’t return this information (we do display a warning though). There is a check in this movie where it queries whether the specific font is installed or not. We used to fulfil this check even when we do a fallback to some other font.

Next -> implement loading of windows fonts for director, and use them in director movies.

Now, this issue took longer than expected (and I don’t know if it is completed or not). One major reason was monsoon.
My city has been flooded due to constant downpour from 2 days.(by flooded, I don’t mean the houses submerged and emergency situation, I mean the roads are submerged, fallen electricity lines and telephone lines). There were 2 instances of electricity and internet outages that lasted hours (the second one was around 22 hours)

I had discussed this with sev and djsrv about this issue so I was able to work on them, but with hiccups. And I don’t know yet if it is complete (as stated previously).
I added loading of FON fonts to the MacFontManager for this and looked up some documentation of FON format to also extract the font name (Though it works for FON files with one font in the FONTDIR, I didn’t write it for all entries). Then adding of quirks and other things. One thing that bothered me was that these components are used commonly among engines (like WAGE, PINK and MTROPOLIS use the MacFontManager), and there were some instances that used constant pointers or passed parameters by value instead of by reference, which made an elegant implementation difficult. I couldn’t change the argument type or the return type, as it would mess up 50 other things in other engines, so I wrote it (though it looks bad to me. I believe it would become better after a review)

This turned out to be a long post. This week, when I picked up the apartment issue, I thought of solving a bug a day. Nearing the end of the week, it didn’t quite turn out to be that way, but this was a happening week. As always, I got all the guidance and support from my mentors and the Director Engine dev team.

I am looking forward to an amazing week now. Also, I will be going back to my uni this week. So there won’t be any blackouts then 😀

Thanks for reading.

PS: Turns out the image is not legible. You can check it out here: https://imgur.com/a/EOEgZMc

This week revolved around implementing importFileInto command for D4. I didn’t think it would take this long but one thing led to another.
So at the start of this week, we figured out that Director also uses the PICT file format for it’s BitmapCastMember. This was found in the “importFileInto cast” workshop movie. sev asked me to write a general PICT renderer based off WAGE engine’s sprite renderer.
I ported WAGE’s sprite rendering into Director, but it didn’t work. I checked the PICT file we had, blend1.pic
Looking at the bytes of the file, I found that it was a PICT version 2 file, with word offsettinng instead of byte offsetting (1 word is 2 bytes here). While the WAGE based renderer was not accounting for word addressing. Also, while debugging why the renderer doesn’t work, the code logic didn’t fit in with the raw hex data of the PICT file I had. It was as if it looked at the wron opcodes, or wrongly read other data.

So I looked for other implementations of a PICT renderer. I found this really good image decoder, deark. This worked great with the PICT images and was written in readable C. I asked if I must switch the current implementation to something based off this on the discord channel.

Here, eientei pointed me towards image/pict.cpp, which had a basic PICT renderer similar to deark’s implementaion, but it only had support for PICT version 2 and for bitmaps (many opcodes like the ones for primitives were simply skipped). The PICT renderer worked for the files we had, but as the images were 32 bpp, the movies had to be forced to run in 32 bpp to run correctly.

So, sev then implemented a naive ditherer, and Floyd-SteinBerg ditherer to dither 32bpp images to 8bpp.
My next step was to add PICTv1 support to ScummVM too. sev found a PICTv1 image “Face.pict” (can be found here). I added byte offsetting and the version and Rect opcode in the existing image/pict.cpp, and It showed some results. Apparently all the tests we used till now had bitmap data in them, the only thing that works in ScummVM’s PICTDecoder. I would find an example with primitives and add them too.
The decoding worked, but it had the wrong palette. sev then proceeded to fix it, as I wasn’t able to grasp the solution to this fully and he said that it is a short fix and I can see the changes once he does it. And it is in a semi-complete state as of now (it works in 32 bpp, but palette mapping is not working)
Last night, I was made aware of the fact that I must not use _loadedCast indiscriminately to manipulate the CastMembers. This has an important reason. Every version of Director is different from the last one in some way. It turns out that D5 had multiple casts, instead of the single + shared cast of D4. We already have CastMemberID, which has 2 integer fields, member and castLib. While member referred to the ID of CastMember, I wasn’t sure about what castLib did. Now this is something I think would be my next task -> implementing multiple casts and integrate _loadedCast and _sharedCast in them.
I also pushed some shoddy work yesterday, which was a total let down. I am very sorry for what went down then.

The BUILDBOT had encountered some issues this week, which were fixed. It then revealed some build which were failing due to my changes. I pushed the relevant fixes for the failing builds.

This week was full of learnings, but the code pushed was less than what I intended at the start of the week (I feel it is that way). I mentioned to sev about starting bug hunting in Meet Mediaband, but he told me to keep it on hold for the moment. My first work tomorrow morning would be to work on multiple casts (I must discuss this with sev too once) and then I must have a discussion with sev about tasks, so we can continuously build the Director Engine.

I must sign off now. Thanks for reading. Looking forward to a great week ahead of me.