Month: August 2022

This week, I finally got to the bottom of this issue. I will describe the cause and the fix.
Now we have the MacButton widget, which inherits from MacText. Basically, we have MacText, which has a shape drawn around it, and that is MacButton for you (a cursory description). I spent time trying to find something around.
The color we use for rendering text is not the one provided to the widget but the ones stored in _textLines chunks of MacText.
This then led me to drawString() of Font namespace, then to drawChar(), and then to MacFONTFont::drawChar(), where the surface is filled with pixel data at relevant places.

Now, this flow did not have the issue. It worked as expected. I checked this for anything wrong but everything till the surface population seemed correct.
In the end, It turned out to be this. As you can see, values below 255 were inherently supposed to be 8bpp, and that is where the issue lied. I caught this by passing 100 and 150 as the bgcolor for the MacButton widget. When we might expect a gray color in case of 32bpp, I got green and blue. This clearly meant that it was 8bpp behaviour.

I got around this by templating this function for 8bpp and 32bpp surfaces, as the function which calls it is also templated according to surface. The changes are here.

Apart from this, I got an outline of how to implement the PopUpMenuXObj from sev, where I had some doubts regarding when to render the expanded menu list. That is something I would be completing now, along with the window optiones issue I had paused for some time earlier.

Looking for a great week ahead 😀

This week, I was mainly working on 2 things: popUpMenuXObj and the 32bpp button text bug I mentioned in the last post.

Clearly, the hack I mentioned in the last post shouldn’t be on the master upstream. Substituting 0x000000FF with 0x010101FF is a bad idea. I and sev delved deeper into the issue tonight, and this would be resolved as a lot of details were gathered from our investigations. A lot of functions related to drawing stuff on the screen don’t use uint32 for their colors, and this is one of the things to fix.

This week, I have also started work on the popUpMenuXObj, which is a Mac XObject used in Meet Mediaband and the Apartment movies. The popUp menu is similar to the existing MacMenu in looks (just constrained to 1 submenu and can be drawn anywhere on the screen instead of just at the top)

Currently the MacPopUp is resolving the menuLists and saves it in the relevant object, making an entry in the _windows hashmap. The next step is to actually draw the menu on screen whenever it is called.

Next week, I would be focussing on completing these tasks at the earliest and then resolving the palette issues of The Seven Colours and Windows movies.

Goodnight 😀

There were 3 issues I fixed this week. The rest of this blog will explain them.

The first one was the extra corner pixels being drawn in some rectangles.

While the first thing you will notice in this image is the distorted big black rectangle with colored streaks, that is not the issue I am talking about (Though that is the next one).

This was a simple fix of not overlapping the sides of rectangles at the corners in Graphics::drawRect()

The next issue was the faulty decoding of BITD resources, which gies us that garbled rectangle. This is in fact a regression, it worked well before BITD decoding of 32bpp was changed to support D4 movies.

I created a couple of test movies to check how BITD works. After checking the bytes of the movies I made, I realized that before D4, pixel data in BITD for 32bpp was saved in the ARGB format. But from D4, Director started saving the alpha of all pixels in a row, then the red value, then green and then blue. I was looking for some similarity in both the decodings, not wanting to branch it on the basis of Director version (I was thinking that Director might not have done such a change and there might be some uniformity I am missing), but I ended up writing decoding by a version check.

The end result:

I made sure this does not introduce a regression in D4 movies, and it works fine.

The next issue I picked up was no text in buttons in 32bpp mode. Now this one had more than one thing wrong with it. Buttons in ScummVM Director engine have a MacButton widget, which inherits from the MacText widget. While TextCastMember did work fine in 32bpp (Which uses the MacText widget), buttons had no text in them.

The first issue I found was that the foreground color and the background color being passed to the widget was same. I did change it, but there was this werid bit. The colors being passed to the widget were both black instead of white. Still, the buttons were all white (empty). When I switched the background color to any other 32bpp color, it did fill the button with that color, showing the text in white.

Also, MacText is not using the foreground color we pass for the font in the button, but uses the color specified in the _textLines chunk (A Graphics::MacFontRun struct)

The next problem I observed was that ScummVM was, for some reason, turning 32bpp black (255) into white. This was happening only for MacButton but not for MacText. This was the reason why buttons were white even when the background color we passed was black. When I passed 0x010101FF (nearly black) instead of 0x000000FF (black), the text rendering works. The solution I cam up with is quite hacky (replacing 0X000000FF with 0x010101FF for 32bpp button text), but I must find the root of why 255 is being converted to white and fix it.

This was all for this week. Looking forward to the next one 😀 !

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!

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:

• 32bpp rendering has no text
• 8bpp image decoding is broken

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