そんなこんなで色々な妄想をして、日々自作ドラクエを続ける事10年。
なんとなくシステム面も出来てきて、ゲームとして成立しつつあるドラクエ。
とは言ってもほとんどがハリボテ状態の為、細かい部分の精度を上げていく。
マップ情報やキャラクタチップの容量が肥大化してきた為、独自の圧縮機能を使ったり、サウンドデータを減らす為にMP3のデータ構造を解析したり、実運用に耐えられる様に改善を繰り返す。
更にはメインでもあるエディタ部分、つまりドラクエそのものをユーザ自身が作れる編集機能部分も精度を上げていく。
マップ表示機能のプレビュー機能や、時間帯によるマップの変化確認、実行しなくともある程度はエディタ上で視覚的に分かりやすくしたり、とにかく細かく作り込んでいく。
そしてシナリオ部分はオリジナルを忠実に再現しつつ、より大人向けを演出する為に漢字表示に対応したり、各マップチップのリアリティを上げる為に、1チップあたり4色の上限を排除してクオリティの高いチップを作ったりと大忙し。
ここまでやったところでとうとうあの部分に手を出す始める。
そう「スムーズなマップスクロール処理」の実装だ。
まずやった事としては、世間一般の技術の勉強をした。
60fpsを通常はどのように制御しているか？だ。
60fpsは1秒間に60回画面を更新して、モニタ側の走査タイミング前に画面描画し終える事で、人の目に見えない範囲でスムーズに画面更新を行う事ができる。
つまり、1000ms/60回の画面更新となり、単純計算で16.333...msが画面更1回あたりの更新遅延時間となる。
これをVB6でどのように実装するかが非常に難しい。
なんせ0.1ms以下のタイミングを制御しなければならなず、msオーダーですら安定しないVBでどう制御するか？
色々と調べてみると、下記の様な考え方もある事が分かった。
16ms待ち→更新
16ms待ち→更新
17ms待ち→更新
(16+16+17)/3 = 16.3333...ms
この様に振り分けて時間制御すれば、0.1ms単位でのタイミング処理が不要となり、1000ms後には60回の画面更新、つまり60fpsを実現できる(はず)。
ちなみに、単純に16.333...msを四捨五入して約16msとして考えるのは大間違い。
1000ms/16ms=62.5fpsとなり、モニタ側のリフレッシュレートに合わずに画面がカクカクする結果となってしまう。
※まぁ近年のモニタはソフト側でリフレッシュレートが変えられる様だが、それは邪道なのでやめた。
というかモニタに依存してしまう懸念がある。
本当に世の中のプログラマは色々と考えるものだ。
こんな感じで先人たちの知恵に感心しながら、なんとかVB6に落とし込んでいく。
が、VB6では困った事にmsオーダーの制御がうまく動かない。
VB6はリアルタイム性に欠けるというのはこの意味だったのかとここで判明した。
イベント型の様に、ユーザーからの何かしらのトリガーの場合であれば特に気付かない挙動だが、
今回の様に一定のリズムを刻む必要がある場合はそうもいかない。
ここから終わりへの始まりとなる...
次回へと続く。