stablesteady's GSoC blog

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!

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!

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!

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.

After adding the games to detection, the next step would be to work on the actual code responsible for detecting and loading the game. Since I am just porting over C code for this engine, most of work consists of just formatting everything to look good and change things when needed to integrate it with the existing ScummVM code.

The way I did this during my pre-GSoC task was to first recognize which files needed to be implemented and tackle them one by one. While this approach was initially fast, it became quite some work towards the end when I had to bring everything together. Also it only worked because back then I didn’t have the best git habits and would commit at random without caring about the code compiling.

This time I am trying to follow some basic rules (keep commits atomic and compile-able, etc.) which was a bit difficult because I wasn’t used to this and ended up writing a lot of code again without committing which caused me to lose a fair bit of time and work in fixing that ?. I am trying to be more careful so that this can be avoided during the actual coding period.

I did push some commits this week and got a bunch of feedback, mostly related to formatting and style issues and as of writing this I have already fixed them. I haven’t encountered any other problem with the porting process which is great.

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

The first week of GSoC was a slow one for me. I had my semester-end exams which kept me occupied for most of the week. So instead of starting with writing code I decided to instead spend time on some other things.

First was going through the Pro Git book for a better understanding of how git works and it helped me a lot. My previous knowledge of git was limited to a bunch of commands I picked up from here and there which meant I had no idea of what’s possible to do and what isn’t. I can now actually understand why things are the way they are and can do better than just copying commands from stackoverflow and hope that it works.

Second was to find some C64 games which are also supported by spatterlight for testing my implementation. Luckily there’s a set of game on ifarchive I can use. While I can’t run spatterlight myself because it’s only available for macs, I can look into the source code and sure enough those games are also supported by it.

I started working on adding these games to detection which is when I encountered a minor bug. The Scott engine has a list of supported games along with their filesizes and md5 hash. When adding a new game, the file is matched against this list but a wrong condition caused it to match with the first entry in the list with the same filesize. This wasn’t a problem till now because every supported game had a different file size but the C64 games happen to be of the same size. I fixed it and sure enough, the games are now detected properly.

Now that the games are detected and can be loaded, the next thing to work on is loading the game data and that’s what I am doing right now. It’s a bit involved and might be the hardest part of this task so I hope I can make some good progress in the coming week.

Welcome to my blog!

I am Avijeet Maurya and I’ll be a part of Google Summer of Code this year. This is great opportunity for me to learn some new things and work alongside some experienced people so I am really excited for this journey.

In my first blog post I’d like to share my pre-GSoC experience with ScummVM. I had known about ScummVM for quite some time now so I immediately decided to try and see if I could participate as a contributor here. I had no experience with working on a codebase as big as ScummVM’s and I was very overwhelmed when I first cloned the repo and started going through it. Luckily there’s a very comprehensive resource with a lot of helpful info on about everything you need to know as a beginner and I found myself referring to it a lot in the following weeks.

I found an appropriate task to get me started with contributing to ScummVM and after a few weeks of coding I finally managed to finish it.

There were many problems I encountered along the way, the biggest being my lack of git knowledge which delayed my PR by quite some time but I received a lot of help from the ScummVM team, especially from DreamMaster who helped me a lot with this task.

My proposal for GSoC involves working on several engines which are already in ScummVM but with an incomplete implementation. I’ll be starting with continuing my work on the scott sub-engine to add support for more platforms and games to it. More details will be in the coming blog posts so look forward to those!