File I/O

Hi all! 🙂

As I promised in my previous post, I started working on CGE2 during the past days. Sadly, there’s nothing flashy to show you yet, but here’s what I got so far: the file handling.

Of course, first thing first: I had to add a skeleton engine and the detection parts of it to hook CGE2 into ScummVM properly. Since I did the same before with Avalanche, and the ScummVM Wiki page is very helpful on that matter, it didn’t take much time. The only problem was with CGE1’s detection, since it also handled Sfinx, but after removing that, everything seems fine.

Now, the file handling:
To get a full understanding of the situation, I show you my pre-GSoC work with CGE2. (You can also find it in my proposal.) The thing is that (as I mentioned before), CGE1 and CGE2 shares a lot of code, and with the coding/decoding of the sources file(s), it’s maybe the most prominent. Actually, they just differ in the size of a variable and a define statement which describe the size of a bigger data unit.
In depth: the engines use two source files for their work. One of them is the “catalog” file, with the extension of “.cat”, and the other is the one with the actual data, the “.dat” file. The process of the decoding looks like this: we parse the catalog file, which contains the so called “pages”. These pages are basically nodes in a binary tree, and they contain information about chunks of data in the .dat file. We can use this information to navigate to the desired chunk of data, read it, and then use it as we wish. By the way, in the .dat file there’s no distinction between script or graphic data, or even simple text for the dialogues: we have to know what we are looking for and how we want to use it later. Also, the .dat file can be chopped up into smaller files. That’s what we use in the extraction/packing tool to get the “.SAY” file, which contains the texts of the game, so we can do the English translation of it.
After understanding all of that and spending a couple of hours examining the file I/O in CGE1, I simply grabbed it and modified the few parts where it was necessary, to support CGE2’s file format as now the extraction tool does. I only had to change the define describing the size of a page, the size of a “size” variable (:)), and the reading of it. (The last one caused me a bit of headache before I found what was the actual problem with it.) After that, I tested it a little by writing out the content of the “CGE.SAY” unit, which contains the texts of the game, and the whole thing worked as intended.

My next bigger step will be the implementation of parts of the graphics. Hopefully it will be as smooth as the file I/O was, since it’s also very similar to CGE1’s implementation.

See you next time! 🙂

Acceptance again

Yes!!! Another year of Google Summer of Code in the embrace of ScummVM! I just can’t express my happiness and my gratitude towards the team that they accepted me again! 🙂

My project this year will be CGE2 engine. As you might have guessed, in some way it’s an improvement to our already existing CGE engine. The truth is that they will probably share a lot of code, since Soltys (the game which uses CGE) and Sfinx (the game which will use CGE2) are very similar in a lot of major parts (for example: management of graphics, sounds, scripts, texts), but they also have a lot of significant differences (for example: Soltys has only one controllable character, while Sfinx has two, and a more complicated inventory system to support them.)

To get a better overview of my project, you can read my proposal, and as the work will go on, there will certainly be a ScummVM Wiki page for the engine, where you will be able to track my progress. Also I won’t forget about this blog neither, I’ll keep it up-to-date with at least one post per week.
So the system is the same as the year before. I hope I’ll have as much fun this year as I did in 2013. 🙂

If everything goes fine, I’ll start working on my project this Thursday, so watch out! 😉