Month: June 2022

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.