今日の一歳

・ここ一周年
・反動ゲーム製作開始
・衝突方程式作成
何時の間にかの一周年。でも今出せるネタがあるわけでもない。困った物だ。移転先は未だ検討中。何のお祝いもない誕生日。

昨晩思いついたアイデアを1.5時間ほどかけて実装した反動ゲーム。でもこの程度ではお祝いに出来ない。
今日は頭がそこそこまともだったので衝突の方程式も書いた。合っているかは知らない。少なくとも効率のいい計算方法ではないはず。

作っていて、ライブラリにベクトル演算機能を標準でつけるのも悪くないと思い始めた。

今日の0.5

・数学遊び
昨日の式は積分が間違っていたので正確に積分を行ったが、そもそも積分を使うこと自体が誤りであることに気がついた。そこで、積分のロジックを当てはめて長さを計算してみたが、平方根の計算で詰んだ。(1+h^2)^0.5+(1+2h^2)^0.5+・・・+(1+(n-1)h^2)^0.5という感じ足し算を行う公式を知らない。存在するかも分からない。
計算結果の検算に使うために求めていた概算の方法で誤差が出ることを妥協して求めるのが最も現実的な計算と思い始めた。どうせグラフの点を打つ位置は整数にするのだから構わないのではないか。

衝突の公式を求めようとしているが今日は妙に頭が働かない。

今日のリスト

・ToDoリスト作成
・円描画実装＋α
・数学遊び
いろいろやることを思いついたのでToDoリストを作っておいた。日記だと日々の更新で埋もれる可能性があるのでWS本体の方に作成。

円の描画機能の実装。他に比べて格段に処理が多いので多用は禁止ということにしておく。Zバッファを実装しようと試みたが、αブレンドとの併用はやはり上手く行かない様子。作ってもあまり使う機会もないので諦める。

ブロック風の背景に色々グラフとかを書こうと思い、毎フレームごとに同じ長さが伸びた方がきれいだろうと思ったのでy=x^2のグラフの長さを求める計算をしてみた。微分っぽいことと積分を組み合わせてやったが、積分した時点で数字が異様に大きくなった。第一段階で求めた長さは√(4x^2+1)。これは手法が根本的に間違っていない限り合っている。これを積分した結果が16/3*(4x^2+1)^1.5+C。計算を間違えている可能性があり、そもそも積分を使うことが正しいのかわからない。明日にでもy=xやx^2+y^2=1のグラフについて同じ処理をして考え方があっているか調べようと思う。
正直微積を使わずに概算でも構わないようにも思うが折角なので使う。

あと、衝突の計算法を思いついたので休み中に実装する。衝突が扱えれば3本できる。
一般相対性理論も入門の本を借りてきたので頑張ってみたい。
プリンの落下は物理法則無視で適当に縮んでバウンドすればいいと思う。

今日の空間

・ライブラリ関数整理
・プリミティブ描画実装
思いついたのでライブラリの関数を変な風に整理した。関数のジャンルごとにabstract classに分けてstatic関数としてつくり、namespace的に使う。この利点はジャンルごとに変数を宣言できる点と、staticコンストラクタやデストラクタが使えること。scope文を使っても良かったがこちらは何も意識せずにちゃんと終了処理をやってくれる。

今まで面倒がっていたプリミティブ描画関数もようやく実装。点、直線、多角形の描画を作成。同じ名前の関数なのに4種類作ったりしたので無駄に面倒だった。頂点カラーを指定する機能もつけておいた。
円の描画はOpenGLの機能としてなかったので保留。実装するにしても相当重い処理になる。
折角3次元なのでZバッファ機能も実装してみようかと思っている。

今日のうずまき

・ブロック崩し風製作中
あまり進歩はない。ブロックの部分をどう作っていくかを考えている。そろそろ物理や数学の資料をあわせていかないと困難な部分に差し掛かってきたので製作が停滞しそう。物理は物体同士の反射、数学は背景模様の作成に使う。
ゲームのメインの部分はモノトーンで作って背景はランダムな色のパーティクルで描こうかと思っている。目が痛そう。

