2017/10/29 | 投稿者: ghost

今回の開発で留意しようと思っていて実際にやっていることについて、途中で自分が忘れてしまわないようにメモ。以下に書くことは、目下の開発スタイルにある程度特化した話であり、必ずしも普遍的なものではないことを予めお断りしておく。

まず前提として、今回も前回同様に32KBのROMフォーマットを採用している。以前、メモリマップの概略図を示したことがあったかと思うが、32KB ROMフォーマットというのは、Z80の素のアドレス空間64KBを、MSX-BIOS ROMに16KB、ゲーム本体(ROMカートリッジ)に32KB、MSX本体のRAMに16KB配分して使うスタイル、ということになる。そしてこの方式を採用する場合、ゲームのプログラム、グラフィック・サウンドのデータは、当然のことながら32KBのROMの中に収まっていなければならない。

そもそもMSXというシステムは、基本的な入出力はBIOSサブルーチンがやってくれたり(その分、プログラマが書くコードは減る)、低メモリでもそれなりに複雑なグラフィックを描くことができるVDP TMS9918を採用していたり、と、小さなメモリ空間でもそれなりのことができるよう設計されている。その観点からすると、32KB=32,768バイトというのは開発開始時点では「こんなの使いきれるのか?」と思ってしまうほどに広大なメモリ空間なのだが、でありながら、ドラコニックスロウンの開発最末期には、メモリ不足への対応に苦労する羽目になった。

今「メモリ不足への対応に苦労」と書いたが、逆に言えば、労を惜しまなければ「メモリ不足」に陥らない「対応」の手段がいろいろある、ということでもある。敢えて仰々しい言い方をすれば、ある表現形とそれを実現するプログラム・データ構造は一対一対応はしておらず、絶対的情報量による限界に至るまでの間にメモリ節約については無限の好適手が存在し得る、ということなのだが、ドラコニックスロウンで「苦労」したのは、ほとんどゲームが完成した後でこのメモリ使用の最適化に着手したがために、既にその時点で確定している仕様に影響を与えないように等価かつ軽量なプログラム・データへ置き換えるのに「苦労」したのであって、これを開発当初から心がけておけば、これはしなくていい苦労じゃないか、というのが、まぁ、現時点での取らぬ狸の皮算用なのである。

さて、どのような対応手段があるだろうか。抽象的に一言でまとめると、あるデータ構造があるとして、そのデータが何らかの計算の結果得られるものであり、かつ、その計算のためのプログラム長がデータそのものよりも短くなるのであれば、データをプログラムから生成する、ということになる。

続きを読む
タグ: MSX Z80




AutoPage最新お知らせ