Reverse Engineering Arkanoid DX-ball, or New Life of an Old Game

Congratulate all the residents of the unofficial day of computer graphics ! This day I want to tell you about how I made an online version of an old game.

Perhaps many people are familiar with the game DX-Ball , I played it at a preschool age, and already at school I was taking lessons in computer science after it. Therefore, I was interested in doing it in HTML5.

A bit about work

I will not give healthy pieces of code, and explain how it works, I will talk about how I analyzed this game, and I will only say about the game itself, that it was made only on canvas. I wanted to make it as much as possible similar to the original, and leave as many files as possible unchanged, the only thing that changed was the list of records - it became “endless”.
At the beginning, it was thought to redraw only those elements which are changing, but due to the large number of bugs that arose in connection with this, I settled on the option of a complete redraw of the frame. And despite the fact that the game can be stretched to full screen, its resolution always remains 640x480px, however, as in the original.

Let's analyze the composition of the game:

* .pcx files are raster backgrounds of the game, such as the initial splash screen with the description of bonuses, and the final “High Score”. I did not begin to disassemble them, but you can read about the PCX device in an interesting series of articles , right there on the hub
* .mds - MIDI music files, savex helped me convert them to * .mp3 .
The Default.bds file contains information about the location of bricks at all 50 levels.
At one level, 20 ² bricks are written byte into this file.
From this we get 20 ² × 50 = 20 KB
* .sbk - files of raster fonts, and the rest of the graphics (bricks, rackets, etc.)
I couldn’t find any information on how this file is arranged, so I had to figure it out myself, and here’s what I found out:
Files of this type contain something like this: the ^{image is clickable.} The structure of this file is a bit more complicated than Default.bds, the characters are described in it, the first 4 bytes of the file is the file header, it contains information about how many characters (images) the file contains. After the header is a sequential description of the characters (images), as shown in the screenshot, the Sysfont.sbk file contains 94 characters. The width and height of the first character are specified in the 4th and 8th bytes. 12th byte is the character number from the ASCII table






, 0x41 = A, if it is 0x00, then this is not a symbol, but some kind of picture. Next are a few more bytes, in our case 130 (13 × 10), starting from the 17th byte - this is the symbol raster (indicated in green in the figure). Then all this is repeated 93 more times (starting with a byte indicating the width of the character).

Images (characters) are drawn from bottom to top, from left to right 1 byte = 1 pixel, the byte value is the color number.
As I understand it, the game uses 2 color modes, the first is used in the game itself, and the second only in the splash screen.
here are 2 schemes, each color has 2 numbers, the top is the color number in Dec, and the bottom in Hex: Here is an example of the first 3 characters of the Sysfont.sbk file using the first scheme:





Oh yes, zero in both tables is a transparent color, and the colors in the first scheme from 224 to 231 are dynamic, that is, each frame is shifted by one color to form such an animation.

But here there is a problem, some characters, such as qypgj should be lower than the rest, and apostrophes and other signs should be higher, but since all characters have different sizes, they are aligned to the bottom.



To solve this problem, there is a special byte that goes after the symbol, (in the first screenshot it is underlined in blue).
For gj characters, this byte is 0xFD = 253. and for ^ 'this byte is 0x08 = 8. This is exactly the offset of the character relative to the rest, but why are there such large numbers instead of the negative offset? The fact is that this is the form of writing negative numbers, in one byte 128 negative and 128 positive numbers. If our byte is less than 128, then we don’t touch it, and if it’s more, we simply subtract 256. From it, we
get an excellent result:


Before starting the game, all images (characters) are drawn in the same canvas as the game, I save them as pictures,
that is: char[...].img.src = canvas.toDataURL("image/png");
Since putImageData () is much slower than drawImage () and this is not the only minus.
putImageData, does not overlay the image on top, but replaces it completely.

In the process of analyzing the game, I discovered two secret bonuses that are not used in the original game :-)



All the animation in the game is optimized using requestAnimationFrame, but different devices give different FPS values. In order for the ball to fly at the same speed, regardless of fps, I multiplied the speed of the ball by the delta coefficient, which was calculated using the following formula: delta = 1000/fps/60;my laptop managed to draw about 55 frames per second, but it hung periodically and swallowed more than 30 frames at a time, from for this hang, the delta coefficient was calculated incorrectly and the ball acquired an uncontrolled speed, so I got rid of it I decided to average fps for 4 seconds, so it is so rarely updated.

In the previous Doodle Jump gameI gave users the opportunity to insert its iframe on any site, as a result of which over 7,000 users played this game every day on third-party sites of completely different subjects, from personal blogs to recording studios.
Therefore, in DX-ball I do not take away this opportunity, moreover, the game is flexibly configured to be inserted on the site.

It seems to be all, if in your opinion I didn’t tell anything before, ask questions, I will definitely answer.

Link to the game: DX-Ball.ru

P.S. The game is still damp, bugs and hangs are possible in it, so I will be grateful if you write about the shortcomings in the comments.