パラボラマスターに使う重力の方程式を考えている。ニュートン力学での重力の公式はただの3次方程式なのでその解を求めさえすれば済むのだが、一般相対性理論でやろうとなると一転して分からなくなる。一番分かりやすいはずのシュヴァルツシルト解でもよく分からない。フォトンではカー解が必要なので全く分からない。主に前提として使われている記号の意味が分からない。あとそれをちゃんと実装できるのか。R言語という数学専用の言語があるらしい。

何だかんだ言って中規模作品系よりもSSの方が作りやすい。
古典物理である剛体の衝突運動が扱えれば卓球とブロック崩し風と反動STGが、ゴムのような物と床との衝突が扱えればランチャが、シュヴァルツシルト解を理解すれば超重力天体にまで拡張できるパラボラマスターが、カー解まで理解すればフォトンが作れる。実際のところフォトンはどれだけ妥協するかが重要なポイントである。

今日の複素数

・文字列描画作成
・ブロック崩し風本格製作開始
文字列描画がようやく上手くいった。表示や、透過の問題はSDL_ttfにあったサンプルを参考にしてやった。日本語はフォントのせいだったらしい。テストにずっとArialを使っていたのを、VLゴシックに変えたら上手くいった。Arialも日本語表示に対応しているはずなのに不思議。
ソースコード内に日本語を書いても元々D言語のソースはUTF8で保存しているのでDのstringからC形式の文字列に変換するtoStringzを使うだけで使用できるのは強み、だと思う。コンソールやウィンドウのタイトルに日本語を使うにはtoMBSzを使うと行ける。が、Eclipseのデバッグ用コンソールは何故か日本語を表示すると化ける。もっともコンソールに日本語を使う必要はあまり感じないので構わない。
ライブラリはあとは音楽再生機能の実装と各種プリミティブの描画の実装。それから描画関数のバリエーションを増やす。

手始めにブロック崩し風の製作を本格的に開始。パドルを回転させるのだが、その操作方法に少し悩んでいる。単純に2つのキーに時計回り、反時計回りを割り当てる方法と、上下左右キーを使ってその方向にパドルが来るように回転させる方法と、押したキーの方向のベクトルを加算していってスカラーは変化させない方法との3つを考えたが、どれも一長一短。最初のやつは一番シンプルだが直感的な操作かというとあまりそういえない。2つ目は直感的ではあるが、ソースが長くなるのとパドルが一番横や上に行ったときの挙動が問題。3つ目はソースがきれいなのと直感さが両立されているが、回転する角速度が変化するので微調整が不便そう。

今日の反動

・オブジェクト指向にライブラリ変更
・拡大回転描画実装
・新作ネタ
クラスのコンストラクタでファイルを読んで、クラスに描画関数を持たせ、デストラクタで開放する。GCを活用することでだいぶすっきりした。D言語にはデフォルト引数指定がなさそうなので関数のオーバーロードで代用。
回転拡大描画も実装。回転描画だけ指定する座標が中心座標というのも気持ちが悪かったので全て中心座標を指定して描画するように変更。平行移動、回転、拡大の行列変換を使っている。
SDL_TTFをOpenGLで使おうと試みていて、文字色が青になるのと、文字の背景が透過してくれないのが問題。UTF8なので日本語が使えると思ったがそれも上手く行かないのが予想外だった。ソースコードをUTF8で書いているから問題はないはずなのだが。Phobosの変換機能を使って解決すればいいのだが。

またネタが出来てしまった。中小規模作品で6本目。自機を回転させて、ショットを撃った反動で移動する。慣性が働いて、その上移動手段がそれだけなので相当難しくなりそう。敵の弾に当たっても自機が大きく弾き飛ばされる。それで、壁にぶつかるとダメージ。受けるダメージが速度に比例する形式でも取りたい。

今日の捻り

・OpenGL使用開始
OpenGLが動くようになった。何だかリンカエラーが出てどうしても解決しないと思っていたが、glutのヘッダにextern(Windows)が付いていないのが原因だった。
それで早速OpenGLを使った画像描画を実装。実装するのが面倒で放置していた回転縮小描画や図形描画機能が一気にサポートされた。機能不足気味だったSDLから一転自由度が高すぎて困る。
描画用の関数の美しさも考えて、C言語的なスタイルで設計していたライブラリをオブジェクト指向へ転換しようと思う。デストラクタに終了処理を書けばGCで確実にメモリを開放できるはず。
VC++でOpenGLが動かなかったのはDirectXを使わせようというMSの陰謀だろうか。

