すべてに良い。
前回 、私はTahoma11をゲームに導入し、喜んだという事実に落ち着きました。
![画像](https://habrastorage.org/getpro/habr/post_images/3d0/1aa/967/3d01aa967557e0133affd29df2eccccb.png)
短所はすぐに表示され、フォントはゲームのスタイルに適合しません。
新しいトラブルがあります:
- オリジナルとして様式化された美しいロシア語フォントを導入し、
- dosboxのほぼすべての動画をスキップすることに対処します。
ツール:IDA、dosbox +デバッガー、winhex。
フォントに関する探求
まずフォント。 それでも、フォーラムアーティストは、オリジナルとして様式化された美しいロシア語フォントをペイントしました。
ゲームにはそれらの6つがあります。
![画像](https://habrastorage.org/getpro/habr/post_images/796/e97/37f/796e9737f061a8ca7876f5bdf35ca568.png)
![画像](https://habrastorage.org/getpro/habr/post_images/12e/35c/2e0/12e35c2e0b96689cbc0295f04a421d62.png)
![画像](https://habrastorage.org/getpro/habr/post_images/fa4/c39/eb4/fa4c39eb4ec8da215e76290ddaf27c0b.png)
![画像](https://habrastorage.org/getpro/habr/post_images/27a/b28/758/27ab28758eaed8cbbc643ebf69d5eb74.png)
![画像](https://habrastorage.org/getpro/habr/post_images/901/9af/e7b/9019afe7bb331a474a540ac0b20cff27.png)
![画像](https://habrastorage.org/getpro/habr/post_images/226/397/fff/226397fff769bd2fab27a51b7698d7c5.png)
フォントは8ビットであるため、シンボルの各ピクセルはパレット内のカラーインデックスを含む1バイトです。 ヘッダー内の各文字の幅の表があり、フォント内のすべての文字の1行が行を形成し(ヘッダーにも記述されています)、複数の行が高さを形成します。
データブロックのサイズは(高さ*行)バイトで、対応する画像は(高さ*行)ピクセルです。
これらのゲームにそれらをどのように配置するかについて、小さなst迷がありました。 拡大されたオリジナルを見て、ピクセルごとにテストTahoma11を描きました。 使用される色は白のみです。
この時点で、色を選択して各文字をピクセル単位でレンダリングするツールを準備しましたが、巨大なBUTがあります。 小さな印刷を何らかの方法で手動で再描画できる場合、40x50ピクセルのサイズの大きなフォントは、妥当な時間のように想像できなくなりました。 各文字は依然として256色のパレットからいくつかの色を使用していたため、手動レンダリングのタスクがさらに複雑になりました。
BMPからデータをインポートする必要がありました。
アルゴリズムは次のとおりです。 フェローアーティスト(Ogr 2)は、各文字に異なる背景を提供しました。つまり、各文字の幅に関するデータを自動的に収集する手がかりがあります。 その後、彼は各文字の幅を計算できるように、異なる色の1つのサービスラインを追加し始めました。
だからプロセス。
BMPでロシア語フォントの1行のバイトを実行し、文字間の境界でピクセルの色の変化を検出し、幅のテーブルをコンパイルしました。
高さはピクセルの行数です。 各フォントは別々のファイルにあるため、データブロックの末尾にゼロを追加するだけで高さを増やすことはできません。 ゼロの数は、シリーズのバイト数に等しくなります。 その後、バイトの高さと出来上がりを修正し、新しい高さの準備が整い、希望のサイズに調整されます。
次の項目は各文字の幅です。幅に同意する必要があります。 データをシフトし、幅を揃えます。
これでインポートの準備が整いました。高さのループ、幅のループを作成し、BMPからゲームデータブロックにバイトを直接コピーします。
結果は素晴らしいものでしたが、何らかの理由で各アクションが何らかの結果につながります。
問題が明らかになりました-ロシアの文字の合計幅は、開発者が持っていたものよりもはるかに広いことが判明し、エンジン転送システムは次の結果をもたらしました:
![](https://habrastorage.org/getpro/habr/post_images/664/fe8/dc4/664fe8dc4d1901f7dd746754beba558a.png)
エンジンでは、行の長さが39文字であることは困難です。 40文字以上の文字列を連続して印刷すると、ゲームはフリーズし、少なければインターフェイスからクロールします。
デバッグのパスが始まりました。
dosヘッダーがスローバックされ、LEファイルがIDAに挿入されました。 ボーナスとして、開発者はすべてのデバッグ情報をEXEファイルに残しました。つまり、すべての関数の名前がすべて表示されます。
IDAの数字38、39、40を直接検索しても何も起こりませんでした。 デバッグは「Talk to」機能の分野で急上昇し、具体的には「Talk to Hank」をテストし、数学の結果として切望された39の結果として、最終的に素晴らしいブロックをトレースし、トレースしました。
ブロックは次のようになりました。
cseg01:00059D94 lea ecx, [eax-1]
cseg01:00059D97 sar edx, 1Fh
cseg01:00059D9A mov eax, ebp
cseg01:00059D9C idiv ecx
IDIVを分割した結果、EAXは番号39になります。これはさらに改行に使用され、エンジンは0Ahコードを挿入し、39文字ごとに改行します。
最初に置き換えた最初の2つのチーム
mov al, 36
しかし、それはエラーであることが判明し、AHに何かが残っていて、行が永遠に長いことが判明し、テキスト全体が1行に拡大し、2回目は登録しました
mov ax, 36
そして出来上がり:
![](https://habrastorage.org/getpro/habr/post_images/405/e3e/5a6/405e3e5a6896e64cd73e5940786bfa20.png)
後に、36も多く、35を登録しなければならなかったことが判明しました。これで、行とフォントを使用したクエストは終了しました。
行方不明のビデオに関するクエスト
問題。 グローバルな問題。 多くのサイクルがあるdosboxでは、ゲームはスムーズかつ順調に実行されますが、ほとんどすべてのビデオはショーの開始直後にスキップされます。 これは受け入れられません。
サイクル数を減らすことは可能で、ビデオのスキップは停止しましたが、ゲームはスライドショーに変わりました。
Process Monitorは、ビデオが読み始めていること、ビデオが表示されていることを示しましたが、1秒後に停止しました。
IDAをじっくり見てトレースすると、ビデオデコードユニットがループ状態になり、常にいくつかの行を通過することがわかりました。
![](https://habrastorage.org/getpro/habr/post_images/a61/140/d8a/a61140d8a8deb011ffea43e9efaf2ae6.png)
判明したように、プレイバック中に、ゲームはESCボタン、左右のマウスボタンの押下をチェックしました。 マウスのクリックでダイアログをスキップしてビデオの再生を開始すると、何らかの理由でこのクリックがバッファに残り、ビデオが中断されました。 マウスからのNOP-iveトランジションと、ESCキーを押すだけでビデオからの出力を残すことで、非常に厄介なゲームバグを打ち負かすことができました。