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