Author: superlemon

This week’s progress was somewhat better than the previous. Continuing from last week’s writing task, I was successfully writing the initial map, memory map, the key data and the cast data (‘CAS*’ data) successfully. Until then, we’re outputting the data as it is, without any modification. The goal was to be able to write movies for now even if there aren’t any modifications. This week I got to actually writing data that will be modified.

The first thing was the cast config data (‘VWCF’ chunk) data, this was pretty straightforward. I just had to save all the data that was being ignored and write it back in `saveConfig()`. Although, it involved calculating checksum for the config.

The next thing was the cast member data (‘CASt’ chunk), this was the tricky part. As I understand it, a ‘CASt’ chunk is made up of three sections, the first is the headers (which includes the metadata, like flags, cast member type and size of the rest of the two sections), there is info and data. The info has “strings” inside which contain information about the cast member like the name of the cast member, the file name (if it’s external), id of the script attached to it, font information, etc. Depending on the cast member, this number of strings varies. Hence, the size of the info also varies. Since I need to write the size of the info and data sections in the header, I have to calculate it from the loaded data. Hence, I ended up creating three methods getCastResourceSize(), getCastInfoSize(), and getCastDataSize(), this is useful since, I’ll need the ‘CASt’ resource size when I’m writing it in the memory map. Thankfully, this structure of info is consistent across all ‘CASt’ resources. So, I can create a single method in the base class and it works for all the cast members. The only section the cast members differ in is the data section for which I created a custom method in each derived class. (Note: Here the base class is CastMember and the derived classes are TextCastMember, PaletteCastMember, BitmapCastMember, etc.) The data section contains the cast member data (the bounding box dimensions, background color, flags, etc.). Now that I think about it, data and info are arbitrary names. Both contain different data about the castmember, but data still.

Majority of this weeks’ time was spent on testing chunks being written(even though there were only two (‘VWCF’ and ‘CASt’)). For debugging, I’ve also introduced a new channel (kDebugSaving). Some of the cast members are still haven’t been tested thoroughly.

These cast members can have children resources. Data like bitmap (pixel data in ‘BITD’ resource), text (‘STXT’ resource), are stored in these children resources. After the ‘CASt’ resource, our next step is writing these children resources which I think are going to be easier to write and test than the ‘CASt’ resource. Sidetracking, I tried writing the ‘CLUT’ (Palette data) and ‘STXT’ (Text data).

Even though, I was occupied the entire week, this still isn’t that much progress. It is still some time before this task is on its way to completion. I’ll need to speed up if I want to complete it within time.

Also, I realized my blogs are not as information rich as I’d like them. So, I’m planning on writing a mid-week blog to explain in detail, what I’ve done till now (shouldn’t take long!).

Quarter of GSoC period is gone… Wow, time flies!

This week I switched my task to saving Director movies in ScummVM. This was my main task of focus in my proposal. @sev explained to me that some games need to save .dir movies.

A director movie is in a containerized format. Chunks of different types of files are stored under a resource header. We can load and parse the movies in ScummVM but we cannot save them back since we throw away the things we don’t know yet. However, it is not as simple as reading the data in the file and writing it back to file. Because these games may modify the data inside these chunks. Also, the loading functionality is scattered throughout the Director engine. The ProjectorRays project by @djsrv is a great resource for this task.

So, the task is to keep the unknown data for the sake of saving the movies and to figure out how I can save the chunks that will be modified. All the other chunks that won’t be touched will be written verbatim.

This week, I started by writing the “reverse functions” to the archive loading functions in the Archive class readStream(), readMemoryMap(), readKeyMap()and readCast()  namely writeStream(), writeMemoryMap(), writeKeyMap() and writeCast(). The former load an Director movie archive whereas the latter saves the said archive. The rest of the chunks as described in the memory map (chunk ‘mmap’) are written as they are. For now, the movies are being written properly (except for a minor hiccup which I will check out today). Although I have done much testing on the windows, Director 5 movies I have, but @sev asked me to test this with a variety of movies before opening a pull request. Another idea is to store all the data for a specific chunk in a struct for consistency just like how ProjectorRays does. However, ProjectorRays doesn’t handle all chunks.

My initial idea to saving director movies was to move all the loading functions to the Archive class so that it can store them. It will have all the data and write it whenever necessary. However, @sev pointed out, that is a substantially flawed approach. There are far too many chunks to move to the Archive class, they don’t belong to the Archive class and it will be an unmaintainable mess. Thankfully, I didn’t spend much time on it.

Now, this week, I need to start writing Cast data (reversing loadCastData()).

I had to go to Pune again, for the publishing of our college magazine. Finally, that responsibility of mine is over. This week, I was logging in late, which moving forward, won’t be happening.

I’ve finally started to pick up the pace (although still slow). Things have started to look little brighter now…

