WEEK 8: Finalising KEY* and update

This week, I tested and finalized the KEY* Pull Request. It is good to be merged now, and shouldn’t be adding any regressions.

moralrecordings streamed a playthrough of  Eastern Mind: The Lost Souls of Tong Nou on this twitch link. It seems that this game now runs much better than it did 7 months ago, that means that support for D4 games is getting better.

My first task for this week is to look in the BITD rendering regression for 8bpp. sev pointed me towards this commit, this did enable the BITD rendering for 32bpp mode. I have been advised to retain the 8bpp rendering which worked before this change along with the 32bpp which works after this, while introducing no new regressions.

This week, there wasnt much progress, as I had some interviews which ate up a lot of my hours. But that is over now, and I will resume work full time now on the tasks. The next issue in line would be fixing text in buttons in 32bpp, and I would move onto other issues then.

Looking for a great week ahead!

WEEK 7: Resource loading from KEY*, looking at text rendering in 32bpp

This week, I completed the resource loading from KEY* chunks. This change implements the correct loading of the following chunks:

  • CAS*
  • VWCF
  • VWFM
  • FXmp
  • Fmap
  • VWTL
  • STR
  • Lctx
  • Sord
  • VWLB
  • VWFI
  • VWSC
  • VWAC

Earlier, we were just looking for the first resource of these resource types and load them. But these resources are owned by the movie, and the right way is to load them from the KEY* resource.

Now, I am looking at these issues:

I am taking a look at the widget of Button castmember to check the text in the widget in 32bpp mode and other modes.

I had a crazy week full of tests, so I didn’t have a lot of progress this week. But I am happy to have passed the Mid evals, a huge thanks to sev and djsrv for that. It was made possible with their help.

Looking forward to a great week ahead!!

Week 6: Working on stuff related to resource loading

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!

WEEK 5: Working on window properties

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!!!

WEEK 4: Fixing things

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

WEEK 3: importFileInto and the PICT file format

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.

Not 32bpp
32bpp
Notice that you can clearly distinguish three prominent columns. This gave away what was wrong

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.

Second Week – some bugs and new stuff

This week’s plan was to get the STUBs done. At their current state, I won’t say ALL of them have been addressed, but yes, very few of them remain, and some of them can’t be done right now (more on that). This week’s work can be seen here.

The STUB list can be referred to know the current state of STUBs.

  • LB::b_saveMovie() : something sev mentioned on the #director-engine channel. This would be a project in itself and there is no code around it. Saving is currently not supported in ScummVM’s Director Engine and this STUB would need some time to be implemented.
  • LB::b_setCallBack() : This needs to be adressed when I encounter this command while playing one of the director targets. The documentation to this is vague. here:

    • The third point is not very clear. It appears as if this would involve the implementation of the specific factory object, and the interactions between that and the XCMD or XFCN callbacks are not generalised.
  • LB::b_playAccel() : Deprecated since D3
  • LC::cb_v4theentitypush – kTEAMenuIdItemId and LC::cb_v4theentityassign – kTEAString : These will also be implemented when I encounter their usage. The MenuIdItemId is probably creating menus from scripts, but that is just speculation. I haven’t encountered their usage and their purpose is not documented, so I would have to encounter them first
  • LM::m_moveToBack() and LM::m_moveToFront() : These will be tackled along with this.

There were some things which were fixed this week, like checking for constraint before rendering sprites, acknowledging movable sprites as active.

There are some things which ScummVM would never be able to fully support, like openDA and closeDA, which open the Macintosh’s Desk Accessories like calculator. To be honest, I don’t thin many games which target both Windows and Mac might be using it. There is the open comman too which opens any document in the application specified. ScummVM can’t run arbitrary applications.

I took the liberty of modifying some commands in the way they work (these commands were mainly used for debugging in Lingo and sev said that those are basically no ops for us, so can be ignore) like showResFile and showXlib as we have a REPL Lingo debugger in ScummVM.

While I looked into importFileInto cast Lingo command, we realised that the BitmapCastMember uses PICT files. So I would be porting WAGE’s PICT handling code for that. The remaining STUBs (5 exactly: param, importFileInto and special cases of framesToHMS, HMStoFrames and openResFile) I intend to do in the next couple of days (param has a bug which I can hopefully solve tonight, importFileInto would need work and for the others, I must discuss with sev and others.)

