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