This week, I actually got to implementing the Movie castmembers in ScummVM. The idea behind this was to use the MovieCastMember as a wrapper around a Movie member. This Movie class variable will handle the updating of frame number, execution of Scripts, handling events, etc. just like how a the main movie handles it. The tricky part was that it does not have a window. The main movie has a dedicated window where it can render its Sprites. The Movie castmember needs to be rendered in a box inside this main window. For this purpose when the main window updates (renders the next frame in the main movie) it also asks the MovieCastMember for its updated sprites using a function called getSubChannels(). So, the idea was simple, before returning these sprites, we ask the Movie castmember to “step”, update its own state.

But, this simple idea lead to me facing many difficulties. First of all, I had to include a check at each place the _window member was accessed in all functions in classes Movie and Score. The class Window also tracks the the Lingo State, which was now inaccessible for our MovieCastMember. So, the Window class needed refactoring.  I separated all Lingo State keeping functionality into a separate class LingoStateKeeper and migrated all the relevant functions  from Window. I added a member _stateKeeper to Window and Score. There was also a question of whether MovieCastMembers can switch movies using the go to movie ... command. I created a movie as a test in the original Director to check this. @sev asked me to add it to the director-tests repository.

This task is still incomplete. I’m able to see externally linked movies in ScummVM’s Director but they are stuck. They still do not allow execution of their own scripts.

What was thought to be a two day job, ate my entire week. I didn’t have my Director basics down. I hadn’t read the Manuals that were given to me a weeks ago.  I made obvious logical mistakes, I got stuck at multiple points… to the point that @sev has asked me to take a step away from this task.  I was working on processing Lingo script events the last. He will continue from here. He asked me to focus on my main task of  saving Director Movies. Hopefully, I’ll learn enough to come back to this task and be able to finish it.

I’m worried at this pace, whether I’ll be able to complete my project or rather make a meaningful contribution to ScummVM in a reasonable time period. I wanted to work yesterday (Sunday) but I thought it’d best to take the day off and read the Interactivity Manual (even though its a bit late now) and start working today (Monday) with a fresh mind.

This week I’ll focus on studying ProjectorRays to start writing director files. Study the different chunk types in a .dir file.

So… the first two weeks for me have been much less than perfect. I’m too focused on the greener side of the river forgetting there is deep water in between, gotta pass through that first or I’ll drown… But I’m optimistic. Even though I couldn’t keep the promise of having a good week from last week, I hope to have a comeback week starting today.

Okay, Week 1 over! Hussshh! Not how I imagined it would go.

I started the week by “trying” to work on my unfinished QTVR task. I made very minor improvements, but they were not my main goal. Basically, the QTVR decoder in ScummVM uses a two step approach to projecting a cylindrical panorama in ScummVM. First Step: Cylindrical projection correction, Second Step: Perspective projection correction. I tried to implement a warp mode 1 in it by skipping step 2. But apparently that’s not the correct solution. This introduces a wobble to the image when tilting up and down. I tried working on it, but couldn’t do it. @sev suggested I abandon it because I have to focus on my main task of saving Director files.

This week I worked on familiarizing myself with the Director 5. I started reading the Director 2 Interactivity Manual. My main task for this week was to understand how Director Movies can be embedded into other Director Movies as cast members. Currently this functionality is missing from ScummVM Director. We cannot load external Movies into the current movie. It was my task to implement this functionality. This is used extensively in startrek, a game we’re hoping to support in ScummVM, which has a main (Director) movie that loads other (Director) movies which store different things (e.g. the floor plans of different rooms on the USS Enterprise NCC-1701-D spacecraft). But so far I’ve been struggling to carry out the task.

To get acquainted with Director and to understand what the task is, @sev asked me to create a simple movie in Director 5. I had to embed an external movie into that just like startrek does using a lingo script. Although, making the movie was simple enough, I failed to see the point behind the exercise. Instead of embedding an external movie, I instead imported all the cast members of my external movie into my current movie and basically mimicked the external movie in my current movie (to not do so was the entire point). After a helping hand from @sev, I was able to make the movie. I will be using this movie as a unit test to check whether the movie cast member loader (which I will start implementing starting next week) works or not.

@sev wanted me to do another thing which was to create a loader for Score that works for all of these cast members: scores, filmloops (very similar to scores but very little or no external control using scripts) and movies (which have their own score and casts and scripts unlike filmloops).  But my progress was slow, I am getting stuck often; which lead @sev to tell me that I should immediately ask for help if I feel stuck. I have very little time to make this happen and I can’t afford to spend much time on just getting the basics done. Other students are well on their way to complete their respective tasks.

So to expedite this process @sev and I had a video call where he explained how the Director works, how its components work, how it is implemented currently in ScummVM, how are they loaded, how all of this is tied to my main task of saving movies in ScummVM, and what is it exactly that I need to do. This helped a lot. I now have a clear picture of what needs to be done. From next week I’ll start by implementing a common loader for Score, filmloop and movies in ScummVM’s Director.

I hope I’ll have better news and a better blog next week!