DXRuby1.0.5に向けて。 - mirichiの日記

特にネタも無かったのだが、いくつかのバグを直したことだし。
ここへ来て新機能も追加検討し始めているので、1.0.5の目標を考えてみよう。
長期ビジョンの無いいい加減なバージョンアップなわけだが、すでに精一杯やったのだから、これより上はそう簡単にはいかない。

まずは、Inputモジュールの修正。
現在の仕様では、パッドの判定にキーを割り当てることができるが、キーの判定にパッドを割り当てることができない。
普通に考えたらキーボードのキーをパッドに割り当てる使い方をするからこれでいいが、例えばキーをたくさん使うゲームで、その一部をパッドに自由に割り当てて遊べるようなゲームでは厳しい。
その場合はInput.keyDown?でパッドも判定できないと困るわけだ。
キー割り当てについての問題は、塵風氏がDXRuby用キー割り当てツール＆ライブラリのDXRConfigを公開しておられるので、それを使うのも手だ。
通常の用途には非常に便利だと思う。
ちなみに塵風氏のサイトはここ。
http://windmesser.tm.land.to/

もともとInputモジュールは、キーとマウス、パッドの入力をしたかっただけなのだが、カーソルキーとパッドは同時に判定できたほうがラクだということで、MSXの入力のイメージでパッドにキーボードを割り当ててみたのだ。
メソッドも色々な入力メソッドを作ったが、結局消して、いまの形になっている。
これを修正するとすれば、パッドに割り当てたキーに対して、キーの入力判定でパッドの入力も同時に取れるような感じになるだろう。
Input.PadXxxx?だけで両方の取得をできていたのが、keyXxxx?でも両方取れるようになる、という話だ。
大きく問題になるような動作ではないと思うが、コードの修正は大きいことになりそうだ。

もうひとつ、Inputモジュールのオートリピートにも問題がある。
現在の仕様では、keyPush?とpadPush?にオートリピートの設定が影響するが、すべての入力に対して効果が出るため、たとえばRPGでカーソルにはオートリピートを設定したいが、決定ボタンでリピートされると困る場合がある。
同様に、STGでショットをオートリピートさせた場合に、ボムもリピートされてしまっては困る。
padDown?で押した瞬間を判定すればいいが、それをするならそもそもオートリピート機能の存在意義が微妙になってしまう。
キーごとにオートリピートの設定をしたいところだ。

あとは、昨日からコードをいじって実験している疑似3D描画の可能性。
これはどうやったら実現できるのか、というところがわからないので、とりあえずいろいろ試してみてその結果で考えるしかない。
それから、Image編集系のメソッドの追加と。
Window.draw系並みの品質や速度、柔軟性を確保するのは大変というか無理だが、少しずつでも追加していけたらいいなと思う。
が、これもそれなりに大変なので見送るかもしれない。
まあ、考えてるのはそのあたりでそんな感じ。
あ、背景描画用のDXRubyMapを本体に統合して、Window.drawTileを実装した。
これは実装済みで、追加ライブラリとして提供するのよりもずっと高速になっているから、背景の描画で小細工をする必要性はほぼなくなったと思ってよい。
ということで、いろいろ作るのはこれから。
リリースは当然しばらく先になるだろう。