今日の埋火

・D言語熱再燃
・画像認識の妄念
カタテマさんを見ていてD言語熱が再燃。調べてみるとDecentというEclipseの拡張機能があって、これに立派な入力補完機能が付いていてびっくり。以前D言語に初めて触れたのが昨年12月28日で、Decentが出たのが今年の2月のはじめ。入力補完がついたからもうDを使うのに問題がなくなってきたので、今作っているライブラリをD言語に移植してこれからはD言語での製作に移行するかも。
一つだけ問題としてあるのはDecentを使ってコンパイルする為のDSSSという奴がコンパイラの1.xにしか対応していないこと。最新版のコンパイラを取るか、VC++感覚でコマンドラインとか何も考えずにコンパイルできる便利を取るか。D言語はあまり深い機能は使う予定はないので、「コンパイラのバージョン上げたら通らなくなった！」ということにはならないだろうけれど、一度そのバージョンにあわせて書き始めたのを別のバージョンのために書き換える面倒は踏みたくない。
Eclipseを入れた勢いでJavaとか始めるかもしれない。始めないか。

マイクロソフトがTouchlessというのをデモ公開したのを見て、画像認識を使った何かを妄想。何も触らずにカメラの前で動くだけで入力になるのは見世物として面白い。Wiiリモコンを更に発展させたという感じがする。MSが公開したSDKを使うのが多分楽。だがOpenALという茨の道もある。だが、一つ大きな問題なのはウェブカメラを持っていないということ。いくらぐらいで売っているだろう。あと画像認識にはどれぐらいマシンパワーが入るのか。携帯電話で文字認識が出来るといってもあれは静止画だから。
音声認識のできるライブラリでもあったらもっと面白そう。

今日の速度

・SDL_gfx導入
まだ動作を試しただけ。コンパイラが通らないようなソースコードを公開しているのはなかなか凄い物だと思う。
メモリリークを発見してくれる関数というのを見つけた。MSはこの関数の使用は推奨していないらしいが。
Windows標準のフォントのディレクトリを取得する方法も発見。
あとはSDL_gfxで詰まったりしなければライブラリの完成まで問題はない。製作中に必要な機能はどんどん追加する予定なのでライブラリが本当に完成するのはもっと先だが。

ジャンプ問題について調べる為に洞窟物語を見たところ、ボタンを押している間の上昇中は重力加速度を小さくしている模様。ただジャンプの高さは押す時間によって滞空時間ほどは変化していなく、ジャンプの頂点辺りで急激に重力が弱くなっているよう。
自分のアイデアとしてはボタンを押す長さとは関係なく、ジャンプの高さは歩きジャンプと立ちジャンプの2種類で、空中操作で2段ジャンプをさせる。一段ジャンプでそのままだとかなり高いジャンプなのを、何かの行動によって上昇をキャンセルや急速落下させるというのも考えたが操作が煩雑になりそうなので微妙。動きが速いとタイミングを取るのも難しいし。ただ使いこなせれば一番小回りの利きそうなスタイルであることも確か。マップシステムの基礎を書いたら色々と試してみるのもいいかもしれない。

今日の垂直

・紅白改善
昨日書いた後、マルチスレッドを使う必要が何もないことに気付き、昨日のあれをマルチスレッドなしで実装した。まだテストはしていないが、少なくとも遅くなることはない。
ただもともとの設計とは違う通信のタイミングなのでソースが汚く、バグが潜んでいる可能性は大きい。おまけに作ったのが寝る直前なのでますます怪しい。
一番の不安なところは通信開始した最初のループ。

今日の糸

・文字列表示動作
ライブラリの文字描画機能を作成。文字描画のシステムを開始していなかったのが原因だった。フォントの読込先がカレントディレクトリ内からのみなので、フォントの入っているフォルダを取得したい。

