Month: July 2022

Work on WAGE continues this week too. I started by writing some test games which rendered multiple different shapes in different styles so I could get ScummVM to match the original as close as possible.

A common problem with all shapes was how thick borders were handled. The border was supposed to to increase in width equally on both sides of the shape’s edge but it didn’t which made the shapes larger than they should have been. This was easy to fix and I did it for all the shapes.

Now to discuss the individual shapes. Rects had the same problem as before with being a pixel longer on the right and bottom so that had to fixed.

For Polygons the way the line was being drawn didn’t match the original perfectly. ScummVM uses the Bresenham’s line drawing algorithm for drawing lines but mini vMac either uses something else or is changing the end points of the line… There’s a difference of a pixel here and there in the lines which is minor but visible, specially at certain slopes.

For ovals there was another problem with the borders. The thickness had to be uniform throughout the perimeter so I had to change that. And again a similar problem as with the polygons where some lines didn’t quite match.

Now to deal with the individual game bugs. Most of the are resolved and right now I only have 2 more left to deal with. I hope those don’t take much time as I have already spent quite a bit of time on WAGE and would like to move to the next engine.

That’s it for this week and thanks for reading!

Another week spent on working on WAGE and I am getting closer to finishing up.

Continuing the issue with the font from last week, we decided to just hardcode the correct font as the game might have been using a different version of the engine with different behavior.

After that I worked on implementing the about screen. Different games do different font types, sizes, alignment, etc. so I just went with a general center aligned screen. It took some time to get the alignment working properly but I managed to do that.

There were a bunch of game specific bugs left to deal with, 24 to be exact so I started working on them one by one. There wasn’t much in terms of how I solved them and the process was to just set some breakpoints in places related to the bug and see what’s going wrong.

To fix them I had to implement some game specific fixes but I think it’s the only way as they all might have used a slightly different version of the engine.

The only notable task from these fixes was to add more resolution options to WAGE. Originally it was hardcoded to run at 512×342 but now it also supports 800×600 and 1024×768. This was necessary to support some games which needed larger windows.

Currently there are 13 tasks left and most of them fall under the category of “Ignored bytes while rendering” and “Unhandled comparisons while executing the script”. I don’t have a good idea of why these are caused but so far I haven’t found any difference in the behavior in the Original vs ScummVM so they might be harmless after all. I’ll look more into them and that should be the last I have to do.

Thanks for reading and see you next week!

I started working on WAGE this week and it has been the most challenging engine so far. Some tasks took a long time to finish but I am happy to say that I managed to fix them 🙂 There’s still some work to do but I am expecting to finish that this week.

In this blog post I’ll just talk about a really long chain of issues. So one of the game wasn’t looking like it was supposed to.

The immediately obvious problem is that things are moving, more specifically the windows and the right side corners. Looking at just the bottom right corner would make you think that it’s also moving diagonally with the windows but that’s not the case actually! It just appears to be moving diagonally because of the pattern it has. The top right corner makes it more clear that they are actually moving sideways.

So the first thing to fix was the corners and after going through the code responsible for it I realized that it’s a problem with the code drawing the corners. The rounded corners are drawn by drawing horizontal lines of varying widths and the problem was that the right side was being drawn a pixel longer. This was because the code didn’t consider that we don’t use the right and bottom edges of a Rect.

However I couldn’t just change this code to fix things because other engines were already using it and had accounted for it’s weird behavior in their own code. After confirming that they were indeed working fine with the broken version of the code (which took a long time), sev came with the idea to create alternate versions of the functions with the correct behavior and use them where needed.

After that I just hardcoded coordinates for the window to see if that’s the only thing wrong with it’s position and that’s when I found another small issue.

It’s a bit hard to see but the image inside the window is surrounded by some empty space. This one wasn’t that hard to fix and was caused because the dimensions were being calculated before the title for the window was set.

Next was actually fixing the window coordinates. This took some time going through all the relevant code but eventually I did found out the problem. If you look at the window border you can see the squares at the corner which extend past the window edge by 2 pixels. The coordinates in the game data didn’t consider them but ScummVM would position the window from their vertex. To fix this the code just added 4 pixels to both dimensions. However it just added them to the bottom and right edge. To correctly fix it I had to subtract 2 pixels from the top and left edge and add 2 on the other ones.

However this brought another problem to light.

Even with the window at the correct position, the title itself wasn’t at the correct position. This one took a lot of time to fix. The biggest problem was in actually understanding how the borders were drawn. I could see that it in a file called nine_patch.cpp but I neither knew what the name meant or what the code was doing. The text was rendered after the border so I decided to see if I could fix it’s alignment first.

The problem with this was simple, there’s supposed to be 5 pixels of padding between the rect and the left and right sides on the text. However the font itself had a pixel of whitespace around the individual characters. The padding only had to be 4 pixels on each side to look correct. I changed it and that made the text aligned.

However the Rect itself was in the wrong position and that meant going back to nine_patch.cpp to fix it.

Initially I was just thinking that it(nine patch) was just weird name choice and not a specific thing which exists. But after a long time of just looking at the code and understanding nothing, I decided to just google it because nothing else was coming to my mind. And it turns out that it is a way of storing borders to draw them at any resolution. All the resources online seemed to Android specific but the basic concept was still the same and with that knowledge and some stepping through I managed to get a good idea of how it was working.

I won’t explain how nine patch works here because there are already some online resources which will do a better job so let’s just focus on the problem. The Rect is supposed to be centered on the border but because of the Rect had an odd length (67 pixels wide) and the border even (306 pixels wide), one side would have one more pixel than the other, 119 and 120 to be specific.

