Week 12 – Working on MacVenture

3 months have passed since GSoC started! This week I started working on MacVenture which was also worked on by another GSoC student blorente in 2016. You can see his blog here. My work continues were he left off, fixing the engine to work with the newer MacGui while also implementing some new things.

The first thing I worked on was the borders.

The borders had a bunch of problems. The title wasn’t aligned properly in either direction and it was just broken when you had a window active. If you read my past blogs then you might remember how nine-patch gave me some troubles when I was working with WAGE. This time wasn’t any different either.

It took me a decent amount of time to wrap my head around how they work but eventually I figured things out and realized that the problem is in the division of the border into different areas.

The images below aren’t accurate as far as the scale of the area is concerned but it’s good enough to show the problem and how to solve it.


This was the older way the border was divided into 3 areas. The 2nd rect is stretched to fill the required width while the others are fixed in length. Also the title can only be printed at the start of an rect. This is why the title wouldn’t get centered.

To fix this we can instead divide the border into 5 rects. This time the 2nd and 4th rect are stretched to fill the remaining area while the 3rd one is of the size of the title. This way we can center the 3rd rect and the title with it.

The other problem was that active windows also shared the same set of offsets as the inactive ones. This wasn’t a problem when we were just printing the title in the beginning but with it being centered, I now had to make sure that the same offsets also worked with the active window borders. This required some tedious redrawing and testing but eventually I got it to work too.

After this I starting working on the leftover tasks from the previous work. There’s also the task of adding support for the Apple IIgs version of the games and that’s what I am working on right now.

That’s it for this week. Thanks for reading and see you next week.

Week 11 – Finishing WAGE and PINK

After last week’s blog post I opened the PR for both WAGE and PINK to get them reviewed. Let’s start with PINK:

For PINK there was a regression caused by a later commit which broke some things. The problem was that the window mode wasn’t being set and the fix was really easy. A bigger problem was the Hebrew text wasn’t being rendered properly. It has been there from the start but I never noticed it because I can’t read it.

The text is reversed and the borders are broken

Thanks to discord user rzil for the help with the hebrew text. It was kinda hard dealing with text you can’t read and it being an RTL language just made things more annoying. What I ended up having to do was to render the text in reverse order and that was enough to fix it.


With this PINK was done and it got merged.

WAGE spent quite some time in review. The first major issue was Engine code being called from inside Graphics. Another issue was with how I had solved some game specific issues. I had implemented some game specific hacks but a general solution was desirable.

Most of the issues were caused because of how object click detection was implemented. In the current system, each object had it’s own screen to draw on. To detect clicks, ScummVM would just see if something was drawn at that pixel. This was however too precise because the original game seemed to count any click inside the bounding box of the object. I rewrote the object detection code to work like that and it fixed all issues.

There was also a problem with how the bounds of the objects were calculated. Fixing that fixed the issues with cropped bitmaps.

Some formatting issues needed to be fixed too but after that WAGE finally got merged. However there are still some things which need to be addressed. Some functions were stubbed (not implemented) so I worked on those. There’s are some some TODOs from the original JAVA implementation which need to be looked at.

And that’s where I am right now.

Thanks for reading and see you next week!

Week 10 – Working on WAGE III

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!

Week 9 – Working on WAGE II

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!

Week 8 – Working on WAGE

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.

Spot the differences!

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.

There’s one pixel of empty space around the image

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.

ScummVM vs Original Diff

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!

Week 7 – Finishing up PINK

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.

Clicking on them brings up this dialog

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.

Some items are grayed out and can’t be clicked

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.

Recent saves

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!

Week 6 – Working on PINK

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.

Top Right and Bottom Left have “green dots”

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.

No more green dots

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

The black box is supposed to have yellow text

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.

Wait that’s not yellow…

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.

Yellow finally!

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.

The title text should be center aligned
Another transparency artifact?

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!

Week 5 – Finishing up Scott

Picking up from where I left last week, the bug I was stuck on has been fixed! It was caused by a missing conditional return statement in the 6520 emu which would cause it to run for longer than it was supposed to for certain games. I fixed it just some hours after the last blog post went up so luckily I didn’t lose much time because of it.

Once the bug was fixed, the rest went by relatively quickly. I finished adding all the games to detection and that was basically it. That work has been merged into the ScummVM master which is great. There are some minor visual bugs still present but I decided to move on to TI99/4A support as they were nothing game breaking.

TI99/4A support was much easier as it doesn’t have any graphics and as of writing this I am done with it too. This means I am done with the Scott engine outside of any fixes I have to make if needed.

The next thing I’ll be working on will be either PINK or WAGE engine. Look forward to next week for updates on that and thanks for reading!

Week 4 – Start of the coding period

The coding period has started and I managed to make some decent progress this week. However I did hit a major roadblock which has had me stumped for the last few days.

C64 support has reached the point where it seems to handle games without any special decompression. This include 11 Mysterious Adventures which were the first games to be tested. The ones which do need to be decompressed (or decrunched) are a mixed bag.

I started with Robin of Sherwood and that worked fine. I then moved to Gremlins and unfortunately a variant of the game wouldn’t work. Thanks to Petter (the original author) for letting me know about garglk a few weeks ago as that would give me a better way to debug my code.

I managed to setup it on my Windows laptop thanks to WSL but it seemed to have problems with that variant of Gremlins too. I initially thought that this meant that the game wasn’t supported by spatterlight either but after talking to Petter about it, he found out a bug which was causing it to not work. He fixed it promptly (along with some other bugs) and the game does indeed work properly on spatterlight.

I now have a working piece of code to compare my version to and hopefully fixing this bug won’t take a lot of time now. If everything goes fine then I might even finish working on scott by the time the next blog post comes out πŸ˜€

That was it for this week. Thanks for reading and see you next week!

Week 3 – Community Bonding period ends

Today’s the last day of community bonding which means that full time work will start from tomorrow so the blogs will actually have more progress to show from now on πŸ˜….

Continuing from last week, this week’s work was focused on improving the detection code. Spatterlight’s game detection would iterate through different systems followed by different games till it finds one which loads the game successfully. While I am not too familiar with Spatterlight, I would guess that this system exists so that you can throw any file at it and it would figure out if it’s supported. However on ScummVM, the md5 hash of the game file is calculated and only games which are known to be supported are loaded. This means that we don’t have to rely on hit and trial to know if the file is a supported game. I was already using the md5 hash to figure out the system directly but the game itself would be figured out after iterating through a list. This has been changed to also use the md5 hash to immediately load the correct game.

That was it for this week. I’ll admit to slacking off a bit this week but I am ready to be working full time from now. Thanks for reading and see you next week.