Hey everybody! 🙂

Finally, Sfinx got the point (with the English translation in parallel), that it’s available for testing! 🙂
You can read the official announcement here.
So if you have the time and you are eager to try something new, feel free to test our new engine!

Cheers! 🙂

Merged #2

Yes, yes, yes! 🙂 CGE2 engine is finally merged, the fruit of this summer grew ripe! 🙂

This week I was busy with fixing issues regarding my merge request and other problems reported by Coverity. Also, I found the sound system of the game still pretty buggy, but after a day of work, it finally works as intended. Other than that, the engine is really complete now, we are only waiting for a decent translation, and that’s all, it will be free to download from our site. 🙂

About Avalanche: as I said, I started to work on Avalanche engine again. This week I spent my time with the objectifying of the dropdown menu’s code, and now I can say that even if it’s not perfect, but it’s much cleaner than before and easier to read. Now, during the remaining two days of this GSoC, I plan to implement the keyboard handling of the dropdown menu. We’ll see if I’ll have enough time for that…

Now only the end of the program remains, so I’d like to say to you guys as a closing a big thank you for this another great summer! I am especially thankful for the work of Arnaud, Paul, David and Thierry. I wouldn’t be here without you guys!

I am still very proud to be a member of ScummVM. 🙂

Another avalanche

Hi everybody! 🙂

As I mentioned at the end of my last post, from now I’ll work on my previous GSoC project, Avalanche. As you can see on it’s wiki page if you click on the link, there are still much and more to do until not only the game is completable but actually the engine itself is complete.

I already started a new branch and started my work with a quite great deal of refactoring and reworking the drawing of sprites. Now they are fully handled by my putImage() implementation, what is really similar to Pascal’s. (Yes, I know that there a couple of commits with CGE2 tags, my bad, they’ll be amended before the merge.)

From now, you can take the TODO section of the wiki page as a listing of milestones for the remaining two weeks of GSoC. I’ll do my best to erase as much as I can from that list. Today, during the refactoring, I fixed half of the Shoot em’ Up – the display of the heads of shot people in the pallets were not right at all. Now, using drawSprite() – which uses the brand new putImage() –  it’s all right. Besides that, there’s still a little graphical glitch in it regarding Avalot’s walking – it’s a bit too robotic at the moment. To be fixed as well. 🙂

Finally, I decided I will take care of the rest of the main menu this week. There’s still a missing “pushed in” state for the buttons, and several menu items are just placeholders, selecting them does nothing, since they are not implemented yet. That’ll be my first concern from now.
See ya guys!

Merging #2

This time: CGE2!!! 🙂

You can follow my pull request here!
I am very happy and very proud of the four of us that we got to this point that early. Great work guys, we deserve a beer! 😉
On the other side, my last week was spent mostly with cleaning up TODO-s, FIXME-s and CHECKME-s in the engine’s code.
All the while, Paul fixed our FXP implementation, so the ever haunting bug concerning pathfinding is finally fixed.
Also, as David supplemented me with a couple of Valgrind error logs, I was able to fix almost all of the memory leaks until now. I write “almost”, because David wasn’t able to play trough the whole game yet, so issues could still arise, but I am pretty optimistic about things now. 🙂
The autosave functionality and the Return to Launcher support are also added to CGE2 now, so we can say: the engine is finally complete!

For the remaining weeks of GSoC, I’ll implement the rest of my last summer’s project, Avalanche, and of course, I’ll keep a very keen eye on my pull request to fix every problematic part as soon as possible.

See you soon! 🙂

Another completable game

Yes, your eyes didn’t mislead you: another engine is – almost – ready to be added to ScummVM, yaay! 😀

My last week was spent mostly with bug-hunting and implementation of stubbed functions, so I really can’t highlight anything from it. I also implemented the functionality of the two volume switches on the toolbar. It was a pretty good experience, because I had a lot of freedom regarding this subsystem‘s implementation compared to other parts of the engine, since ScummVM’s sound handling is highly different from DOS’s. Because of that, new bugs and unwanted behavior is still possible when you use the sound options of ScummVM and the related buttons on the game’s toolbar in parallel, but that’s what testers for… ;>

After fixing some very ugly bug connected to script-handling, Sfinx is absolutely completable now. Here’s the proof – without too many spoilers:

At the moment, we can say that the engine itself is almost complete too.
There’s only one more major bug about our coordinate-handling what affects the pathfinding, so it works a bit hectically. My plan is to get done with this issue during the next week completely.
Another nice-to-have thing is the autosave function. Now CGE2 only supports classic saving and loading (it gives you the opportunity to save or load anytime you want), but as Arnaud and Paul implemented in CGE1, I also plan to add an autosave save slot which will always be overwritten when the player exits the game, and the he/she won’t be able to delete this slot.
One more missing feature is the Return-to-Launcher support, but it’s really the work of a couple of minutes, thanks to ScummVM’s great system.

The most important thing now is the numerous memory leaks the engine still suffers from. I’ll concentrate my attention on this issue along with our FXP implementation during the upcoming days.

At last, but not least, the English translation is complete as well. Many thanks goes to Arnaud for this! Currently, Thierry is trying to improve it, so hopefully we can leave the “Alfa v0.1” tag from the ribbon of the ScummVM window soon. 😉

See you next week! 🙂


Hi all! 🙂

