We continue to dismantle the quest Harvester 1996

All good.

Last time, I settled on the fact that I introduced Tahoma11 into the game and was pleased.


Immediately became visible cons, the font does not fit into the style of the game.
There are new troubles:

• introduce a beautiful Russian font, stylized as an original,
• deal with skipping almost all the videos in dosbox.

Tools: IDA, dosbox + debugger, winhex.

Quest about fonts

')
First font. All the same artist of the forum was drawn beautiful, stylized under the original Russian font.
There are six of them in the game:







Since the font is 8-bit, each pixel of a character is one byte, containing a color index in the palette. There is a table of widths of each character in the header, one line of all the characters of the font form a series (also spelled out in the title), several rows form the height.
The size of the data block is (height * row) bytes, and the corresponding picture is equal (height * row) pixels.

There was a small stupor how to shove them into these games. I drew my test Tahoma11 pixel-by-pixel looking at the enlarged original. Color used only white.
By this time, I had prepared a tool for pixel-by-pixel rendering of each letter with a choice of color, but there is a giant BUT. If the small print could somehow still be redrawn manually, then a large font with dimensions of 40x50 pixels could no longer be thought of as a reasonable time. Each letter still used several colors from a palette of 256 colors, which further complicated the task of manual rendering.

I had to import data from BMP.
The algorithm is the following. The artist comrade (Ogr 2) provided a different background for each letter, that is, there is a hook for automatically collecting data about the width of each letter. Later he began to add one service line with different colors so that the width of each character could be counted.

So the process.
I ran through one row of bytes of Russian font in BMP and on the border between the characters I caught a pixel color change, made a table of widths.
Height is the number of rows of pixels. Since each font is in a separate file, nothing prevents you from increasing the height by simply adding zeros to the end of the data block. The number of zeros is equal to the number of bytes of the row. After that, it remains to fix the byte height and voila, the new height is ready, adjusted to the desired size.
The next item is the width of each character, you need to agree on the width. We shift the data, we align width.
Now everything is ready for import, we loop for height, loop for width and copy bytes from BMP directly into the game data block.

The result was excellent, but for some reason, every action leads to some consequences.
The problem came out - the total width of Russian letters turned out to be much wider than the developers had, and the engine transfer system produced the following result:


In the engine it is rigidly clogged, that the length of the row is 39 characters. If you draw a string of 40+ characters in a row, the game freezes, if less, it crawls out of the interface.

Began path debaga.
The title was opened, the LE file was inserted into IDA. As a bonus, the developers left in the EXE file all the debug information, that is, all the names of all the functions are visible.
A direct search for the numbers 38, 39, 40 in IDA did not lead to anything. Debugging jumped around the Talk to functions and specifically I tested Talk to Hank, I traced and traced a wonderful block, finally, as a result of the mathematics of which there was a treasured number 39.

The block looked something like this:
cseg01:00059D94 lea ecx, [eax-1]

cseg01:00059D97 sar edx, 1Fh
cseg01:00059D9A mov eax, ebp
cseg01:00059D9C idiv ecx

As a result of IDIV division in EAX, the number 39 appears, which is further used to wrap lines, the engine inserts the code 0Ah, each 39 characters, a line break.

The last two teams, I first replaced by
mov al, 36
but it turned out to be an error, in AH something remained and the line turned out to be eternity-long, the whole text was unrolled in one line, the second time I registered
mov ax, 36

and voila:


Later it turned out that 36 was also a lot, and I had to register 35, on this quest with lines and type is completed.

Quest about video passes

Problem. Global problem. In dosbox with a large number of cycles, the game goes smoothly and well, but almost all videos are skipped immediately after the start of the show. This is unacceptable.
It was possible to reduce the number of cycles, then the video skips stopped, but the game turned into a slide show.
Process Monitor showed that the video was starting to be read, the video was shown, but after a second it stopped.
Peering into IDA and tracing showed that the video decoding unit was going in a loop and constantly went through several lines:


As it turned out, during playback, the game checked the ESC buttons, the left and right mouse buttons. If you skip the dialog by clicking the mouse and the video playback began, for some reason this click remained in the buffer, which caused the video to be interrupted. For-NOP-ive transitions from the mouse and leaving the output from the video just by pressing the ESC key, we managed to defeat a very nasty bug of the game.