ジョイパッド入力完成

結局昨日のエントリの修正案に添った形に。

つまり、存在しないパッド番号やボタン番号を入れてもエラーが出ないようにして、キーボードはジョイスティック番号0番として使える。

ただし、ジョイパッドの数に制限を入れることはやめた。また、単体でジョイパッドだけのライブラリを使うことも可能にした。

その場合ウインドウ生成してないのでキーボード入力をパッドに見かける方式（つまりジョイパッド番号0番）はつねにニュートラル状態になってしまうが、パッド部分だけ自分で対応させたいという場合にはありだろう。ためしていないけど、ShinGL3と組み合わせて動くはず。

次はサウンド周りに移ろう。ShinGL3で一番負荷周りが怪しい部分だったと思う。描画部分は用意なので一番後回しにする。

サウンドも単体でつかえるといいかな。自分でJava2Dでゲームエンジンとか使っていてもパッドやサウンドだけ使いたい場合というのはあるかもしれないし。

ただし、機能的にはShinGL3と同じにする予定。つまり、BGM用に1音、効果音8音。BGMにはWAVのほかOggVorbisにも対応するのもShinGL3と同じ。効果音にもOggVorbis対応するかもしれない。

あらかじめPCMを展開してバッファを設ける形にしてGC等メモリ負荷を大幅に抑える予定。その結果消費メモリは増えるが、マシンパワーが低い場合も大幅に改善されるはず。BGMの展開をして消費メモリが4MBとか増えたとして問題になるのは今はないだろう。ターゲットはJavaSEだし。でも16bit44KHzステレオとかで展開されると余裕で10MBはこえそうだけれども、このへんはバッファ容量をユーザーに設定させればよいかな。

現在のShinGL3ではデコード後の生PCMをバイト配列で保持してそれをコレクションでバッファリングしている。最初はスレッドもわけてプロデューサとコンシューマでまわしていたんだけれども、効率が悪かったりその他のコマンドもあるということで今ではコマンド受付用と再生用とでわけてる。コマンドはブロッキングキューにいれておいて、処理は完全非同期で。この辺行き当たりばったりで修正加えていたからなんとかしたい。Javaのメジャーバージョンで一番挙動が変わるのがJavaSound（とJava2D）なんで特に。

やっぱり効率化を考えるとバイト配列を1つにしてリングバッファでやるべきなんだろうけど、それをJavaでというのがなんか抵抗が。Cだと普通にやろうという気になる不思議。一番の負荷がメモリの負荷なんでまず現状を改善するところから行くか。