今日のプリン

・ネタ考案
何か作業をしたわけでもないが。中小規模作品4つ作るとなると、それを纏めるランチャが欲しくなった。ので、物理ランチャのアイデア。OpenGLが動くかどうか試してみて、動くようなら3D&やわらかい物落下シュミレーション。

昨日のパラボラマスターはコンセプトを変えてみる。この世界の物理法則の定数を忠実に再現して、縮尺が正確になるようにして作る。ニュートン力学において重力を精密に計算して動かす。投げ方しだいで公転を始めるようなこともできるかも。パラボラといいながら二次曲線ですらなくなる。60FPSだけど、1フレーム毎に2,3周計算を行うことで動きの精度が上がると思う。

あとはライブラリをD言語風に書き直したいと思ったり、GCに頼った書き方ができるようにしたいと思ったり。

今日の赤色

・ディレクトリ整理
・Touchless実験
ソースのディレクトリを整理。今までソースファイルもオブジェクトファイルもDLLも全部いっしょになっていたが気持ち悪かったのでビルドの出力先とソースコード、プロジェクトファイルの場所を分けた。
DSSSはコンパイラがエラーを吐いてもそれが見られないようで、Rebuildも機嫌が悪く、Antは入れるのが面倒なので結局バッチを書くような形でDMDをそのまま使っている。変更していないファイルまでコンパイルしなおしてしまうが、コンパイルが早く、今作っている程度ではソースがあまり長くもないので問題ない。

ManyCamという仮想Webカメラソフトを使ってTouchlessを実験してみた。ManyCam側の問題でFPSが5程度しか出ないが、問題なく動いている模様。TouchlessのデモのソースがついていたもののC#だったので読めないが、ドキュメントを読んで分かりそうだったので何とかなると思う。あとはマウスの位置に小さなウィンドウがくっついてくるプログラムを書いて実験に便利なようにした。

変なネタが思いついたのでメモ。お題の放物線が示されて、その放物線に近くなるように物を放り投げてどれだけお題に近いかを競うゲーム。玉手箱と同じで、「どうでもいい事にわざわざ拘る」スタイル。色々な場所の重力を忠実に再現したり、重力をニュートン力学ではなく一般相対性理論で計算したりしようと考えてみたが、それらによる誤差よりも他の場所から及ぼされる重力の方が誤差の範囲として大きいので挫折。その放物線よりも、別の面に無駄に拘るというのも考えている。例えば通信対戦にしてSkypeのボイスチャットを組み込むとか、合成音声なりで少年漫画的な無駄にかっこいいセリフを棒読みさせるとか。たとえば「私の幽雅なパラボラの前に打ち砕かれるがいいわ！」とか。

今日の相似

・ブロック崩し風製作開始
ライブラリをずっと作っているのも飽きてきたので製作を開始。オブジェクト指向を意識してやってみる。あとDスタイルでのコーディング。
演算子オーバーロードやプロパティがD言語だと分かりやすく使えるので積極的に使っている。Descentの入力補完はまだ不完全らしく、プロパティの記法に対応していないようだがあまり気にならない。
D言語パーフェクトガイドを再び借りてきたので契約プログラミングや例外処理もやってみたい。特にライブラリにおいてはそういう処理をやる価値が有りそう。
Phobosのドキュメントを読むと色々と便利そうな機能がある。C++と違って分かりやすく資料がまとまっているのでいい。ただ昔から話題になっているらしいのに未だにUnicodeからマルチバイト文字への変換が簡単にできるようになっていない。自分で変換関数を書くのも何だか面倒なので日本語はSDLの文字列描画以外で使わないことにする。
そろそろ復讐も作り始めたいところ。マップエディタのシステムは大体考えてあるが、キーとなるであろう地形とキャラクターとの当たり判定の仕方を何も考えていない。

今日の蛇

・移転先検討開始
・Python導入
・Touchless導入
本格的に移転先を探し始めた。掲示板ぐらいは自作して載せようと思っているのでCGI可能で、そこそこ容量があるところを探した。2,3ほどよさそうなのが見つかったので後は比較。移転する内容は大してないので作業は楽なはず。