ネットワークプログラム構想。現在使っている手法は「ループ開始→入力取得･送信→入力受信待ち→ゲーム処理→ループ終了」という形。これだと受信待ちでとんでもなく遅くなる。
そこで考えたのがマルチスレッド。入力の部分を別のスレッドに分離して処理する。入力を受けるスレッドを入力を扱う部分が終わった直後に開始して、入力が必要になる部分にたどり着く直前のところでそのスレッドが終わるまで待機する。この方法だとスレッドを作成するのにかかる時間が一つの問題。
もう一つは常に入力を受けるスレッドも併走させておいて、メインのスレッドとは無関係にひたすら勝手に通信し続ける方式。これだとタイミングが微妙になってややこしいことになるかもしれない。
そして書いていて思いついたのが両者を足して2で割ったもの。入力を受けるスレッドは常駐させつつ、シグナルを送らない限りは動かないようにする。
int signal,hoge;

int main()
{
 start(sub);
 signal=1;
 while(~~~)
 {
  mainloop();
  while(signal==1){piyo++;}
  InputProcess();
  signal=1;
 }
 signal=2;
 return 0;
}

void sub()
{
　while(signal!=2)
　{
 　while(signal==0){}
 　~
 　~
 　~
 　hoge=1;
 　signal=0;
　}
}

みたいな。わかりにくい。これならデッドロックも起きないだろうし、同じ変数を同時に参照しておかしくなる心配もないと思う。これでpiyo++が何度も繰り返されるようなことになると通信が重いことだって分かる。

今日の落下

・ライブラリバグ改善
・蘇生操作性改善作戦
・作品ネタ考案
ライブラリのウィンドウ移動バグが解決。デバッグ実行するときにはウィンドウを動かして閉じると例外が出るが、普通に実行する分には何もメッセージは出ず、メモリをヒープしている様子もなかった。色々悩んだのは何も意味がなかったということ。
OpenGL＋SDLは他の環境でも非動作確認。でも環境によって結構差が出る。

蘇生の操作性を全般的に向上させる作戦を思いついた。今ある案としては従来の一文字ごとに会話を送るのと、行ごとに会話を送る2つの設定を使えるようにする。それから、ボタン押しっぱなしで項目の選択が出来るようにする。これを実装してどれぐらい改善されるか。

あと作品ネタ。ドッヂボールをやっていて思いついた。当たり判定の周りに板か何かをまわして弾を受け止めて当たり判定を守るゲーム。ブロック崩しっぽい。結構ありきたりなのでこれをどう変な物に育てるか。
原子核の周りに電子をまわして突っ込んでくる光子か何かから守るゲーム。何かの周りに鉛の板をまわして核分裂で出来た中性子から守るゲーム。ブラックホールの周りに何かをまわして降ってくる物質をブラックホールに入れないようにするゲーム。
最後の奴をフォトンに絡めるのがいいかもしれない。ブラックホールの蒸発まで時間を稼ぐとか。
これだけだと単調なのでショットでも出して降って来る物質をはじき返すようにしてみるのもいいかもしれない。ショットは重力でブラックホールに向かって落ちてくる。
別に意味づけしなくても抽象ゲームとしても構わない気もする。

今日の数式

・グラフ描画プログラム作成
ふと思いついたので、関数のグラフを書くプログラムを書いてみた。純粋な好奇心と弾幕に使えるという期待とがきっかけ。∞という形を数式で表したいと思って三角関数をいじったりしたがあまり納得の行く形が作れず。
x=cos(θ),y=sin(θ*√2)でグラフを書いたら正方形が出来て面白かった。
適当な軌道でも弾源も動かしながら撃てばそこそこきれいな形になりそう。

今日の卓球

・効果音再生実装
・αブレンド実装
どちらも結構簡単だった。
そして文字列描画だが、DLLを入れても上手く行かない。多分原因は使うライブラリ周りにあると見ているが不明。
あとは音楽の再生と、拡大･回転描画でもあれば十分に使える。どちらも実装の目処はついている。
ウィンドウ移動問題は強制的にフルスクリーンを使わせるか、終了時にエラーメッセージが出ても気にしないようにするか。

卓球をやっていて思いついたネタをメモ。卓球台が動いたり、小さかったり、卓球台に当てては駄目な卓球。