戻る


2013/12/28 06:44

crystalcandyまで修正完了。

あとはfg4cppdemosを直せば動作確認までできていい感じになる。

できれば今日中に完了したいところだが、そううまくいくだろうか。


2013/12/26 18:06

あかん、サイトちょっといじりたくなってきた

だってわざわざタグ打つのめんどいし。

日付入力するのもめんどいし。

そのためにはまずログインシステムを構築する必要があるが、とりあえずは元からあるやつを使えばいいのでは、という気もする。

後から差し替えるというのでも問題ないはずだ。第一ログインするのは私くらいのものだ。

まー、動作確認まで終わってからにしよう。途中で他のことを考えてもしかたがない。


2013/12/26 17:56

結局fgppをやっつけた。

fg4cppdemosを修正しようと思ったらfg4cppを修正する必要が出てきたし、fg4cppはfgppに依存しているから、fgppを先に修正した方がすっきりするだろうという結論。

次はfg4cppをやっつけて、その次にfg4cppdemos。その辺が完了したらsucroseとcrystalcandyをやっつけて、動作確認し、なんか問題あったら直し、最終的にpushして完了、という流れ。

寝るまでにはfg4cppdemosまでやっつけてしまいたいところだが、やる気がもつかしら。


2013/12/26 05:11

fgのダミー関数の定義自動生成はやっつけた。

中途半端な時間だしfgppの方もやってしまおうかどうしようかと考えながらうだうだしていたら、もう寝た方がよさそうな時間になっていた。

やる気がからっぽになっていたようだ。起きたらがんばろう。

fgのダミー関数用ソースをC++からCにしたら、ダミーの共有ライブラリのサイズが小さくなった。得した気分。

ちなみにまだpushはしていない。インターフェースは変更していないのだがヘッダファイル名とか変えてしまったので、sucroseやcrystalcandyまで修正しないと動作確認ができないのだ。

や、違うな。依存プロジェクト全部だからデモプロジェクトもそうだ。

うんそうだな。次はfgppじゃない。fgppはfgと無関係だし。fgに依存しているプロジェクトを順々に修正していき、動作可能な状態まで持っていこう。


2013/12/25 16:43

ダミー関数の定義を自動でやるべきな気がしてきた。

その関数がポインタを返すのか、数値を返すのか、何も返さないのかでダミー関数の処理は一律に決まるわけだし、ヘッダのインターフェースを修正したらダミー関数の方も修正する、なんてのがまず非効率なのだ。

それに今、C++で記述していたfgのダミー関数定義をCに直しているのだが、コンパイル時に関数定義の引数名が記述されてないよエラーが出て困っている。

インターフェースの引数名を記述するなら、ダミー関数を定義するソースファイルではなくインターフェースを定義しているヘッダファイルに書くべきだ。それは引数がどういう意味を持っているのか示す重要な情報であり、それをソースファイルだけに記述するというのはもったいない。

インターフェースについてのドキュメントを書くつもりはないのだし、記述しなければならないことでそれが情報になるのならなるべく書いておきたい。

しかし、fgのイベントハンドラの定義をちょっと直して、Cでもイベントドリブンなプログラムを書きやすくしたというのに、threads.hが存在しないためにfg4cppdemosのソースを移植できなくて困っている。

glibcのバージョンを上げるべきなのかしら。しかしどこまで上げればC11に対応するのか分からん。ぐぬぬ。


2013/12/25 15:18

ゲームを動的ライブラリでなく、単体のプログラムにするべきではとか考えていた。

現時点での結論としては、それはやっぱだめっぽいといったところ。

正直、単体で動作可能な方が分かりやすくていいのだけれど。

しかし、その場合ゲームから動的リンクするライブラリを選択できないわけで。

ある機能の利用を許可しない場合に、同じインターフェースを持ったダミーライブラリにリンクさせることにより、ゲームの動作自体は可能にしても特定の機能の利用を不可能にする、みたいなことをやりたいのだ。

この機能の実現のためには、ライブラリを勝手にリンクされては困る。

最終的には、SELinuxみたいなセキュアOSの機能も利用する形できちんとやりたいところ。といっても、まだSELinuxとかのセキュアOSを使ったことないけど。ただの妄想である。


2013/12/24 14:40

windows側の対応が予想以上にやる気起きなかった。