なんとなくPythonを導入してみた。Python+Pydev。とりあえずHelloWorldをやっただけ。スクリプト言語用として勉強予定。
あとTouchlessもインストール。Webカメラがないのでサンプルの起動が出来ない。サンプルのソースを見て、手に負えそうなレベルであればWebカメラを買って本格的に始める。

習得済み・予定言語をリストアップしてみる。Object Pascal with Delphi（簡単なGUIアプリケーション製作）、C++（ライブラリの使用、GUIアプリケーション製作、CGI製作？）、D（SDL/OpenGL使用、メイン）、Python（スクリプト）。こうしてみると色々触っている気がするわりにそうでもない。

今日の倍率

・画面全体の拡大縮小機能実装
復讐は320*240の画面サイズで作ろうと思っているので。3Dをキャラのグラフィックに使うと、絵が小さい方がいいかは微妙だが、マップチップは描きやすいはず。

ブロック崩し風について。ブラックホールの蒸発という要素を考えていたが、蒸発し終わる直前だと質量が小さいから引力が小さくなって物が振って来難くなるが、この効果を再現するとバランスが崩れるので無視せざるを得ない。それだと何だか癪なので、ブラックホールの蒸発という要素は無くし、蒸発の影響を考えないような十分な質量のブラックホールにする、もしくはそもそもブラックホールではなく抽象化する。背景を数学的な図形を使った抽象的なものにしたいと思っているので後者が有力。

D言語では実数型から整数型への暗黙のキャストをやってくれない模様。VCでは警告が出るものの暗黙でキャストしてくれていたので、警告を非表示にしてごり押ししていたので少し面倒に感じる。
あと、D言語には参照渡しの機能があるがSDL等ではポインタ渡しを使っているのでその統一感のなさがやや気になる。D

今日の纏め

・製作予定物纏め
ふと思ったのでいつもと時間帯が違うが纏めてみる。
タイトル、言語、ライブラリ、その他、の順で

・蘇生　C++　DXライブラリ　0.50まで完成。操作性改善計画
・復讐　D　自作ライブラリ　アクションゲーム
・フォトン　C++　DXライブラリ3D　ブラックホールシュミレーター
・Lunatic卓球　C++　DXライブラリ3D　Touchless　（Skype）　壁と物体との衝突
・全方位ブロック崩し風　D　自作ライブラリ　物体同士の衝突　数学的背景画面　（ブラックホールの蒸発）

五又。まるで昆虫のよう。下の3つは中小規模作品で、大体今年度中の完成。上二つは大規模作品で完成時期未定。
下の3つの内どれが完成しないか。フォトンはモデリングをしたから今更引けない。卓球は夢の技術天子盛り。行き詰る要素が多い分完成すると嬉しい。ブロック崩しはDでのゲーム作り第一弾。2Dだから作りなれている。
物理･数学面で詰まりそうなフォトンとあらゆる面で詰まりそうな卓球とD言語で詰まりそうなブロック崩し。製作のモチベーションがどこへ行くかに多分全てがかかっている。モチベーションが弾避けに流れたりする事の無いよう。

今日の動的

・D言語でDLL使用法まとめ
implibが必要。http://www.digitalmars.com/download/freecompiler.htmlのBasic Utilitiesに入っている。
Pathを通して、使いたいDLLを用意。で、
implib /system hoge.lib hoge.dll
とコマンドプロンプトに打つと、hoge.libが生成される。
これで、

module hogedll;

pragma(lib,"hoge.lib");
extern(C){
int hogehoge(int hogera);
}

という形でDのソースを書く。C言語で言うヘッダファイル。extern(C)の部分はDLLの関数の呼び出し規約による。cdeclならextern(C)、stdcallならextern(Windows)。後者は試していないが。
それで、後は使うだけ。

import hogedll;
void main()
{
hogehoge(0);
}

という感じ。当然、実行するにはhoge.dllも必要。
SDLとかのメジャーなライブラリなら、ヘッダが既に公開されている場合が多いので、必要なのはimplibでインポートライブラリを作る作業だけ。
なければ、素直に手書きしていってもいいし、htodを使うのもいいかもしれない。
結局のところ、CとかでDLLを使うのとほとんど同じ手順で出来る。
動的にDLLを使う方法は知らない。C言語でも動的に使ったことはない。

