Repaired coordinates and a fully functioning first scene

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

Info line, event handling and winking miniatures

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;
  for (i = 0; i < CAVE_MAX; i ++) EyeTab[i] = V2D::Eye;
  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:

240=160, 100, -200 ; camera

(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… 🙂

An almost correct display of the first screen and a bit of mouse handling

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

Roaring sphinx

Hey all! 🙂

Before boring you with the little details of my last week’s work, let me show you the actual output of the engine:

Sfinx intro – ScummVM from Peter Bozsó on Vimeo.

Promising, isn’t it? 🙂

Actually, it is, very much, and even more. Compared to Avalanche (which was my last year’s work), CGE2 engine is more advanced, and right because of that, it needed much more work to make it show us something than the previous one. On the other hand, now I have a much deeper understanding of the whole structure of the code and I also have some plans how to proceed with the engine as a whole. Finally, I’ve got a grab on it and it feels safe, especially in the light of the past few weeks’ anxious coding. 🙂

Let me explain it more deeper and make the comparison cleaner!

In case of Avalanche, all I had to do is implementing the picture loading code, then choose and put the right pictures on the screen, smash the whole thing into a big main loop with the keyboard and mouse event handling, and here you go: a half-working game, with the main character running around on the screen. (Of course, I struggled much more with it anno, and it was certainly more complex, but in a nutshell, that was that.) All in all, Avalanche was more appropriate to develop step-by-step, concentrating only on one thing at a time and bothering with the game logic only when almost all was said and done regarding the graphics.

In comparison with my previous work, CGE2 engine is more complex and was harder to find a solid grab on it. It handles things differently: it has very little, almost no hard-coded logic (which took up the greatest part of Avalanche by the way), but has a pretty scpript parser system, Snail.

I was lucky, I didn’t have to implement the guts of the picture loading and drawing from scratch, using the ASM code in the original, because Arnaud and Paul did it for me during the implementation of CGE1. I only had to revise the fundamental classes and add/remove or modify function slightly to fit into CGE2’s different coordinate or NPC-handling. The really hard part was to track down the inner workings of the engine through the not-so-verbose variables (there are tons of variables named “a” or “b”, for example) and the not always logically named or placed functions (“getCave()” – What cave?!). Nevertheless no matter how I tried, which perspective I regarded the engine from, I always ran into Snail (called CommandHandler in the ScummVM version), which is clearly far from being complete, through the fundamentals of it are now settled, and as I concentrated on the parts what are used during the displaying of the intro, now it’s done and working as you may have seen above. 🙂

After deciphering it, the internals of the command parser are not so hard to understand. Actually, every Sprite has a file with the extension of SPR, and those what are more than only one static image (For example the backgrounds are consist of only one picture. Yes, the backgrounds are considered as sprites by the engine as well.) has a bunch of information in them about the display sequence of the animation of the sprite. For example, 00SFINX.SPR, which contains the information of the roaring sphinx animation has a pretty readable table of  the to-be-executed commands of the sprite, right under the “[near]” header in it. Especially, if you check this table of constants for the better understanding of the commands listed. So practically the intro animation is a sequence of pictures with sounds displayed right after each other, with a certain amount of delay inserted between each of them.

Luckily, I was also able to copy the main loop of the game from the ScummVM version of CGE1, and I only have to adjust some delay time to match the output of DOSBox.

My plan for the upcoming week is to proceed with the implementation of the main loop of the game and see what is needed to be implemented in order to display the first scenes of the game and very importantly: the NPC’s on it and the animation of them.

See you soon! 🙂

Invisible progress

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

Splash screen with a little music

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

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


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:

This one may need some description: It’s a basic shoot em’ up mini-game, where your aim is to shoot the bad guys in the pallets. If a criminal doesn’t get hit in the face with a rotten vegetable repeatedly in a certain amount of time, it will escape, and your score decreases. The more guys you keep in the pallets when the time counter reaches 0, the more points you’ll get. Also, you gain score for each successful shoot, and lose some if you hit a pedestrian by accident. It’s wasn’t hard to implement, since I’ve got everything for the graphics, and just a little bit of effort needed to understand the logic behind the mini-game itself.
4. Help:
Of course, there’s also the Help menu. The implementation of it was pretty straightforward, the only difficulty was with the display of the big fonts, but I came over it by time and effort too.
5. Main Menu:
Last but not least, I finally fought with the menu, and got out as a winner. The biggest problem here were the display of the little buttons on it, because they are all drawn together, not one-by-one, but plane-by-plane. It also uses a different display resolution then the rest of the game, but it was really a minor thing after I solved the mystery of the icons. 🙂
That’s all folks! There are still some missing bits of the game, which you can see on the TO-DO section of the engine on our wiki, but I never said I stopped working on them. 🙂
By the way, I submitted my proposal just today, and hopefully I’ll get accepted to this year’s GSoC as well so I’ll be able to blog about my progress with CGE2 engine soon. Fingers crossed! 😉


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