C++11の対応がクソすぎるのが悪い。char16_tとかUnicodeリテラルとかに対応してないのをどうにかするとかめんどすぎるので、その辺とかC++11対応がちゃんとしてくるまで待つ。

vs2014はやくしろ。

というわけで別のところを進める。

どこを進めたものかと考えたところ、音やゲームパッドなど、インターフェースの追加を進めるのも悪くないだろう。

しかし、現時点でウィンドウの生成と、それに付随してマウスやキーボードの入力、あとOpenGLでの描画にも対応できているわけだ。

それならば、運用側の処理についても進められそうな気がする。

そうするとそれはそれで、インターフェースの追加が必要になってくるけど。


2013/12/21 22:27

イベントハンドラのインターフェースを修正した。

本当なら昨日に終わっていそうなものだが、びみょうにやる気が出なかったのだ。

raspberrypiにMinecraft Pi Editionをつっこんで試してみた。

マップが比較的小さいとか、クリエイションモードしかないなどの制約を除けば、快適に動作する。名刺サイズであることを考えれば、なかなかすごいと思う。

しかし、それが生かせない場面はきつい。具体的にはデスクトップからしてきつい。軽量なawesomeを使っているが、端末のurxvtを開くだけでも数秒かかるし、ウィンドウを動かそうものなら描画が遅れまくる。

Xを起動しなくてもOpenGLESを使えることは知っているのだが、その場合キーやマウスなどの入力を取得するのはどうすればいいんだろう。そこが解決すれば、raspberrypiをゲーム機にできそうなのだけれど。

次はどこを進めようか。windows側の対応を進めようかなぁ。OpenGLの関数の取得らへんが気になるし。


2013/12/19 15:33

OpenGL対応、一応できた。

拡張機能とかは全然対応していないが、基本的な骨組みはできた感じ。

気になるのは、まだ対応していないwindowsでの実装か。OpenGLの関数の取得をコンテキスト生成後に行なうようにしているので、問題ないと思うのだが。

イベントハンドラ周りのインターフェースを修正する。

SDLとかで、なぜイベントドリブンなインターフェースがないのかと考えたところ、多分修正しにくいからだと思った。

ただの関数であれば、別の関数を作るとかすれば、既存のインターフェースを壊さずに拡張できるが、イベントハンドラはそうもいかない。あるいは、引数を末尾に付け足すとかなら可能かもしれないが確証はない。

で、どうすればいいの考えたところ、イベントハンドラの引数は完全固定にして、引数に対し関数を使って値を取り出す形にすればいいのだ。

具体的には、イベントハンドラの引数を、それ専用の構造体の参照1つだけにしてしまう。構造体の実装は隠蔽し、データ取得は関数を使う。イベントハンドラの引数をいじってインターフェースを壊したりせずに、データを増やしたり減らしたりできる。

どっかで見たなぁと思ったらJavaのAWTとかSwingとかのイベントリスナのような感じだ。あんな感じに修正しようと思う。


2013/12/10 02:40

まだOpenGL対応作業中。

ようやくインターフェースが定まってきた。

OpenGLのインターフェースは、OpenGLを使える状態にしていなくてもOpenGLの関数を呼び出すことができてしまうのが気に食わなかった。

OpenGLを使える状態というのはつまり、スレッドに対してウィンドウとコンテキストの関連付けを行なった後、ということ。

それをする前は、そもそも関数呼び出しを書くことができない、というインターフェースにしたかったので、そのようにした。

具体的には、ウィンドウとコンテキストの関連付けを行なう関数の戻り値に関連付け情報を返し、glClear()などのOpenGLの関数の第1引数に関連付け情報の参照を渡さないといけないようにした。

無理矢理やろうとすれば、適当なデータを関連付け情報の参照にキャストして渡したりすればできなくもないが、そんなあほなことはやらなければいいといった感じで。

他にも、なんたらした後じゃないと実行できちゃまずいのに、なんたらする前でも実行できる状態になってる、みたいな点を改善して、大体満足のいくインターフェースになったと思う。

問題なければ、後は実装を書くだけだ。問題があっても、それが発覚した時点でまた構成を考え直すだけのことだが。

多分、一番めんどくさいのはOpenGL関数の取得。バージョン毎に取得する関数を変えないといけないし。処理の流れ自体は変わらないだろうから、とりあえずは1.0だけ対応するとかいう感じにしようかな。


戻る