During the past week, I mostly spend my time with the missing/badly working sound parts of my engine. The first and most nasty problem I had to solve was that in the original, every animation is blocked while a sound was playing. Clearly, it wasn’t the case with my version of the game until now. To specify the problem, it’s not true for every sound, only for the the speech of the characters. To achieve that, I had to add a block to the script parser of the engine, so there won’t be any action until the actual sound is fully played out. Luckily, that checking of the blocking flag was already in the original as well as the setting of it to true. The tricky part was to decide where, when and how to reset this flag. Again, ScummVM’s very friendly library came to my rescue. In the main loop of the game, I simply have to check the responsible sound handle:

void Sound::checkSoundHandle() {
    if (!_vm->_mixer->isSoundHandleActive(_soundHandle))
        _smpinf._counter = 0;

As you can see, if it’s no longer active – there’s no sound playing at the moment – I set the counter back to 0. This counter tells our LoopingAudioStream instance how many times it has to loop when playing the given sound, and the script parser checks for this number and doesn’t do anything if it’s a positive number.

After this issue fixed, my attention was fully paid to the buttons on the toolbar what are connected to sound manipulation. The “hard” part here was not the actual implementation of the buttons, but the fact that I have to pay extra attention to them so they keep in synchronization with ScummVM’s Launcher’s and Global Main Menu’s sound settings.
You can see the mentioned buttons on the toolbar with a cute pink outline around them on this picture:

Until now, I was only able to achieve complete functionality (and parallel behavior with ScummVM’s options) with the music on/off button. (This is the big grey round plate in the middle with a note on it.) Currently, I am working on the speech/text mode switches (to the right, with two blue arrows above them), so they’ll take into account the global options in the Launcher regarding speech only/text only/both modes.

Besides that, Arnaud is still progressing nicely with the translation. It’s not far from being complete, but there is still a very nasty blocking bug concerning the dentist’s scene we are looking at almost constantly.

For the next week, I’ll finish with the sounds completely, including the two remaining switches on the toolbar. Then I’ll keep on refactoring the code – what I already started to do here and there -, and fix memory leak issues as well as other persisting bugs. I already paid attention to eliminate all the remaining stubs in the engine, but there are still a bunch of them in the script parser. I plan to take care of these too as soon as possible.

See ya next time! 😉

Toolbar and memory leaks

Hi guys! 🙂

During the last week, the most spectacular part of my progress was the implementation of some functionalities on the toolbar. Now, you can switch between normal, colorful display, and “mono-color” mode, which is there to support players with seeing difficulties. Let me illustrate it with two pictures:

Pretty kind of the original developers, isn’t it? 🙂 Besides that, thanks to ScummVM’s another great feature, now you can enable this colorblind mode not just by clinking the purple sphere on the toolbar (next to Vincent’s inventory), but you can also configure the engine right from the launcher, so it always runs in this mode.

To do so, I only had to add this static array to detection.h:

static const ADExtraGuiOptionsMap optionsList[] = {
    _s("Color Blind Mode"),
    _s("Enable Color Blind Mode by default"),


And just pass it as an argument to the constructor of my subclass of AdvancedMetaEngine. It’s quite awesomely simple, isn’t it? 🙂

Another feature I added is that now you can also switch between speech-only and text-only mode using the little ear and eye icons next to the main switch on the right side of the toolbar. Of course, you can still stick with both, simply clicking on the mouth icon above the two. 🙂

Besides that, my last week mostly spent with fixing various newly found bugs and patching up the engine in different places so it (hopefully) leaks less memory now.
In practice, I will keep on doing that during the next week, since now (many many thanks to Arnaud) all the scenes in the game are reachable and most of them are fully or at least partially translated too. So we are absolutely not far from saying that the game is in a completable state, but there are still a lot of showstopping bugs what need to be tended

See you soon! 🙂

Save and load system

Hi everybody! 🙂

My last week’s progress is mainly centered around the save and load system. I had a couple of difficulties, but now CGE2 engine supports almost every Advanced Engine Features. I only left out “Return to Launcher” support, since the engine still have a lot of memory leak issues (even through I managed to solve a couple of them) needed to be fixed before that.

So as I said, now it’s possible to load a gamestate via the launcher, or even do saving or loading in-game. I plan to also implement an autosave functionality, similar to the one implemented in CGE1, but for now it works and that’s totally enough for debugging and the translation works of Arnaud.
I’ve got a couple of hardships during the implementation of this subsystem, but ScummVM’s built-in Common::Serializer class helped me a lot and spared me a great deal of time by hiding the actual stream operations behind an abstract interface. Since the original game only supports saving when exiting the game, and loading when starting it, I had to make so modifications in the engine itself to make it possible to save/load anytime during gameplay. But knowing the internal workings of the engine, it was quite straightforward. The hardest part was to rework Spare and the way it’s used, so now it’s not just a temporary container for some of the sprites in the game, but a big catalog, which stores every Sprite used by the engine, all the time, so most of the synchronization work is to keep Spare up to date.

Otherwise, I mostly spent my time with annoying and hard to find bugfixes like this miracle.

During the past week, Arnaud went on a translation-frenzy. 😀 Thanks to him, almost all of the scenes of the game (Warning, spoiler alert!) are reachable/finishable. I just can’t express my gratitude toward him. 🙂

My plans for the upcoming week is more bugfixes and even more taking care of various Valgrind errors, provided generously by David, what I am still really thankful for. 🙂

See you soon!

A bit of vacation and the Advanced Detector

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)

A girl and her sausage

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!