Which side gets which length would depend on the implementation of the nine patch but for ScummVM it was the exact opposite of the Original behavior. To fix it I just had to change how it was rounding the length after dividing it into two. Rounding to the nearest integer makes it match the Original.

With that fixed I can get to the last issue and that is the font in the second window being different. I haven’t made a lot of progress with this but based on what I have seen so far, the font type is correct but the size is wrong. There are also two more other issues pending for now.

With only one week left in the coding period, I’ll be trying to finish everything in time so look forward to the next blog to see if I could do it ?.

Thanks for reading and see you next week!

Continuing from last week, I fixed all the remaining issues with PINK so I’ll just go over them in this blog.

First thing I worked on was to disable the country name menu items in Passport to Peril. Unlike in Hokus Pokus Pink, the country items in Peril have a submenu to jump to any section which means they don’t need to do anything when clicked.

We don’t want such a dialog because they don’t have any functionality to implement in the first place. The fix was relatively easy and all I did was to prevent it from firing an event when clicked. Commit which fixes this.

The next issue was to fix the menu behavior in the hebrew versions of the game. There are two different menu behavior which can be used: First is the Mac mode where you need to keep to mouse button held to keep the menu open. Second is the Modal mode which keep the menu open unless you click out of it.

Modal mode is what was expected but it’s tied to Win95 mode (because it’s how menus behaved in Win95). However we can’t use Win95 with the hebrew version because the font it uses lacks hebrew support.

The fix was to add a flag which forces Mac fonts to be used and to enable it when the hebrew version of the game is loaded. Now we can keep Win95 mode enabled to get the Modal mode working. Commit #1, #2.

Next issue was a weird bug where some submenu items in Peril were disabled. This wasn’t the expected behavior as the actual game has the items enabled.

First thing I did was to ensure that the code responsible for creating the menu was working as intended and indeed it was. After that I opened the exe in a hex editor to check the flag which sets the menu item status. The result had me surprised because the items were indeed disabled.

I talked to sev about this and it turns out that the menus are later enabled by a different function. So I also implemented a similar function which goes through the menu recursively and enables the items. Commit.

Last issue was to show the last 10 saves in the menu. This was kinda straightforward and I just get the list of all saves, sort them by time and add the first 10 to the menu. There are a bunch of commits so I’ll just link the main one here. I also had to limit the submenu width to account for really long names.

With this PINK should be completed 🙂 I started going through WAGE so expect a blog post detailing my progress with it next week.

Thanks for reading!

Picking up from where I left last week, I decided to go with PINK as the next engine to work on. For those who don’t know about it, it’s the engine used by two Pink Panther games, The Pink Panther: Passport to Peril and Pink Panther: Hokus Pokus Pink.

The main issue with the engine is that it relies on ScummVM’s graphics backend MacGUI which has been updated since the engine was finished. This broke some of the functionality and introduced various bugs. My task is to identify and resolve all of these bugs. In this blog I’ll go over some of the bugs I resolved.

The first bug I had some trouble with was these transparency artifacts in the sub menu.

This one took me a lot of time simply because I had no idea of how things were rendered. A lot of time was spent just going through the macgui code to understand what was even happening. However what I learned helped in all subsequent fixes so it was time well spent.

In macgui, green is used as a transparency color. The sub menu would be drawn on a green background and then all the non-green pixels would be moved to the final screen. Originally the menu bar and the submenu were drawn together, after which there was one step of copying the non-green pixels to a screen. During one of the refactors, the rendering of menubar and submenu were split into two different functions. However the function which would copy only the non-green pixels was left out of the submenu rendering. That’s what caused the bug and as you might think, the fix was just to add that function back and that’s what I did.

Next would be the missing text in the PDA for Passport to Peril.

After some debugging I realized that the text is there but black colored which means the problem is related to setting the font color. Looking into the code, the colored font was applied to the string but then the function which appends the string to the textbox was still using the older plain string. Quite easy to fix.

Well this uncovered another bug, this time with the color which was being applied to the font. So what happened originally was that PINK’s code read a value which was a color stored as BGR and used macros to extract the individual colors which was then used to find the closest color in the palette. The id of that color would then be used in PINK’s code itself to color the text.

However after some refactors, the place where the text would be colored moved to macgui and whoever made the changes just used the BGR color value for the font. Unfortunately the value was stored as _textRGB so they didn’t realize that the colors weren’t in the correct order. If we look at the hex color code, yellow is 0xFFFF00 and cyan is 0x00FFFF which matches with what we are currently seeing. The background color might be suffering from the same problem but coincidently the only background colors used are black (0x000000), green (0x00FF00) and white (0xFFFFFF). All three are unaffected by this issue :P. Anyways the fix for this was simple and all I did was to store the color as RGB.

The final bug I would like to talk about was extremely simple to fix and was only complicated by an initial misunderstanding. So there were these two separate bugs I had identified.

I started with the misaligned text and even after spending a long time, I could find no problem with the alignment code. I even calculated the correct alignment offsets by hand and sure enough the values matched. I then decided to move on to a different task for the time being and tried to figure out why there was an out of place green rectangle.

This is when I realized that maybe it’s actually a part of the textbox and the entire textbox itself is misaligned. I checked the part which render the textbox and it was just like that. The textbox was also being rendered at an offset which wasn’t required because we were also doing it for the text. I removed the offset for the textbox and that fixed both of the issues.

I fixed some other issues too but none of them were as interesting as these. As for the progress, as of writing this only two more bugs remain to be fixed. After that I plan on going over the game to see if anything else comes up. If that goes fine then I can continue on to the next engine WAGE but that’s something for the next blog post.

Thanks for reading!