Month: June 2014

Hey all! 🙂

During the last week, I spent a few days on vacation, so I haven’t really progressed much with the engine. Truth to be told, I am still on time regarding my schedule, so everything is okay.
Besides that, Arnaud progressed a great deal with the translation, and with the implementation of a few more opcodes, we were able to unlock a couple of new scenes in the game. Here are some pictures of them:

Now, if I count it correctly, we have almost 10 playable scenes of the game, most of them fully translated. That’s a quite good number if you take into account that the game has about 28 scenes in all. 🙂

Considering the advice of David (digitall), I also added a fallback detection for the English translation, so we don’t have to modify gameDescriptions[] every time Aranud comes up with a new version of the translation.
In a nutshell, it’s algorithm is very primitive: it checks for a “lang.eng” dummy file. If it finds it, the engine detects the game’s data files as the WIP English translation. Of course, it’s just a temporary solution, only used during the development. The cool thing is, it was VERY easy to implement, thanks to the great Advanced Detector what ScummVM provides. I only had to implement fallbackDetect(), and that’s all, ScummVM takes care of everything else.

We also decided that the bug in the pathfinding can wait. It’s absolutely not a showstopper, since you can interact with every sprite on the screen what needed to proceed with the game, it only blocks the player to wander around with our two heroes on certain screens. We postpone it for later, to be implemented with other rather “cosmetic” features.
This week, I am working on the save/load system, so we can test and translate the game much effectively and swiftly. Sadly, my parents are moving to a new house during these days, and I have to help them a lot, which consumes a lot of energy and time of mine. Nevertheless, I don’t fear that will slow my progress significantly

Right after that, I’ll have a pretty long list of Valgrind warnings to take care of as well. Great thanks again to David for providing me with these information, and helping me so much! 🙂

See you next time! (Hopefully with a working save/load system, and with much less memory leaks. :D)

Yes, the title is misleading on purpose. Sorry, I just couldn’t miss it. 😀

Now the facts: As I promised in my last post, I was able to implement the inventory system, I fixed the speech bubbles, and many more. Let’s see them one by one!

In this picture, you can see a perfect example of the now correctly placed speech bubbles. Also you may notice that the texts are finally in English in the game – as well as you can see the currently detected game version on the top border of the window. Of course, the translation is far from complete, but you can trust me that Arnaud did a great work already and he is progressing with it more and more each day. I am very thankful for his efforts, as always. 🙂

You may also notice the little candy above Vincent’s head at the bottom left corner of the screen. That’s the inventory, and each playable character has 4 slots in which he/she can store items. And yes, it’s implemented and fully working too. 🙂

And here is our darling, Anna, who is also playable now thanks to another bunch of implemented functions in the command parser. She has an almost full inventory with a lot of things in it. (Notice the sausage! ;D)

As always, I left the least interesting thing for the end: it’s the implementation of the little switch on the right end of the toolbar, next to Anna’s inventory. If clicked, it displays this little menu where the player can decide to exit the game or keep on playing it.

Finally, bad news: as I also predicted it, I wasn’t able to implement the pathfinding fully before the midterm evaluations. There are some scenes (now we are able to reach the 5th, even if it’s not completable), where the pathfinding works, and some where it just doesn’t. I am a bit puzzled over it, and did a lot of debugging already but I fear the problem is not with the engine’s logic, but with our FXP implementation behind the coordinates. Yes, that stupid FXP again…

The next week will be dedicated to this problem, and I hope that next time I will be able to show you a video with an example of the working pathfinding. 🙂

See you then!

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