Author: Administrator

Hi everybody! 🙂

Even if this week’s post is delayed by a day (thanks to a heavy sickness I suffered the past few days), I have terribly good news for you! 🙂
First of all, a video about the new things:

Sfinx first and second scenes – ScummVM from Peter Bozsó on Vimeo.

(The mouse pointer has no problems in the game, only Vimeo tricked it a bit with it’s video conversion.)

Let’s go through the changes together!

The most spectacular difference compared to the last output is that the items on the screen are finally at their destined places! Yess! For all this I can say a big thanks to my two awesome mentors, who didn’t gave up and with a few days of reverse-engineering, got to the roots of the problem and fixed it.
Our problem was the following: FXP (the fixed-point representation which was used to store the coordinates of everything) contained two data members, 16 bits each. So in loadTab()’s first implementation I naively read in two integers and scratched my head why were these totally wrong values. I tried with big-endian read as well as with little-endian, but nothing helped. That’s when Paul discovered that the right way to handle these data is to read in them as little-endian 4-byte chunks, then divide them to 1 byte of floating part and 3 bytes of integer part. That’s what he did in the correct reimplementation of loadTab(), and since meanwhile Arnaud implemented the FXP type correctly, there were no more obstacles before the right display of the first (and consistently all the other) screen.

The other things I added during the week seem minor modification compared to this absolute success, but I was managed to progress a lot with the engine. Now the speech bubbles are displayed correctly (even as you can see in the video, the coordinates of some of them are not computed correctly at all – I am still working on that), and you can also trigger a lot of events like the pulling up of the shades over the window. Also there’s a very basic implementation of the pathfinding in the engine, which is quite buggy right now, but good enough to test the other added features.

My plans for the upcoming weeks are these (in order):
– Fix the coordinates of the speech bubbles.
– Implement the inventory system.
– Rework the pathfinding.

These are my main goals right now, but to be rational, only the first two is possible to achieve before the midterm evaluations. I am almost entirely sure that the pathfinding will remain after that.

All the while, we are working on the English translation of the game with Arnaud (but most of the credits goes to him, since he does the actual translating work), so it won’t cause another obstacle in my progress that I can’t play through the game.

That’s all for now, see you soon! 🙂

Hey all! 🙂

First of all, let me show you the most significant progress of the week! Then I’ll talk about our present difficulties.

So, the new things is the so-called ‘info line’:

It’s the brown strip on the top of the panel at the bottom of the screen, showing ‘Wacek’  – the name of our hero. 🙂 (Arnaud decided to call him Vincent in the English translation, since that’s the closest name we’ve got to the original.) The purpose of this line is very common in adventure games: it shows the name of the thing which the player is hovering his mouse over at the moment.

What I left out from my last post: you may also notice that the face of our protagonist at the bottom left corner of the screen is now in color. I can tell you that the small icon is also animated now: it winks and makes various faces. (You can check this in motion in my last video.) As I perceived, it’s intended to display which one is the currently active character in the game, and you will be able to switch between them by clicking on their icons. (Since in the first screen you only got Vincent, only his portrait can be active.)

Now my problems:
As you can see, the misplacement of numerous objects is still a great problem. Also as I implemented the info line, which checks the screen and the coordinates of objects on it, it turned out (not unexpectedly) that the wrong handling of the z dimension manifests there also. Even worse, as I implemented the event handling of the mouse, the problem (also not so unexpectedly) came to the surface again. So now I am pretty much stuck because of that. But everything has a bright side: I also discovered what might be utterly wrong. I have a very strong suspicion that the problem is not with the numeric representation of the coordinates (that I use doubles for storing the values instead of fixed-point integers, as the original did), but with the loading of them.

Let me show you it in more depth! The problem is, that CGE2 uses some – currently a little bit mythical – reference coordinates called “eyes” in almost every function which computes the final coordinates of objects. All I could found about what this eye supposed to be is a comment in one of the original sources which calls it “camera”. So I suppose it’s purpose is to center the view of each scene at a particular point. And THAT’S THE PROBLEM. The original has this code for the loading of the “eye” value for each room:

static void LoadTab (void)
{
  int i;
  V2D::SetEye(Text[240]);
  for (i = 0; i < CAVE_MAX; i ++) EyeTab[i] = V2D::Eye;
  INI_FILE f(TAB_NAME);
  if (!f.Error) f.Read(EyeTab, sizeof(EyeTab));
}

To understand the problem fully, here’s also the declaration of EyeTab:

V3D    EyeTab[CAVE_MAX];

And since the original stores the coordinates in V3D in the form of three FXP’s (the fixed-point integer representation which we can’t reimplement because we don’t have the full source code of it), I wasn’t able to manage to mimic it correctly. The best I’ve got so long is that I set all values of EyeTab to V2D::Eye which is stored plainly as numbers in a source file, like this:

(See? The “camera” comment!)

…and use this one for every screen. But, as you may see, this causes all of the coordinate computations to go wrong, and here we are: I am stuck.

So, my most urgent task currently is to fix this loading (with help from Arnaud and Paul). Then, I’ll have to find the point where the event triggered which gets Vincent out of his seat, and then… Who knows? Hopefully there won’t be much to stop me anymore from rapid progress… 🙂

As the very verbose title of this post described, that’s what you will see in this short video:

Sfinx first scene – ScummVM from Peter Bozsó on Vimeo.

You may have noticed a “little” problem above. Yes, some of the sprites are placed totally wrong on the screen. Namely it’s the door, the shades on the window, the fan on the ceiling, and the wardrobe to the right. Besides that, everything seems fine, and you might have seen that I hovered the mouse cursor over the screen – yes, that’s also implemented now. 🙂
(Also the sounds are “a bit” loud compared to the music of the game, but it really won’t be a hard-to-fix thing, it’s just out of my scope of attention right now.)

