Testing

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! :D

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! :)

Sounds

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[] = {
  {
   GAMEOPTION_COLOR_BLIND_DEFAULT_OFF,
   {
    _s("Color Blind Mode"),
    _s("Enable Color Blind Mode by default"),
    "enable_color_blind",
    false
   }
  },

  AD_EXTRA_GUI_OPTIONS_TERMINATOR
};

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. :D 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. :D

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!

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;
  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:

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 320x240 instead of Soltys' 320x200. 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! ;)

Summary

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! ;)