今日の変換

・D言語環境完成
・ライブラリをD言語に移植中
DSSSにコンパイラをインストールする機能が付いていたので、それを使って対応しているコンパイラをインストールした。あとはパスを通したりドキュメントを読んでみたりでそれなりに使い方は理解。

これまで開発していたライブラリをD言語に移植。一通りコンパイルできて、ウィンドウを出すことは出来たが、画像の読み込みが上手く行かない。今のところD言語とC言語とで一番大きな壁に感じているのはポインタと配列の関係。と書いたら解決策が思いつく。でも美しくない。
C言語においてはポインタも配列も全く同じように扱えるが、D言語だと配列の機能が拡張された代わりにポインタとの互換性が失われたように感じる。多分解決する為の構文はあるのだろうがまだ勉強不足。
あと、SDL_gfxを使うのがDだと少し面倒そう。とは言ってもこれぐらいの面倒があるのが普通なのかもしれない。

あと、昨日の日記の訂正。OpenALは音関係のライブラリでOpenCVが画像認識。

今日の埋火

・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を入れても上手く行かない。多分原因は使うライブラリ周りにあると見ているが不明。
あとは音楽の再生と、拡大･回転描画でもあれば十分に使える。どちらも実装の目処はついている。
ウィンドウ移動問題は強制的にフルスクリーンを使わせるか、終了時にエラーメッセージが出ても気にしないようにするか。

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

今日のフォント

・画像描画修正
・文字列描画多分作成
・マウス入力作成
PNG等を読めるように。透過色の設定とかが良く分からないので標準の画像フォーマットはPNGということにする。
文字列描画のコードを書いたが、DLLがなかったので実行できない。
音再生のコードを書こうとしたが情報不足で書けなかった。
マウス入力は上手くいった。
だいぶ必要な機能は揃ってきたがウィンドウ移動のバグはやはり直らない。必要な機能をそろえるにつれてDLLが大量に必要になってきたのもあまり気に入らない。現状でDLLが5つ必要。Libファイルに変更しようとしたが良く分からない理由でビルドできなかった。

ジャンプというアクションについて考察。精密な回避を要求するようなゲームではボタンを押す長さによるジャンプの高さの変更は必要。だが、初速度は飛び始めるときに設定しなければならないしジャンプ中に重力を強めるのも軌道が不自然になる。そこでボタンをリリースしたときにジャンプするというのも考えたがそれだと即座に高いジャンプが出来なくて不便。どうすればいいか。ジャンプの高さは一定にして空中ジャンプを作るか。

今日の分割

・ライブラリグラフィック周り作成
256色ビットマップの読み込み、及び分割読み込み。もっと色々読めるはずなのだがSDLの機嫌が悪い。ウインドウを動かすと終了するときにエラーが出たり、OpenGLが使えなかったり画像の透過情報が読めなかったりと、とことんSDLの機嫌が悪い。
SDLのソースコードを持ってきて自分でビルドしなおしたりしているし、メジャーなところのサンプルを引っ張ってきたりしているのに上手く動かない。これだけ不安定な状況だとまともな製作に取り掛かりにくくて困る。

今日の断念

・OpenGL使用を断念
ベンチマーク以前にどうやっても動かない。色々なサンプルコードを実行したがいつもエラーが出る。Vista対応のベンチマークソフトを入れてみたらOpenGL2.0対応と出たが、レンダリングテストをしたらメモリ保護とかで落ちた。調べてみてもOpenGLの動作が遅いという現象はあれど動かないという情報はなかった。でもなぜかABAGamesのゲームが動くので妙。
というわけで、重さ以前に動かないのでOpenGLはきっぱり諦めることにする。完全にSDLのみで作成。どうせ一度に表示するグラフィック数は1000以下なので大丈夫のはず。ひとまずは特に変形のない画像描画と文字の描画と分割画像読み込みでもあればグラフィック面でのことは足りるはず。そのほかはFPSの安定や音周り。
緑青をタイピングゲーム化するとか考えた。弾幕を制御するスクリプト的な文章を打たせて弾幕を張る。タイピングが遅くても弾避けが得意なら勝てるステキなルール。いっそ文字弾幕。

