Week 6

At the sixth week I have done:

 

  1. fixes of game bugs. Thanks, Henke37 for bug reports.
  2. code cleanup
  3. implemented recalculation of walking sprites.
  4. added debug commands to list/goto modules, pages, to look/set variables, to add items.

This is how walking looked like before implementing frames recalculation:

After:

I have opened the pull request to merge engine with ScummVm’s repository.

Next week I will implement the game menu.

Week 5

The fifth week was very productive.

I have done:

 

  1. rewritten ActionCEL(sprite) and its inheritors. This was needed to properly implement reversed playing of sprites in ActionLoop.
  2. fixed rewinding of FLIC decoder in the main tree.
  3. implemented Hokus Pokus scripting system.
  4. implemented AudioInfo. This is the specific feature of Peril, activated by the right button.
  5. implemented skipping of the walk. This speeds up testing of games.

This is how sprites were drawing before rewriting ActionCEL.

That’s after

The Hokus Pocus’s scripting system is almost the same as Peril’s. It only adds support for playing scripts by the timer. The peril’s engine can only play 1 action by a timer.

Before:

After:

 

Week 4:

At the fourth week I have done:

 

  1. reworked sound system( now volume from objects attributes is used)
  2. implemented sound balance depending on sprite position.
  3. implemented dirty rectangles
  4. various fixes

Earlier engine was redrawing full screen each frame when smth updated. This was very ineffective.

An interesting thing that the original engine consumes full core of CPU. Probably it hasn’t any delay or just redraws screen each frame.

I have implemented various ways of effective drawing and compared their performance.

  1. Redraw only parts of the temporary screen, but make a full copy to the system. When sprite updates it is redrawn and intersecting parts of other sprites.
  2. Same as previous, but only dirty rectangles are copied to the system.
  3. When sprite updates, get dirty rectangles from decoder, merge them and redraw to the temporary surface. Then to the system. This method can be worse than simpler methods if there are too many dirty rectangles, which can’t be unioned. To solve this, a sprite must be redrawn fully if there are more than 100 – 200 rectangles.

I have compiled ScummVM in release mode with optimizations and set delay 5 ms. This means that maximum FPS will be 200.

Logo1 Logo2 Intro
3 No scaling 187.07 185.8 181.98
HQ 3X 177.28 162 164.03
2 No scaling 182.78 183.6 180.15
HQ 3X 169.42 160.8 160.44
1 No scaling 185.35 181.2 180.28
HQ 3X 167.92 126.6 152.91

Not big gain using dirty rectangles from decoder, but a huge improvement from dirty rectangles which are copied to the system because scalers redraw only parts which are changed.

Week 3

At the third week I have done:

  1. Added metadata to the saving system
  2. Added World Book implementation(PDA)

 

Not much for this week. PDA in games is slightly different, so I need to reverse 2 executables, which aren’t same. The newer executable has very aggressive inlining.

PDA consists of content(text, sprites) and buttons. Buttons have commands:

For now, I have implemented HokusCommandType.

Joke from executable)

  Code for this asm

Here we access non-existent string if the array size is zero. This is SIGSEGV.