いらなくなった型の削除まで完了した。
＊
コントローラの処理の改訂版は気合で仕上げた。
まだ使ってないので明日試したいところだが、色々とやることあるしなぁ。
コントローラ関係の新しいイベント型は一通り作り終わった。
＊
あとはバッファ型を作り、それを利用する形にsucrose::ControllerManagerに修正を加えればいい。
それで、いらなくなる型とかを消せば完了だな。
コントローラの処理、扱いにくいなぁ。
＊
ボタンとか軸とか、それらをバラバラに扱ってるのが悪い気がする。
確かにコントローラの見た目からしてそれらは別々なわけだけど、実際の扱いではそれらがどの順で使われたかとかが重要なことが多い。
現状の機能でそれをやろうとすると、入力を一旦全てバッファにつっこみ、それを参照して処理するスレッドに渡す、みたいな処理をしなければならない。
そのバッファにつっこむところまではsucrose側で処理して、バッファを参照して処理する部分だけゲーム側でやらせればよさそう。
＊
明日からその方針で進めていこう。
年内にはコントローラの扱いを確立させたいところだが、間に合うかな。
想像以上に整えることができた気がする。
＊
いくつかの画面を遷移してから、1つずつ戻すのはもちろん、特定のポイントまで一気に戻したりもできる。
とりあえず、この構成でコントローラ設定画面を作ってみようかな。
やはりだめだな。
＊
色々と試行錯誤してみたが、大きく変更を加える必要がある、というのが結論。
データ型の構成や処理の流れからして変える必要がある。
想像以上に複雑になってしまった。
＊
正直、これでいいのかあまり確信がない。
来週の頭に見直してから確定しようと思う。
ロック処理にミスがあった。
＊
ミューテックスを2つにしないとうまくいかない気がする。
関数内でロックとその解除を行なうロック処理って、自動テストでテストできるんだろうか。
fg::BasesystemEventPropertiesManagerを追加して、不要になった型や関数の削除も完了。
＊
ここに来て、ゲーム初期化時にスレッドプールを稼働させていないことが悪影響を及ぼしている。
しかし、テストの都合上fg::BasesystemContext生成完了時点ではスレッドプールを稼働させてない方がやりやすいんだよなぁ。
まぁ、それ以外に理由がないならfg::BasesystemContext生成時にスレッドプールを稼働させるべきだろうな。
既存のfg::EventPropertiesManagerはfg::EventPropertiesStackに変更した。
＊
で、新たにfg::EventPropertiesManagerを追加した。
fg::EventPropertiesManagerを介してfg::EventPropertiesStackに対してpush()、pop()を行なう。
fg::EventPropertiesManagerを生成した時より浅い階層へのpop()はできないようになっている。
また、fg::EventPropertiesManagerを破棄する時、生成した時の階層までpop()するようになっている。
自発的なpop()は必要ないかとも思ったけど、そうなるとfg::EventPropertiesManagerを生成しまくることになりそうだし、まぁいいかなって感じで。
＊
明日からはfg::BasesystemEventPropertiesManagerを追加していく。
インタフェースを少し変えて、fg::BasesystemEventPropertiesStackは最終的にsucrose内に内包し、インターフェースからは削除しようと思っている。
ゲーム側から見せる必要がなくなりそうなので。
機能の追加漏れがあった。
＊
その部分について、昨日追加を行ない、0.23.1とした。
＊
処理自体はこれで問題ないと思う。
問題はインターフェースだな。
1本のスタックの中身を、push()とpop()だけ管理するのは厳しいものがあると思う。
容易く整合性が崩れそうだ。
生成時にpush()し、破棄時にpop()するRAIのようなものを考えているけど、それでいいのかどうか。
fg::BasesystemEventPropertiesManager出来上がった。
＊
テストの記述をちょっと修正したら、0.23.0を確定しよう。
詰まる箇所もあったが、fg::BasesystemEventPropertiesManagerのpush()、pop()まで完了。
＊
fg::BasesystemEventPropertiesManager関連の残件は、push時、pop時、変更時のイベント関数対応と、fg::BasesystemContextからのpushとpop実行くらいか。
来週の頭には全て完了したいところ。
fg::EventPropertiesは出来上がった感じ。
＊
勢いで作ったところがあり、なかなかひどい作りだったのをどうにかした。
これでいよいよfg::BasesystemEventPropertiesManagerの方に取り掛かることができる。
しかし、今の状態でもfg::EventPropertiesの作りはびみょうな気がするな。
fg::BasesystemEventPropertiesManagerの修正、かなりトリッキーなことになりそう。
push()とpop()は追加できた。
＊
fg::BasesystemEventPropertiesManagerの修正はまだ。
その辺りを対応するためには、fg::EventPropertiesに機能を追加する必要があるな。
fg::EventPropertiesManagerの中身を修正中。
＊
push()については、1種類でいいと思った。
2種類目は、fg::EventPropertiesに機能を追加する形にしようと思う。
明日中に片付けられればいいが、そこまで気力が続くかどうか。
作りが甘かったかもしれない。
＊
現状のBasesystemEventPropertiesTaskによるEventProperties更新は、言ってみればgotoのようなものだ。
規模の大きい物を作る場合には混乱の元になるかもしれない。
関数呼び出しのような、スタック形式にするべきか。
その形にすれば、リソースの生成、破棄タイミングも明確になるかも。
というのも、今その辺でちょっと困っている。
EventProperties更新するのはいいが、更新されたイベントから参照するリソースの生成、破棄タイミングはどうしよう、と。
＊
さて、現状からの修正を考えるとどうなるかな。
Readerはそのままでいいけど、Writerはだめだな。
Writerは削除して、Managerにpush()、pop()を付ける。
push()はEventPropertiesのみと、それに加えてリソースの生成、破棄を目的とした関数の参照2つと、そのリソースを配置する場所の参照も持つ2種類を用意する。
＊
しかし、fg::EventPropertiesって必要かな。
fg::BasesystemEventPropertiesだけでいい気がする。
fgへの関数追加まで完了。
＊
あとは実際にそれを使用するように記述を修正するだけ。
やる気がやばいけど、画面遷移確認まで完了。
＊
画面遷移処理は全く同じ記述にしかならなさそうなので、fgに関数を追加することにする。
OpenGLのタスク生成と同じような感じだし、明日中には仕上げたい。
それを使用して画面遷移処理を書き換えたら、中身を作り始められるかな。
fg::BasesystemEventPropertiesに関係する型を追加している。
＊
現状では自分でロックかけたり解除したりができないので、ロック中に他の処理もやっておく、ということができない。
それを改善するために、ロックに関する型を追加しようかと。
＊
それができたら、簡単な画面遷移を作る。
今の構成で進めてみることにした。
＊
正直、違和感を感じた部分の構成は変わってないんだけど。
慣れてなかっただけかもしれないし、いい解決方法が思い付かないし。
＊
ひとまず、コントローラ設定画面について、新しい仕様に合わせる修正をした。
合わせる、といっても起動できるようにしただけなので、もっと今の構成に合わせた記述に直す。
それから、画面遷移についての処理を入れてみよう。
ゲームの関数変更完了。
＊
へびゲームにも修正を加えて、きちんと動くことを確認した。
しかし現状の構成ではよくない。
イベント処理関数からゲームデータを参照するのがちょっとめんどくさい。
どうにかするべきとは思うんだけど、どうするかがまだもやっとしているな。
fg::EventPropertiesをfg::EventProcsに変更するの、いらなかったかも。
＊
そう思ったので、とりあえず変更したブランチは残しておいて、別のブランチを作ってそっちをいじっている。
というわけでfg::GameDataの追加をやっている。
fgには追加したし、久々にcandymaker自体をいじくる必要があるな。
fg::EventPropertiesをfg::EventProcsに変更した。
＊
明日はイベント処理関数の型を以前の状態に戻すところから始める。
コントローラ設定画面に手を付けようとしたが、思うように書けない。
＊
ちょっと構成見誤ったか。
書いていて違和感を感じる箇所がところどころにある。
＊
fg::EventPropertiesは少し間違いだったように思う。
主に名前が。
そんな汎用的に使うものではなく、イベント処理関数だけつっこんどけばそれでいい関数な気がする。
fg::EventProcsにするべきだったな。
よって、読み込み専用のこれをイベント処理関数の引数にするのも違和感ある。
イベント処理関数の参照なんて、普通はイベント処理関数内で必要にならないだろ。
前の構成に戻すべき。
＊
あとは、ゲームの関数も変更するべきだな。
現状ではfg::BasesystemContextとfg::BasesystemArgsをまとめた、fg::BasesystemDataの参照を引数に、色々やってからboolを返す関数だけど、fg::BasesystemArgsはもはや必要なくなってきた。
ゲームデータの設定処理しかできないし。
それなら、fg::BasesystemArgsとfg::BasesystemDataは削除し、引数としてfg::BasesystemContextの参照を受け取り、ゲームデータを生成して返す、とした方がいいだろう。
もちろん、ゲームデータの破棄関数も必要になるけど。
＊
とりあえず名前変更からかな。
次にイベント処理関数の引数を元に戻す、といきたいけどゲームデータ型にしたいところもあるし、それを追加した後か？
となると、ゲームの関数変更を先にやるべきだな。
ゲームの関数変更は大きい変更だけど、他とは独立してる感じだし最初にやってしまっても構わない気がする。
＊
その前に、ひとまず今の状態でバージョンを確定させておこう。
へびゲームをfgの仕様変更に合わせる形で修正完了。
＊
コントローラ操作の部分に関しては、まだ存在しないため書いていないが。
コードの量はほとんど変化しなかったな。
新しい仕様の要素で相殺された感じか。
＊
問題なく動くことは確認できた。
次回からはコントローラ設定画面を使って、画面遷移処理を書いてみたりなどしてみるか。
OpenGLによる描画イベント、できた気がする。
＊
明日、へびゲームとかそこらを新しいインターフェースに合わせた書き方に修正して確認しよう。
想定通りなら、より短いコードで同じ処理ができるようになっているはずだ。
これで元からある機能の実装は完了できたか。
＊
あとはOpenGLによる描画イベントを実装すればいい。
これは新しい機能になるが、大体は既に作ってある機能の組み合わせでいけるだろう。
fg::BasesystemEventPropertiesを作っている。
＊
あとは、内容更新のためのsucrose::BasesystemEventPropertiesManagerを作り、それをfg::BasesystemContext内につっこめば出来上がり、かな。
ここまでやって、ようやく画面遷移などがやりやすくなるはず。
早くコントローラ設定画面を作りたい。
スレッドのキャンセルの件については解決。
＊
fg::EventPropertiesをudev関係でも使うべきか、悩ましいところ。
あまり実装方法がばらけてても分かりにくいし、統一してしまうか。
ようやく原因判明かな。
＊
スレッドのキャンセル時にこけてる原因が分からなくて、かなり時間をかけてしまった。
キャンセルかけたスレッド内でwaitしたり、wait中のスレッドにキャンセルかけたりしたらいかんってことね。
その辺考慮したコードになっていなかった。
すぐ修正しないとまずいな。
ひとまず、ウィンドウ周りは対応した。
＊
メインウィンドウについても、fg::BasesystemContextに対してデータを設定することで処理を変更可能にした。
しかしながら、構成は変更するべきだろうな。
現状では、fg::BasesystemContextの内部で利用するデータはヘッダファイルに列挙型を用意し、特定のインデックスに特定のデータをセットすることで対応している。
このやり方はよくない。
将来的に、fg::BasesystemContext内部で利用するデータを増やしたり変更したりした時の影響が大きすぎる。
fg::BasesystemContextに対して設定するものは、fg::EventParametersをラッピングし特殊化した型にするべきだろうな。
＊
とりあえず問題ないことは確認できたわけだし、ちゃちゃっとコントローラ周りについても対応してしまおう。
それが済んだら、fg::BasesystemContext用のfg::EventParametersの追加を含めた様々な変更を行なっていくとしよう。
fg::EventParameters関係を作り終えた。
＊
型の名前はこれでいいのかどうか。
いまいちしっくりこない感じがあるが、まぁいいだろう。
来週の前半には、既存のイベント関係の処理をこれで差し替えてしまいたいところ。
ベースシステム周りは処理を差し替える以外にも色々変える予定なので、ちょっと時間がかかりそうだな。
＊
来週はもう8月なのか。
まずいなぁ、これでは今年中にゲーム1本作るのは厳しそうだ。
fg::ThreadTaskの件については保留とした。
＊
今のところ大きな問題にはなっていないし、不要になって消す場合にも代替方法は明確だ。
他の部分の構成が変わってしまうわけでもないので、とりあえずは放置でいいかなと。
＊
fg::ThreadTask以外の簡単な部分については処理し終わったので、ベースシステムのイベント処理関係に取りかかっている。
ベースシステムの、とは言ったが、結局のところそれ以外の部分でもイベント処理関数は固定しない方がいいと思った。
なので、汎用的にイベント処理関数を変更できる仕組みを考えた。
複数の項目について、同期を取って変更可能な仕組みにできたとは思うのだが、いまいち扱いにくいような。
インデックスで管理する仕組みだし、バグの温床になりそうで怖い。
とは言え、これより良い方法が思い付かないんだよなぁ。
ちょっと行き詰まっている。
＊
イベント処理関数を完全に固定するやり方は、ベースシステム関連に関して言うならよくないかもしれない。
画面が遷移すれば、画面の描画内容は変わるし、コントローラによる入力の扱い方も変わる。
イベント処理関数が固定されている状態でそれに対応するためには、自前で分岐処理を書き、呼び出す関数を変えるなどする必要がある。
しかしながら、そのような処理はごく一般的なものであり、わざわざゲーム側でやるべきことには思えない。
＊
全体的に構成を見直すべきかもしれない。
上記以外にも、例えばfg::ThreadTaskとfg::WaitThreadTask。
fg::ThreadTaskはいらないのではないだろうか。
fg::WaitThreadTaskを用意したのは、スレッド数が固定であるfg::ThreadTaskにおいて、処理中に待機が入ってスレッドを占有してしまうと全体の処理が止まってしまうという懸念からだ。
しかし、スレッド数を固定で用意することにあまり意味はないのではないだろうか。
固定で用意したとしても、fg::WaitThreadTaskを使えばそれとは別にスレッドを増やせてしまう。
もちろん、スレッドを増やし続けてしまうとメモリ圧迫などの問題が出るため、fg::WaitThreadTaskは必要な場合にのみ使う、と決めてはいる。
とはいえ、実際のところfg::WaitThreadTaskの処理をfg::ThreadTaskで処理するのには問題があったとしても、その逆はない。
無駄に複雑にしているだけにも思えるのだ。
＊
他には、描画イベントのパラメータだ。
再描画関数では範囲を指定することが可能だし、再描画が必要な範囲は描画イベントのパラメータとして受け取ることができる。
しかし、どのような範囲を指定したところで、現状では全画面が再描画の対象となってしまっている。
クリッピングによって再描画範囲を指定することは可能だろうけど、そこまでする必要があるものなのかどうか。
私の用意したインターフェースでは、描画イベント関数と再描画処理は別のスレッドで行なわれる。
その2つで描画範囲を共有するのは困難なのだ。
いっそ、常に全体を再描画するようにした方がすっきりするような。
作るゲームにもよるだろうが、一部分のみよりも全体を再描画する機会の方が多いようにも思えるし。
＊
最初の話に戻るが、ベースシステムの構成をより高度なものにするべきかもしれない。
イベント処理関数を変更可能にするなら、イベント処理関数は複数存在するため、整合性を保つためにイベント処理関数に対する処理は排他ロックをかけてから行なうことになる。
ただ、単純にそうしてしまうと、1つのイベントを処理している時に他のイベントが処理できなくなる、という問題が発生する。
そこで、ゲーム側のイベント処理をfg::ThreadTask化することを考えた。
それであれば、fg::ThreadTaskを起動する時だけロックをかければいいので、処理中はロックをかける必要がなくなる。
その場合、fg::ThreadTask起動前にベースシステム内で前処理をしておいたりする必要があるだろうな。
＊
古いコントローラ制御処理の削除も含めて、色々と修正を加える必要があるな。
まずは分かりやすいところから進めていこう。
削除関係が一番簡単だろうから、削除に関する2件を先に進めよう。
その次に描画イベントの変更だ。
ベースシステムの構成変更は大幅な変更なので最後だな。
予想以上に困難だった。
＊
メンバの並び順が原因で、破棄時に処理がこける場合があった。
こういうのはやはり、場合がある、という部分が厄介だ。
全く同じ記述なのに毎回発生するわけでなく、発生する時としない時がある。
マルチスレッド処理に起きがちで、原因の特定に時間がかかる問題だ。
＊
でもまぁ、今回の問題は今日で解決できた。
ついでにOpenGL関係でも同じような問題が起きていたので、それも解決した。
＊
これでようやく次に進める。
fg::BasesystemContextに、新たに作成したコントローラ制御処理を追加していっている。
＊
もうちょいで完了。
完了したら、ゲーム側で入力データを取得し、コントローラ割り当てなどに利用する処理を作っていく。
やる気減退が著しいが、とりあえずできたか。
＊
sucrose::ControllerManagerにfg::ControllerRawEvent呼び出し機能を追加した。
これでコントローラとして使用できるデバイスが直接生成するデータを、イベントとして受け取れるようになった。
このデータを使って、設定ファイルを生成できるようにしたい。
＊
しかし、これだと最近作ったfg::ControllerTesterがいらなくなるような。
明日にはfg::ControllerRawEventに対応できるかな。
＊
昨日、デバイスファイルを開き直せばーと書いたが、それでどうにかなるなんて全く気のせいだった。
現状得られるデータを見るに、オープン時の初回データは破棄するしかない、というより破棄するべきだな。
例えボタンを押しながらジョイスティックを接続したところで、初回オープン時に得られるデータではボタンは押されていないことになっている。
別のジョイスティックを使えば何か別の結果が得られる可能性がないわけではないだろうが、意味のないデータを得られる可能性がある時点で使い物にならないと判断するべきだろう。
sucrose::ControllerManager作成開始。
＊
とりあえず、sucrose::ControllerManagerが受け取ったイベントをほぼそのまま流すイベントのみ対応する予定。
実際に必要なボタンイベントや軸イベントについては、設定ファイルがないとどうしようもないから後回し。
＊
evdevのジョイスティック対応も追加するべきかもしれない。
evdevでないジョイスティックの制御は、なぜか接続時の軸データがおかしいのが気にかかる。
evdevの方なら大丈夫、という保証は全くないが。
＊
暫定的な対応としては、一度デバイスをオープン、クローズしてから再度オープンする、か？
そうすればおかしなデータは読まずに捨てられるかもしれない。
sucrose::UdevJoystickManager完成。
＊
次はsucrose::ControllerManagerだけど、その前にsucrose::UdevJoystickManagerを試しに使ってみよう。
動作が確認できているのは単体レベルなので、他と組み合わせたりするとちゃんと動くかどうか、まだ不安だ。
その辺を確認してから次に進む。
後はsucrose::UdevJoystickManagerを作るだけになった。
＊
ジョイスティックの入出力自体は作った。
接続と切断についての管理を、sucrose::UdevJoystickManagerで行なう。
その辺が未完成だ。
＊
しかし、既存の型であるsucrose::GamepadManagerとそれに関連する型よりも、整った構成になったように思う。
いい傾向だ。
udevを扱う型、sucrose::UdevManager完成。
＊
今は、sucrose::UdevManagerで検出したゲームパッドを扱う型として、sucrose::UdevJoystickManagerを作っている。
接続、切断、ボタン、軸のイベントがあるので、多少めんどくさい。
でもまぁ、大まかな構成は既存のものと同じなので、そこから持ってくれば明日中には完成するかな。
とりあえず必要最低限な情報を扱うものを作る。
まさに接続、切断、ボタン、軸のイベントを処理するだけのもの。
デバイス名だとか、ボタン数だとか、軸数だとかについては取得しない。
＊
ただ、既存のものにはなかった要素として、デバイスを特定する情報は生成する。
具体的には、接続したポートとデバイスを一意な情報として扱う。
同じデバイスであっても、違うポートに接続すれば別物として扱うのだ。
udevならそういった情報を取得できるので楽だが、例えばwindowsのdirectinputなんかで同じことはできるのだろうか。
windowsだからできない、なんてことはないだろうけどdirectinput以外の機能が必要、とかなってくるとめんどくさそうだ。
udevを扱う型がもう少しで完成。
＊
udevで検出したデバイス情報を元にして、デバイスを管理する型に接続したり切断したり、といったことをさせる予定。
とりあえず古い処理が存在するゲームパッドを対応する。
他にもキーボードの対応も可能だと思うけど、後回しだな。
様々な種類のデバイスを統括管理する型の方を先に作る。
入力テストを行なう型について、作れるところまで作った。
＊
といっても、入力テストを行なう型、fg::ControllerTesterは中身ほぼ空っぽでなにもしない状態だけど。
ここから先は、デバイスを扱う型を別に作り、fg::BasesystemContextに搭載しないと話が進まない。
どのように構成すべきか、というところまで済ませた。
明日は末端から作っていく。
末端の処理は既に作ってあるものを流用できると思うので、さくさく作っていきたい。
ID型の内容については後回しにすることにした。
＊
udevの接続時に得られる情報とか、その辺を実際に見てから決めることにする。
あと、IDというのはゲームパッドではなく、ゲームパッドのボタン1つや軸1つにつき1つずつ用意することにしようと思う。
私の考えている改訂版では、ゲームパッド自体を一意に示す情報があっても大して役に立たないのだ。
ゲームパッドに搭載されている要素1つ1つに用があるので、それらに対して一意に示す情報があればいい。
＊
とりあえず、入力テストを行なう型を生成するために必要な情報をまとめた型を作った。
中身空っぽの暫定的なID型も作ったし、明日は入力イベントの対応から入る。
入力イベントが出来上がったら、いよいよ入力テスト処理だ。
また先走るところだった。
＊
初回設定を行うかどうか、なんて処理は後でいい。
とにかく初回設定に必要な機能を作ろう。
まず初回設定をできるようにする。
次に初回設定を保存できるようにする。
そして読み込み処理を作り、その後にようやく初回設定するかの判定処理を入れる。
この順で片付けていくべきだろうな。
＊
というわけで、初回設定を行うために、ゲームパッドの入力を読み取るインターフェースを大体作った。
ゲームパッドの入力値やゲームパッドを特定するための情報についてはまだちょっともやもやしているため、まだ作っていない。
後者については、入力デバイスの種類、入力デバイス名、デバイスが接続されているポートを特定する情報、を文字列にまとめられればよさそうな気がするのだが。
それらをID型として定義すればいける、か？
おととい辺りに、SEGVについては解決した。
＊
ゲームパッドの扱いの改良版を作ろうとしているが、やはり自身にとっての未踏領域のためなかなか手が出ない。
コントローラ設定アプリ起動時に、コントローラ設定数が0だった時初回設定を行うようにしよう、というのは決めた。
しかしコントローラ設定数はどこから取得できるようにするべきか。
fg::BasesystemContextからであるのは確定だが、そこから直接取得するか、コントローラ管理の参照を取得し、そこから取得するか。
後々他にも色々な情報を取得することを考えると後者にするべきかもしれないが、前者の方が現時点では簡単だ。
とりあえずはfg::BasesystemContextから直接取得する形でやろう。
結局、最終的にその形で落ち着きそうな気もする。
実に困った。
＊
ゲームのユーザーデータの破棄が、場合によってはSEGVで失敗する。
その原因がいまいち分からない。
少なくともへびゲームでは発生していなかったのだが、ユーザーデータの内容を少なくしていったら発生するようになった。
＊
色々いじくってたら、原因は分かった。
ゲームのライブラリをアンロードした後に、ゲームのライブラリ内にあるユーザーデータ破棄関数を呼び出そうとしたためだ。
しかし、それならユーザーデータの内容に関わらずに発生しなければ辻褄が合わないのだが。
デバッガを使って調べた限りでは、そういう結論になった。
＊
実際、構成がおかしいのだ。
ゲームのライブラリロード前に生成したインスタンスに対して、ゲームのライブラリ中で生成しているユーザーデータを設定してしまっている。
これでは今回のようなバグが発生してしまうのは当然と言える。
構成を大きく修正するべきかもしれない。
へびゲームでOpenGLの描画タスクを使用するようにしたりなどした。
＊
OpenGLの描画タスクが想定通りに機能するか不安だったが、特に問題なく使用できて一安心。
最終的に、へびゲームのソースを400行近く削減できた。
OpenGLの描画タスクに分かりにくい処理をまとめた関係で、ゲーム側にそういった処理を書かずに済むようになったし、いい感じ。
＊
というわけで、明日からはゲームパッドの扱いの改訂版作成に戻ろう。
描画処理が書きやすくなったから、前よりは楽に進められるはず。
ゲーム初期化前にウィンドウを生成するように変更完了。
＊
ゲームパッドマネージャについてもゲーム初期化前に生成するようにしたので、ゲーム初期化後にはデータの設定とスレッドプールの開始をするだけになった。
明日はへびゲームをどうにかするとしよう。
ゲームパッドについても対応完了。
＊
明日は、ゲーム初期化より前にウィンドウを生成するように処理を変更する。
それが済めばようやく、OpenGLの描画タスクを利用できるようになるな。
なんとか、関数の追加はできた。
＊
fg::WindowInfoへのイベント関数及びユーザーデータ設定関数を追加して、さて古い関数を消して帳尻合わせるか、と思ったら他の部分にも追加が必要なことに気付いてやる気が下がった。
fg::BasesystemArgsだ。
とりあえず、そちらにもfg::WindowInfoに似た関数の追加を行なって、関数の追加については完了。
古い関数の削除などは明日にする。
＊
想定外なことが起きるとやる気がぐーんと下がるの、よくないなぁ。
頭を絞って、どうにか便利そうなインターフェースになった気がする。
＊
イベント関数の設定と、イベント関数から参照できるユーザーデータの設定関数はそれぞれ別々に用意した。
それだけだと、イベント関数で参照できるユーザーデータの型が分からず、void *をキャストする必要があり、ちょっと気分が悪い。
そこで、可変長テンプレート関数を用意して、イベント関数とユーザーデータの設定を1つの関数で一気にできるようにした。
この形にしたことで、イベント関数で参照するユーザーデータの型と、設定するユーザーデータの型を統一できるようになった。
＊
とはいえ、各設定関数の実装とテストがまだだ。
来週の頭には済ませてしまいたい。
問題ないようなら、同じ形でゲームパッドについてもちゃっちゃと実装してしまおう。
そうすれば、ゲーム初期化より前にウィンドウを生成するように変更する作業に移れる。
と思ったが、よく考えたらベースシステムの引数にイベント関数を設定する処理もあるんだったな。
なかなか手間がかかりそうだ。
タスク生成関数のテンプレート修正完了。
＊
これによって、わざわざvoid *で渡されるユーザーデータをキャストして、とかやる必要がなくなった。
違う型にキャストしてしまう、なんてミスも起こらなくなるし、いい感じ。
＊
さて、ウィンドウのイベントハンドラについて、インターフェースを修正しようと試しに記述したのだが、これでいいのか不安になる。
タスク周りの修正がうまく行きすぎたから、相対的に見て微妙な感じに見えるだけだと思うのだが。
＊
実行時にデータを引き渡すタスクのようなもの、があれば便利かもしれない。
苦戦したが、なんとかできた。
＊
OpenGLの描画タスク完成。
それに伴って、タスクの型をちょっと修正した。
OpenGLの描画タスクに加えた処理では自身を再度実行する可能性があるのだが、タスク内から再度自身を実行する、という処理ができなかったのだ。
それができるように、型を修正して対応した。
＊
明日はタスク生成関数のテンプレートの定義修正から。
さて、困ったことになった。
＊
現状では、インターフェースの変更についての修正をへびゲームに適用したので、動くようにはなった。
しかし、OpenGLの描画タスクはまだ使えていない。
ゲームの初期化時点ではまだfg::Windowが生成されていない、というのが問題だ。
OpenGLの描画タスクは、生成関数の引数としてfg::Windowとfg::GLContextの参照を必要とする。
fg::Windowが生成されていないゲーム初期化時点において、OpenGLの描画タスクを生成することができないのだ。
＊
しかしながら、ぱっと見た感じfg::Windowをゲーム初期化時点までに生成してはならない、というわけではないように見える。
ゲーム初期化時にfg::Windowから呼び出されるイベントハンドラの生成などを行なっているため、それらを使うfg::Windowの生成はゲーム初期化の後、というだけの話だ。
ゲーム初期化より前にfg::Windowを生成しつつ、ゲーム初期化時に生成したイベントハンドラが利用される形になれば、問題ないわけだ。
そのくらいなら、ちょっと工夫すれば対応可能だろう。
＊
さて、どこから手を付けるかな。
まずは、OpenGLの描画タスクについて、少し処理を追加する。
それでOpenGLの描画タスクは完成とする。
次にタスク生成関数のテンプレートの定義修正。
それらが済んだら、ウィンドウとかゲームパッドのイベントハンドラについてのインターフェース修正かな。
で、ベースシステムの処理を変更し、ゲーム初期化より前にウィンドウを生成する、と。
大体そんな感じか。
そこまでできれば、へびゲームでもOpenGLの描画タスクを使用できるようになるだろう。
OpenGLの描画タスクについて、とりあえず自動テストは通した。
＊
明日、へびゲームで実際に使ってみよう。
あと、タスク生成関数のテンプレートについて少し定義を変更する、というのもやる予定。
タスク周りは完了した感じ。
＊
細かい修正と、タスク生成関数のバリエーション追加が完了したので、そこでバージョンを区切っておいた。
ラッピングタスクの方はまだ。
とりあえず、OpenGLの描画タスクを追加するつもり。
このタスクによって、自前でfg::GLCurrentを生成したり、バッファのスワップをしたりということをしなくても済むようになる予定。
OpenGLの描画タスク、と言っても単にfg::WaitThreadTaskを生成するだけだ。
想定通りなら割と簡単に済むと思うのだけど、そううまくいくだろうか。
やはり手間取った。
*
とはいえ、ファンクタを関数ポインタに変更するのは完了した。
ただ、タスクを利用していた箇所に一部、このままだと違和感を感じる箇所があるので、そこは明日修正する。
それが終わったら、タスク生成関数のバリエーション追加と、それを使ったラッピングタスクの追加、って感じか？
そこまでやったら、前に作ったへびゲームを修正して動くようにしてみるか。
前よりは整った記述になる、と思うのだけど。
タスク起動インターフェースの修正が思ったよりも手間取ってしまった。
＊
なので、関数の呼び出し方変更についてはまだ。
明日には仕上げる予定。
あと、タスク生成関数のバリエーションを1つ追加する予定。
タスクの関数から参照できるデータは、別の場所に格納されているデータの参照だけだが、タスクの中にデータを格納できるようにもしたい。
そうしなければ、ラッピングしたタスクが作れなさそうなのだ。
いい調子だ。
＊
sucroseのタスク関係のソースファイルをベースシステム関係に統合完了。
fgから、スレッドプール関係の記述を削除。
あとは、タスク起動のインターフェース修正と、タスクで呼び出す関数をファンクタから関数ポインタに変える、といったところか。
そのくらいなら、明日中にできるかな。
もっと丁寧に進めることにした。
＊
とりあえず、sucroseのビルドルールを修正。
自動テストのビルドで、sucroseで生成するライブラリとリンクすることでコンパイル回数を減らした。
今までは依存しているソースファイルを全てコンパイルしていた。
なので、ちょっとソースファイル追加するだけで色々な自動テストのビルドルールにソースファイルを追加しなければならず、面倒だった。
今回の修正で、割と楽になったはず。
candymakerの方もどうにかできるだろうか。
＊
で、fgのタスク関係のソースファイルをベースシステム関係に統合した。
明日はsucrose側のソースファイルを移動し、統合する。
そしたらインターフェースを修正し目標達成、の流れの予定。
盛大に設計ミスってた。
＊
タスクについては作り直し。
既存処理をちょっと改変すれば完了するので、最近書いた処理は全部削除。
すごい徒労感。
必死こいてある程度進めたけど、完了まではいけなかった。
ちゃちゃっと来週前半に終わらせる。
タスク管理も完成。
＊
やっぱりタスク管理で管理しないタスクは最終的に消してしまおうと思う。
その前に、タスク管理まで作れたので既存処理の置き換え、削除を先にやる予定。
待機タスクのキャンセラは作り終わった。
＊
タスク管理の方はちょっと構成を変えることもあって、今日中は難しかった。
明日中には作り終えてしまいたいが。
待機タスクについても作り終わった。
＊
あとは待機タスクのキャンセラとタスク管理。
しかし、タスク管理で管理しないタスクというのは、使う機会あるんだろうか。
いっそのこと、タスク管理で管理されたタスクだけでもいいのではないか。
とりあえず、普通のタスクの方は作り終わった。
＊
来週中頃には待機タスクやタスク管理を作り終えたいところ。
タスク管理の部分に関しては、ちょっと構成を変更する予定。
複数のタスクが存在し、あるタスクから別のタスクを起動する、というようなことをやると、その別のタスクがすでに破棄されているのに起動しようとしてしまう、ということが起きかねない。
そこでタスク管理というものを置き、それが存在している間は別のタスクの起動が成功し、破棄が始まれば起動が失敗するようになるので安全に複数のタスクを破棄できるようにしている。
現状、これはタスクとタスク管理の2つを引数に取るタスク起動関数を使うことで対応しているが、これではタスク管理を用いていてもタスク管理を使用しないタスクの起動もできてしまう。
後者はバグの温床であり、そういうことができない構成が望ましい。
なので、ただのタスクとは別に、タスク管理によって管理されているタスク、というものを用意しようと思う。
＊
しかし、これをどのような位置付けにするか、ちょっと悩んでいる。
型から別のものにしてしまうのが、確実な方法だろう。
しかし、型は同じで、タスクで実行する関数をラッピングする、という方法でもできそうな気がする。
その場合、ただのタスクと管理されているタスクを全く同じように扱うことができる。
…が、そうすることによって何か得することがあるのか、というところに疑問が残る。
型による判別ができなくなるため、むしろバグの温床になりそうな気が。
やる気はびみょうだけど、ちょっとずつ進んでる。
＊
やはり、同じ名前の機能の追加はやりにくいな。
仮の名前を置いて作業しないとうまくいかない。
作り終えて、古い機能を削除するまでの辛抱だ。
モチベーションが上がらない。
＊
なので、別のところを進めることにした。
基本的に、イベントハンドラという名前を使うことをやめることにする。
大体これのせいで、ゲーム側のコードが長くなっているのだ。
全てタスクで統一する形にしようと思う。
現時点では汎用的に使える2種類のタスクがあるが、用途別にタスクを用意する。
タスク内で使えるデータ、つまり引数が異なる感じだ。
＊
これに付随して、現時点ではスレッドプールというものをゲーム側から参照できるようにしているが、これもやめる。
いちいちベースシステムのコンテキストからスレッドプールの参照を取得し、タスクを生成、なんてめんどくさいのだ。
ベースシステムのコンテキストの参照を渡して生成してしまえばいいじゃないか。
これに伴い、fg-threadはfg-basesystemに統合する。
＊
タスクで実行する関数は、C++だしファンクタ、std::functionで定義したものを使っていたが、Cの関数ポインタにしようと思う。
そもそもテンプレートで定義するものを使うのは、なんだか気分が悪かったのだ。
言語自体に用意されてるものの方が、何かと都合がよさそうな気がする。
少し困ったことになった。
＊
ゲーム側で、fgなどのモジュールを使用するコードを含む部分について、自動テストコードを動かすことができない。
モジュールのファイルパスを直接指定してリンクしてやれば動かせると思うが、それをどうやってビルドルールに組み込むか、という話になってくるな。
突貫工事にはまるで向いてないな、この構成。
＊
とりあえず画面になんか表示しよう、と1ファイルにどんどん追加していったらすごくごちゃごちゃしてしまった。
で、冷静になって一旦元に戻した。
＊
コントローラの設定のためのインターフェースは、まだまとまっていない。
ゲームパッドを特定する情報と、押されたボタンを特定する情報があれば、とりあえずできるだろうか。
その2つを、何番のコントローラに割り当てるのか、という情報と合わせて設定する感じで。
画面作り始めた。
＊
ゲームパッドの扱いの改訂版を作るに当たり、どこから進めるべきか迷って、まず画面から始めることにした。
ゲームパッドの初期設定を、画面見ながらいわゆるウィザード形式でできるようにする予定なので、画面がないと始まらないかな、と。
ウィザードの説明文を表示するための機能が足りてないが、これは後回しでいいだろう。
作っている私が把握できればいいので、適当に三角形でも表示しておけばいいのだ。
＊
問題は構成の方だ。
かなり大掛かりで、ややこしい感じになりそうな気がする。
うまいこと機能を分割して、小さく小さく作っていけたらいいのだが。
体調が治ってきた。
＊
fg::ModuleContextがモジュース初期化より後でも使えることを確認した。
adhocrepeaterを搭載したraspberrypiの調整をしたりなどもした。
来週からセーブデータ機能を利用する処理の作成だな。
fg::ModuleContextをモジュール破棄まで保持するように変更した。
＊
しかし、現状では初期化が成功するところまでしかテストコード書いてないな。
明日、テストコードを追加して確認しよう。
＊
体調が思わしくない。
気温が急激に変化したからだろうか。
データ要素の文字列化についての修正をした。
＊
文字列への変換ではなく、ファイルデータ型に変換するように変更した。
文字列化をするのはファイルに書き込むためだし、文字列化してからそれをファイルデータ型につっこむ、というのは回りくどいと思っていたのだ。
セーブデータの読み書き、とりあえず完了。
＊
とはいえ、これは暫定的な処理だ。
まず、セーブデータディレクトリというものを用意していないため、セーブファイルはパッケージディレクトリに対して書き込まれるようになっている。
それに加えて、データが平文なので容易に改竄できてしまう。
＊
しかしながら、とりあえずは機能するし次回からはセーブデータを必要とする機能の作成を、といきたいがまだちょっと無理だな。
セーブデータの読み書きにはfg::ModuleContextが必要だが、fg::ModuleArgsから名前だけ変えただけの今の作りでは、モジュール初期化処理後にfg::ModuleContextは消滅してしまう。
なので、ベースシステムが終了するまではfg::ModuleContextを保持しておくように変える必要がある。
それ以外に、細かい修正もしておきたい。
要素の文字列化は作り切った。
＊
セーブデータの書き込みと読み込み、明日中にいけるかな。
新たに作る処理といえばファイル書き込みくらいだし、問題ないと思うけど。
セーブデータの内容生成処理完成。
＊
次は要素の文字列化、そしてセーブデータ書き込みだな。
明日中にそれを終わらせて、あさってに読み込みを作って完了、といけばきりがいいのだが。
セーブデータの内容生成処理、もう少しで完成。
＊
残件は、リストやマップへの要素追加。
現状の案では、引数のクローンを生成し、クローンを要素として追加する、という形が一番問題が起きにくいだろう考えている。
そこが出来上がったら、いよいよセーブデータ書き込み処理に入る。
要素の文字列化はまだやったことがないので、多少手間取るかもしれない。
とはいえ、文字列からの解析処理に比べたらずっとましだろう。
普通に考えて、セーブデータは書き込みが先だな。
＊
セーブデータを作成しないことには、読み込み機能なんて作っても意味ないし。
やる気のせいもあって、今日はインターフェースを整えただけで終わってしまった。
来週中には読み書きをできるようにしたいところ。
不要になった処理の削除完了。
＊
fg::FileR、fg::DirPathR、fg::ModuleArgsを削除した。
パッケージ内に配置したファイルの読み込みがやりやすくなって、いい感じ。
明日はセーブデータの読み込みをやる予定だけど、ちょっと構成をいじる必要がある気がする。
既存処理の改訂版作成は完了。
＊
差し替えと既存処理の削除は、なかなか規模が大きいこともあり、やはり完了できなかった。
特に、モジュール初期化関数の引数変更については、変える必要がある自動テストがあるし、ちょっとめんどう。
明日には完了したい。
進め方を少し間違えた。
＊
その関係で、ちょっと進行が遅れた。
明日中には、処理の改訂と不要になった部分の削除を済ませてしまいたいが。
パッケージ内のファイル取得処理の改訂版をとりあえず作った。
＊
fg::FileRやfg::DirPathRはいらなくなるので、その辺の処理も消して簡略化する予定。
セーブデータ読み込み処理は、既存部分の改訂を済ませてからだな。
いまいちしっくりこない。
＊
でもまぁ、こんなものだろう。
パッケージ内のファイル取得と、セーブデータ読み込みについてのインターフェースを追加。
とりあえずこれで作ってみようと思う。
この構成なら、ファイル関係のモジュールがいらなくなるが処理自体は1つのモジュールに収めておけば済む形にできるな。
パッケージ内のファイル取得インターフェースも変えるべきな気がしている。
＊
ファイルを開いてそれを読み込む、などということをいちいちやるようなインターフェースは違和感がある。
処理が低レイヤーすぎる。
いちいちそんなことをしなくても、ファイル取得といえばファイルの内容を全て読み込む以外にすることなんてないのだし。
もっと単純な形でいいはずだ。
ヘッダファイルの問題は解決。
＊
あれ、よく考えたら今日追加したのはセーブデータの内部フォーマット作成関係のインターフェースじゃないか。
いかんな、作業間違えてた。
セーブデータ読み込みインターフェースを作らないと。
やれやれ。
＊
既存処理の差し替えは完了。
ユニークポインタ周りで不具合があった。
ひとまず問題が起こらないようにしたけど、根本的な解決はまだ。
ヘッダファイルのインクルードを忘れると、ビルドは通るが実行しようとするとリンクエラーで実行できない、という現象が発生している。
どうすればいいのか大体は把握できているので、明日中には直す。
セーブデータの内部フォーマット解析処理作成完了。
＊
来週から既存処理との差し替えと、セーブデータ読み込みインターフェースの整備と。
そんな具合に進めていく予定。
完了の目処はついた。
＊
明日中には、セーブデータの内部フォーマット解析処理を作り切れるはず。
文字列について、処理を改良した上で完了した。
同じような感じで、リストとマップを対応すれば完了。
想像以上に処理がびみょう。
＊
処理どころかテストもびみょう。
なので、元の処理に手を加えていく形で対応しようとしている。
やる気減退してるというのもあるけど、さすがに1日では無理だった。
演算子オーバーロードなんて消滅してしまえばいいのに。
＊
それに付随するADLとかいう概念が邪魔をして、無駄に時間を使ってしまった。
しかしそのかいあって、ユニークポインタの宣言と定義をfgにまとめることができた。
fgとsucroseとcandymaker、それぞれ別々に記述してるのが気持ち悪かったし、いい感じ。
＊
セーブデータの内部フォーマット解析用インターフェースの定義はできた。
といっても、既に処理まで作ってある、文字列、リスト、マップのみ。
できてる部分の書き換えなら簡単にできるし、数値型なんて現時点ではいらないし。
明日中にcandymakerに追加したい。
やる気減退中。
＊
セーブデータについては、もっときちんと考えてから取り掛かるべきだと思った。
インターフェースを定義することにより、ゲーム側が簡単にセーブデータを作成したり、作成したデータを読み込んだり、だけで済む話ではない。
セーブデータのフォーマットを定めることにより、ゲーム外から参照した場合にもセーブデータ名などの情報を参照したり、コピーや削除などをできるようにしたい。
簡単に言えば、PlayStationのメモリーカード管理画面のような、ああいった機能を実現できるようにしたいのだ。
そう考えると、とりあえずファイル書き込み機能を作ってセーブデータのファイルを作れるようにしました、という対応は今後を考えるとあまり意味がないと思うのだ。
もちろん、内部的にはそういった処理も必要になるので、完全に無駄になるというわけでもないと思うが。
＊
そういう意味では、現在のゲームパッドの対応もよくない。
ゲームパッドの接続や切断、どのゲームパッドのどのボタンが押された、などといった情報を直接ゲーム側に渡してしまっている。
デバイスとゲーム側との間に制御プログラムを挟み込むことにより、柔軟なことができるようにしたいのだ。
しかし、そのためにはセーブデータの概念は必須だろうな。
デバイスをどのように管理するか、という情報はセーブデータとして格納するのだから。
＊
ちなみに、セーブデータの内部フォーマットについては、設定ファイルのものを改良した上で流用しようかと考えている。
現時点ではリストやマップといった構造を除くと文字列値しか扱えないので、数値も扱えるようにする。
そして、ファイル形式としてテキスト形式以外にバイナリ形式にも対応する。
さすがに、プレイヤーが簡単に参照したり改変したり、ができるのはどうかと思うし。
暗号化したテキスト形式をバイナリ形式として扱えば手軽か？
それだとゲーム外からの参照が困難になるな。
暗号化要素という概念でも追加して、一部の要素のみ暗号化、ということができるようにするか。
＊
さて、どこから進めるか。
fgに、セーブデータの内部フォーマット解析インターフェースを定義するところからかな。
ひとまず暗号化については後回しで。
既に作ってある設定ファイル解析処理を使い回して、処理を実装。
それを作ると設定ファイル解析処理と内容が被るため、差し替え。
セーブファイル読み込みインターフェースの定義、実装。
セーブファイル書き込みインターフェースの定義、実装。
そこまで済めば、セーブファイルが必要になる機能も手を付けられるだろう。
とりあえずOpenGL関数追加完了。
＊
へびゲームがきちんと動作することも確認済み。
これであとはセーブデータの読み書きもできるようにすれば、それらしいゲームを作れる気がする。
＊
しかしOpenGL対応は、現時点は仮対応だな。
もっとちゃんとやるなら、使用するバージョンやら拡張機能やらをゲーム側が指定し、そのチェックなどをするべきだろう。
昨日のうちに、ウィンドウに対する処理の追加は完了した。
＊
具体的には、タイトル設定とウィンドウサイズ固定。
今日からOpenGL対応。
過去のプロジェクトで作った処理を流用して追加しようとしている。
＊
それが終わったら次はなんだろう。
セーブデータ対応だろうか。
ファイル名などの修正も完了。
＊
今までハードコーディングしていた、ウィンドウサイズの設定を引数から設定するように変更。
合わせて、ウィンドウ内全てに対する再描画要求関数も追加した。
あとはウィンドウのタイトル設定くらいか。
ウィンドウ情報へのウィンドウタイトル設定関数の追加も忘れていたようなので、合わせて追加する。
大まかには完了。
＊
前に作ったへびゲームのsucrose版関数呼び出し箇所をfg版に変更し、動作するところまで確認できた。
残件は、ファイル名の修正と一時的に付けた型名、関数名の修正。
さすがにその程度であれば、2時間もあれば十分完了できるだろう。
足りなかったりいらなかったり、を解消。
＊
OpenGL関係のfg版インターフェース定義もやった。
実装作って、sucrose版消して、を明日中にできるだろうか。
sucrose版の削除も予想以上に面倒だった。
＊
OpenGLに関係するものについてもfg版を作らなければいけないようだ。
他にも、関数定義位置の不備や実装漏れなどがあったりするので、それらまとめて今週中に終わらせるのを目標にやろう。
ゲームパッドの追加は、あとは実際にゲームパッドを扱う部分だけ。
＊
ちゃちゃっと追加すればベースコンテキストの方も対応できる。
それが済めば、いよいよsucrose版の削除に移れる。
ゲームパッドについてもfgに定義を追加しなければならなかった。
＊
今日中？無理無理。
来週の火曜ぐらいまでには片付けたいところ。
いつか起きるだろうと思っていた事態の対処でかなり時間を食ってしまった。
＊
やはり、先に宣言していないと参照できないというのは面倒だ。
しかし今日加えた修正により、この点については今後同様の問題が発生しないようにできたはずだ。
明日中に残件を片付けられるだろうか。
sucrose版の利用箇所をfg版に差し替えるのは後回し。
＊
ウィンドウ関係とベースシステム関係、fg版を追加していっている。
ベースシステムの内部にウィンドウで生成をしているし、ウィンドウの内部でベースシステムの機能を利用している。
循環参照のような形なので、なかなか追加が面倒だ。
想像以上に面倒だった。
＊
とりあえずスレッド関係についてはfg版作成完了。
sucrose版の利用箇所を差し替えるのはまだ。
今週中には、ウィンドウ関係についてもfg版の作成とsucrose版の利用箇所差し替えまで終わらせたい。
ウィンドウに関する定義を、全てfgに追加した。
＊
sucroseの定義をfgに変えている最中。
最小の修正で変更していくには順序があるので、ちょっと面倒だ。
明日中には完了したい。
やはりやる気がびみょう。
＊
ウィンドウと、ウィンドウ生成時に必要な情報をまとめた型に関する定義を追加した。
sucroseではイベントハンドラ集合としていたものに、ウィンドウのタイトルとサイズの情報を追加した感じ。
イベントハンドラ削除関数は使う機会があるとは思えないので追加していない。
イベントハンドラ呼び出し関数は、実装するライブラリ内に用意すればいいと判断したので追加していない。
最初に想定していたよりもシンプルな感じになりそう。
来週の頭には、イベントハンドラの定義を全部追加してしまいたい。
できれば、実装側も整えられればいいのだが。
ウィンドウ周りを整えるに当たり、fgに定義を追加することにした。
＊
fg::newWindow()の引数にfg::BaseContextの参照があるのでその定義の追加が先。
fg::BaseContextの関連関数のfg::getThreadPool()の戻り値がfg::ThreadPoolの参照なのでその定義の追加が先。
といった具合で、とりあえずfg-threadを新たに作った。
fg::BaseContextの定義をfg-basesystemに追加したし、明日からウィンドウに入る。
現状ではウィンドウのタイトルは無し、幅や高さは固定で生成、ウィンドウのサイズ変更可能となっているので、その辺をどうにかできるように関数を定義する。
ひとまず、ファイル読み込み処理統一を対応した。
＊
その他細かい修正もしたが、これ次何をやろう。
ウィンドウ出せるし、ゲームパッドも扱えるし。
ウィンドウについては、サイズ固定じゃなかったりといい加減な感じあるが。
へびゲームを作ったりもできたわけだし、ようやくゲーム自体の制作に入れるのだろうか。
その場合、何を作るかが問題になるなぁ。
＊
ウィンドウ周りをもう少しきちんとしたら、windows向けのモジュール生成をやるというのもいいかもしれない。
それをできるようにするためにも、玄箱T4を使えるようにしたというのもあるし。
＊
ああ、現状だとOpenGL関数を直接呼び出してるんだっけ。
それだとOpenGL使えない場面でも関数呼び出せちゃって気持ち悪いんだよなぁ。
古いプロジェクトではその対応も入れてたし、ウィンドウ周りと合わせてそこをやってしまうか。
rootfsはメモリ上で問題ない、というのが結論。
＊
USBメモリにrootfsを構築して玄箱T4を動かしたが、処理時間を計測したところそこまで差が出なかった。
USBメモリ上のrootfsだと壊れる可能性があり、修復の手間などを考慮するとメモリ上に展開する方がいいだろう。
＊
メモリ上にrootfsを展開する場合、TFTPで別のマシンからダウンロードしてくるのだが、ダウンロードだけで30秒程度かかる。
一度起動してしまえば関係ないとはいえ、多少長いのが気になっていた。
その件に関しては、ジャンボフレームに対応するようにMTUとtftpコマンドのブロックサイズ指定で解決。
ほんの数秒でダウンロードが完了するようになった。
＊
明日からcandymakerの開発に戻る。
前に書いた内容だと、ファイル読み込み処理が2つあるからそれを片方に統一するところからやる、とか書いてある。
しかしそれはやらずとも動いてるわけだし、後回しでいいような気もする。
まぁ、どこから進めるかは明日状態を見てから決めよう。
金曜日の時点でハードディスク搭載まではできた、のだが。
＊
sambaだけでは不十分な感じがある。
アクセスしたユーザーでしかファイルにアクセスできないのは不便だ。
ファイルサーバーとして使うなら問題ないんだけど、linuxのrootfs作る時など、ファイル権限をrootにしたい時もあるし。
なので、そういった作業用にnfsも必要だと思った。
＊
というわけで今日、nfs、hdparm、NTPクライアントを追加したものを作った。
機能としてはこれで十分なんだけど、rootfsをメモリ上に展開するのは、メモリが128MBしかない玄箱T4では厳しい感じがある。
ファイル転送速度にも影響が出ているような。
少なくとも金曜日の時点で、samba上にあるlinuxカーネルのビルドをしようとしてもうまくいかなかったし。
TFTPでブートしてから、nfsかUSBメモリ上にあるrootfsで動作させて、メモリ上からは退避させようと思う。
とりあえずはUSBメモリで対応するかな。
それでファイル転送速度とかが改善されればいいのだが。
スワップを使用していた時の使用量から考えると、90MBほどメモリが使えれば問題ないはずなのだ。
まだ2月なわけだし、明日までは玄箱T4の件をやることにする。
あとはハードディスクを搭載するだけ、になったはず。
＊
実際に動かしてみないことにはなんとも言えない。
しかし、よく考えたらhdparm入れてなかった。
まぁ、まだ起動しっぱなしにするわけでもないし。
土日中にビルドしてしまうか。
あとNTPクライアントも入れてなかったな。
adhocrepeaterで複数のデバイスを扱えるようにした。
＊
しかし、実際に使ってみないことにはちゃんとできてるか分からない。
週末に動作確認する予定。
＊
玄箱T4は、ディスクレスでの稼働と、ハードディスク4台の移植で完了としよう。
ソフトウェア構成は明日中に完了させたい。
玄箱T4のemerge完了。
＊
しかし困った。
無線LANアダプタがきちんと動かない。
ファームウェアがどうのとdmesgにはあるものの、きちんとsys-kernel/linux-firmwareは入れてあるし。
対応していると思われるファームウェアも含まれてるしで、いまいち原因が分からない。
そもそも玄箱T4に無線LANアダプタを付けるという構成がおかしいかもしれない。
玄箱T4やらメインのマシンやらは、有線LANで構成すべきか。
しかしそれ用にdhcpやらdnsやら、iptablesやらを用意するのは、これまた手間だなぁ。
とりあえずは固定IPで、iptablesとかその辺はなしでやるか。
＊
その辺いじくってたりも並行してやっていたせいもあり、adhocrepeaterの進みはいまいち。
ひとまず設定ファイルの追加項目について、テストを作った。
明日中に完了させて、木金で玄箱T4の方も完了させたい。
想定外に時間がかかっている。
＊
玄箱T4でemergeをしているが、想像以上に進みが遅い。
昨日の夜からやっているので、せめて今日の昼頃には終わるかと思ったのに。
distccでコンパイルは高速なマシンでやっているものの、それにしたって遅い。
＊
adhocrepeaterや玄箱T4の件は、2月中には決着させたい。
adhocrepeaterの1ポート構成化も、やるべきなのかどうか。
現状の2ポート構成でも、とりあえず問題はないわけだしなぁ。
気になるところと言えば、扱えるデバイスの数ぐらいか。
現状、1つのデバイスしか相手にできない。
簡単な修正で解決できると思うし、そこぐらいはどうにかするか。
＊
3月からはcandymakerの方を進める予定。
nfs？知らんな。
＊
カーネルとファイルシステムを、全て外部からTFTPでダウンロードして起動することに成功。
起動後は全てメモリ上に配置されるため、有線LANの接続が必要なのは起動時のみ。
起動中ずっと接続していなければならないnfsとは違う。
＊
ファイルシステムに関しては、gentooのstage3を展開したものをほんの少しいじったもので確認しただけ。
なので、来週はそこをどうにかして、完成といきたいところだ。
＊
メモリ使用量は起動直後で40MB弱といったところ。
まぁ、セットアッププログラムでインストールできるdebianはもうちょい多かった気がするから問題ないだろう。
stage3をハードディスクに入れて起動した時には3MB弱だから多少気になるが、ファイルシステムが40MB近くあるのだから当然である。
まぁ、mdraidやらsambaやら、必要なツールつっこんでも容量は大して変わらんだろう。
動いた動いた。
＊
バージョン4.9.9のカーネルに、玄箱T4のカスタマイズパッチを適用したソースをビルドしたカーネルが玄箱T4で動作した。
miconaplも一応問題なく動いていたようなので、おそらく問題なく手直しできたのだろう。
しかし現状、miconaplはセットアッププログラムでインストールできるdebian上でなければ動作できていない。
miconaplはバイナリだし、やはりこれもビルドツールのバージョンの差異の影響だろうか。
とはいえ、公開されているマイコンの仕様書に沿って互換性のあるツールを自作すれば、この問題はクリアできるようだ。
しかし、やりたかったのはファンの回転速度を落とすこと程度なので、そんなにすぐ作る必要もないだろう。
＊
明日中に、玄箱T4でnfs bootやnfs rootをできるようにしたいところだ。
玄箱T4の方をやってる。
＊
起動させるだけなら簡単にできるかと思ってたけど、そんなことはなかった。
カーネルのビルドは問題なかった。
FIT対応とかいうのも問題なく作れる。
問題は、2.6.30.8のカーネルだとFATAL: kernel too oldとかいって起動でこける。
ソースのバージョンに対して、gccとかのビルドツールが新しすぎるのかもしれないが、確証はない。
新しいバージョンのソースならいけるかと思い、カスタマイズ分の差分を適用しようとしたら面倒なことになった。
元のソースが古いせいか、構成が新しくなったせいでそのままでは使えない処理とか、そういうのが多くて手直しが必要になる。
とりあえず、ビルドが通るようにしたいところだ。
＊
raspberrypiと同じく、ディスクレス環境にしたいがメモリ128MBだし。
さすがにきびしい気がする。
確認が取れたので0.2.0として確定。
＊
1ポート構成の0.3.0を作る前に、raspberrypiの方を先にやることにした。
といっても、今日で完成した感じはある。
他に何かなければ、adhocrepeaterの方に戻って0.3.0を、と行きたいところだけど。
明日用事で出かけるし、今週中は厳しそう。
構成自体、結構変える必要があるだろうし。
別のポートを使用する構成が完成。
＊
したと思うんだけど、実際に使ってみないことにはなんとも言えないなぁ。
多分大丈夫だと思うんだけど、1人ではなかなかテストしづらい。
明日動作確認して、問題なければ0.2.0として確定。
＊
問題ないようなら、1ポート構成に修正する。
それを来週中に完成させたら、とりあえず一段落にしたい。
あまりadhocrepeaterばかりやっていても仕方ないし。
＊
adhocrepeaterの次は、raspberrypiと玄箱T4かな。
しかし面倒だからなぁ。
玄箱T4については、ぱぱっとできそうならやる、ぐらいだな。
方針変更。
＊
試したこともないことを、急にやろうとするのは無茶だ。
できないことはないだろうけど、奇妙な、後々手を付けにくい構成になってしまうだろう。
なので、まずは簡単な作りのものを作ることにした。
SSID転送用に、別のポートを使用する。
これであれば、多少分かりやすい構成で作ることができる。
もちろん、これは暫定的な構成の予定だ。
うまくいったのを確認してから、効率のいい、よりよい構成に変更する。
＊
というわけで、その構成でSSID送信処理は作った。
SSID受信処理ももう少しでできる。
明日中にはSSID受信処理を完成させて、それを組み込む予定。
SSID強制変更対応完了。
＊
やはり、比較的簡単に対応できた。
ちょっと面倒に考えていたせいで多少手間取ったが、最終的にはシンプルにできたと思う。
＊
問題はSSID転送の対応だ。
こちらはちょっと修正して完了、とはいかないだろう。
デバイスのデータ中継に混ぜて転送する予定なので、その選別とか必要になる。
それをどのように表現するかが問題だ。
＊
どんな変更を加えたところで、設定ファイルの項目追加はなさそうな気がする。
名前変更くらいはあるかもしれないけど。
ならば今日中に、今日までの変更で追加するべき項目の対応は済ませておくべきか。
そうすれば、木金はSSID転送に集中できる。
＊
送信についてはどうとでもなるだろう。
問題は受信だろうな。
SSIDの履歴機能追加完了。
＊
pspautoconnector2に実装していた機能では無駄、というより不自然な処理があったので、それを省いた上で実装した。
adhocrepeaterでは別の箇所で同様の処理をしているため、必要ないのだ。
＊
明日から、できれば明日中に、SSID強制変更の対応をする。
方法については大体まとまっている。
pspautoconnector2よりも機能を分割しているため、対応しやすそうな気がする。
実際にやってみなければ、なんとも言えないが。
＊
しかし、自動テストはどうしよう。
SsidChangerに強制変更用の関数を追加する、というのも違うし。
SsidChangerのSSID変更関数の仕様変更で対応する形になりそうだな。
その関数用のテストを作るか。
v0.1.0として確定。
＊
今週中には、SSID変動に対応させたい。
相手にSSIDを送信して、相手も同じSSIDに設定するところまで。
とりあえず、SSIDの履歴機能を追加する。
今のままでは、周囲に複数のネットワークが存在する場合に、順々にチェックしていくようなことができない。
pspautoconnector2に実装済みの機能だし、明日中には完成させて次に行く予定。
＊
次というのは、SSIDの強制変更だ。
特定のSSIDを検出したら、そのSSIDに強制的に変更する。
＊
その次はSSIDの転送機能だろうな。
検出したSSIDの他者への送信と、他者から受信したSSIDの処理。
そこまでできれば、SSID変動に完全に対応できるはず。
ここまで、できれば今週中に。
設定ファイルの読み込み完了。
＊
明日試しに動かしてみて、特に問題ないようならバージョン0.1.0のプロトタイプ完成。
全体的な動作確認以外の確認事項としては、データ中継の効率に変化があるかどうか。
データ中継処理を、前に作ったものから変えているためだ。
効率が良くなっているといいのだが。
残るは、データ送信機と受信機の設定。
＊
それ以外は一通り対応した。
明日中には、今作ってある部分については設定ファイルをいじることで色々できるようになり、一応動かせる状態になるはず。
あくまでプロトタイプであり、機能はまだまだ足りないが。
＊
かなり行き当たりばったりで作ってたpspautoconnector2と違って、比較的ソースが見やすい気がする。
pspautoconnector2には引数10個以上の関数とかあってわけわからなかったし。
その原因は設定ファイルのデータを1つ1つ引数で渡していた、というのもある。
今回はその辺、設定の型ごと一気に渡す形に変えたので、引数が多くなりすぎず見やすい感じ。
設定ファイルの対応開始。
＊
テスト用データのビルドルールとか、その辺の動作がおかしかったり、記述が気に入らないので直したりしていたら多少手間はかかったが、とりあえず軌道に乗った。
後は、設定データを追加し、それを読み込む処理の追加、読み込んだデータの使用。
それを追加していけば完成する。
というわけで、他者から受信したデータをPSPに送信する処理完成。
＊
明日から設定ファイルの読み込みと、読み込んだデータの使用。
できれば全て作ってしまいたいけど、それなりに量あるしできるか分からない。
設定ファイルの解析処理自体はpspautoconnector2のものを使うから、そこで詰まったりはしないが。
ネットワークへの接続の確立処理ができたようだ。
＊
対象のSSIDが見つかるまでスキャンを繰り返すことで対応。
変更するSSIDの選択処理については、とりあえずはなくてもどうにかなるし、後々追加する。
PSPから受信したデータの送信処理はできたので、明日からは他者から受信したデータをPSPに送信する処理を作る。
明日から、というか明日中に作ってしまいたい。
蓄積されているデータからのSSID変更処理は一応完成。
＊
変更するSSIDの選択処理は作っていないため、そこは追加する必要があるけど。
＊
既存のネットワークに接続するにはSSIDの検索を行なえば、と昨日書いたが、やはりというかそこまで単純なものではないようだ。
SSID設定後、あまりに速くSSIDの検索をかけてもうまく行かなかった。
だから、何回か繰り返して検索処理をかける必要があるだろう。
具体的には、設定したSSIDが見つかるまで。
やはりアドホック接続についてはきちんと理解できていなかったようだ。
＊
アクセスポイントをanyに設定すれば既存のネットワークに接続するようになる、と思ったのだがそんなことはなかった。
SSIDの検索を行なうべきだろうな。
複数回行なう必要はない。
1回行なえば、見つかり次第アクセスポイントのアドレスに変更されるようだ。
iwlistならうまくいったが、iwlibを利用したプログラムでも同じ動くになるかどうかは分からない。
明日試しに処理を追加してみよう。
＊
SSID変更要求の呼び出しは追加したが、蓄積されているデータからSSIDを変更する処理はまだ。
この部分も明日作ってしまえればいいのだが。
そうすれば、PSPから受信したデータの送信処理は完了になる。
受信したデータが処理対象かどうかのチェック、完了。
＊
データを受信できなかった場合のSSID変更要求、関数作成完了。
あとはそれの呼び出し処理追加と、すでに蓄積されているデータからSSIDを変更する処理の追加。
これでPSPから受信したデータの送信処理は完了。
次は、他者から受信したデータをPSPへ送信する処理。
こっちは多少単純にできるはずだ。
それが出来上がったら、設定ファイルの読み込みに取り掛かる。
これをやらないと、とりあえずプロトタイプで使ってみる、ということができない。
データの中継が完了すれば、とりあえず使える状態にはなるわけだし。
やる気はびみょうだが、大枠はできたっぽい。
＊
残りは、受信したデータが処理対象かどうかのチェックと、データを受信できなかった場合のSSID変更要求。
後者に関しては、とりあえず関数を追加する必要があるなぁ。
前者はどうやって処理しよう。
MACアドレスのチェックなんだけど、まぁmemcmp()しておけばいいか？
型は全て作った。
＊
後は組み合わせて機能にするだけ。
UDPによる送受信と、生パケットの送受信ができるソケットをそれぞれ作った。
＊
あとは、パケットの配列の定義とパケットの配列を管理する型の作成。
それができれば、PSPから受信したデータの送信処理が作れる。
思うようにやる気が出なくてよくない。
＊
UDPによるデータ送出処理がまだ途中。
パケットを管理する型は作った。
ソケット通信をする型は明日中に全て作ってしまいたい。
盛大に勘違いしていたようだ。
＊
SSID設定処理でSSIDの検出なんかいらない。
アクセスポイントをanyに設定すれば、既存のネットワークに接続するようになるらしい。
無理解から勝手なことやろうとしてた。
簡単に言えば、昨日やったSSID検出処理の共通化は完全に無駄になった。
モチベーションの低下がやばい。
＊
アクセスポイントをanyに、という情報も、実際に試して確認しただけなので、それが正しい仕様なのかどうかは分からない。
anyじゃなくても、とりあえずアクセスポイントを何かしら設定すれば接続できたし。
アドホック接続に関する詳しい仕様がどっかにまとまって書かれていればいいのだけど。
その辺はRFCとかIEEEとかなんとかなんだろうか。
＊
そんなわけで、モチベーション下がりつつもPSPからデータを受信し、それを他者に送信する処理を作り始めている。
必要な追加機能は、PSPからデータを受信するための生パケット取得用ソケットと、他者に送信するためのUDPソケット。
あとは、一時的にパケットを溜め込むバッファもあった方がいいだろう。
PSPからデータを受信する処理と、そのデータを他者に送信する処理はそれぞれ別のスレッドにする。
バッファはその橋渡しだ。
想定以上にめんどくさい。
＊
SSID設定処理でもSSIDの検出を行なうため、SSID検出処理を共通化した。
SSID検出スレッドの処理を、共通化したSSID検出処理で行なうようにするところまで完了。
これで明日にはSSID設定処理にSSID検出を追加できる。
＊
多少やる気が落ちてきてるのも、やはり効率に影響している。
次にやることまでちゃんと考えておかないと、モチベーションの維持ができんな。
この次はいよいよ中継処理に入る。
PSPから受信したデータを他者に送信する。
pspautoconnector2にはなかった処理だ。
PSPからデータが受信できなかったら、SSID設定処理に対してSSID変更しろ、と要求を投げる感じ。
SSID設定処理には、まだそれに対応するための処理を作っていないので、合わせて機能追加をしていく。
＊
その次は他者から受信したデータをPSPに送信する処理か？
で、検出したSSIDについて他者に送信する処理と、他者から受信したSSIDの処理。
それでメインの処理は多分全部。
後は設定ファイルの読み込みと、その適用。
そんなところだろう。
SSID設定処理作成中。
＊
とりあえず設定するだけならできたが、これ多分接続前にネットワークを検出している必要があるな。
pspautoconnector2がうまく動いていない時があったのも、そのせいかもしれない。
明日中には設定処理を作り終えたい。
SSID検出に反応してSSIDを設定する処理を作っている。
＊
SSID検出に反応して、というイベント処理がもうちょいで出来上がる。
イベント処理については、大体sucroseと同じような感じで処理している。
来週の頭には、SSID設定処理まで仕上げたいなぁ。
周囲のSSIDを検出する処理を作った。
＊
pspautoconnector2ではチャンネルを考慮していなかったが、今回は一致するもの以外扱わないことにした。
この方が、混線を防げていいだろう。
＊
次に作るべきは、SSIDの設定処理だな。
しかし、目的のSSIDかどうか確認するにはデータを受信してみないと分からないしどうしよう。
などと考えたが、今回はデータの転送もするんだし、その辺はそっちに任せるか。
＊
SSIDの設定については、大きく分けて2種類のルートで行なおうと思う。
1つは、SSIDの検出に反応して行なう設定。
もう1つは、ネットワークの切断に反応して行なう設定。
まず前者から作り始める。
後者はデータの読み取りができるようになってから。
SSIDをまとめる型を作った。
＊
まだ完全ではないが。
例えば、イベントハンドラを登録できるようにして、新しいSSIDがつっこまれた時に呼び出すようにしたい。
が、それを作るのはもうちょい先でいい。
明日には、周囲のSSIDを見つけ次第つっこんでいく処理を作る。
pspautoconnector2の改良版、adhocrepeaterの開発に取り掛かっている。
＊
pspautoconnector2のソースを見てたら、テストコード全く書いてないしひどかった。
adhocrepeaterはテストファーストでがんがんテスト作っていくことにする。
パッケージ内のファイルを読み込めることを確認。
＊
具体的にどのディレクトリである、という情報に触れることがなく、いい感じ。
最初はsucroseに作ってたけど、candymaker内に移動した。
candymakerでパッケージパスを生成する必要があるためだ。
＊
candymakerに実装されているインターフェースについても、なんらかの処理が必要になりそうだな。
現状何もしてないから、ロードするとcandymakerと競合してしまうモジュールもロード可能な状態になっていてよくない。
あと、パッケージ情報ファイルなどを読み込むために書いたファイル読み込み処理はそのままになっている。
今回追加したfgの仕様のファイル読み込み処理に置き換えて、古い処理は削除したいところだ。
とはいえ、処理が被っていて気分悪い程度であり、なんらかの問題を起こしているわけでもない。
他の作業を終えて、candymakerの作成に戻ってきた時に、最初にやるとしよう。
年が明けてしまった。
＊
ファイル読み込み関係の処理作った。
これを使ってパッケージ内のファイルにアクセスする。
そこまでやったら一区切り付くし、別の作業をやりたい。
pspautoconnector2の改修とか、放置してある玄箱T4を使えるようにしたりとか。
今週中には終わらせて…って、あと1日しかないではないか。