今日のSDL

・ライブラリ開発開始
SDL＋OpenGLだがOpenGLに関する資料が不足していたのでそのときの資料だけで出来たメインループと、入力を作った。
どうもOpenGLでの2D描画のサンプルを見る限り、SDLの2D機能を使った方が無駄が少なそうに思える。OpenGLだと2D描画専用の関数ではなく3D空間にZ軸無視で四角形を描画し、それにテクスチャマッピングをするという形。汎用性が高い分凄く重い気がする。ベンチマークを作ってみてSDLとどちらが重いのか試してみる。2Dゲームの画面を斜めから見ても嬉しくないのでSDLの方が速いならOpenGLを使わずSDLのみでやってしまおうと思う。

今日のGL

・復讐計画変更
語弊のある書き方。仕方がない。
DirectXで使う部分だけの3Dと2D＋αを実装してライブラリを作ろうと思ったのだが3Dのサンプルを見て嫌になった。何でモデル読み込む関数が標準でついていないんだか。
それで、計画変更。まず復讐での3Dの使用を諦めた。もともとゲーム自体のZ軸はなく、普通のゲーム画面でZ軸を含めて描画すると「どうしてZ軸移動しないのだ」というツッコミをしたくなる。イベントや背景に3Dを使おうというのがもともとの考え。だが、そのために3D作成は明らかに労力に見合っていないのでやめた。
次に考えたのがDirectXで2Dのみを使用。だがそれならDXライブラリを使わないメリットがなく自作ライブラリを作る気がなくなったのでそれも止めた。そこで、どうせライブラリを作るならあまりライブラリを見かけないOpenGL+SDLでやってやろうと。
暫くその組み合わせについて調べていて、D言語での使用という手が出てきたのでそれを試した。1時間以上情報を集めた後実際に作り始めたのだが、温室プログラマにとっては開発環境が辛かったのでD言語を諦めた。BCC時代よりも厳しい環境だった。エクリプスやvimを使うと便利ではないかと思っても見たが良く分からなかったのであきらめた。
そして結局C++でOpenGL+SDLを使うという計画に落ち着いた。まだ実際の作業をしていないからどれだけ厳しいのか分からないがD言語を調べていたときにみたサンプルでは2Dの分には結構簡単そうだったので頑張ってみる。
この組み合わせなのでWindows以外の環境に移植が容易になりそうだが、今のところLinuxもMacも使っていない。アンドロイド移植にはJavaが必要でどうしようもない。

今日の復讐

・SS製作開始一周年
・蘇生0.50リリース
・SS第2弾製作開始
実は今日がSSの製作開始一周年。一周年ということで大きなことを二つ。

一つは蘇生0.50のリリース。予定通り。これでバージョン番号も0.5となり、ステージも半分が完成。長かった。タイトルも『a Story of the Sword 蘇生』で正式決定にする。

そしてSS第2弾『復讐』の製作を開始。今度は「破壊的ジャンプアクションゲーム」と銘打ったそのままの内容。蘇生がC＋＋の勉強をしながらだったのに対し、こちらはDirectXの勉強をしながらの製作。DirectXのサンプルを見ながら必要な機能を自作のライブラリに纏めていく。
アクションゲームの製作は実質初めてなのでDirectXあわせてかなりの苦戦が予想される。あとはよりC++ライクなスタイルでの作成をしたいと思っているがまだクラスの設計などをしていない。namespaceを使っているだけ。

あと前々から思っていたが、そろそろウェブサイトを移転しようと思っている。ファイルアップロードが遅かったりFTPが出来なかったりがそろそろデメリットとして目立ち始めたから。Bloggerは継続。

BlackMan.KCLC.googlepages.com/ss

今日の時計

・システム時計変更ツール作成
・SS0.50仕上げ
ふと思いついたので、システム時計を指定の時刻に変更するツールを作った。変更後元に戻す機能はまだ作っていない。形になったら公開するかも。APIという物が少しは分かってきた気がする。あとMSDNの情報はやっぱり強い。
SSは会話を書いた。これでほぼ完成。明日リリース。上手く会話を纏められなかったのと奥義取得後イベントが保留になっているのが問題点。