So this week, I can start looking at Meet Mediaband. Personally, I have never seen anything more interestingly weird than that. There are bugs in UNDO ME, Macaroni Man and HOUSE JAM, and the popupMenuXObj needs to be implemented. I had alotted 4 weeks of time to work on Meet Mediaband, and I believe that would be enough to fix it and clear up my trello cards too! Hoping for a productive week ahead.

First Week!!

This week was quite eventful. sev assigned me some tasks in the Trello board for the director engine. I have shared the link to that in my previous blog post.
I first tried my hands on the window properties task that was assigned to me on Trello. I had some progress in finding the cause of the issue, but didn’t have any code to push (this was the first day of the week). So I kept it for later and started working on the STUBs in the Director Engine codebase. A github gist of the STUBs.

This gist doesn’t contain some STUBs I had implemented at the first day of week. Still, it has all the ones that are unimplemented. I will add a strikethrough to the ones that are done.

This week I created 19 Pull Requests. 14 of them are merged. 4 are open and 1 is a draft (Though that will be open tomorrow). 18 of them were implementations of STUBs. The lingo properties now don’t have STUBs (yay!) (Actually one is left, but I have figured that out. Need some sleep and then will push it)

I also refactored the RIFX Chunk dumping so it dumps all Archive chunks now.
You can see all my PRs for the week, sorted by last updated here.

I had 2 non productive days this week. One was when I had some mild fever and was exhausted. Second was my birthday, I turned 20 this week. So there wasn’t much progress these days.

But seeing how things went this week, I am sure that I can implement all the STUBs in Director Engine’s Codebase next week, which would be inline to what was my goal for the first two weeks in my proposal. Then the issues won’t be about missing code in Director, it would be about wrong code. So it would be all about resolving bugs in various targets like Meet Mediaband, The Journeyman Project, Spaceship Warlock.

Speaking of targets, hsrtron playtested The Seven Colours : Legend of PSYS City. There were a few issues with the target :

  • Wrong palette in the corridor (This is an issue while importing palettes from sharedCast)
  • Animations are quite fast at some places
  • Not being able to leave the first level (sev identified this as an issue of not checking for punycoded file paths)

These issues have been documented on the trello board. sev also pushed a quick fix for the game’s cursor. Seems like this target is also being one which we would be using to fix the Director Engine and will make it work just like the original.

So this would be another target for me to tackle in my coding period. This week, when I get done with the STUBs, I can start looking for the source of bugs in the targets I mentioned in my proposal. I can also finish my trello tasks one by one (as they are identified bugs)

Looking ahead to an even more eventful and productive week!

Official Coding Period Begins!

The GSoC coding period has begun, and I have some tasks in my kitty for the week.

Starting with the updates from last blog. I got the MENUREF working! The Pull Request for same is opened. I also implemented the Text and Font related STUBs.
The Discord user hsrtron#3373 had translated a D3 game (The Seven Colours: Legend of PSYS City) but this had some issues, with a wrong color palette being the most evident one. While ScummVM had most of the palette implementation required to use custom palettes, there were some missing links. After changing a few things, we could run the game with its intended color palette!

I talked to sev about my apprehensions of making different git branches for every task, and turns out its fine!

Also, I got added to the Trello board of the Director Engine so I can pick up the ToDo tasks from there and complete them. Link

Now my tasks for this week: Complete the implementation of window properties. I would try to do this soon. And then move on to making all archive types to dump all movie chunks.

Looking for a great week ahead!!

Working on STUBs

The community bonding is going on, and I managed to push some work on unimplemented STUBs for director engine in till now.
The first issues I picked up in this period were of implementing the move cast command and the findEmpty builtin function. I completed them and then moved on to the Menu properties.

I implemented the MENUREF datumType to generalize the setting and getting of Menu, Menus, MenuItem and MenuItems properties in the existing setTheEntity() and getTheEntity(). Changes to MacMenu and MacWindowManager were done to accomodate these changes and remove duplicacy of code. While the lingotests and workshop movies passed the changes, the BUILDBOT failed on some Director Games. I would fix these as these properties are used in a lot of targets.

I then resolved a couple of small issues (stageColor and b_union) and sev then asked me to implement font-related properties (kTheFont, kTheTextHeight, kTheTextStyle, kTheTextSize). The setters of these properties were taking wrong inputs and I implemented the required functions.

The changes described in the last two paragraphs are under review. I have submitted Pull Requests on them and can be seen here.

One thing I am guilty of – not having a single seperate branch on my fork to which I make commits. I usually make different branches for different issues I work on to isolate them from other changes I might make on other issues. I will make a dedicated GSoC branch on my fork so that all my commits can be viewed in a single branch.

That was all, thanks for reading!