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
Now, the changes to these functions were done directly in MacMenu. Adding a macpopupmenu.cpp to the project is resulting in LNK2019 error. I had tried resolving it before writing the constructor, but then went ahead with just the header. I will try to fix it again now and override them in the MacPopUp class.