Back to the problem of the misplaced objects:
As far as we were able to perceive it with Arnaud, the problem is about the z-coordinates of the objects. In Sfinx, everything that is placed on the screen has not 2, but 3 coordinates. These are the traditional x and y, and there’s also a z axis which describes the distance of each object from the screen – where the z-coord is equal to 0 and the further the object is, the greater the number is.
The problem here is that the original engine used a quite weird fixed-point implementation to store the coordinates of things, and until now I wasn’t able to properly reimplement or mimic it completely. Right now, it’s on the top priority list of ours and hopefully we will get over it soon.

Looking at the bright side, even if it’s ugly, it’s not an obstacle which would pull back my progress. As you may see, it didn’t hold me back from implementing the basic mouse handling of the engine (which blessedly has A LOT in common with CGE1), and I am not far from actually handling the events fired by mouse-clicks. From that point, a bunch of opportunities will open, and I will be able to dive into the depths of the command handling (Snail) again.

So, these are my plans for the upcoming week, see you soon! 🙂

Hi all!

Sorry for not posting for so long. The thing is that  I didn’t want to write again until I can present you guys something visible again, but now I just don’t want to postpone any more giving some signs of life about myself.

After Eugene brought it up, we reconsidered our approach with Arnaud about CGE2. Even through we decided against merging it with the previous version of the engine during the development, we did made up a new, a little bit different plan from the one that is in my proposal. Instead of concentrating immediately on the display of the scenes, we decided that I should try to implement the intro animation of the game first. We think it’s important now, since as Eugene (and me) pointed it out, the two engines are painfully similar, so we should first map the differences because it could speed up my progress significantly. If I’d know what parts of CGE1 are completely reusable (like the sound code was), and what need certain modifications, I’d be able to just copy-paste the analogous parts and concentrate on the ones what need more attention.

For example, right after I started to work on the intro animation, it turned out that the graphics code itself is in the second group: even if it’s very similar to it’s predecessor, it uses a new form of coordinate representation and the storing and loading of sprites is very different from CGE1, even through the displaying of the pictures share the same code. (Actually, EVERY picture in Sfinx is a sprite, or part of a sprite’s sequence of pictures.) For the coordinates, CGE2 introduces V2D and V3D, and for the sprites, it uses a pointer collection of them: Spare. I had great difficulty with the latter, since the original code uses an ugly DOS-specific hack for the implementation. I think I finally got it right and mimicked it in the right way. Anyway, time will tell…

If you check my repository, you can see that I am working with full power on the finishing of the implementation of movie(), which is responsible for displaying the intro animation. My next aim is to (at least partially) implement Snail, the script parser, which is responsible for the displaying of the animation by drawing the pictures of it one after the other.

Stay tuned guys! Hopefully in my next post I’ll be able to give you even a roaring sphinx! 😉

Progress-progress-progress! 🙂

As the title describes, during the past week I was able to display the splash screen at the beginning of the game (right before the intro), and play some MIDI formatted music. Let’s see the result of it:

Cool, isn’t it? 🙂 (I know you can’t hear the music, but please imagine some eight-bit beeping playing for the full experience. :D)
The key of my fast progress is that as we augured with Strangerke before, I was able to use most of the graphic and the sound code from CGE1 in my engine. In truth, it only needed a little bit of hammering here and there, and the biggest differences were the different file names of the music files and that Sfinx uses a screen resolution of 320×240 instead of Soltys’ 320×200. I also included the WAV player in my engine, but it’s testing will wait until I implement “Snail” (the script parser), because it’s only used there. But, if everything goes as planned, there won’t be much more difference than the different file names again.
I’d explain the working of the sounds and the graphics here, but since it’s working for now, I didn’t really spend much time with understanding what’s under the hood yet. I am convinced that there’ll be difficulties with the further implementation, and sooner or later I’ll have to fully understand and modify these parts of the engine too, so I leave the explanation for that time. For now, my aim is to copy as much as I can from CGE1, get as much as possible of CGE2 working, and then modify and polish the resulting code.

See you later! I hope I’ll be able to show you the intro animation or some scenes from the actual game next time! 🙂

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! 🙂

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! 😉

Hey all! 🙂

Yes, it will be a summary of my past half year of coding on ScummVM, and practically a summary of my latest additions to the Avalanche engine. I’ll go through a list of the most significant and spectacular modifications of the engine and describe them one-by-one. Of course, during that period, there were a lot of bugfixes (Even some bugs of the original were fixed!), and other additions and refactorings, but I won’t mention all of them.
So… let’s get started! (The pictures will become enlarged once you click on them.)

1. Game of Nim:

This was the first thing I implemented since my last post. The graphical part of it wasn’t particularly hard, but the game logic got me scratching my head for a while. In the end, the Wikipedia page of the game and a lot of patience helped me trough all the troubles. You can find the – not so nicely refactored – sources in our GitHub repo.

2. Ghost Room:

Basically, it is a little animated scene, which gets triggered when you make Avvy walk to one of the “hidden” corridors of his castle. He (represented by the two grey, little floating eyeballs) walks in innocently, then got scared by the descending ghost and other appearing freaks, so he hastens out of the room. It’s was pretty fun to implement, even if I had to fight a bit with the picture of the ghost to decode and display it properly.

3. Shoot em’ Up:

Yesterday, I became a full member of the ScummVM team! I just can’t describe how grateful and proud I am right now. It’s really like a dream came true for me. 🙂
This isn’t strictly connected to my project, but it’s so important for me, I knew I must share it in this blog as well. Many thanks again to everyone who supported me during this long journey! And I am still so far away from the end… 🙂