tekuto.net

メール:g.tekuto@gmail.com

twitter


2018/04/26 04:20

ちくしょう厄介だなぁ。

コンセプト上、モジュールに配置した変数に直接代入するような記述ばかりになるのだが、記述方法と参照の仕方のバランスを取るのが難しい。

同じ名前で参照しているはずなのに、代入前の値が取れてしまったりする場合があるのだ。

色々と調べていて、おそらく変数に対応するアドレスを決定するタイミングが問題なんだろうな、というのは把握できた。

明日には、納得のいく記述形式にできそう。


2018/04/21 03:00

根幹は仕上がったように思う。

しかしながら、既存のものとは構成が大きく異なるために、これでいいのかどうか不安が残っている。

まぁ、今のところは想定からずれてもいないし、このままC++用のツールも作っていこう。


2018/04/17 02:25

fgbuilder(仮称)はtafという名前に決定。

先週からwscriptの書き方を見直し、どのようにまとめるかを考えていた。

今まで無駄にロジック組んでたところが、実はもっと単純に書けることを知って驚いたりなどしていた。

色々考えた結果、tafのモジュールをインポートし、変数に必要なデータをセットだけで、ビルドルールになるようなものを作ってみようと思う。

本当にその通りにできるのか、怪しいところではあるが。


2018/04/12 02:05

JPEG画像を読み込んで表示するテストプログラム、案外簡単にできた。

というわけで、ビルドライブラリの方に取りかかろう。

fgbuilderとかそんな感じの名前で作ってみるかな。


2018/04/11 03:00

今日から画像読み込みテストを作り始めている。

ビルドルールの件については、ビルドライブラリのロード方法をどうしようか考え中。

PYTHONPATHの指定か、importlibの使用か。

前者の場合、exportとかあまり使いたくないので、waf実行時常にPYTHONPATH=と付ける必要があってびみょう。

後者の場合、configure時にだけビルドライブラリのパスを指定すればよいのはいいが、各プロジェクトのビルドルールが多少複雑になってしまう気がする。

どっちもどっちだなぁ。


2018/04/07 04:30

もうちょい。

完全に新しい処理の追加はもう必要ないはず。

既存の処理に似たものを追加して、おそらく問題なく通るであろう自動テストを追加し、動作を確認すれば完了か。


2018/04/06 03:25

おおむね想定通りに進んでいるが、問題も少し。

fg::EventProcsStackの方は大体できた。

記述がいい加減な感は否めないが、処理の流れ自体は間違っていないはずだ。

あとは、不要になる古い機能を除去してしまえば問題ない。

問題はfg::BasesystemEventProcsStackの方だ。

やっつけで無理して実装したツケが、ここに来て回ってきた。

テクニカルな処理をやめ、潔く無難な処理に変更するべきかもしれない。

しかし、そのためにはfgに存在しないインターフェースを新設しなければならない。

そのような事をすると、sucroseのfg::BasesystemEventProcsStackがsucroseのfg::EventProcsStackを使わなければ動作しなくなるので、あまりやりたくはないのだが。


2018/04/05 01:50

少しぼんやりしてしまった。

イベント処理周りを見直していたが、今のままではよくないかもしれない。

何がよくないかと言えば、イベント関数群をpush/popした時に呼ぶ関数の呼び出しタイミングだ。

イベント関数群を切り替えることで、ウィンドウ描画時やコントローラ操作時などで呼び出される関数を一度に変更できるようにし、それで画面遷移を表現できるようにしている。

そして、切り替えるタイミングで呼び出すイベント関数も設定できるようにしていて、切り替えた後で使用するデータの生成や、切り替え終わった後に不要になるデータの破棄などをできるようにしている。

しかし、イベント関数群を切り替えた時点ですでに切り替え後のデータが必要になるにも関わらず、現状では切り替え→イベント関数呼び出し、の順になってしまっている。

切り替え前に切り替え時のイベント関数を呼び出さなければ、切り替え後に必要となるデータの準備などできない。

その辺、修正する必要があるな。

そもそも切り替え時に呼び出すイベント関数の構成も少し思うところがあるし、それと合わせて修正しよう。

画像読み込み処理を試してみたいところだが、新しいプロジェクトというか、リポジトリを作るのがめんどくさい。

何が悪いのかは大体分かっている。

ビルドツールにwafを使っているが、ビルドルールを書きやすくするために自分で作ったファイルをいちいちコピーしているのが気にかかっているのだ。

できることなら、それ自体を1つのライブラリにまとめてしまいたい。

イベント処理周りの修正を終えたら、画像読み込み/表示をするプログラムを作る前にその辺りをどうにかしてみよう。


2018/04/04 03:30

sucroseのv0.33.0完成。

不要になった処理をばっさりカットしてすっきりした。

へびゲームに、fgの仕様変更を適用して、きちんと動作することも確認済み。

そして、fg::GameDataからfg::BasesystemContextの参照を排除できた。

明日には、コントローラ設定についても対応してみよう。

ここまで来ると、いよいよ画像ファイルの読み込みとかもどうにかしないと見た目がよくない気がする。


2018/03/31 04:20

ウィンドウと、そのイベント処理を別々の型でやるようにしたバージョンを作った。

来週の頭に、fg::BasesystemContext内のfg::Windowをこっちに置き換えてみよう。

いや、他の古い方を使っている部分を新しい方に置き換える方が先か。

ともかく、新しい方を用いる処理の追加、古い方の削除、スレッド周りの古い処理の削除、と問題が出なければそんな感じの流れか?

その辺が全部済んだらバージョンを確定させよう。


2018/03/30 02:55

一応、完成はした。

しかし現状、これを既存のものと置き換えることは不可能だ。

これは新たに作ったものが悪いのではなく、既存の構成の仕様がよくないことが影響している。

というか既存の構成、ゲーム側でOpenGLを使って描画するウィンドウ作れないじゃないか。

この問題を解決するには、ウィンドウの生成とイベント処理の開始タイミングをずらす必要がある。

そうしなければ、ウィンドウを生成し、イベント処理を開始するまでの間にOpenGLの準備をすることができない。

次のバージョンで追加して、置き換えられるようにしよう。


2018/03/29 03:35

あともうちょい、だと思う。

ミューテックスと実行中のタスクデータをスレッド処理側のみに置く構成への変更は、これまで書いた処理の配置変更とそんなに多くない処理の追加でスレッド処理側はできた、はず。

残るはタスク管理側だが、こちらについてはほぼもしくは全て、スレッド処理側の関数を呼び出すのみのラッパーのような構成になるので、すぐ済むと思う。

タスク関数内からの、実行中のタスクの再起動処理も、タスク管理側の関数を呼び出すだけだし簡単だ。

明日中には完成すると思う。

別の問題が浮上しなければ。


2018/03/28 01:30

うまくいかない。

もっと構成を単純にすれば、うまくいくかも。

しかし、それをするにはかなり大掛かりな変更が必要になる。

というより、1から作った方が早いかもしれない。

今週中にはどうにかしたいところ。


2018/03/27 03:05

一応は完成、だがバグがある。

キャンセル周りが不完全だ。

キャンセル時にスレッドの再起動処理もしている関係か、デッドロックを起こしているようだ。

明日中に解決したい。


2018/03/24 03:30

スレッド周りの改修はほとんどできた。

21日の分はちょっと勘違いしていた。

スレッド処理側はより単純になるはずだったのだ。

それで、結果的に既存のものよりコンパクトになった。

その代わり、起動管理側は既存のものより規模が大きくなった。

後は、実行中のタスクの再実行と、起動管理部分のリファクタリングくらいか。

来週の頭には仕上げたい。


2018/03/21 03:10

スレッド周りの改修を進めている。

とりあえず、スレッド処理側の処理はほぼできた。

とはいえ、ここまでは既存の処理をちょっと変えただけだから、比較的簡単にできた。

ここから先は、新しい構成を構築する必要がある。

なかなか骨が折れそうだ。


2018/03/13 03:45

とりあえず、へびゲームとコントローラ設定について対応した。

書き換え程度ではあまり実感できなかったような感触だが、それでも従来よりましになったな、という気はする。

fg::GameData内にfg::BasesystemContextの参照を含めなくてよさそうな感じになったのは大きい。

とはいえ、含めなくてよい、ではなくよさそう、であり、他の部分にも修正を行なわないとまだ含めなくてはいけない状況にもなる。

具体的に言えばスレッド周りだ。

やはり、早いところ修正が必要だな。


2018/03/09 21:15

fg::EventProcsViewer追加完了。

実際にはfg::EventProcsStackを見ているし、fg::EventProcsStackViewerの方が合ってるかなとも思ったが、冗長な気がしたのでこれでいいことにした。

これでイベント周りの修正は完了した。

来週の頭に、過去に作ったプログラムに修正を適用して使い勝手を確認してみよう。


2018/03/08 22:30

fg::Event追加完了。

次はfg::EventProcsStackViewer、と仮称しているものの追加だ。

現在の仕様では、fg::EventProcsCallerを生成するためにはfg::EventProcsStackの参照が必要だ。

fg::BasesystemEventProcsStackに設定している関数を呼び出すために、fg::BasesystemContextからfg::BasesystemEventProcsStack内にある、fg::EventProcsStackの参照を取得できる。

そこまではいいのだが、fg::EventProcsStack自体を参照すると、fg::EventProcsManagerを介してfg::EventProcsをプッシュしたりポップしたり、という操作も可能になってしまう。

fg::BasesystemEventProcsStackは、fg::BasesystemEventProcsをプッシュ、あるいはポップするためのものであり、それより機能が少ないfg::EventProcsをプッシュしたりすると、予期しない動作になるのは目に見えている。

そこで、プッシュ/ポップはfg::EventProcsManagerを介して行ない、関数の呼び出しはfg::EventProcsStackViewerを介して行なう、という風に分けようと考えている。

fg::EventProcsStackViewerはfg::EventProcsStackから取得できるようにする。

fg::BasesystemContextから取得できるのも、fg::EventProcsStackViewerの参照にすれば、関数の呼び出しは可能なままで、fg::BasesystemEventProcsStackに対するfg::EventProcsのプッシュ/ポップは不可能にできる。

それを完了しても、既知の問題はもう1つある。

が、そっちは今の仕様では解決が難しい気がする。

特定状況下でfg::EventProcsCallerを生成するとデッドロックがかかってしまう、という問題だ。

もっと言うなら、fg::BasesystemEventProcsStackのプッシュイベント関数内で、といったところか。

詳しく確認はしていないのだが、fg::EventProcsCallerの生成時にはfg::BasesystemEventProcsStackのスレッド処理を待機する処理が入っているため、おそらくその関係だと思う。

fg::Eventを追加した時に、fg::Eventからfg::EventProcsCallerの参照を取得できるようにしたため、それを利用することで回避はできるのだが、問題のタイミングでfg::EventProcsCallerが生成可能なことは変わっていない。

できることなら、問題の起きる記述はできないようにしたいところなのだが。


2018/03/08 04:10

またしても想像よりも時間がかかりそうだ。

fg::Eventを追加するに当たり、既存部分への変更も多く必要になっている。

とはいえ、明日丸1日がんばればどうにかなるかもしれないが。

遅くとも今週中には片付けてしまいたい。

まぁ、実現は可能そうだし、ユーザーデータを持たないイベント関数内でユーザーデータにアクセスしようとするような記述は、コンパイル段階で弾かれるなど、想定よりももっと便利になりそうだし、いい感じだ。


2018/03/07 03:30

想像よりずっと時間がかかってしまった。

既存のものを維持したまま、それを差し替えるものを追加するのはやはり手間がかかってよくない。

できる限り、そういうことをしないで済ませたいものだ。

そんなわけで、fg::EventPropertiesをfg::EventProcsという型に差し替えた。

一区切りついたので0.29.0としたが、まだ終わりではない。

0.29.0は差し替えのみで、ここからより使いやすくするために追加を行なっていく。

手始めに、と言っても今のところ予定している追加は2つだが、統合されたイベント型を追加する。

現状の仕様ではイベント型は完全に別々であり、イベント型共通の機能というのを用意したくても、各イベント型に関数を追加する、という方法でしか実現できない。

そこで、fg::Eventというテンプレート型を用意する。

各イベント型へのアクセスや、イベント型共通の機能の使用はfg::Eventから行なう形にする。

この形式に変更することで、記述が簡略になる部分もあるはずだ。


2018/01/20 02:40

物は試し、と画像ファイルを読み込み、表示するだけのモジュールを作ろうとしていた。

しかし、どうにもfg::EventPropertiesが使いづらく、どうにかならないかと考えていたら、改訂案を思い付いてしまった。

イベント関数と、イベント関数で利用するデータを別々にして考えているからいけないのだ。

2つを合わせて考えれば、いい感じにできそう。

タスク周りのと違って、こちらはインターフェースも大きく変わるし、変える前のものは使い物にならないと言える。

こっちは画像ファイル読み込みの前に片付けてしまおう。


2018/01/17 01:10

タスク周りの改訂案を思い付いてしまった。

考え方は変わらないけど、構成はかなり大きく変わるしすぐにはやりたくないな。

しかし、今の構成より無駄が減りそうなので、そのうちやりたい。


2018/01/11 02:40

暫定的な基本コントローラ設定画面を作れた。

コントローラのボタン入力により、基本メニューボタン、スタートボタン、セレクトボタンの割り当てをファイルに出力できるようになった。

画面、といっても描画処理がまだついてないけど。

現時点では画像ファイルを読み込む機能などもないので、きちんとした画面描画をするのは難しい。

他にも色々問題はあるが。

で、この後は実際にゲームで使うコントローラ設定画面を、と行きたいところだがそれは難しいだろうな。

なんせ、まだどのような仕様にするか固まってない。

なので別のところ、例えば前述の画像ファイルの扱いなどを進めようかと。

今まであまり積極的にやった記憶がないが、避けては通れないしいい機会だろう。


2017/12/29 03:25

いらなくなった型の削除まで完了した。

コントローラの処理の改訂版は気合で仕上げた。

まだ使ってないので明日試したいところだが、色々とやることあるしなぁ。


2017/12/15 02:25

コントローラ関係の新しいイベント型は一通り作り終わった。

あとはバッファ型を作り、それを利用する形にsucrose::ControllerManagerに修正を加えればいい。

それで、いらなくなる型とかを消せば完了だな。


2017/12/12 01:00

コントローラの処理、扱いにくいなぁ。

ボタンとか軸とか、それらをバラバラに扱ってるのが悪い気がする。

確かにコントローラの見た目からしてそれらは別々なわけだけど、実際の扱いではそれらがどの順で使われたかとかが重要なことが多い。

現状の機能でそれをやろうとすると、入力を一旦全てバッファにつっこみ、それを参照して処理するスレッドに渡す、みたいな処理をしなければならない。

そのバッファにつっこむところまではsucrose側で処理して、バッファを参照して処理する部分だけゲーム側でやらせればよさそう。

明日からその方針で進めていこう。

年内にはコントローラの扱いを確立させたいところだが、間に合うかな。


2017/11/07 02:10

想像以上に整えることができた気がする。

いくつかの画面を遷移してから、1つずつ戻すのはもちろん、特定のポイントまで一気に戻したりもできる。

とりあえず、この構成でコントローラ設定画面を作ってみようかな。


2017/10/30 23:40

やはりだめだな。

色々と試行錯誤してみたが、大きく変更を加える必要がある、というのが結論。

データ型の構成や処理の流れからして変える必要がある。


2017/10/28 02:20

想像以上に複雑になってしまった。

正直、これでいいのかあまり確信がない。

来週の頭に見直してから確定しようと思う。


2017/10/27 03:05

ロック処理にミスがあった。

ミューテックスを2つにしないとうまくいかない気がする。

関数内でロックとその解除を行なうロック処理って、自動テストでテストできるんだろうか。


2017/10/25 01:50

fg::BasesystemEventPropertiesManagerを追加して、不要になった型や関数の削除も完了。

ここに来て、ゲーム初期化時にスレッドプールを稼働させていないことが悪影響を及ぼしている。

しかし、テストの都合上fg::BasesystemContext生成完了時点ではスレッドプールを稼働させてない方がやりやすいんだよなぁ。

まぁ、それ以外に理由がないならfg::BasesystemContext生成時にスレッドプールを稼働させるべきだろうな。


2017/10/18 01:00

既存の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内に内包し、インターフェースからは削除しようと思っている。

ゲーム側から見せる必要がなくなりそうなので。


2017/10/13 19:05

機能の追加漏れがあった。

その部分について、昨日追加を行ない、0.23.1とした。

処理自体はこれで問題ないと思う。

問題はインターフェースだな。

1本のスタックの中身を、push()とpop()だけ管理するのは厳しいものがあると思う。

容易く整合性が崩れそうだ。

生成時にpush()し、破棄時にpop()するRAIのようなものを考えているけど、それでいいのかどうか。


2017/10/12 03:45

fg::BasesystemEventPropertiesManager出来上がった。

テストの記述をちょっと修正したら、0.23.0を確定しよう。


2017/10/07 04:25

詰まる箇所もあったが、fg::BasesystemEventPropertiesManagerのpush()、pop()まで完了。

fg::BasesystemEventPropertiesManager関連の残件は、push時、pop時、変更時のイベント関数対応と、fg::BasesystemContextからのpushとpop実行くらいか。

来週の頭には全て完了したいところ。


2017/10/04 22:35

fg::EventPropertiesは出来上がった感じ。

勢いで作ったところがあり、なかなかひどい作りだったのをどうにかした。

これでいよいよfg::BasesystemEventPropertiesManagerの方に取り掛かることができる。

しかし、今の状態でもfg::EventPropertiesの作りはびみょうな気がするな。

fg::BasesystemEventPropertiesManagerの修正、かなりトリッキーなことになりそう。


2017/09/30 03:50

push()とpop()は追加できた。

fg::BasesystemEventPropertiesManagerの修正はまだ。

その辺りを対応するためには、fg::EventPropertiesに機能を追加する必要があるな。


2017/09/29 04:10

fg::EventPropertiesManagerの中身を修正中。

push()については、1種類でいいと思った。

2種類目は、fg::EventPropertiesに機能を追加する形にしようと思う。

明日中に片付けられればいいが、そこまで気力が続くかどうか。


2017/09/27 04:00

作りが甘かったかもしれない。

現状のBasesystemEventPropertiesTaskによるEventProperties更新は、言ってみればgotoのようなものだ。

規模の大きい物を作る場合には混乱の元になるかもしれない。

関数呼び出しのような、スタック形式にするべきか。

その形にすれば、リソースの生成、破棄タイミングも明確になるかも。

というのも、今その辺でちょっと困っている。

EventProperties更新するのはいいが、更新されたイベントから参照するリソースの生成、破棄タイミングはどうしよう、と。

さて、現状からの修正を考えるとどうなるかな。

Readerはそのままでいいけど、Writerはだめだな。

Writerは削除して、Managerにpush()、pop()を付ける。

push()はEventPropertiesのみと、それに加えてリソースの生成、破棄を目的とした関数の参照2つと、そのリソースを配置する場所の参照も持つ2種類を用意する。

しかし、fg::EventPropertiesって必要かな。

fg::BasesystemEventPropertiesだけでいい気がする。


2017/09/23 04:00

fgへの関数追加まで完了。

あとは実際にそれを使用するように記述を修正するだけ。


2017/09/22 00:40

やる気がやばいけど、画面遷移確認まで完了。

画面遷移処理は全く同じ記述にしかならなさそうなので、fgに関数を追加することにする。

OpenGLのタスク生成と同じような感じだし、明日中には仕上げたい。

それを使用して画面遷移処理を書き換えたら、中身を作り始められるかな。


2017/09/09 03:30

fg::BasesystemEventPropertiesに関係する型を追加している。

現状では自分でロックかけたり解除したりができないので、ロック中に他の処理もやっておく、ということができない。

それを改善するために、ロックに関する型を追加しようかと。

それができたら、簡単な画面遷移を作る。


2017/09/06 00:15

今の構成で進めてみることにした。

正直、違和感を感じた部分の構成は変わってないんだけど。

慣れてなかっただけかもしれないし、いい解決方法が思い付かないし。

ひとまず、コントローラ設定画面について、新しい仕様に合わせる修正をした。

合わせる、といっても起動できるようにしただけなので、もっと今の構成に合わせた記述に直す。

それから、画面遷移についての処理を入れてみよう。


2017/09/02 02:45

ゲームの関数変更完了。

へびゲームにも修正を加えて、きちんと動くことを確認した。

しかし現状の構成ではよくない。

イベント処理関数からゲームデータを参照するのがちょっとめんどくさい。

どうにかするべきとは思うんだけど、どうするかがまだもやっとしているな。


2017/08/31 01:10

fg::EventPropertiesをfg::EventProcsに変更するの、いらなかったかも。

そう思ったので、とりあえず変更したブランチは残しておいて、別のブランチを作ってそっちをいじっている。

というわけでfg::GameDataの追加をやっている。

fgには追加したし、久々にcandymaker自体をいじくる必要があるな。


2017/08/30 00:00

fg::EventPropertiesをfg::EventProcsに変更した。

明日はイベント処理関数の型を以前の状態に戻すところから始める。


2017/08/28 23:50

コントローラ設定画面に手を付けようとしたが、思うように書けない。

ちょっと構成見誤ったか。

書いていて違和感を感じる箇所がところどころにある。

fg::EventPropertiesは少し間違いだったように思う。

主に名前が。

そんな汎用的に使うものではなく、イベント処理関数だけつっこんどけばそれでいい関数な気がする。

fg::EventProcsにするべきだったな。

よって、読み込み専用のこれをイベント処理関数の引数にするのも違和感ある。

イベント処理関数の参照なんて、普通はイベント処理関数内で必要にならないだろ。

前の構成に戻すべき。

あとは、ゲームの関数も変更するべきだな。

現状ではfg::BasesystemContextとfg::BasesystemArgsをまとめた、fg::BasesystemDataの参照を引数に、色々やってからboolを返す関数だけど、fg::BasesystemArgsはもはや必要なくなってきた。

ゲームデータの設定処理しかできないし。

それなら、fg::BasesystemArgsとfg::BasesystemDataは削除し、引数としてfg::BasesystemContextの参照を受け取り、ゲームデータを生成して返す、とした方がいいだろう。

もちろん、ゲームデータの破棄関数も必要になるけど。

とりあえず名前変更からかな。

次にイベント処理関数の引数を元に戻す、といきたいけどゲームデータ型にしたいところもあるし、それを追加した後か?

となると、ゲームの関数変更を先にやるべきだな。

ゲームの関数変更は大きい変更だけど、他とは独立してる感じだし最初にやってしまっても構わない気がする。

その前に、ひとまず今の状態でバージョンを確定させておこう。


2017/08/26 03:45

へびゲームをfgの仕様変更に合わせる形で修正完了。

コントローラ操作の部分に関しては、まだ存在しないため書いていないが。

コードの量はほとんど変化しなかったな。

新しい仕様の要素で相殺された感じか。

問題なく動くことは確認できた。

次回からはコントローラ設定画面を使って、画面遷移処理を書いてみたりなどしてみるか。


2017/08/25 03:30

OpenGLによる描画イベント、できた気がする。

明日、へびゲームとかそこらを新しいインターフェースに合わせた書き方に修正して確認しよう。

想定通りなら、より短いコードで同じ処理ができるようになっているはずだ。


2017/08/23 01:15

これで元からある機能の実装は完了できたか。

あとはOpenGLによる描画イベントを実装すればいい。

これは新しい機能になるが、大体は既に作ってある機能の組み合わせでいけるだろう。


2017/08/19 03:10

fg::BasesystemEventPropertiesを作っている。

あとは、内容更新のためのsucrose::BasesystemEventPropertiesManagerを作り、それをfg::BasesystemContext内につっこめば出来上がり、かな。

ここまでやって、ようやく画面遷移などがやりやすくなるはず。

早くコントローラ設定画面を作りたい。


2017/08/09 03:15

スレッドのキャンセルの件については解決。

fg::EventPropertiesをudev関係でも使うべきか、悩ましいところ。

あまり実装方法がばらけてても分かりにくいし、統一してしまうか。


2017/08/08 04:10

ようやく原因判明かな。

スレッドのキャンセル時にこけてる原因が分からなくて、かなり時間をかけてしまった。

キャンセルかけたスレッド内でwaitしたり、wait中のスレッドにキャンセルかけたりしたらいかんってことね。

その辺考慮したコードになっていなかった。

すぐ修正しないとまずいな。


2017/08/05 00:35

ひとまず、ウィンドウ周りは対応した。

メインウィンドウについても、fg::BasesystemContextに対してデータを設定することで処理を変更可能にした。

しかしながら、構成は変更するべきだろうな。

現状では、fg::BasesystemContextの内部で利用するデータはヘッダファイルに列挙型を用意し、特定のインデックスに特定のデータをセットすることで対応している。

このやり方はよくない。

将来的に、fg::BasesystemContext内部で利用するデータを増やしたり変更したりした時の影響が大きすぎる。

fg::BasesystemContextに対して設定するものは、fg::EventParametersをラッピングし特殊化した型にするべきだろうな。

とりあえず問題ないことは確認できたわけだし、ちゃちゃっとコントローラ周りについても対応してしまおう。

それが済んだら、fg::BasesystemContext用のfg::EventParametersの追加を含めた様々な変更を行なっていくとしよう。


2017/07/29 23:50

fg::EventParameters関係を作り終えた。

型の名前はこれでいいのかどうか。

いまいちしっくりこない感じがあるが、まぁいいだろう。

来週の前半には、既存のイベント関係の処理をこれで差し替えてしまいたいところ。

ベースシステム周りは処理を差し替える以外にも色々変える予定なので、ちょっと時間がかかりそうだな。

来週はもう8月なのか。

まずいなぁ、これでは今年中にゲーム1本作るのは厳しそうだ。


2017/07/28 03:50

fg::ThreadTaskの件については保留とした。

今のところ大きな問題にはなっていないし、不要になって消す場合にも代替方法は明確だ。

他の部分の構成が変わってしまうわけでもないので、とりあえずは放置でいいかなと。

fg::ThreadTask以外の簡単な部分については処理し終わったので、ベースシステムのイベント処理関係に取りかかっている。

ベースシステムの、とは言ったが、結局のところそれ以外の部分でもイベント処理関数は固定しない方がいいと思った。

なので、汎用的にイベント処理関数を変更できる仕組みを考えた。

複数の項目について、同期を取って変更可能な仕組みにできたとは思うのだが、いまいち扱いにくいような。

インデックスで管理する仕組みだし、バグの温床になりそうで怖い。

とは言え、これより良い方法が思い付かないんだよなぁ。


2017/07/27 00:35

ちょっと行き詰まっている。

イベント処理関数を完全に固定するやり方は、ベースシステム関連に関して言うならよくないかもしれない。

画面が遷移すれば、画面の描画内容は変わるし、コントローラによる入力の扱い方も変わる。

イベント処理関数が固定されている状態でそれに対応するためには、自前で分岐処理を書き、呼び出す関数を変えるなどする必要がある。

しかしながら、そのような処理はごく一般的なものであり、わざわざゲーム側でやるべきことには思えない。

全体的に構成を見直すべきかもしれない。

上記以外にも、例えば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件を先に進めよう。

その次に描画イベントの変更だ。

ベースシステムの構成変更は大幅な変更なので最後だな。


2017/07/20 02:55

予想以上に困難だった。

メンバの並び順が原因で、破棄時に処理がこける場合があった。

こういうのはやはり、場合がある、という部分が厄介だ。

全く同じ記述なのに毎回発生するわけでなく、発生する時としない時がある。

マルチスレッド処理に起きがちで、原因の特定に時間がかかる問題だ。

でもまぁ、今回の問題は今日で解決できた。

ついでにOpenGL関係でも同じような問題が起きていたので、それも解決した。

これでようやく次に進める。


2017/07/19 03:45

fg::BasesystemContextに、新たに作成したコントローラ制御処理を追加していっている。

もうちょいで完了。

完了したら、ゲーム側で入力データを取得し、コントローラ割り当てなどに利用する処理を作っていく。


2017/07/15 03:15

やる気減退が著しいが、とりあえずできたか。

sucrose::ControllerManagerにfg::ControllerRawEvent呼び出し機能を追加した。

これでコントローラとして使用できるデバイスが直接生成するデータを、イベントとして受け取れるようになった。

このデータを使って、設定ファイルを生成できるようにしたい。

しかし、これだと最近作ったfg::ControllerTesterがいらなくなるような。


2017/07/13 03:45

明日にはfg::ControllerRawEventに対応できるかな。

昨日、デバイスファイルを開き直せばーと書いたが、それでどうにかなるなんて全く気のせいだった。

現状得られるデータを見るに、オープン時の初回データは破棄するしかない、というより破棄するべきだな。

例えボタンを押しながらジョイスティックを接続したところで、初回オープン時に得られるデータではボタンは押されていないことになっている。

別のジョイスティックを使えば何か別の結果が得られる可能性がないわけではないだろうが、意味のないデータを得られる可能性がある時点で使い物にならないと判断するべきだろう。


2017/07/12 03:10

sucrose::ControllerManager作成開始。

とりあえず、sucrose::ControllerManagerが受け取ったイベントをほぼそのまま流すイベントのみ対応する予定。

実際に必要なボタンイベントや軸イベントについては、設定ファイルがないとどうしようもないから後回し。

evdevのジョイスティック対応も追加するべきかもしれない。

evdevでないジョイスティックの制御は、なぜか接続時の軸データがおかしいのが気にかかる。

evdevの方なら大丈夫、という保証は全くないが。

暫定的な対応としては、一度デバイスをオープン、クローズしてから再度オープンする、か?

そうすればおかしなデータは読まずに捨てられるかもしれない。


2017/07/11 04:10

sucrose::UdevJoystickManager完成。

次はsucrose::ControllerManagerだけど、その前にsucrose::UdevJoystickManagerを試しに使ってみよう。

動作が確認できているのは単体レベルなので、他と組み合わせたりするとちゃんと動くかどうか、まだ不安だ。

その辺を確認してから次に進む。


2017/07/08 04:25

後はsucrose::UdevJoystickManagerを作るだけになった。

ジョイスティックの入出力自体は作った。

接続と切断についての管理を、sucrose::UdevJoystickManagerで行なう。

その辺が未完成だ。

しかし、既存の型であるsucrose::GamepadManagerとそれに関連する型よりも、整った構成になったように思う。

いい傾向だ。


2017/07/07 03:15

udevを扱う型、sucrose::UdevManager完成。

今は、sucrose::UdevManagerで検出したゲームパッドを扱う型として、sucrose::UdevJoystickManagerを作っている。

接続、切断、ボタン、軸のイベントがあるので、多少めんどくさい。

でもまぁ、大まかな構成は既存のものと同じなので、そこから持ってくれば明日中には完成するかな。

とりあえず必要最低限な情報を扱うものを作る。

まさに接続、切断、ボタン、軸のイベントを処理するだけのもの。

デバイス名だとか、ボタン数だとか、軸数だとかについては取得しない。

ただ、既存のものにはなかった要素として、デバイスを特定する情報は生成する。

具体的には、接続したポートとデバイスを一意な情報として扱う。

同じデバイスであっても、違うポートに接続すれば別物として扱うのだ。

udevならそういった情報を取得できるので楽だが、例えばwindowsのdirectinputなんかで同じことはできるのだろうか。

windowsだからできない、なんてことはないだろうけどdirectinput以外の機能が必要、とかなってくるとめんどくさそうだ。


2017/07/06 04:00

udevを扱う型がもう少しで完成。

udevで検出したデバイス情報を元にして、デバイスを管理する型に接続したり切断したり、といったことをさせる予定。

とりあえず古い処理が存在するゲームパッドを対応する。

他にもキーボードの対応も可能だと思うけど、後回しだな。

様々な種類のデバイスを統括管理する型の方を先に作る。


2017/07/05 00:30

入力テストを行なう型について、作れるところまで作った。

といっても、入力テストを行なう型、fg::ControllerTesterは中身ほぼ空っぽでなにもしない状態だけど。

ここから先は、デバイスを扱う型を別に作り、fg::BasesystemContextに搭載しないと話が進まない。

どのように構成すべきか、というところまで済ませた。

明日は末端から作っていく。

末端の処理は既に作ってあるものを流用できると思うので、さくさく作っていきたい。


2017/07/04 03:05

ID型の内容については後回しにすることにした。

udevの接続時に得られる情報とか、その辺を実際に見てから決めることにする。

あと、IDというのはゲームパッドではなく、ゲームパッドのボタン1つや軸1つにつき1つずつ用意することにしようと思う。

私の考えている改訂版では、ゲームパッド自体を一意に示す情報があっても大して役に立たないのだ。

ゲームパッドに搭載されている要素1つ1つに用があるので、それらに対して一意に示す情報があればいい。

とりあえず、入力テストを行なう型を生成するために必要な情報をまとめた型を作った。

中身空っぽの暫定的なID型も作ったし、明日は入力イベントの対応から入る。

入力イベントが出来上がったら、いよいよ入力テスト処理だ。


2017/07/01 03:35

また先走るところだった。

初回設定を行うかどうか、なんて処理は後でいい。

とにかく初回設定に必要な機能を作ろう。

まず初回設定をできるようにする。

次に初回設定を保存できるようにする。

そして読み込み処理を作り、その後にようやく初回設定するかの判定処理を入れる。

この順で片付けていくべきだろうな。

というわけで、初回設定を行うために、ゲームパッドの入力を読み取るインターフェースを大体作った。

ゲームパッドの入力値やゲームパッドを特定するための情報についてはまだちょっともやもやしているため、まだ作っていない。

後者については、入力デバイスの種類、入力デバイス名、デバイスが接続されているポートを特定する情報、を文字列にまとめられればよさそうな気がするのだが。

それらをID型として定義すればいける、か?


2017/06/30 03:30

おととい辺りに、SEGVについては解決した。

ゲームパッドの扱いの改良版を作ろうとしているが、やはり自身にとっての未踏領域のためなかなか手が出ない。

コントローラ設定アプリ起動時に、コントローラ設定数が0だった時初回設定を行うようにしよう、というのは決めた。

しかしコントローラ設定数はどこから取得できるようにするべきか。

fg::BasesystemContextからであるのは確定だが、そこから直接取得するか、コントローラ管理の参照を取得し、そこから取得するか。

後々他にも色々な情報を取得することを考えると後者にするべきかもしれないが、前者の方が現時点では簡単だ。

とりあえずはfg::BasesystemContextから直接取得する形でやろう。

結局、最終的にその形で落ち着きそうな気もする。


2017/06/21 01:55

実に困った。

ゲームのユーザーデータの破棄が、場合によってはSEGVで失敗する。

その原因がいまいち分からない。

少なくともへびゲームでは発生していなかったのだが、ユーザーデータの内容を少なくしていったら発生するようになった。

色々いじくってたら、原因は分かった。

ゲームのライブラリをアンロードした後に、ゲームのライブラリ内にあるユーザーデータ破棄関数を呼び出そうとしたためだ。

しかし、それならユーザーデータの内容に関わらずに発生しなければ辻褄が合わないのだが。

デバッガを使って調べた限りでは、そういう結論になった。

実際、構成がおかしいのだ。

ゲームのライブラリロード前に生成したインスタンスに対して、ゲームのライブラリ中で生成しているユーザーデータを設定してしまっている。

これでは今回のようなバグが発生してしまうのは当然と言える。

構成を大きく修正するべきかもしれない。


2017/06/16 03:45

へびゲームでOpenGLの描画タスクを使用するようにしたりなどした。

OpenGLの描画タスクが想定通りに機能するか不安だったが、特に問題なく使用できて一安心。

最終的に、へびゲームのソースを400行近く削減できた。

OpenGLの描画タスクに分かりにくい処理をまとめた関係で、ゲーム側にそういった処理を書かずに済むようになったし、いい感じ。

というわけで、明日からはゲームパッドの扱いの改訂版作成に戻ろう。

描画処理が書きやすくなったから、前よりは楽に進められるはず。


2017/06/15 02:30

ゲーム初期化前にウィンドウを生成するように変更完了。

ゲームパッドマネージャについてもゲーム初期化前に生成するようにしたので、ゲーム初期化後にはデータの設定とスレッドプールの開始をするだけになった。

明日はへびゲームをどうにかするとしよう。


2017/06/14 02:30

ゲームパッドについても対応完了。

明日は、ゲーム初期化より前にウィンドウを生成するように処理を変更する。

それが済めばようやく、OpenGLの描画タスクを利用できるようになるな。


2017/06/13 03:30

なんとか、関数の追加はできた。

fg::WindowInfoへのイベント関数及びユーザーデータ設定関数を追加して、さて古い関数を消して帳尻合わせるか、と思ったら他の部分にも追加が必要なことに気付いてやる気が下がった。

fg::BasesystemArgsだ。

とりあえず、そちらにもfg::WindowInfoに似た関数の追加を行なって、関数の追加については完了。

古い関数の削除などは明日にする。

想定外なことが起きるとやる気がぐーんと下がるの、よくないなぁ。


2017/06/10 01:30

頭を絞って、どうにか便利そうなインターフェースになった気がする。

イベント関数の設定と、イベント関数から参照できるユーザーデータの設定関数はそれぞれ別々に用意した。

それだけだと、イベント関数で参照できるユーザーデータの型が分からず、void *をキャストする必要があり、ちょっと気分が悪い。

そこで、可変長テンプレート関数を用意して、イベント関数とユーザーデータの設定を1つの関数で一気にできるようにした。

この形にしたことで、イベント関数で参照するユーザーデータの型と、設定するユーザーデータの型を統一できるようになった。

とはいえ、各設定関数の実装とテストがまだだ。

来週の頭には済ませてしまいたい。

問題ないようなら、同じ形でゲームパッドについてもちゃっちゃと実装してしまおう。

そうすれば、ゲーム初期化より前にウィンドウを生成するように変更する作業に移れる。

と思ったが、よく考えたらベースシステムの引数にイベント関数を設定する処理もあるんだったな。

なかなか手間がかかりそうだ。


2017/06/09 03:45

タスク生成関数のテンプレート修正完了。

これによって、わざわざvoid *で渡されるユーザーデータをキャストして、とかやる必要がなくなった。

違う型にキャストしてしまう、なんてミスも起こらなくなるし、いい感じ。

さて、ウィンドウのイベントハンドラについて、インターフェースを修正しようと試しに記述したのだが、これでいいのか不安になる。

タスク周りの修正がうまく行きすぎたから、相対的に見て微妙な感じに見えるだけだと思うのだが。

実行時にデータを引き渡すタスクのようなもの、があれば便利かもしれない。


2017/06/08 04:10

苦戦したが、なんとかできた。

OpenGLの描画タスク完成。

それに伴って、タスクの型をちょっと修正した。

OpenGLの描画タスクに加えた処理では自身を再度実行する可能性があるのだが、タスク内から再度自身を実行する、という処理ができなかったのだ。

それができるように、型を修正して対応した。

明日はタスク生成関数のテンプレートの定義修正から。


2017/06/07 01:30

さて、困ったことになった。

現状では、インターフェースの変更についての修正をへびゲームに適用したので、動くようにはなった。

しかし、OpenGLの描画タスクはまだ使えていない。

ゲームの初期化時点ではまだfg::Windowが生成されていない、というのが問題だ。

OpenGLの描画タスクは、生成関数の引数としてfg::Windowとfg::GLContextの参照を必要とする。

fg::Windowが生成されていないゲーム初期化時点において、OpenGLの描画タスクを生成することができないのだ。

しかしながら、ぱっと見た感じfg::Windowをゲーム初期化時点までに生成してはならない、というわけではないように見える。

ゲーム初期化時にfg::Windowから呼び出されるイベントハンドラの生成などを行なっているため、それらを使うfg::Windowの生成はゲーム初期化の後、というだけの話だ。

ゲーム初期化より前にfg::Windowを生成しつつ、ゲーム初期化時に生成したイベントハンドラが利用される形になれば、問題ないわけだ。

そのくらいなら、ちょっと工夫すれば対応可能だろう。

さて、どこから手を付けるかな。

まずは、OpenGLの描画タスクについて、少し処理を追加する。

それでOpenGLの描画タスクは完成とする。

次にタスク生成関数のテンプレートの定義修正。

それらが済んだら、ウィンドウとかゲームパッドのイベントハンドラについてのインターフェース修正かな。

で、ベースシステムの処理を変更し、ゲーム初期化より前にウィンドウを生成する、と。

大体そんな感じか。

そこまでできれば、へびゲームでもOpenGLの描画タスクを使用できるようになるだろう。


2017/06/06 01:25

OpenGLの描画タスクについて、とりあえず自動テストは通した。

明日、へびゲームで実際に使ってみよう。

あと、タスク生成関数のテンプレートについて少し定義を変更する、というのもやる予定。


2017/06/03 03:00

タスク周りは完了した感じ。

細かい修正と、タスク生成関数のバリエーション追加が完了したので、そこでバージョンを区切っておいた。

ラッピングタスクの方はまだ。

とりあえず、OpenGLの描画タスクを追加するつもり。

このタスクによって、自前でfg::GLCurrentを生成したり、バッファのスワップをしたりということをしなくても済むようになる予定。

OpenGLの描画タスク、と言っても単にfg::WaitThreadTaskを生成するだけだ。

想定通りなら割と簡単に済むと思うのだけど、そううまくいくだろうか。


2017/06/02 03:40

やはり手間取った。

*

とはいえ、ファンクタを関数ポインタに変更するのは完了した。

ただ、タスクを利用していた箇所に一部、このままだと違和感を感じる箇所があるので、そこは明日修正する。

それが終わったら、タスク生成関数のバリエーション追加と、それを使ったラッピングタスクの追加、って感じか?

そこまでやったら、前に作ったへびゲームを修正して動くようにしてみるか。

前よりは整った記述になる、と思うのだけど。


2017/06/01 03:30

タスク起動インターフェースの修正が思ったよりも手間取ってしまった。

なので、関数の呼び出し方変更についてはまだ。

明日には仕上げる予定。

あと、タスク生成関数のバリエーションを1つ追加する予定。

タスクの関数から参照できるデータは、別の場所に格納されているデータの参照だけだが、タスクの中にデータを格納できるようにもしたい。

そうしなければ、ラッピングしたタスクが作れなさそうなのだ。


2017/05/31 03:15

いい調子だ。

sucroseのタスク関係のソースファイルをベースシステム関係に統合完了。

fgから、スレッドプール関係の記述を削除。

あとは、タスク起動のインターフェース修正と、タスクで呼び出す関数をファンクタから関数ポインタに変える、といったところか。

そのくらいなら、明日中にできるかな。


2017/05/30 03:30

もっと丁寧に進めることにした。

とりあえず、sucroseのビルドルールを修正。

自動テストのビルドで、sucroseで生成するライブラリとリンクすることでコンパイル回数を減らした。

今までは依存しているソースファイルを全てコンパイルしていた。

なので、ちょっとソースファイル追加するだけで色々な自動テストのビルドルールにソースファイルを追加しなければならず、面倒だった。

今回の修正で、割と楽になったはず。

candymakerの方もどうにかできるだろうか。

で、fgのタスク関係のソースファイルをベースシステム関係に統合した。

明日はsucrose側のソースファイルを移動し、統合する。

そしたらインターフェースを修正し目標達成、の流れの予定。


2017/05/27 04:30

盛大に設計ミスってた。

タスクについては作り直し。

既存処理をちょっと改変すれば完了するので、最近書いた処理は全部削除。

すごい徒労感。

必死こいてある程度進めたけど、完了まではいけなかった。

ちゃちゃっと来週前半に終わらせる。


2017/05/26 03:30

タスク管理も完成。

やっぱりタスク管理で管理しないタスクは最終的に消してしまおうと思う。

その前に、タスク管理まで作れたので既存処理の置き換え、削除を先にやる予定。


2017/05/25 03:15

待機タスクのキャンセラは作り終わった。

タスク管理の方はちょっと構成を変えることもあって、今日中は難しかった。

明日中には作り終えてしまいたいが。


2017/05/24 03:55

待機タスクについても作り終わった。

あとは待機タスクのキャンセラとタスク管理。

しかし、タスク管理で管理しないタスクというのは、使う機会あるんだろうか。

いっそのこと、タスク管理で管理されたタスクだけでもいいのではないか。


2017/05/20 00:55

とりあえず、普通のタスクの方は作り終わった。

来週中頃には待機タスクやタスク管理を作り終えたいところ。

タスク管理の部分に関しては、ちょっと構成を変更する予定。

複数のタスクが存在し、あるタスクから別のタスクを起動する、というようなことをやると、その別のタスクがすでに破棄されているのに起動しようとしてしまう、ということが起きかねない。

そこでタスク管理というものを置き、それが存在している間は別のタスクの起動が成功し、破棄が始まれば起動が失敗するようになるので安全に複数のタスクを破棄できるようにしている。

現状、これはタスクとタスク管理の2つを引数に取るタスク起動関数を使うことで対応しているが、これではタスク管理を用いていてもタスク管理を使用しないタスクの起動もできてしまう。

後者はバグの温床であり、そういうことができない構成が望ましい。

なので、ただのタスクとは別に、タスク管理によって管理されているタスク、というものを用意しようと思う。

しかし、これをどのような位置付けにするか、ちょっと悩んでいる。

型から別のものにしてしまうのが、確実な方法だろう。

しかし、型は同じで、タスクで実行する関数をラッピングする、という方法でもできそうな気がする。

その場合、ただのタスクと管理されているタスクを全く同じように扱うことができる。

…が、そうすることによって何か得することがあるのか、というところに疑問が残る。

型による判別ができなくなるため、むしろバグの温床になりそうな気が。


2017/05/18 01:30

やる気はびみょうだけど、ちょっとずつ進んでる。

やはり、同じ名前の機能の追加はやりにくいな。

仮の名前を置いて作業しないとうまくいかない。

作り終えて、古い機能を削除するまでの辛抱だ。


2017/05/16 03:25

モチベーションが上がらない。

なので、別のところを進めることにした。

基本的に、イベントハンドラという名前を使うことをやめることにする。

大体これのせいで、ゲーム側のコードが長くなっているのだ。

全てタスクで統一する形にしようと思う。

現時点では汎用的に使える2種類のタスクがあるが、用途別にタスクを用意する。

タスク内で使えるデータ、つまり引数が異なる感じだ。

これに付随して、現時点ではスレッドプールというものをゲーム側から参照できるようにしているが、これもやめる。

いちいちベースシステムのコンテキストからスレッドプールの参照を取得し、タスクを生成、なんてめんどくさいのだ。

ベースシステムのコンテキストの参照を渡して生成してしまえばいいじゃないか。

これに伴い、fg-threadはfg-basesystemに統合する。

タスクで実行する関数は、C++だしファンクタ、std::functionで定義したものを使っていたが、Cの関数ポインタにしようと思う。

そもそもテンプレートで定義するものを使うのは、なんだか気分が悪かったのだ。

言語自体に用意されてるものの方が、何かと都合がよさそうな気がする。


2017/05/11 00:45

少し困ったことになった。

ゲーム側で、fgなどのモジュールを使用するコードを含む部分について、自動テストコードを動かすことができない。

モジュールのファイルパスを直接指定してリンクしてやれば動かせると思うが、それをどうやってビルドルールに組み込むか、という話になってくるな。


2017/05/09 01:45

突貫工事にはまるで向いてないな、この構成。

とりあえず画面になんか表示しよう、と1ファイルにどんどん追加していったらすごくごちゃごちゃしてしまった。

で、冷静になって一旦元に戻した。

コントローラの設定のためのインターフェースは、まだまとまっていない。

ゲームパッドを特定する情報と、押されたボタンを特定する情報があれば、とりあえずできるだろうか。

その2つを、何番のコントローラに割り当てるのか、という情報と合わせて設定する感じで。


2017/05/02 02:10

画面作り始めた。

ゲームパッドの扱いの改訂版を作るに当たり、どこから進めるべきか迷って、まず画面から始めることにした。

ゲームパッドの初期設定を、画面見ながらいわゆるウィザード形式でできるようにする予定なので、画面がないと始まらないかな、と。

ウィザードの説明文を表示するための機能が足りてないが、これは後回しでいいだろう。

作っている私が把握できればいいので、適当に三角形でも表示しておけばいいのだ。

問題は構成の方だ。

かなり大掛かりで、ややこしい感じになりそうな気がする。

うまいこと機能を分割して、小さく小さく作っていけたらいいのだが。


2017/04/29 03:40

体調が治ってきた。

fg::ModuleContextがモジュース初期化より後でも使えることを確認した。

adhocrepeaterを搭載したraspberrypiの調整をしたりなどもした。

来週からセーブデータ機能を利用する処理の作成だな。


2017/04/26 03:10

fg::ModuleContextをモジュール破棄まで保持するように変更した。

しかし、現状では初期化が成功するところまでしかテストコード書いてないな。

明日、テストコードを追加して確認しよう。

体調が思わしくない。

気温が急激に変化したからだろうか。


2017/04/24 23:40

データ要素の文字列化についての修正をした。

文字列への変換ではなく、ファイルデータ型に変換するように変更した。

文字列化をするのはファイルに書き込むためだし、文字列化してからそれをファイルデータ型につっこむ、というのは回りくどいと思っていたのだ。


2017/04/22 00:15

セーブデータの読み書き、とりあえず完了。

とはいえ、これは暫定的な処理だ。

まず、セーブデータディレクトリというものを用意していないため、セーブファイルはパッケージディレクトリに対して書き込まれるようになっている。

それに加えて、データが平文なので容易に改竄できてしまう。

しかしながら、とりあえずは機能するし次回からはセーブデータを必要とする機能の作成を、といきたいがまだちょっと無理だな。

セーブデータの読み書きにはfg::ModuleContextが必要だが、fg::ModuleArgsから名前だけ変えただけの今の作りでは、モジュール初期化処理後にfg::ModuleContextは消滅してしまう。

なので、ベースシステムが終了するまではfg::ModuleContextを保持しておくように変える必要がある。

それ以外に、細かい修正もしておきたい。


2017/04/21 03:30

要素の文字列化は作り切った。

セーブデータの書き込みと読み込み、明日中にいけるかな。

新たに作る処理といえばファイル書き込みくらいだし、問題ないと思うけど。


2017/04/20 03:35

セーブデータの内容生成処理完成。

次は要素の文字列化、そしてセーブデータ書き込みだな。

明日中にそれを終わらせて、あさってに読み込みを作って完了、といけばきりがいいのだが。


2017/04/19 01:10

セーブデータの内容生成処理、もう少しで完成。

残件は、リストやマップへの要素追加。

現状の案では、引数のクローンを生成し、クローンを要素として追加する、という形が一番問題が起きにくいだろう考えている。

そこが出来上がったら、いよいよセーブデータ書き込み処理に入る。

要素の文字列化はまだやったことがないので、多少手間取るかもしれない。

とはいえ、文字列からの解析処理に比べたらずっとましだろう。


2017/04/15 03:10

普通に考えて、セーブデータは書き込みが先だな。

セーブデータを作成しないことには、読み込み機能なんて作っても意味ないし。

やる気のせいもあって、今日はインターフェースを整えただけで終わってしまった。

来週中には読み書きをできるようにしたいところ。


2017/04/14 03:20

不要になった処理の削除完了。

fg::FileR、fg::DirPathR、fg::ModuleArgsを削除した。

パッケージ内に配置したファイルの読み込みがやりやすくなって、いい感じ。

明日はセーブデータの読み込みをやる予定だけど、ちょっと構成をいじる必要がある気がする。


2017/04/13 02:50

既存処理の改訂版作成は完了。

差し替えと既存処理の削除は、なかなか規模が大きいこともあり、やはり完了できなかった。

特に、モジュール初期化関数の引数変更については、変える必要がある自動テストがあるし、ちょっとめんどう。

明日には完了したい。


2017/04/12 03:20

進め方を少し間違えた。

その関係で、ちょっと進行が遅れた。

明日中には、処理の改訂と不要になった部分の削除を済ませてしまいたいが。


2017/04/11 02:55

パッケージ内のファイル取得処理の改訂版をとりあえず作った。

fg::FileRやfg::DirPathRはいらなくなるので、その辺の処理も消して簡略化する予定。

セーブデータ読み込み処理は、既存部分の改訂を済ませてからだな。


2017/04/07 02:30

いまいちしっくりこない。

でもまぁ、こんなものだろう。

パッケージ内のファイル取得と、セーブデータ読み込みについてのインターフェースを追加。

とりあえずこれで作ってみようと思う。

この構成なら、ファイル関係のモジュールがいらなくなるが処理自体は1つのモジュールに収めておけば済む形にできるな。


2017/04/06 03:50

パッケージ内のファイル取得インターフェースも変えるべきな気がしている。

ファイルを開いてそれを読み込む、などということをいちいちやるようなインターフェースは違和感がある。

処理が低レイヤーすぎる。

いちいちそんなことをしなくても、ファイル取得といえばファイルの内容を全て読み込む以外にすることなんてないのだし。

もっと単純な形でいいはずだ。


2017/04/05 02:45

ヘッダファイルの問題は解決。

あれ、よく考えたら今日追加したのはセーブデータの内部フォーマット作成関係のインターフェースじゃないか。

いかんな、作業間違えてた。

セーブデータ読み込みインターフェースを作らないと。


2017/04/04 03:30

やれやれ。

既存処理の差し替えは完了。

ユニークポインタ周りで不具合があった。

ひとまず問題が起こらないようにしたけど、根本的な解決はまだ。

ヘッダファイルのインクルードを忘れると、ビルドは通るが実行しようとするとリンクエラーで実行できない、という現象が発生している。

どうすればいいのか大体は把握できているので、明日中には直す。


2017/04/01 02:30

セーブデータの内部フォーマット解析処理作成完了。

来週から既存処理との差し替えと、セーブデータ読み込みインターフェースの整備と。

そんな具合に進めていく予定。


2017/03/31 03:15

完了の目処はついた。

明日中には、セーブデータの内部フォーマット解析処理を作り切れるはず。

文字列について、処理を改良した上で完了した。

同じような感じで、リストとマップを対応すれば完了。


2017/03/30 04:15

想像以上に処理がびみょう。

処理どころかテストもびみょう。

なので、元の処理に手を加えていく形で対応しようとしている。

やる気減退してるというのもあるけど、さすがに1日では無理だった。


2017/03/29 01:40

演算子オーバーロードなんて消滅してしまえばいいのに。

それに付随するADLとかいう概念が邪魔をして、無駄に時間を使ってしまった。

しかしそのかいあって、ユニークポインタの宣言と定義をfgにまとめることができた。

fgとsucroseとcandymaker、それぞれ別々に記述してるのが気持ち悪かったし、いい感じ。

セーブデータの内部フォーマット解析用インターフェースの定義はできた。

といっても、既に処理まで作ってある、文字列、リスト、マップのみ。

できてる部分の書き換えなら簡単にできるし、数値型なんて現時点ではいらないし。

明日中にcandymakerに追加したい。


2017/03/28 00:45

やる気減退中。

セーブデータについては、もっときちんと考えてから取り掛かるべきだと思った。

インターフェースを定義することにより、ゲーム側が簡単にセーブデータを作成したり、作成したデータを読み込んだり、だけで済む話ではない。

セーブデータのフォーマットを定めることにより、ゲーム外から参照した場合にもセーブデータ名などの情報を参照したり、コピーや削除などをできるようにしたい。

簡単に言えば、PlayStationのメモリーカード管理画面のような、ああいった機能を実現できるようにしたいのだ。

そう考えると、とりあえずファイル書き込み機能を作ってセーブデータのファイルを作れるようにしました、という対応は今後を考えるとあまり意味がないと思うのだ。

もちろん、内部的にはそういった処理も必要になるので、完全に無駄になるというわけでもないと思うが。

そういう意味では、現在のゲームパッドの対応もよくない。

ゲームパッドの接続や切断、どのゲームパッドのどのボタンが押された、などといった情報を直接ゲーム側に渡してしまっている。

デバイスとゲーム側との間に制御プログラムを挟み込むことにより、柔軟なことができるようにしたいのだ。

しかし、そのためにはセーブデータの概念は必須だろうな。

デバイスをどのように管理するか、という情報はセーブデータとして格納するのだから。

ちなみに、セーブデータの内部フォーマットについては、設定ファイルのものを改良した上で流用しようかと考えている。

現時点ではリストやマップといった構造を除くと文字列値しか扱えないので、数値も扱えるようにする。

そして、ファイル形式としてテキスト形式以外にバイナリ形式にも対応する。

さすがに、プレイヤーが簡単に参照したり改変したり、ができるのはどうかと思うし。

暗号化したテキスト形式をバイナリ形式として扱えば手軽か?

それだとゲーム外からの参照が困難になるな。

暗号化要素という概念でも追加して、一部の要素のみ暗号化、ということができるようにするか。

さて、どこから進めるか。

fgに、セーブデータの内部フォーマット解析インターフェースを定義するところからかな。

ひとまず暗号化については後回しで。

既に作ってある設定ファイル解析処理を使い回して、処理を実装。

それを作ると設定ファイル解析処理と内容が被るため、差し替え。

セーブファイル読み込みインターフェースの定義、実装。

セーブファイル書き込みインターフェースの定義、実装。

そこまで済めば、セーブファイルが必要になる機能も手を付けられるだろう。


2017/03/25 02:50

とりあえずOpenGL関数追加完了。

へびゲームがきちんと動作することも確認済み。

これであとはセーブデータの読み書きもできるようにすれば、それらしいゲームを作れる気がする。

しかしOpenGL対応は、現時点は仮対応だな。

もっとちゃんとやるなら、使用するバージョンやら拡張機能やらをゲーム側が指定し、そのチェックなどをするべきだろう。


2017/03/24 03:15

昨日のうちに、ウィンドウに対する処理の追加は完了した。

具体的には、タイトル設定とウィンドウサイズ固定。

今日からOpenGL対応。

過去のプロジェクトで作った処理を流用して追加しようとしている。

それが終わったら次はなんだろう。

セーブデータ対応だろうか。


2017/03/22 02:35

ファイル名などの修正も完了。

今までハードコーディングしていた、ウィンドウサイズの設定を引数から設定するように変更。

合わせて、ウィンドウ内全てに対する再描画要求関数も追加した。

あとはウィンドウのタイトル設定くらいか。

ウィンドウ情報へのウィンドウタイトル設定関数の追加も忘れていたようなので、合わせて追加する。


2017/03/18 04:10

大まかには完了。

前に作ったへびゲームのsucrose版関数呼び出し箇所をfg版に変更し、動作するところまで確認できた。

残件は、ファイル名の修正と一時的に付けた型名、関数名の修正。

さすがにその程度であれば、2時間もあれば十分完了できるだろう。


2017/03/17 03:10

足りなかったりいらなかったり、を解消。

OpenGL関係のfg版インターフェース定義もやった。

実装作って、sucrose版消して、を明日中にできるだろうか。


2017/03/16 02:55

sucrose版の削除も予想以上に面倒だった。

OpenGLに関係するものについてもfg版を作らなければいけないようだ。

他にも、関数定義位置の不備や実装漏れなどがあったりするので、それらまとめて今週中に終わらせるのを目標にやろう。


2017/03/14 01:00

ゲームパッドの追加は、あとは実際にゲームパッドを扱う部分だけ。

ちゃちゃっと追加すればベースコンテキストの方も対応できる。

それが済めば、いよいよsucrose版の削除に移れる。


2017/03/11 01:00

ゲームパッドについてもfgに定義を追加しなければならなかった。

今日中?無理無理。

来週の火曜ぐらいまでには片付けたいところ。


2017/03/10 02:50

いつか起きるだろうと思っていた事態の対処でかなり時間を食ってしまった。

やはり、先に宣言していないと参照できないというのは面倒だ。

しかし今日加えた修正により、この点については今後同様の問題が発生しないようにできたはずだ。

明日中に残件を片付けられるだろうか。


2017/03/09 02:50

sucrose版の利用箇所をfg版に差し替えるのは後回し。

ウィンドウ関係とベースシステム関係、fg版を追加していっている。

ベースシステムの内部にウィンドウで生成をしているし、ウィンドウの内部でベースシステムの機能を利用している。

循環参照のような形なので、なかなか追加が面倒だ。


2017/03/08 00:50

想像以上に面倒だった。

とりあえずスレッド関係についてはfg版作成完了。

sucrose版の利用箇所を差し替えるのはまだ。

今週中には、ウィンドウ関係についてもfg版の作成とsucrose版の利用箇所差し替えまで終わらせたい。


2017/03/07 02:50

ウィンドウに関する定義を、全てfgに追加した。

sucroseの定義をfgに変えている最中。

最小の修正で変更していくには順序があるので、ちょっと面倒だ。

明日中には完了したい。


2017/03/04 02:45

やはりやる気がびみょう。

ウィンドウと、ウィンドウ生成時に必要な情報をまとめた型に関する定義を追加した。

sucroseではイベントハンドラ集合としていたものに、ウィンドウのタイトルとサイズの情報を追加した感じ。

イベントハンドラ削除関数は使う機会があるとは思えないので追加していない。

イベントハンドラ呼び出し関数は、実装するライブラリ内に用意すればいいと判断したので追加していない。

最初に想定していたよりもシンプルな感じになりそう。

来週の頭には、イベントハンドラの定義を全部追加してしまいたい。

できれば、実装側も整えられればいいのだが。


2017/03/03 01:45

ウィンドウ周りを整えるに当たり、fgに定義を追加することにした。

fg::newWindow()の引数にfg::BaseContextの参照があるのでその定義の追加が先。

fg::BaseContextの関連関数のfg::getThreadPool()の戻り値がfg::ThreadPoolの参照なのでその定義の追加が先。

といった具合で、とりあえずfg-threadを新たに作った。

fg::BaseContextの定義をfg-basesystemに追加したし、明日からウィンドウに入る。

現状ではウィンドウのタイトルは無し、幅や高さは固定で生成、ウィンドウのサイズ変更可能となっているので、その辺をどうにかできるように関数を定義する。


2017/03/02 01:45

ひとまず、ファイル読み込み処理統一を対応した。

その他細かい修正もしたが、これ次何をやろう。

ウィンドウ出せるし、ゲームパッドも扱えるし。

ウィンドウについては、サイズ固定じゃなかったりといい加減な感じあるが。

へびゲームを作ったりもできたわけだし、ようやくゲーム自体の制作に入れるのだろうか。

その場合、何を作るかが問題になるなぁ。

ウィンドウ周りをもう少しきちんとしたら、windows向けのモジュール生成をやるというのもいいかもしれない。

それをできるようにするためにも、玄箱T4を使えるようにしたというのもあるし。

ああ、現状だとOpenGL関数を直接呼び出してるんだっけ。

それだとOpenGL使えない場面でも関数呼び出せちゃって気持ち悪いんだよなぁ。

古いプロジェクトではその対応も入れてたし、ウィンドウ周りと合わせてそこをやってしまうか。


2017/03/01 01:00

rootfsはメモリ上で問題ない、というのが結論。

USBメモリにrootfsを構築して玄箱T4を動かしたが、処理時間を計測したところそこまで差が出なかった。

USBメモリ上のrootfsだと壊れる可能性があり、修復の手間などを考慮するとメモリ上に展開する方がいいだろう。

メモリ上にrootfsを展開する場合、TFTPで別のマシンからダウンロードしてくるのだが、ダウンロードだけで30秒程度かかる。

一度起動してしまえば関係ないとはいえ、多少長いのが気になっていた。

その件に関しては、ジャンボフレームに対応するようにMTUとtftpコマンドのブロックサイズ指定で解決。

ほんの数秒でダウンロードが完了するようになった。

明日からcandymakerの開発に戻る。

前に書いた内容だと、ファイル読み込み処理が2つあるからそれを片方に統一するところからやる、とか書いてある。

しかしそれはやらずとも動いてるわけだし、後回しでいいような気もする。

まぁ、どこから進めるかは明日状態を見てから決めよう。


2017/02/28 00:41

金曜日の時点でハードディスク搭載まではできた、のだが。

sambaだけでは不十分な感じがある。

アクセスしたユーザーでしかファイルにアクセスできないのは不便だ。

ファイルサーバーとして使うなら問題ないんだけど、linuxのrootfs作る時など、ファイル権限をrootにしたい時もあるし。

なので、そういった作業用にnfsも必要だと思った。

というわけで今日、nfs、hdparm、NTPクライアントを追加したものを作った。

機能としてはこれで十分なんだけど、rootfsをメモリ上に展開するのは、メモリが128MBしかない玄箱T4では厳しい感じがある。

ファイル転送速度にも影響が出ているような。

少なくとも金曜日の時点で、samba上にあるlinuxカーネルのビルドをしようとしてもうまくいかなかったし。

TFTPでブートしてから、nfsかUSBメモリ上にあるrootfsで動作させて、メモリ上からは退避させようと思う。

とりあえずはUSBメモリで対応するかな。

それでファイル転送速度とかが改善されればいいのだが。

スワップを使用していた時の使用量から考えると、90MBほどメモリが使えれば問題ないはずなのだ。

まだ2月なわけだし、明日までは玄箱T4の件をやることにする。


2017/02/24 04:35

あとはハードディスクを搭載するだけ、になったはず。

実際に動かしてみないことにはなんとも言えない。

しかし、よく考えたらhdparm入れてなかった。

まぁ、まだ起動しっぱなしにするわけでもないし。

土日中にビルドしてしまうか。

あとNTPクライアントも入れてなかったな。


2017/02/23 04:05

adhocrepeaterで複数のデバイスを扱えるようにした。

しかし、実際に使ってみないことにはちゃんとできてるか分からない。

週末に動作確認する予定。

玄箱T4は、ディスクレスでの稼働と、ハードディスク4台の移植で完了としよう。

ソフトウェア構成は明日中に完了させたい。


2017/02/22 04:25

玄箱T4のemerge完了。

しかし困った。

無線LANアダプタがきちんと動かない。

ファームウェアがどうのとdmesgにはあるものの、きちんとsys-kernel/linux-firmwareは入れてあるし。

対応していると思われるファームウェアも含まれてるしで、いまいち原因が分からない。

そもそも玄箱T4に無線LANアダプタを付けるという構成がおかしいかもしれない。

玄箱T4やらメインのマシンやらは、有線LANで構成すべきか。

しかしそれ用にdhcpやらdnsやら、iptablesやらを用意するのは、これまた手間だなぁ。

とりあえずは固定IPで、iptablesとかその辺はなしでやるか。

その辺いじくってたりも並行してやっていたせいもあり、adhocrepeaterの進みはいまいち。

ひとまず設定ファイルの追加項目について、テストを作った。

明日中に完了させて、木金で玄箱T4の方も完了させたい。


2017/02/21 01:00

想定外に時間がかかっている。

玄箱T4でemergeをしているが、想像以上に進みが遅い。

昨日の夜からやっているので、せめて今日の昼頃には終わるかと思ったのに。

distccでコンパイルは高速なマシンでやっているものの、それにしたって遅い。

adhocrepeaterや玄箱T4の件は、2月中には決着させたい。

adhocrepeaterの1ポート構成化も、やるべきなのかどうか。

現状の2ポート構成でも、とりあえず問題はないわけだしなぁ。

気になるところと言えば、扱えるデバイスの数ぐらいか。

現状、1つのデバイスしか相手にできない。

簡単な修正で解決できると思うし、そこぐらいはどうにかするか。

3月からはcandymakerの方を進める予定。


2017/02/18 04:36

nfs?知らんな。

カーネルとファイルシステムを、全て外部からTFTPでダウンロードして起動することに成功。

起動後は全てメモリ上に配置されるため、有線LANの接続が必要なのは起動時のみ。

起動中ずっと接続していなければならないnfsとは違う。

ファイルシステムに関しては、gentooのstage3を展開したものをほんの少しいじったもので確認しただけ。

なので、来週はそこをどうにかして、完成といきたいところだ。

メモリ使用量は起動直後で40MB弱といったところ。

まぁ、セットアッププログラムでインストールできるdebianはもうちょい多かった気がするから問題ないだろう。

stage3をハードディスクに入れて起動した時には3MB弱だから多少気になるが、ファイルシステムが40MB近くあるのだから当然である。

まぁ、mdraidやらsambaやら、必要なツールつっこんでも容量は大して変わらんだろう。


2017/02/17 04:30

動いた動いた。

バージョン4.9.9のカーネルに、玄箱T4のカスタマイズパッチを適用したソースをビルドしたカーネルが玄箱T4で動作した。

miconaplも一応問題なく動いていたようなので、おそらく問題なく手直しできたのだろう。

しかし現状、miconaplはセットアッププログラムでインストールできるdebian上でなければ動作できていない。

miconaplはバイナリだし、やはりこれもビルドツールのバージョンの差異の影響だろうか。

とはいえ、公開されているマイコンの仕様書に沿って互換性のあるツールを自作すれば、この問題はクリアできるようだ。

しかし、やりたかったのはファンの回転速度を落とすこと程度なので、そんなにすぐ作る必要もないだろう。

明日中に、玄箱T4でnfs bootやnfs rootをできるようにしたいところだ。


2017/02/16 04:30

玄箱T4の方をやってる。

起動させるだけなら簡単にできるかと思ってたけど、そんなことはなかった。

カーネルのビルドは問題なかった。

FIT対応とかいうのも問題なく作れる。

問題は、2.6.30.8のカーネルだとFATAL: kernel too oldとかいって起動でこける。

ソースのバージョンに対して、gccとかのビルドツールが新しすぎるのかもしれないが、確証はない。

新しいバージョンのソースならいけるかと思い、カスタマイズ分の差分を適用しようとしたら面倒なことになった。

元のソースが古いせいか、構成が新しくなったせいでそのままでは使えない処理とか、そういうのが多くて手直しが必要になる。

とりあえず、ビルドが通るようにしたいところだ。

raspberrypiと同じく、ディスクレス環境にしたいがメモリ128MBだし。

さすがにきびしい気がする。


2017/02/14 02:25

確認が取れたので0.2.0として確定。

1ポート構成の0.3.0を作る前に、raspberrypiの方を先にやることにした。

といっても、今日で完成した感じはある。

他に何かなければ、adhocrepeaterの方に戻って0.3.0を、と行きたいところだけど。

明日用事で出かけるし、今週中は厳しそう。

構成自体、結構変える必要があるだろうし。


2017/02/11 03:40

別のポートを使用する構成が完成。

したと思うんだけど、実際に使ってみないことにはなんとも言えないなぁ。

多分大丈夫だと思うんだけど、1人ではなかなかテストしづらい。

明日動作確認して、問題なければ0.2.0として確定。

問題ないようなら、1ポート構成に修正する。

それを来週中に完成させたら、とりあえず一段落にしたい。

あまりadhocrepeaterばかりやっていても仕方ないし。

adhocrepeaterの次は、raspberrypiと玄箱T4かな。

しかし面倒だからなぁ。

玄箱T4については、ぱぱっとできそうならやる、ぐらいだな。


2017/02/10 04:00

方針変更。

試したこともないことを、急にやろうとするのは無茶だ。

できないことはないだろうけど、奇妙な、後々手を付けにくい構成になってしまうだろう。

なので、まずは簡単な作りのものを作ることにした。

SSID転送用に、別のポートを使用する。

これであれば、多少分かりやすい構成で作ることができる。

もちろん、これは暫定的な構成の予定だ。

うまくいったのを確認してから、効率のいい、よりよい構成に変更する。

というわけで、その構成でSSID送信処理は作った。

SSID受信処理ももう少しでできる。

明日中にはSSID受信処理を完成させて、それを組み込む予定。


2017/02/08 19:40

SSID強制変更対応完了。

やはり、比較的簡単に対応できた。

ちょっと面倒に考えていたせいで多少手間取ったが、最終的にはシンプルにできたと思う。

問題はSSID転送の対応だ。

こちらはちょっと修正して完了、とはいかないだろう。

デバイスのデータ中継に混ぜて転送する予定なので、その選別とか必要になる。

それをどのように表現するかが問題だ。

どんな変更を加えたところで、設定ファイルの項目追加はなさそうな気がする。

名前変更くらいはあるかもしれないけど。

ならば今日中に、今日までの変更で追加するべき項目の対応は済ませておくべきか。

そうすれば、木金はSSID転送に集中できる。

送信についてはどうとでもなるだろう。

問題は受信だろうな。


2017/02/08 04:15

SSIDの履歴機能追加完了。

pspautoconnector2に実装していた機能では無駄、というより不自然な処理があったので、それを省いた上で実装した。

adhocrepeaterでは別の箇所で同様の処理をしているため、必要ないのだ。

明日から、できれば明日中に、SSID強制変更の対応をする。

方法については大体まとまっている。

pspautoconnector2よりも機能を分割しているため、対応しやすそうな気がする。

実際にやってみなければ、なんとも言えないが。

しかし、自動テストはどうしよう。

SsidChangerに強制変更用の関数を追加する、というのも違うし。

SsidChangerのSSID変更関数の仕様変更で対応する形になりそうだな。

その関数用のテストを作るか。


2017/02/07 04:15

v0.1.0として確定。

今週中には、SSID変動に対応させたい。

相手にSSIDを送信して、相手も同じSSIDに設定するところまで。

とりあえず、SSIDの履歴機能を追加する。

今のままでは、周囲に複数のネットワークが存在する場合に、順々にチェックしていくようなことができない。

pspautoconnector2に実装済みの機能だし、明日中には完成させて次に行く予定。

次というのは、SSIDの強制変更だ。

特定のSSIDを検出したら、そのSSIDに強制的に変更する。

その次はSSIDの転送機能だろうな。

検出したSSIDの他者への送信と、他者から受信したSSIDの処理。

そこまでできれば、SSID変動に完全に対応できるはず。

ここまで、できれば今週中に。


2017/02/04 04:00

設定ファイルの読み込み完了。

明日試しに動かしてみて、特に問題ないようならバージョン0.1.0のプロトタイプ完成。

全体的な動作確認以外の確認事項としては、データ中継の効率に変化があるかどうか。

データ中継処理を、前に作ったものから変えているためだ。

効率が良くなっているといいのだが。


2017/02/03 04:10

残るは、データ送信機と受信機の設定。

それ以外は一通り対応した。

明日中には、今作ってある部分については設定ファイルをいじることで色々できるようになり、一応動かせる状態になるはず。

あくまでプロトタイプであり、機能はまだまだ足りないが。

かなり行き当たりばったりで作ってたpspautoconnector2と違って、比較的ソースが見やすい気がする。

pspautoconnector2には引数10個以上の関数とかあってわけわからなかったし。

その原因は設定ファイルのデータを1つ1つ引数で渡していた、というのもある。

今回はその辺、設定の型ごと一気に渡す形に変えたので、引数が多くなりすぎず見やすい感じ。


2017/02/02 04:00

設定ファイルの対応開始。

テスト用データのビルドルールとか、その辺の動作がおかしかったり、記述が気に入らないので直したりしていたら多少手間はかかったが、とりあえず軌道に乗った。

後は、設定データを追加し、それを読み込む処理の追加、読み込んだデータの使用。

それを追加していけば完成する。


2017/02/01 04:00

というわけで、他者から受信したデータをPSPに送信する処理完成。

明日から設定ファイルの読み込みと、読み込んだデータの使用。

できれば全て作ってしまいたいけど、それなりに量あるしできるか分からない。

設定ファイルの解析処理自体はpspautoconnector2のものを使うから、そこで詰まったりはしないが。


2017/01/31 00:30

ネットワークへの接続の確立処理ができたようだ。

対象のSSIDが見つかるまでスキャンを繰り返すことで対応。

変更するSSIDの選択処理については、とりあえずはなくてもどうにかなるし、後々追加する。

PSPから受信したデータの送信処理はできたので、明日からは他者から受信したデータをPSPに送信する処理を作る。

明日から、というか明日中に作ってしまいたい。


2017/01/28 04:30

蓄積されているデータからのSSID変更処理は一応完成。

変更するSSIDの選択処理は作っていないため、そこは追加する必要があるけど。

既存のネットワークに接続するにはSSIDの検索を行なえば、と昨日書いたが、やはりというかそこまで単純なものではないようだ。

SSID設定後、あまりに速くSSIDの検索をかけてもうまく行かなかった。

だから、何回か繰り返して検索処理をかける必要があるだろう。

具体的には、設定したSSIDが見つかるまで。


2017/01/27 04:15

やはりアドホック接続についてはきちんと理解できていなかったようだ。

アクセスポイントをanyに設定すれば既存のネットワークに接続するようになる、と思ったのだがそんなことはなかった。

SSIDの検索を行なうべきだろうな。

複数回行なう必要はない。

1回行なえば、見つかり次第アクセスポイントのアドレスに変更されるようだ。

iwlistならうまくいったが、iwlibを利用したプログラムでも同じ動くになるかどうかは分からない。

明日試しに処理を追加してみよう。

SSID変更要求の呼び出しは追加したが、蓄積されているデータからSSIDを変更する処理はまだ。

この部分も明日作ってしまえればいいのだが。

そうすれば、PSPから受信したデータの送信処理は完了になる。


2017/01/26 04:20

受信したデータが処理対象かどうかのチェック、完了。

データを受信できなかった場合のSSID変更要求、関数作成完了。

あとはそれの呼び出し処理追加と、すでに蓄積されているデータからSSIDを変更する処理の追加。

これでPSPから受信したデータの送信処理は完了。

次は、他者から受信したデータをPSPへ送信する処理。

こっちは多少単純にできるはずだ。

それが出来上がったら、設定ファイルの読み込みに取り掛かる。

これをやらないと、とりあえずプロトタイプで使ってみる、ということができない。

データの中継が完了すれば、とりあえず使える状態にはなるわけだし。


2017/01/25 04:00

やる気はびみょうだが、大枠はできたっぽい。

残りは、受信したデータが処理対象かどうかのチェックと、データを受信できなかった場合のSSID変更要求。

後者に関しては、とりあえず関数を追加する必要があるなぁ。

前者はどうやって処理しよう。

MACアドレスのチェックなんだけど、まぁmemcmp()しておけばいいか?


2017/01/24 04:00

型は全て作った。

後は組み合わせて機能にするだけ。


2017/01/21 03:00

UDPによる送受信と、生パケットの送受信ができるソケットをそれぞれ作った。

あとは、パケットの配列の定義とパケットの配列を管理する型の作成。

それができれば、PSPから受信したデータの送信処理が作れる。


2017/01/20 03:55

思うようにやる気が出なくてよくない。

UDPによるデータ送出処理がまだ途中。

パケットを管理する型は作った。

ソケット通信をする型は明日中に全て作ってしまいたい。


2017/01/19 03:25

盛大に勘違いしていたようだ。

SSID設定処理でSSIDの検出なんかいらない。

アクセスポイントをanyに設定すれば、既存のネットワークに接続するようになるらしい。

無理解から勝手なことやろうとしてた。

簡単に言えば、昨日やったSSID検出処理の共通化は完全に無駄になった。

モチベーションの低下がやばい。

アクセスポイントをanyに、という情報も、実際に試して確認しただけなので、それが正しい仕様なのかどうかは分からない。

anyじゃなくても、とりあえずアクセスポイントを何かしら設定すれば接続できたし。

アドホック接続に関する詳しい仕様がどっかにまとまって書かれていればいいのだけど。

その辺はRFCとかIEEEとかなんとかなんだろうか。

そんなわけで、モチベーション下がりつつもPSPからデータを受信し、それを他者に送信する処理を作り始めている。

必要な追加機能は、PSPからデータを受信するための生パケット取得用ソケットと、他者に送信するためのUDPソケット。

あとは、一時的にパケットを溜め込むバッファもあった方がいいだろう。

PSPからデータを受信する処理と、そのデータを他者に送信する処理はそれぞれ別のスレッドにする。

バッファはその橋渡しだ。


2017/01/18 03:15

想定以上にめんどくさい。

SSID設定処理でもSSIDの検出を行なうため、SSID検出処理を共通化した。

SSID検出スレッドの処理を、共通化したSSID検出処理で行なうようにするところまで完了。

これで明日にはSSID設定処理にSSID検出を追加できる。

多少やる気が落ちてきてるのも、やはり効率に影響している。

次にやることまでちゃんと考えておかないと、モチベーションの維持ができんな。

この次はいよいよ中継処理に入る。

PSPから受信したデータを他者に送信する。

pspautoconnector2にはなかった処理だ。

PSPからデータが受信できなかったら、SSID設定処理に対してSSID変更しろ、と要求を投げる感じ。

SSID設定処理には、まだそれに対応するための処理を作っていないので、合わせて機能追加をしていく。

その次は他者から受信したデータをPSPに送信する処理か?

で、検出したSSIDについて他者に送信する処理と、他者から受信したSSIDの処理。

それでメインの処理は多分全部。

後は設定ファイルの読み込みと、その適用。

そんなところだろう。


2017/01/17 04:00

SSID設定処理作成中。

とりあえず設定するだけならできたが、これ多分接続前にネットワークを検出している必要があるな。

pspautoconnector2がうまく動いていない時があったのも、そのせいかもしれない。

明日中には設定処理を作り終えたい。


2017/01/14 02:20

SSID検出に反応してSSIDを設定する処理を作っている。

SSID検出に反応して、というイベント処理がもうちょいで出来上がる。

イベント処理については、大体sucroseと同じような感じで処理している。

来週の頭には、SSID設定処理まで仕上げたいなぁ。


2017/01/13 01:40

周囲のSSIDを検出する処理を作った。

pspautoconnector2ではチャンネルを考慮していなかったが、今回は一致するもの以外扱わないことにした。

この方が、混線を防げていいだろう。

次に作るべきは、SSIDの設定処理だな。

しかし、目的のSSIDかどうか確認するにはデータを受信してみないと分からないしどうしよう。

などと考えたが、今回はデータの転送もするんだし、その辺はそっちに任せるか。

SSIDの設定については、大きく分けて2種類のルートで行なおうと思う。

1つは、SSIDの検出に反応して行なう設定。

もう1つは、ネットワークの切断に反応して行なう設定。

まず前者から作り始める。

後者はデータの読み取りができるようになってから。


2017/01/12 01:20

SSIDをまとめる型を作った。

まだ完全ではないが。

例えば、イベントハンドラを登録できるようにして、新しいSSIDがつっこまれた時に呼び出すようにしたい。

が、それを作るのはもうちょい先でいい。

明日には、周囲のSSIDを見つけ次第つっこんでいく処理を作る。


2017/01/10 23:30

pspautoconnector2の改良版、adhocrepeaterの開発に取り掛かっている。

pspautoconnector2のソースを見てたら、テストコード全く書いてないしひどかった。

adhocrepeaterはテストファーストでがんがんテスト作っていくことにする。


2017/01/07 00:35

パッケージ内のファイルを読み込めることを確認。

具体的にどのディレクトリである、という情報に触れることがなく、いい感じ。

最初はsucroseに作ってたけど、candymaker内に移動した。

candymakerでパッケージパスを生成する必要があるためだ。

candymakerに実装されているインターフェースについても、なんらかの処理が必要になりそうだな。

現状何もしてないから、ロードするとcandymakerと競合してしまうモジュールもロード可能な状態になっていてよくない。

あと、パッケージ情報ファイルなどを読み込むために書いたファイル読み込み処理はそのままになっている。

今回追加したfgの仕様のファイル読み込み処理に置き換えて、古い処理は削除したいところだ。

とはいえ、処理が被っていて気分悪い程度であり、なんらかの問題を起こしているわけでもない。

他の作業を終えて、candymakerの作成に戻ってきた時に、最初にやるとしよう。


2017/01/05 17:52

年が明けてしまった。

ファイル読み込み関係の処理作った。

これを使ってパッケージ内のファイルにアクセスする。

そこまでやったら一区切り付くし、別の作業をやりたい。

pspautoconnector2の改修とか、放置してある玄箱T4を使えるようにしたりとか。

今週中には終わらせて…って、あと1日しかないではないか。


2016/11/15 02:15

日数かけすぎたけど、設定ファイルに関数のシンボル情報を書かないようにする対応できた。

その変更に対応するように、sucroseとかへびゲームとかを修正すれば完了。

次はパッケージパスを利用してパッケージ内のファイルにアクセス、という本来やるべきだった作業に戻ろう。


2016/10/25 01:35

モジュール初期化時に情報を引数で渡すのはできた。

ちょっと考えていたが、ゲームとベースシステムの情報を独立させているのはそのままでよかった。

モジュール内に記述してしまうと、ショートカットファイルに記述する際にもモジュール名が必要になり、よくない。

もう一方の関数のシンボル情報に関しては、予定通り進めよう。


2016/10/19 23:45

ひとまずテストの作成から。

何を焦っていたのか知らないが、テストも作らずに始めようとしていた。

なので、ひとまずテストを作った。

明日にはそのテストを通す処理を実装するとしよう。


2016/10/19 00:45

久しぶり。

まだ体調は不完全だが、今日無理しなければ明日には万全になるだろう。

今更ながら、パッケージ情報ファイルの構成がおかしい気がする。

おかしい点は2つ。

1つは、パッケージ内のゲームとベースシステムの情報を独立させていること。

まとめてあることで、見た目は分かりやすいが処理はしにくかった。

それがどのモジュールに入っているのかという情報があるが、そもそもモジュール情報内に書いておけば済むことだ。

もう1つは、ゲームやベースシステムの情報に関数のシンボル情報を含めていること。

設定ファイルに記述する情報としては、ちょっと低レイヤーすぎる。

設定ファイルには関数のシンボル情報を含めない形にした方がいいかもしれない。

ちなみに、モジュール初期化時に渡すパッケージ情報に関するどうのこうの、もまだ終わっていない。

正直、渡す内容についても再度検討するべきではと考えている。

いっそ、パッケージ情報ファイルの中身も渡してしまった方が分かりやすいような。


2016/10/05 00:40

ひどくやる気が出ない。

しかし、このままではまずいので直近でやるべきことをリストアップし、とりあえずfgに関数の宣言を追加した。

明日はcandymakerにその関数の実装を追加するのをやろう。


2016/09/28 00:50

軽く熱が出ている。

最近気温の変化が激しいので、それにやられたのかもしれない。

作業しようにも頭が痛くてうまく思考がまとまらない。

とりあえずいくつかファイルを追加したが。

モジュール初期化時に渡すパッケージ情報に関する型を追加して、関数も追加しようと思ったけど、手順違うかも。

パッケージ情報に含む情報として、パッケージディレクトリのパスがあるが、これもただの文字列とかでなく型を作る予定。

なので、そっちの方を先にやるべきだろうな。


2016/09/24 01:25

やる気が出ない。

とりあえず、関数の仕様だけまとめるプロジェクトとしてfgを作った。

過去に作ったプロジェクトと同じ名前。

ここに最初に追加するものは、やはりcandymaker内で使用する関数や構造体の宣言だろうな。

sucroseのものについても宣言を追加するけど、量が多いし今やったら絶対だれる。

そういうのは後回し。


2016/09/22 00:40

cmmainの記述を整えて、candymakerも試しにライブラリ化して動作するところまで確認。

関数の仕様だけまとめたプロジェクトも必要な気がしてきている。

今のままでは、モジュール初期化時にファイル読み込みをするためだけに、candymakerのヘッダファイルを読み込む必要があるし。


2016/09/21 03:25

コアライブラリのダミーを作って、それをロードし、関数が呼び出されるところまで確認。

cmmainはとりあえずこんなところだろうな。

明日からcandymakerの方を修正していく。


2016/09/15 01:45

やる気絶不調。

とりあえず、cmmainとかいうプロジェクトを作った。

あともう少しでコアライブラリのロードまでできる。


2016/09/08 23:30

昨日の時点で実験は済んでいる。

今日から作業に入ろうとしたのだけど、どのように構成するのが最適なのか、色々考えていた。

まず、candymakerのほぼ全てをライブラリ化したものとそれを読み込むメインプログラムは、別のプロジェクトにするべきなのか?

前者はモジュール側から参照されることはあるが、後者にはそれがないため、分けるべきかもしれない。

しかし、その場合双方の名前はどうしよう。

そもそもcandymakerとかいう名前、あんまかっこよくないし別のに変えたい気もする。

名前空間がcandymakerだとなかなか長いので、もうちょい短めので。

少し考えたが、プロジェクトの分割はやろう。

メインプログラムの方は、一度作ったら多分ほぼ修正しない感じになりそう。

コアライブラリのロードと、メイン関数の呼び出しくらいしかやることないし。


2016/09/07 00:10

確実にやる気落ちてる。

方針変更。昨日のはなし。

candymakerのほぼ全てを共有ライブラリ化する。

これにより、モジュールからcandymakerの関数を参照可能にする。

こっちの方が、昨日の案よりずっと現実的だと思う。

そういった構成が可能なのか、簡単なコードで実験しなければと思うのだが、まだやってない。

明日にはやってしまう予定。


2016/09/05 17:00

思ったよりも大規模な変更が必要になりそう。

モジュールロード時の初期化関数に渡すデータは、仮にパッケージコンテキストと呼称することにした。

このパッケージコンテキストは、ゲームの初期化関数にも引数として渡す。

そうしないと、ゲーム内からパッケージのファイルにアクセスする場合に、必ずモジュール初期化関数を用意しなければならず、面倒だ。

と、そこまではいい。

問題は、モジュールのロードを行うcandymakerで生成したデータの内部に、モジュール側からどうやってアクセスするのか、ということだ。

パッケージコンテキストの仕様は後々変更することはもちろんあると思うので、メンバを直接アクセスするなんてのは現実的ではない。

ではパッケージコンテキストに関するモジュールを作って、ってやるとそのモジュール初期化時にパッケージコンテキストを渡せないではないか。

現在の構成として、candymakerは完全に独立している。

ゲームやベースシステムは、candymakerが一方的にモジュールをロードし、関数を呼び出すだけであって、その呼び出された関数の中からcandymaker内のデータにアクセスするような仕組みを作っていない。

なので、その仕組みを作る必要が出てきたな、という感じ。

具体的には、candymaker内のデータにアクセスするための、ラッパーのようなモジュールを作ろうと思う。

モジュールロード後に、ラッパーモジュール内に用意した初期化関数を呼び出し、candymaker内の関数にアクセスできるようにする。

パッケージコンテキスト内のデータを参照するには、ラッパーモジュールの関数を呼び出し、その関数を経由してcandymaker内の関数にアクセス、データを参照する、といった流れ。

さて、そんなに都合よくできるかどうか。


2016/09/03 00:45

パッケージ内のファイル読み込み方法考え中。

ゲーム内で使うテクスチャであれば、BaseContextにパッケージのパスを追加しておけばいいかー、と思ったけど違う気がする。

BaseContextは、読み込んだモジュールすべての関数が参照する可能性のあるものだ。

パッケージが違っていても関係ない。

そういう性質のものに対して、1パッケージのみに関係する情報を乗っける、というのは違和感がある。

モジュールロード時のデータを追加するべきかもしれない。

現状のモジュールロードは、初期化関数が指定されていれば、引数のないその関数を呼び出すだけ。

これに対し、引数を付け加えるべきかも。

その引数のデータとして、そのモジュールが属するパッケージのパスなどを乗っける。

しかしその場合、そのデータはどうやって管理しよう。

実体はモジュールをロードしたところに置いておいて、初期化関数でポインタをモジュールのグローバルに配置する、というのがセオリーだろうか。

できるだけグローバルとか使いたくないんだけど、さすがにこれは仕方ない気がするなぁ。


2016/09/01 17:00

まずファイル入出力に対応することに決めた。

セーブをできるようにするにも、テクスチャや音声を扱うにも、まずはファイルに対する入出力ができないことには始まらない。

差し当たっては、どれを実現する目的で作ろうかな。

音声はまだ無理だし、テクスチャかセーブデータか。

現状、この前作ったへびゲームは、スコア表示が存在しない。

描画が面倒だったので。

比較的簡単にスコア表示を行なうために、テクスチャ読み込みに対応してもいいかもしれない。

そしてハイスコアを保存するために、セーブデータに対応する、という形はどうだろう。

まだセーブデータという概念自体作ってないわけだから、先にテクスチャに対応するのは道理かも。

テクスチャはパッケージのディレクトリに置けばいいだけだし。


2016/08/31 00:35

ウィンドウクローズイベントハンドラ追加。

ベースシステムに、メインウィンドウのクローズイベントの対応を追加し、メインウィンドウが閉じたら正常終了するようにした。

付随して、起動中はwhile(1)によってCPU1コアの使用率が100%になってしまっていた状態も解消。

きりがいいと思ったので、sucroseをv0.9.0とした。

次はどこを進めようか。

一度よく考えるべきだろうな。

過去の記事を見直せば、ある程度計画のようなものも出てくるかもしれない。


2016/08/29 20:10

メインウィンドウやゲームパッドマネージャに対するイベントハンドラの設定方法を変更。

これにより、とりあえずゲーム側のソースコードが50行少なくなった。

まぁそれはおまけ程度であり、割とどうでもいい。

メインウィンドウやゲームパッドマネージャに対し、特定のイベントハンドラの設定を阻止できるようにインターフェースを変更した。

メインウィンドウのウィンドウを閉じる時のイベントハンドラなんかは、ゲーム側から触らせたくなかったので、想定通りに変更できて満足。

とりあえず、ウィンドウを閉じるイベントに対応しようと思う。

今のベースシステムは、ウィンドウを閉じた時の不正終了で落ちているので気に食わない。

ちなみに、体の描画に付け足したい要素が、とかいうのは土曜に片付けておいた。


2016/08/27 03:10

体の描画と、衝突による進行停止、つまりゲームオーバーも作った。

これで、とりあえずゲームとしての体裁は整ったはず。

もうちょい、体の描画に付け足したい要素があるので、来週の頭にそれをやって、0.1.0としよう。

実際にゲームを作ってみて、ベースシステム側の改善点も少し見えた。

来週はその辺から手を付けていくか。


2016/08/26 02:00

へびが動くようになった。

餌の配置と、餌を食って体が伸びるようになった。

しかし、体の描画処理を行なっていないため、見た目にはほぼ反映されていない。

そのせいもあって、食った後の挙動がこれで合ってるのか、ちょっと判断がつかない。

でも体を描画するためのデータはできているわけだし、明日体の描画処理を作る。

そして衝突判定も作り、明日中の完成を目指す。


2016/08/25 00:10

本格的に描画を開始した。

とりあえず、へびと外壁を描画。こんな感じ。

テクスチャとかまだまともに使えるようにしてないし、というよりも面倒なので見た目がしょぼいのは仕方がない。

緑色のがへび。

左側の、ぱかっとなってる方が口。

コントローラによる向き変更にも対応している。こんな感じ。

体の描画はまだなので、頭としっぽが千切れそうになってるのは仕方がない。

それに、向き変更が可能なだけであってまだ動くこともできない。

その処理はなんとか今日作ったので、明日動かしてみる予定。

それがうまくいけば餌を食べて体を伸ばす処理と、餌の配置処理。

最終的に外壁や体との衝突判定処理も追加する。

そして、衝突でゲーム停止、つまりゲームオーバーになるようにすれば一段落といったところかな。


2016/08/24 00:40

ソースを機能ごとに分割した。

へびの描画を先にやってから、それに対してコントローラ動かした時の挙動を付けていく形にしようとしたが、うまく行かず。

どうも作る順を間違えたらしい。

コントローラでどのようにデータを変動させるか決めないと、そもそもどのようなデータを用意するべきか、がはっきりしない。

なのでコントローラの挙動の方が先だな。


2016/08/23 01:00

背景黒く塗ることはできた。

別にそれ自体、全然難しくないんだけど。

すぐにソースが肥大化しそうで、どうやって機能分割したものかと考えていた。

しかしそれも大体見えてきたので、明日にはもっと機能分割し、手を付けやすくする予定。


2016/08/20 01:30

ゲームパッドイベントハンドラの設定処理も完了。

次からイベントハンドラの中身を詰めていくわけだけど。

基本的には、ゲームパッドの操作→描画処理、という流れになると思うけど、なにもしてなくてもへびを動かす処理も必要になる。

なので、ゲームパッドとは別に待機処理を動かしておいて、一定時間ごとにへびを動かす→描画、という流れも必要になるだろう。

ウィンドウ描画イベントについては、単に描画処理流すだけで問題ないはず。

ゲーム自体の処理はそんな感じだけど、ゲームオーバーになったら処理の流れを変える必要があるだろうな。

ゲーム開始前の画面は、とりあえずは省いてしまってもいいだろう。

起動と同時に開始、ゲームオーバーでもう動かなくなる、みたいな感じ。

あとから、タイトル画面とゲームオーバー時になんか押すとタイトルに戻る、といった処理を追加するか。


2016/08/19 00:35

やる気びみょうだけど、感覚はだいぶ戻ってきた。

とりあえずウィンドウイベントハンドラ設定処理は書いた。

描画イベントの処理は空っぽだが。

ちゃっちゃとゲームパッドイベントの方も設定処理書いて、中身を詰めていきたい。


2016/08/17 15:50

そろそろcandymakerの開発に戻る。

簡単なゲームを作ってみようと思う。

現状、フォントファイルを読んで文字を出すとかできないし、かといって自分で線引いて文字書くのもめんどくさい。

というわけで、そういった表示が必要なさそうなゲームを作る。

思いついたのは、なんていうの?

へびが餌食ってどんどん伸びていくあれ。

あれなら得点などの表示がなくても問題ないし。

あれ作る。


2016/08/16 00:45

というわけで中継ツールを作った。

xlinkkaiだとゲームスピードが落ちてしまうゲームも、ローカル内での中継ではさすがにスピードが落ちなかった。

ネット越しの中継をした場合どうなるかは、まだ確認していない。

xlinkkaiでどうしようもないくらい遅延していたゲームは、ローカルでの中継の時点で既にどうしようもないくらい遅延してた。

もしやデータ到着順が入れ替わったりとかいう、UDPで起きるらしい現象が頻発してこんなことになっているのでは、と思いTCP版を作ってみたが変わらず。

他のゲームの場合、ローカル内で中継する限りではUDP版とTCP版、どちらでもこれといった違いは見られなかった。

なんなんだろう。


2016/08/15 13:00

pspautoconnector2は想定通りに動いているようだ。

しかし、一部のゲームでゲーム性が変わってしまう程度にゲームスピードが遅くなってしまうのが気に食わない。

これはpspautoconnector2ではなくxlinkkaiの問題だと思うけど。

というわけで、xlinkkaiの代わりのツールを簡単に作ってみようかと。

昨日試した限りでは、パソコンに無線LANアダプタを2つ差して、2台のPSPとそれぞれ通信し、単純にデータを中継すれば、チャンネルが違っていても通信が可能ということが確認できた。

その中継を行なうために作ったプログラムに多少手を加えれば、遠隔地とP2P通信するためのツールにできるはずだ。

とはいえ、xlinkkaiもおそらくP2P通信なんだよなぁ。

ポート開放が必要なのも、きっとそのためだし。

しかし、その通信部分の処理が甘くて処理遅延の原因になっているとすれば、改善の余地があるかもしれない。

まぁ、やるだけやってみよう。

今日1日で完成させられると思うし。


2016/08/10 03:00

無理なダイエットはよくないと思った。

pspautoconnector2がきちんと動作していない原因が判明。

無理に環境全体のサイズを小さくしようとした環境を使っていたことが原因のようだった。

ようだった、というのはそうでない環境を使ったらきちんと動作するようになった、というだけなので、他の原因ということも考えられる。

しかし、その2つの環境の相違点は、より多くのプログラムをbusyboxへのシンボリックリンクに差し替えていることが大きいので、やはりその辺が原因かな、と。

他にも、xlinkkaiのエンジンの停止でこけるなどしていたので、無理に小さくしようとした環境は今後使わないようにする。

必要がなくなったらすぐ消そう。

起きたら、新たに作ったmicroSDの動作確認をする予定。


2016/08/09 03:45

過去にやったことをすっかり忘れていた。

カーネルモジュールのソースに修正を加えていた件について忘れていたこともあり、あまり進まなかった。

とりあえずカーネルモジュールは使えるようになった、はず。

しかし、pspautoconnector2がきちんと動作していない。

いや、期待通りの動作はしていると思うのだが。

SSIDとチャンネルはきちんと設定されているので、そこに至るまでにPSPのネットワークも検索しているはずなのだが、既存のネットワークに繋がず新しいネットワークを作っていて接続できていない。

アドレスを指定する処理も必要なんだろうか。

とりあえず明日追加してみるけど、それでうまくいくのかどうか。


2016/08/08 00:15

今日設定ファイルいじくったので1.0.0にした。

pspautoconnector2はとりあえず一区切り。

次は自動生成したgentooの小型化するスクリプトを作るつもり。

だけど、とりあえず前に作ったやつを差し替えて試してみようかな。

正直、そんなに簡単にできるような作業でもないと思うのだ。

なかなかに期限も迫っているし。

pspautoconnectorについては、また新たな問題が浮上した。

SSIDが変動する一部のゲームで、接続がうまくいかない。

PSPのSSIDを変動させる前に、対象のSSIDを検索する処理を行なっているらしく、PSPが変動後のSSIDに変わらないのだ。

簡単に言えばpspautoconnectorと同じ動きをしている。

双方、変動後のSSIDを探そうとするけれど見つからないので、接続がうまくいかない。

解決するには、パソコンの無線LANアダプタのSSIDを変更する必要がある。

一番簡単な手段としては、手動変更だろう。

しかし、それを自動化したくてpspautoconnectorを作ったわけで、それをしては意味がない気もする。

とはいえ、それすらも自動化したい、となると、pspautoconnector同士で通信を行なう必要が出てくる。

親のPSPについては、子のPSPが接続するために自動でSSIDが変動する。

それを検知したpspautoconnectorは、他のpspautoconnectorに通知し、SSIDを変更させる、といった具合だ。

でもそれをするとなると、中継するサーバーを何かで作るとかか、P2P通信するとかが必要になって、かなり大掛かりになる。

難しいところだ。


2016/08/06 03:45

大きな勘違いをやらかしていたため修正。

疲れた。

設定ファイルの要素をいじくったら1.0.0にする予定。

休日はできるだけ作業しないようにしているが、明日にやってしまおうかな。

しかし、めちゃくちゃな作り方したのでソースがとても汚ない。

次からは絶対こんなことしないよ。


2016/08/05 03:40

設定ファイル読み込み処理を作って、0.1.0とした。

明日は特定のゲーム向けの、より迅速なSSID変更処理を追加する予定。

明日中に完成までできればいいのだが。


2016/08/04 00:10

昨日の時点で、初回の接続がうまくいかない問題については解決済み。

接続前に、接続用アダプタで対象のネットワークが見つかるまでネットワーク検索をかけ、見つかり次第接続する形で対応。

前バージョンよりも短い時間で接続できるようになった気がする。

比較するために前バージョンでも試そうとしたんだけど、うまく動いてなかった。

設定値がおかしいのかもしれないが。

今日から、設定ファイル読み込み処理を作っている。

前バージョンでは、設定値をコマンドライン引数で直接設定していた。

しかし今回はコマンドライン引数で設定ファイルのパスを指定し、それを読み込む形にする。

後々、多少複雑な設定値を扱えるようにするためにはその方がいいと判断した。

で、設定ファイルの記述形式はcandymakerのものと同じ物、つまり簡易的なJSONにする。

これであればマップやリストを利用できるし。

何より、すでに作ってあるので手間が省ける。

というわけで、candymakerから必要なソースを持ってくるところまではやった。

明日中に、設定値をハードコーディングしている部分を全て差し替えたいところ。


2016/08/02 18:40

前回接続時から一定時間経過しないと再接続できない仕組みは追加した。

で、今は初回の接続がうまくいかない原因を探っていて、大体把握できた。

大まかに言えば、アダプタを2つにしたのが原因だった。

接続用のアダプタが、接続先のネットワークの存在を把握できていないのがいけない。

把握するための方法は、ネットワークの検索。

検索用と接続用に分け、接続用のアダプタではネットワークの検索をしていなかったからいけなかったのだ。

接続前にネットワーク検索をかけて、ネットワークの存在を把握してから接続、という形にすれば多分いける。

となると、処理の流れ自体に手を加えるべきかもしれない。


2016/08/02 00:50

やる気がびみょう。

ネットワーク検索時の重複を消す処理は追加した。

他にも、PSPの検索を開始した後にSSIDを変更した場合、接続失敗にせず再度PSPの検索をする処理も追加した。

現在のSSIDと同じSSIDに再度接続しようとする問題については、ちょっと考え中。

前回接続時の時間を記録しておいて、一定時間経たないと再接続できない仕組みを追加しようかと考えている。

その仕組みを追加したとしても、ネットワークが変わらない場合再接続を禁止する処理は必要だと思うけど。

もしくは、接続できなかった場合はSSIDを空にしておくことで対応するべきだろうか。

前バージョンはアダプタが1つだから問題なかったけど、今回は2つなので、SSIDをそのままにしておくと検索に引っかかってしまう。

ネットワークが消滅してから10秒程度経たないと検索から消えてくれないので、今すぐ追加したところで効果は確認できないが。


2016/08/01 12:00

金曜の時点で、とりあえず動作する状態にはなった。

まだまだ完成ではないが。

コマンドライン引数か設定ファイルから設定するデータがハードコーディング状態だったりとか。

現在のSSIDと同じSSIDに再度接続しようとしてしまうのもよくない。

前バージョンならそれほど問題でもなかったかもしれないが、今回は違う。

ネットワーク検索用アダプタで検索をかけた時に出てくるSSIDが増えてしまうのだ。

全く同じSSID、チャンネルのネットワークが複数検出される。

検出時に被りがある場合は無視する処理も追加する予定だが、ネットワークが変わらないのに接続しようとすることに意味はないので、こちらも処理を追加して抑制する。

色々試していて気がついたのだが、同じメーカーのチップセットで同じカーネルモジュールを使っていても、チップセットが違うと細かい動きが違う気がする。

xlinkkaiを使うためralinkのアダプタを使っているが、古いアダプタと新しいアダプタで違いが出ている。

アドホック接続をするためにSSIDとチャンネルを設定すると、新しいアダプタの場合は既に存在するネットワークに接続しようとするので問題ない。

古いアダプタの場合、既にネットワークが存在しても、とりあえず新しいネットワークを作る。

それからちょっと経つと、既に存在するネットワークに接続する。

いや、もしかしたら既に存在するネットワーク側がアダプタのネットワークに擦り合わせているのかもしれない。

そこまでは確認していない。

とにかく、そのような動作をしているため、古いアダプタだと素早いネットワーク接続に向いていないのでは、と思っている。

SSID変動型のゲームでうまくいかない場合があるのもそのせいなのでは、と思っている。


2016/07/29 03:15

ネットワーク接続処理を作った。

PSP検知処理はまだまだ。

最終的な作りは見えた感じ。

ネットワークへの接続とPSP検知処理を別々のスレッドでやるので、次に接続するネットワークの決定をどうするか、が問題だった。

古いバージョンの処理は列挙、接続、検知を順々にやっていたので、列挙したネットワークに順番に接続するだけで済んでいた。

しかし今回は別々のスレッドなので、ループで順々にネットワークに接続しては検知、という手段は使えない。

そこで、接続したネットワークの履歴を残す、という方法を考えた。

一度ネットワークに接続したら、そのネットワークの情報を履歴リストにつっこんでいく。

次にネットワークに接続する時には履歴リストを参照し、今まで接続したことがないネットワークに優先的に接続する。

全て接続済みの場合は一番古いものを優先。

一度接続したことがあるネットワークに接続した際には、そのネットワークの情報を一番上に持ってくる。

この方法であれば、同じネットワークばかり接続しようとしてしまう、というようなことにはならない。

実際には、今接続しているネットワークと同じゲームのネットワークが出現したら、すぐさまそのネットワークに切り替える、という機能も作る予定。

SSIDが切り替わるタイプのゲームで、タイムアウトがかなり短いゲームへの対策だ。

それでうまくいくのかどうかは分からないが。


2016/07/28 03:40

古い処理から引っ張ってきて、周囲のネットワークの列挙処理を作った。

ネットワークの列挙とネットワークへの接続はそれぞれ別のアダプタでやることもあり、スレッドで処理している。

色々試して気付いたことには、あまり短すぎる間隔で処理を呼び出しまくるとおかしくなる、という点だ。

大雑把に試してみた感じだと、100ミリ秒間隔が限界点。

それよりも短い、10ミリ秒間隔以下で呼び出すと、新たに出現したネットワークを検知できなかったり、消滅したはずのネットワークがいつまでも検知されたり。

そもそも、前に作った時は検知開始してからデータが取れるまでに1秒程度かかってた気がするのだが。

まぁいいか。

次は検知したネットワークに接続する処理を作ろう。

今回作った処理と同じく、スレッドで処理する。

それが出来たら、その次はネットワーク内のPSP検知処理だな。


2016/07/27 00:40

windows10インストール完了。

使う機会はずっと後になると思うが。

pspautoconnector2の開発開始。

基本的には既存のソースから引っ張ってくるので、そんなに時間かからないと思うのだけど。

設定項目が多少増えるから、コマンドライン引数で与えるのではなく設定ファイルを作った方がいいかもしれない。

でもそうなると面倒が増えるから、とりあえずはコマンドライン引数からにするか。

設定ファイルにするかどうかは、メインの処理が出来上がってからでも遅くはない。


2016/07/26 00:40

アップグレードの期限が迫っているので、そろそろwindowsを10にしようかと思っている。

で、今日ちゃっちゃとアップグレードしようとしたのだが、結果から言えばまだできていない。

1つのパソコンに2環境作ってあるため、とりあえずインストールディスクを作ろうとしたのだが、まずそこがうまくいかない。

ツールを使って落とそうとしたが、Cドライブに8GBの空きが必要などと言われた。

Cドライブは基本的に、必要最低限の領域しか確保しないため、そんなに空きがないのだ。

Dドライブなら余裕があるのに。

クリーンインストールするのだし、と色々消してみたが7.8GB程度までしか空きができない。

windowsアップデート関連のファイルをクリーンアップすれば空きが10GB程度になりそうだが、再起動しないと消せないようだった。

で、再起動してみたらログイン画面から画面真っ黒。

マウスポインタだけは見える状態。

セーフモード起動もできない状態になってしまった。

仕方ないのでgentooを起動して調べてみたら、公式サイトからディスクイメージをダウンロードできるとか。

もっと早く言ってほしかった。

そんな感じでまごまごしていたので、本日は全然進んでいない。

実は昨日、騙し騙しカーネルインストールスクリプトを書いていたので、とりあえずそれを追加しておいた。

この後rootfsインストールスクリプトも書いてしまうか。

それができたら軽量化などと言っていたが、正直めんどくさいので、先にpspautoconnectorの新バージョンの方をやろうと思う。

最悪、軽量化などできなくてもいいのだ。


2016/07/23 03:50

とりあえずrootfs生成まで完了。

次はカーネルインストールだが、これも過去のスクリプトから持ってくればすぐできるはずだ。

そこまでできたら、実際にrootfsとカーネルをSDカードにインストールし、動かしてみる。

特に問題ないようなら、その次は軽量化か?

必要ないパッケージのファイルの除去などを、スクリプトでまとめてできるようにする。


2016/07/21 17:10

昨日の時点で、必要なファイルのダウンロードとカーネルビルド処理まではできた。

あとはrootfs生成について。

そこまでは、過去に組んだスクリプトを参考にして進められる。

過去のスクリプトでは、rootfs生成時にカーネルのインストールもやっていたけど、今回のは別にしようと思っている。

カーネルは複数インストールすることもあるんだし、それをシェルスクリプトで対応させるのはなかなかめんどうだ。

特に今回の場合はraspberrypiなので、1用と2用で別のカーネルを積む予定だ。

場合によって1のみ、あるいは両方、あるいは1用のを複数、などというのを1つのスクリプトで全パターン網羅する、というのは困難を極める。

それなら、1つのカーネルをインストールするスクリプトを作っておいて、それを自分で複数回動かした方が分かりやすそうだ。


2016/07/20 00:30

8月中旬頃までは別の作業することにした。

raspberrypiで動作するgentooの自動生成関係をやる。

それが済んだら、pspautoconnectorの新バージョンを作る。

それをraspberrypiに乗っけて出来上がり。


2016/07/16 00:20

candymaker-0.12.0完成。

前に作ったpainttestとかgamepadtestで試したが、いい感じ。

sucroseを別パッケージに分離したが、ちゃんと動作している。

結構それっぽくなってきた感じがある。

気になった点としては、設定ファイルの記述ミスの場所が分かりにくいというところか。

エラーログの内容を変えることで対応できると思うけど。


2016/07/15 02:15

同パッケージ内の依存解決完成。

古い処理も片付けた。

これで他に何もなければ、明日バージョンを確定させよう。

次はどうしよう。

とりあえず、今回の追加で複数のパッケージを扱えるようになったわけだな。

candymakerに何か追加するとしたら、設定ファイルマネージャやモジュールマネージャとかその辺だろうな。

しかし、それらは現状必須ってわけでもないし。

いよいよ簡単なゲームでも作ってみるか?


2016/07/14 02:30

同パッケージ内の依存解決の目処は付いた。

明日完成させる。

そこまでできたら、古い方の構成は削除するとしよう。

それでとりあえずバージョンを確定させるか。


2016/07/13 03:00

基礎はできたかも。

細部はまだできていないが、インターフェース情報と依存情報、そして有効モジュールリストを使い、適切なモジュールを検索する処理を作った。

山場は越えたのでは、と思うけど、ちょっと処理がぐちゃぐちゃな気がするんだよなぁ。

強引に解決した箇所もあるし。

しかし、その箇所は小手先の修正では解決できない気がする。

きちんと書くには、新たな仕組みを追加するべきだろう。

まぁ、その辺りはやはり後回しで。


2016/07/12 03:00

やる気はいまいちだが順調だと思いたい。

先週の時点では、またしてもうっかり忘れていた部分の機能追加のみだった。

やはり先週末で完成は無理だった。

現時点で、完成までの目処は立った感じがある。

うまくいけば明日には完成するのでは、と思っている。

しかし、インターフェース情報と依存情報、どちらもパッケージ情報に固定データとして書かれてるのはどうなんだろう。

ちょっと融通が効きにくそう。

すぐに追加する必要はないと思うけど、パッケージ設定によって調整できるようにするべきか。

インターフェース情報を追加、あるいは変更をできるようにしたりとか。


2016/07/08 00:15

うっかり忘れていた。

パッケージ情報ファイルの依存モジュール情報の記述方法を、他パッケージへの依存に対応したものに変更するのを忘れていた。

なので、今日はとりあえずそこを作った。

ちなみに、現時点では古いものもまだ消していない。

現状ではそれで動いているわけだし、消したら消したでめんどうなので。

やる気が残念なことになっていたので、そこまでしかできなかった。

明日は金曜日だし、明日で完成させたいところではある。

しかし、大きく違う処理を新規に作ることになるわけだし、そう簡単にいくかどうか。


2016/07/07 00:20

パッケージ情報ファイル読み込み処理に、インターフェース情報についての処理を追加した。

これでとりあえず下準備はできた感じか。

これらの情報を元に、他パッケージへのモジュール依存の解決を可能にする。


2016/07/06 00:20

パッケージ設定ファイル解析処理を作った。

インポート機能は未対応。

そのうちやる。

忘れないように、課題管理に追加しておいた。

次はパッケージ情報ファイルへの記述追加対応。

インターフェース情報の読み込みに対応する。


2016/07/05 15:35

昨日は既存処理を整えていた。

で、今日からパッケージ設定ファイルに入ろうとしたのだが、昨日書いたのは多分間違ってる。

時間が経ちすぎたため、当初の構成を忘れてしまっていたようだ。

パッケージ設定ファイルで依存モジュールのマッピングはしない。

依存モジュールの解決は、パッケージ情報ファイルのモジュール情報に記載する実装済みインターフェース情報と、パッケージ設定ファイルのモジュール使用許可リストで行なう。

他パッケージへの依存モジュールの指定はインターフェース名で行なう。

モジュール使用許可リストから、そのインターフェースが実装されているモジュールを探し出す形。

そんなわけで、パッケージ情報ファイルにも手を加える必要がある。

どこから手を付けたものだろうか。

パッケージ情報ファイルの依存モジュール情報かな、と思ったがこれは最後か?

少なくともインターフェース情報がなければ動作しないし。

インターフェース情報より先に、パッケージ設定ファイルを作るべきか?

その2つは直接的な関わりはないから、どっちから手を付けても大丈夫かな。

インターフェース情報とパッケージ設定ファイルを作って、それを元に依存モジュール情報の内容を変更、最終的にモジュールロード処理らへんを変更する感じか。

しかし、同パッケージについても依存モジュールの指定をインターフェース名でやるべきかと思ったが、正直二度手間な気がする。

インターフェース名でやることによるメリットもあるため可能にはしたいが、モジュール名の直接指定でもできるようにしたい。


2016/07/04 21:15

パッケージ設定ファイルを先に作るべきでは、という気がしてきた。

今のところの問題は、他のパッケージのモジュールへの依存モジュール指定ができないという点だ。

これを、依存パッケージを直接指定して解決する、というのは分かりやすいが、最終的な構成とは割と異なる。

そこから最終的な形に持っていこうとすると、設定ファイルの記述から変えていかなければならない気がする。

それなら、そこはまだ現状のままにしておいて、パッケージ設定ファイルを追加した後に対応した方が楽なのでは、という気がしている。

パッケージ設定ファイルには何を書くんだったか。

とりあえずはモジュールの使用許可リストと、依存モジュールのマッピングか?

他のパッケージ設定ファイルを参照したりするから、それも書くか。

後々、パッケージとセーブデータディレクトリの関連付けも書く。

この中の、最低限必要なものはどれだろうか。

モジュール使用許可リストは後回しでいいだろう。

他の設定ファイルの参照、つまりインポートも後でいい。

そうなると、依存モジュールマッピングだけか。

依存モジュールマッピングの後に、インポートも対応しよう。

依存モジュールマッピングの記述方法はどうしよう。

細かい指定方法と、大まかな指定方法、少なくともその2種類は用意したい。

具体的には、細かい指定方法というのはモジュールレベルのマッピング。

多まかな指定方法というのはパッケージレベルのマッピングだ。

その中間もあれば、より便利だろうな。


2016/07/01 00:00

やる気減退がかなりやばい。

しかし、とりあえず0.11.0確定まではやった。

次は他のパッケージにあるモジュールに対し、依存モジュール指定をできるようにする。

そこまでできれば、とりあえずcandymakerは一段落だろう。


2016/06/28 20:30

昨日はうっかり書き忘れた。

wafのタスク生成がよく分からんので、昨日1日では完了できなかった。

なんとなく分かってきた上で、多分明日までかかりそうだな、といった感じ。

現在のビルドルールが、C++のソースファイルをコンパイルする、という作業を前提に書かれているため、融通が効かない。

そこから修正していく必要がある。

しかしモチベーションが上がらない。


2016/06/25 00:30

モジュール参照を作った。

それをパッケージ情報ファイルで使うようにした。

結果、パッケージ情報ファイル内のモジュールのパス指定が、パッケージ内の相対パスになった。

これで、ベースシステムとゲームに必要なパッケージに加え、ショートカットファイルを1つのディレクトリにまとめることで、candymakerにショートカットファイルを読み込ませればゲームが動作するようになった。

どうしよう、きりがいいしここで0.11.0としてしまうべきか。

しかしながら、開発上の問題点が新たに浮上している。

自動テストで使用するパッケージ情報ファイルの位置と、モジュールの位置が噛み合わないため、自動テストが失敗してしまうのだ。

一応、ビルド後に自分でモジュールをコピーして、テストが通ることは確認したものの、こんなこと毎回やりたくない。

毎回やってたら、いずれコピーし忘れとかで問題が出てくるだろうし。

何よりめんどくさい。

wscriptに手を加えて、その辺を対応してから0.11.0とすることにしよう。


2016/06/23 22:40

パッケージ参照を作った。

それをショートカットファイルで使うようにした。

結果、ショートカットファイルからのベースシステム、ゲームのパッケージ指定が、ショートカットファイルからの相対パスになった。

今まではcandymakerからの相対パスで、実用度は皆無だったため、これは大きな進歩だ。

現状の構成からすると、ショートカットファイルの内容は完成したと言っていいはずだ。

しかしながら、パッケージの参照についてのみ対応したのであって、それ以外は未対応だ。

例えば、パッケージ情報ファイルのモジュール指定なんかは、まだcandymakerからの相対パスで指定しなければならない。

できるだけ早く対応してしまいたいが、パッケージ参照ができたということはモジュールの依存関係にそれを使用できるということだ。

どちらを先にやるべきか、悩ましい。

前者は型の変更であって、処理の流れ自体は変わらない。

後者は型の追加に加え、それを利用した処理の追加、となるだろう。

であれば、負荷の軽いモジュール指定の記述、つまりモジュール参照型の作成を先にやってしまうか。


2016/06/22 22:40

早まらなくてよかったかもしれない。

煮詰まってはいるんだが、よく考えたら始まりから間違っていたのかも。

ショートカットファイルのベースシステム参照について、パッケージパスの記述を色々考えていたんだが、想定では、

{ "base" : "基点ディレクトリ名", "path" : [ "ディレクトリ名", "ディレクトリ名", "パッケージディレクトリ名" ] }

といった感じの記述で、基点ディレクトリからの相対パスを表現しようとしていたんだけど。

しかし、基点ディレクトリから見ても深い階層に配置することなんてないよなぁ、と考え、

{ "base" : "基点ディレクトリ名", "path" : "パッケージディレクトリ名" }

こうでいいよな、と思った。

更に、これならいっそのこと、

{ "at" : "基点ディレクトリ名", "name" : "パッケージディレクトリ名" }

という感じにキーの名前を変えた方が分かりやすそうだな、と。

で更に、この構成は既存のベースシステム参照やゲーム参照の構成と酷似している。

ならば、これはパスというより参照情報という括りで扱った方がよさそうだな、と思った。

ゲーム中で使用する素材なんかは、ある程度区分けされてるディレクトリ構成を扱えた方がいいだろうから、パスの概念が必要になると思う。

しかしながら、現状ではそこまで自由度の高い要素は必要ないのでは、という話。

少し希望が見えてきたかもしれない。


2016/06/21 22:00

確実にやる気減退している。

今日も全然進んでない。

このままではよくないので、candymakerのソースを眺めていたが、ちょっと整理した方がいい気がしてきた。

なんとなくでファイルを置いてしまっている感じがある。

特に設定ファイル周り。

ショートカットファイルの要素、ベースシステム参照とゲーム参照の定義が、ベースシステム側やゲーム側に置かれてるのが違和感ある。

設定ファイル側、あるいはどちらにも属しない独立したディレクトリに置くべきでは。

生成時の引数として、設定ファイルの要素を渡すことになると思うから、設定ファイル側でいいとは思うけど。

その辺から、ソースファイルの配置を整えるところから始めようかな。


2016/06/20 22:00

どこを進めるべきか考えていた。

ひとまずsucroseはここで中断しておく。

設定ファイルのパスの扱いをどうにかしようと思う。

現状では、ベースシステムとゲーム、どちらも1つのパッケージで完結してなければならないという制限がある。

パッケージをまたぐ依存関係を解決できないためだ。

しかし、ゲームやベースシステムが汎用的なパッケージを利用する、などというのはよくあることだと思うので、できないと非常に困る。

というわけで、依存モジュールの指定にパスを含めるようにする。

付随して、今まで環境依存の文字列として扱ってきたパスを、共通的に扱うべく書式を定めようと思う。

しかし、一気に全部をやろうとしてもうまくいかないと思うので、段階的に作っていく。

まずやるべきは、型の関係だろうな。

後に回せば回すほど、影響箇所が増えて面倒になるし。

なので、まずはパスの型を作る。

次に、設定ファイルのパスの箇所について対応し、これで一段落。

その次はどうするか。

最終的には、パッケージ設定ファイルを追加することになるけど、さすがにそこまで一気にはやりたくないなぁ。

パッケージからパッケージに、直接依存する形を取るか?

現状の依存モジュールの記述は、

{ "deps" : [ "依存モジュール名" ] }

といった具合だが、ひとまず

{ "deps" : [ { "path" : パス型(依存モジュールのパス), "name" : "依存モジュール名" } ] }

という形にするか。

で、最終的には

{ "deps" : [ { "package" : "依存パッケージ名", "name" : "依存モジュール名" } ] }

という形にするかな。

実際のモジュールとのマッチングは、パッケージ設定ファイルでやる感じ。

今回の作業の最終的な落としどころも考えておこう。

ショートカットファイルと必要なパッケージ群を1つのディレクトリにまとめた上で、

candymaker ショートカットファイルパス

と実行すれば、ディレクトリがどこに配置してあってもゲームが動かせる、といったところか。

それを実現するには、前述した作業以外にも工程が必要になるが、やりたいことはつまりそういうことだろう。

ショートカットファイルを基点とするファイル配置への対応。

現時点では、candymakerを実行したティレクトリを基点とした配置にしか対応できてないし。

むしろそんなものはなんの役にも立たないし。


2016/06/19 00:55

休みだし、久々にraspberrypi関係をやっている。

raspberrypiで動作するgentooの自動生成をスクリプトにまとめようとしている。

とりあえず、最新のstage3をダウンロードするスクリプトを書いた。

昔書いたスクリプトでは、落とすstage3のパスを直書きしていたので、stage3が新しくなったら修正が必要だった。

今回はサーバーにあるlatest-stage3なんちゃらファイルを参照して、現在の最新版をダウンロードするようにした。

おまけで、stage3の最新版がダウンロード済みで、最新版が更新されていない場合にダウンロードをスキップする処理も追加した。

休日に地道に進めて、起動後ディスクレス化する環境の自動生成までやりたいところ。

スクリプトを使って試行錯誤し、最終的に生成できた、というのは昔やったんだけど。

手動で手を加えたことも色々あって、今ではどうやったら確実に生成できるか覚えてないので。


2016/06/17 20:40

0.8.0確定。

sucroseの.hと.cppの総行数が1万を越えた。

試しに、バージョン毎のファイル数と行数を簡単なシェルスクリプトで出力したところ、

バージョンファイル数行数
v0.1.016495
v0.2.0392676
v0.3.0402810
v0.3.1402810
v0.4.0403032
v0.5.0403253
v0.6.0888790
v0.6.1918685
v0.7.01059449
v0.8.012913001

こんな具合だった。

0.3.0から0.5.0にかけてファイル数が一向に増えてないのは、ウィンドウ周りの機能追加をするたびにバージョンを上げてたんだろう、多分。

過去の記述を見返したら、0.6.0でゲームパッドがどうたら言ってて、行数も一気に倍以上増えてるので多分そう。

0.8.0で追加したスレッドプールとタスクにより、非同期処理が多少書きやすくなった、はず。

しかし、タスクマネージャ書いてる時にデッドロック見つけちゃってやばかった。

スレッド内でロックしてるmutexをロックしながらjoinしようとしてた。

やはり非同期処理で厄介なのは、バグが再現しないことがある、という点か。

今回の件も、たまたまjoinの方が早くロックを取得すると発生するのであって、毎回起きるわけじゃないし。

また、停止してしまうだけで不正終了はしないから、どこで止まってるのかも特定が面倒だし。

久々にgdbとか使って停止箇所特定などしようとしたが、久々すぎてうまく使えず。

結局printfデバッグで発生箇所を特定し、解決した。

まだどこかにバグが潜んでいそうで怖い。


2016/06/17 00:30

ゲームパッドの対応も完了。

しかし、0.8.0はまだ確定しない予定。

タスク管理の共通化のアイデアがひらめいたので。

明日それを作ってから確定する予定。

問題となっていたのは、タスクを括る必要がある、という点だった。

どういうことかと言えば、

{

bool ended;

タスク

タスク

タスク

Ender ender;

}

これで伝わるかどうかは謎だが。

排他制御関係やEnderの定義を省いて簡略化しているが、タスクを管理する構造体の定義だ。

endedは終了フラグで、trueの場合タスクの実行できなくなる。

それにより、各タスクが他のタスクに遷移することなく終了する。

enderは、破棄のタイミングでendedをtrueに設定する。

この構成によって、構造体を破棄すれば安全にタスク群を破棄できるのだ。

不用意にタスクを破棄しようとすると、まだ動いているタスクから破棄済みのタスクに遷移しようとして死ぬ、などということが起きる可能性がある。

これをどう共通化したものか、いい案が浮かばなかった。

仮に、TaskManagerというものを用意して、そこにタスクを登録していく形、とすると各タスクのメンバ名が消えるようなものなので、タスクの遷移がやりにくくなりそうだ。

自分で生成したものの破棄を他でやる、という構成も気に食わない。

早い話が、endedに2回破棄処理をかける必要があるのが問題なのだ。

1回目の破棄でendedをtrueに設定、2回目で物理的に破棄、つまりメモリ領域の解放。

そこで思い付いたのが、

{

TaskManagerBegin taskManager;

タスク

タスク

タスク

TaskManagerEnd taskManagerEnd;

}

このような構成だ。

実際にはBeginとEndをユニークポインタで管理するだろうが、それ以外に違いはない。

TaskManagerBeginに、終了フラグや排他制御関係のものを持たせる。

TaskManagerEndは、生成時にTaskManagerBeginの参照を要求する。

TaskManagerEndの破棄時に、TaskManagerBeginの終了フラグを設定する。

といった具合だ。

他にも、WaitTaskCancellerみたいなものをBeginとEndの間に配置することで、待機タスクをキャンセルによって終了させる、ということもできるようにする予定。


2016/06/16 02:20

待機スレッドプール完成。

出来たそれを使って、早速ウィンドウの処理に待機タスクを追加した。

ゲームパッドマネージャの処理も、タスクで処理するように書き換えた。

あとはゲームパッドだけ。

それが完了したら0.8.0として確定するか。

現時点で、スレッドプールで稼働しているスレッドが1つでも、ウィンドウとゲームパッドマネージャがきちんと動作することを確認している。

待機スレッドプールを作る前は、どちらかのタスクが待機を行なっている間、もう片方のタスクを処理できなかった。

…はず。

残念ながら確認したわけではない。

絶対やばいよなぁ、ということで対応したので。

ウィンドウとゲームパッドマネージャのタスクの管理部分は、ほぼ同じ構成になった。

共通化できそうな気がするが、そううまくいくだろうか、とも思う。

うまく共通化できれば、かなり有用なものになりそうなのだが。

ゲーム側のタスク管理にも使えるし。


2016/06/15 12:20

普通のスレッドプールのタスクについても破棄処理が間違っている気がする。

現状、タスクの破棄処理は未稼働タスクの削除と稼働中タスクの待機をした後に行なっている。

しかし、未稼働タスクの削除はいらないのではないか?

確かにタスクの破棄までの時間が短縮されるが、そもそも稼働させたいから未稼働タスクに蓄積されているのだ。

それを稼働させずに消してしまう、というのはおかしい気がする。

それに、普通のスレッドプールは待機が発生することがないのだから、ちょっと待てばすぐ終了するはずだ。

なので、未稼働タスクと稼働中タスク、どちらからも破棄対象のタスクがなくなるまで待機するのが正しいかな、と。


2016/06/15 00:00

待機スレッドプール、まだ出来てないが構成ははっきりした感じ。

pthread_cancel()で待機を強制的に切って終了させる、というのは多分やらない方向になる。

pthread_cancel()による強制終了処理自体は用意するが、それはあくまで例外的な処理であり、通常は待機が終わるまで待って終了させる。

そもそも、pthread_cancel()を使わざるを得ない状況というのがあまりないのだ。

read()やpoll()などの、条件を満たさなければ処理が進まない、というような関数を使う場合にのみ使うべきだ。

例えばミューテックスと条件変数によるwait()であれば、notify()で起こしてやればいい。

破棄したい場合には、例えば終了フラグなどをセットしてから起こしてやれば上出来だろう。

そんなわけで、昨日書いた想定は間違い。

待機スレッドプールは、私が考えていた以上に便利な面もありそう。

pthread_cancel()を使う場合、今までのやり方では想定しているポイント以外でキャンセルが発生しないか不安に思っていた。

それが、待機スレッドプールを使うことにより、pthread_cancel()の影響する範囲を待機タスクの部分のみに絞ることができる。

普通のスレッドプールで処理する範囲に関しては、pthread_cancel()でキャンセルがかかることは絶対になくなったわけだ。

この安心感は大きい。

しかし、今作ってるこれ、動作的にはファイバのようなものだな。

固定数のスレッドと、それを利用する無数の処理の断片、という構図になるので、効率的に処理を回せそうな雰囲気はある。

でも、処理と処理を繋ぎ合わせてるのは実質的にgotoのようなものなんだよな。

あまり複雑な繋ぎ方はしない予定だけど、やろうとすれば簡単にスパゲティ化するだろうし、ちょっと怖い。


2016/06/14 02:45

ゲームパッドのスレッドについては後回しにした。

だって現状が中途半端すぎるもんで。

ウィンドウのイベント読み込み待機中、スレッドプールの1スレッドを占有してしまうのが痛い。

処理の詰まりを分かりやすくするために、スレッドプールは1スレッドのみで動かしていて、その1スレッドがメインウィンドウのイベント処理だけに使われちゃってもうだめ。

スレッドプールでは待機無しの処理だけを流すので、待機処理は待機スレッドプールというのを別に用意し、そこでやろうと考えている。

待機スレッドプールは、プールっていうよりキャッシュなんだけど。

待機処理が必要になった時にスレッドを起動し、そのスレッドで待機処理をする。

待機処理を終えたスレッドはそのまま保持しておき、別の待機処理に使い回す。

とまぁ、そんな具合。

スレッドプールのタスクは待機が発生しない処理だけを流すので、破棄は処理が終わるのを待ってからにしている。

一方、待機スレッドプールのタスクはpthread_cancel()で待機を強制的に切って終了させる予定。

pthread_cancel()で終了したスレッドは使い回せないので、joinしてから破棄、という流れになるだろうな。

待機スレッドプールについてはまだちょっともやもやしてるんだよなぁ。

きちんと作れるのか不安だ。

普通のスレッドプールと比べて、違うのは内部、つまり実装だけで、インターフェース自体はほぼ同じになる予定ではあるのだが。


2016/06/13 20:30

ひとまず、ウィンドウから使うところまではできた。

ゲームパッドの方についても、ちゃっちゃとやってしまう予定。

とりあえず、スレッドプール以外にstd::threadを使用している箇所が無くなるようにする。

タスクの引数に、そのタスクの参照を追加したのはいいのか悪いのか。

タスクの処理の最後でそのタスクを再度開始させることで、ループ処理をするために追加した。

これが無い場合、タスクをなんらかの構造体のメンバとして追加したりしないと、自身の参照を得るのが困難だったからだ。

しかしながら、実際の運用を考えた場合、自身を再度開始させることなんてないのでは?という気もしている。

処理の待機が存在しないタスクを回し続けたらCPUの稼働率が無駄に高くなってしまうし。

処理の待機は別の種類のタスクで処理する予定なので、それを利用すると処理タスク→待機タスク→処理タスク→…となるので、自身は参照しない。

それにその場合、循環参照になるため全タスクをなんらかの構造体にメンバとして追加することになると思うし。

とはいえ、今はウィンドウの処理で使ってるから、そこで使わなくなったらさっさと消してしまうかな。


2016/06/11 00:00

構成失敗したかも。

スレッドプールの件。

とりあえずできたので、実際に使おうとしたのだがうまくいかない。

スレッドタスクというものを作り、それをプールに投げて実行する、という形を取っているのだが、処理が終了したかどうか確認できないという問題が浮上した。

タスクを破棄したくても、まだ処理中かもしれないし、破棄しても大丈夫なのかどうかが判断できないのだ。

プールが1つならまだどうにかできるかもしれないが、現在の仕様上だとタスクはプールに投げる時に対象のプールを指定する形を取っており、やろうとすれば複数のプールに投げることもできる。

その場合、こっちのプールではどうだ、あっちのプールでは、といった感じの処理が必要になり、収拾つかなくなる感じがある。

実際には、複数のプールを生成することに意味は全く無いので、そのようなことはやらないが、そうなる可能性があるという時点で構成が間違ってる気がするのだ。

私が想定している運用からすると、タスクを生成するタイミングで、そのタスクを処理するプールを指定しておく形がいいのかもしれない。

そうすれば、タスクを処理するプールが1つに固定されるので、処理の終了チェックなどがやりやすくなるはずだ。

他の問題としては、あるタスクの処理内で、他のタスクをプールに投げる、とかについてか。

通常時は問題ないと思うが、これまたタスクを破棄するタイミングで、タスクをプールに投げようとしたらそのタスクはすでに破棄済みでメモリ例外、なんてのは起きそうなものだ。

どちらかといえばプールやタスクの問題というより、そもそもマルチスレッド処理だから起きる問題という感じなので、その辺考慮した記述をすれば問題ないのだろうけど。

本当なら、今の構成を作るのは昨日中に終わってた気もするんだけど、やる気減退してたのか終わらなかった。

終わってたところで、今日同じ問題にぶち当たって頭抱えてたか。

さて、どのように修正加えていくかくらいは目星を付けておくか。


2016/06/09 00:40

とりあえず0.7.0は完了。

スレッドプールについては、waitをどう処理するかまだ考えてないのだった。

そこを考えるのは後回しにしてもいいような気がするけど。

スレッドプールで動かす処理についても、イベントハンドラと同じ形にしようかと思っている。

ファンクタを引数にスレッドプールハンドラとでも言うべきものを生成する。

スレッドプールにそれを登録することで、プールしてあるスレッドで処理する。

そう考えると、同じハンドラを複数回登録するのもありかな、と考えている。

というのも、現状ではウィンドウやゲームパッドのイベントハンドラは、同じものを複数回登録できない仕様にしているのだ。

この制限も、正直あまり意味がないので撤廃するべきかもしれない。


2016/06/08 00:10

ベースシステムデータの変更については完了したと言える。

ゲームパッドのイベントからウィンドウの再描画要求出せるようになった。

ゲームパッドいじくるとウィンドウに描画している三角形の色が変わっていい感じ。

しかしながら、ウィンドウやゲームパッドマネージャのスレッド開始についても変更しておかないとまずい。

その変更が完了したら、0.7.0としようと思う。

0.8.0はどうしよう。

スレッドプールの追加が妥当だろうか。

しかし、それがないと困る、というレベルでも…なくはないか?

イベント処理をスレッドプールでやるようになれば、描画イベントの処理遅延も改善できるはずだし。

他の候補としては、sucroseではなくcandymakerの方か。

ファイルパスの扱いをはっきりさせる。

その辺ができれば、設定ファイルがより実用的になる。

現状では、絶対パスもしくは作業ディレクトリからの相対パスしか指定できないからなぁ。

ファイル入出力なども作り始めることができるようになるはずだ。


2016/06/07 00:10

ゲームパッドのイベント内でウィンドウの参照を取得できるように対応中。

ベースシステムデータの中身を2つに分けることで対応することにした。

片方は従来のものからデータ参照機能を取り除いたもの。

もう片方は従来のもののデータ参照機能と、ウィンドウなどの実行中のデータ参照機能を合わせたもの。

スレッド処理に関しては、とりあえず自前で実行する形にしようと思う。

スレッドプールについてはまた今度。

多分今やってるのが完了したらやる。

今日中に2つに分割する作業は完了したいところだったが、ちょっと厳しそう。

明日中には。


2016/06/06 12:40

色々考えた結果、やはり音は後回しにすることにした。

位置付けとしては、テクスチャ、というより画像ファイルに近い感じがするのだ。

あれば便利だろうけど、今すぐに必要というわけでもない。

それに、音に関してはどのように構成するべきなのか、まだよく分かっていないのだ。

その試行錯誤に時間を使ってしまうよりも、別のところを進めるべきかな、と。

差し当たっては、ゲームパッドのイベントからウィンドウの再描画要求をするのが困難、という点をどうにかしよう。

ゲームパッドの入力が即座に画面に反映されないので、これではゲームにならない。

しかし現状、ウィンドウ生成時にイベント処理スレッドを開始しているのが問題になるか?

ゲームパッドマネージャでも、生成時にイベント処理スレッドを開始している。

全てのイベント処理が始まる前に下準備をしておく、ということができなさそうだ。

今回の件では、ゲームパッドのイベントからウィンドウを参照できるようにしておく、というのがそれに当たる。

対処方法としては、単純に考えて生成とスレッド開始を別々にしておき、準備が完了した後にスレッドを開始する、となるんだろうけど。

しかしそれはあまりスマートじゃないなぁ。

今はまだウィンドウとゲームパッドマネージャだけ、2つだからいいけど、今後スレッドを起動する要素が増えていったら大変そうだ。

そこで、スレッドはスレッドプールで管理する、という方法を考えている。

スレッドプールの生成と開始を別々にしておく。

スレッド処理が必要な要素は、生成時にスレッド処理をスレッドプールに登録する。

スレッドプールのスレッド開始命令で、登録されている処理を一斉に開始する。

しかしながら、私はスレッドプールというものについて、言葉と大体のイメージしか知らんので、そんなにうまくいくものだろうか、という不安がある。

できれば、イベント処理1つ1つについても、スレッドプールに投げてスレッドで処理したいのだけど。

それによって、描画処理の垂直同期による、ウィンドウイベントの処理遅延も解決できる気もするし。

さて、どこから手を付けるか。

ひとまず、スレッドプールは置いといて、ゲームパッドのイベントからウィンドウの再描画要求ができるように、構成を変更するか。


2016/06/03 22:50

0.6.1できた。

ウィンドウ生成とかに追加した、いらんデータの削除と、課題管理に上げてた2件を対応。

次からは音と思っていたけど、うーん。

音を扱うということは、まずファイル読み込みを使うことになりそうな気がする。

ウィンドウやゲームパッドはそんなことないけど。

別のところを進めるべきか。

土日にじっくり考えてみよう。


2016/06/03 18:15

ぐーたらやってたら遅くなってしまったが、0.6.0できた。

ゲームパッドを扱う簡単なプログラム、gamepadtestを作って思ったことには、ウィンドウを参照しにくいという点だ。

ちょっと前に作った描画を行なう簡単なプログラム、painttestの時は、ウィンドウを参照するのが描画イベント内であり、イベントデータからウィンドウの参照が得られるため問題なかった。

しかし今回は、ゲームパッドのイベント内からウィンドウの再描画リクエストをしようとしたけど、現状ではできていない。

ウィンドウの参照を得られないからだ。

そんなわけで、ゲームパッドの抜き差しやボタン押下などに反応して、描画色を変えるようにしているのだけど、ウィンドウを一旦隠すとかして、手動で再描画させないと色が変わらない感じ。

実行中のベースシステムデータ、みたいなものを用意して、今動いてるベースシステムのデータ、つまりウィンドウの参照などを取得できるようにするべきか。

とりあえず、細かい修正をやってしまおう。

ウィンドウの生成時やら描画イベントやらに足してしまった、ベースシステムデータの参照削除と、あとは課題管理に追加してある件を何件か、といったところか。


2016/06/02 20:40

想像以上に疲れた。

ゲームパッドIDの対応は完了した。

やはり仕様変更は疲れる。

テスト駆動でやってるからか、きちんとできてそうな実感があるのはいいのだけど。

今回のは、さすがに最初に横着しすぎただろうか。

最初からゲームパッドIDを文字列でなく独立した型にしていれば、こんなことには。

処理内容だったらともかく、型についてはできるだけ後から変更をかけないようにしないといけないな。

とりあえず、ベースシステムデータにゲームパッドのイベントハンドラを設定できるようにして、メインでゲームパッドマネージャを起動するところまでは書けた。

なので、ゲームパッドを使用する簡単なプログラムを作りたいところだけど、いかんせん疲れた。

明日でいいかなーという気がしている。

プログラムが問題なく動くなら0.6.0として確定させるから、できれば今日やりたい気もするんだが。

明日は金曜日か。

明日中に0.6.1を作れればきりがいいな。

簡単なプログラムの作成と細かい修正、これらをまとめて明日中に…やれるか?


2016/06/01 23:35

ゲームパッドの扱い、ほぼ完成。

ゲームパッドIDに関してはまだ生の文字列のままなので、明日直そう。

それができたら0.6.0とする。

次はゲームパッドに関するものをベースシステムに追加するとしよう。

で、簡単なゲームを作る。

あー、ウィンドウのイベントにベースシステム関係の参照追加しちゃったのも直すか。

他にも細かい修正したらそれを0.6.1とするか。

以前の記述を見直したら、ゲームパッドの次は音って書いてるな。

それもそうか。

音までやって、ゲームパッドで動かせて音も出るゲームを作れたら、中途半端にしてる部分もどうにかしていくべきだろうな。


2016/05/31 21:00

さすがに昨日の今日で本調子とは行かないか。

とりあえず、ゲームパッド接続・切断に関しては出来上がった。

ゲームパッドIDはただの文字列ではなく型を作るべきとは思うが、使えないこともないし今はこれでいいだろう。

次はゲームパッドの入力だ。

接続イベントを済ませた後にゲームパッドの入力を扱うオブジェクトを作り、切断イベントの前に破棄、という形になるだろうな。


2016/05/31 00:10

先週中にゲームパッド対応は終わらせたかった。

でもそれはさすがに無茶だったようだ。

金曜開始時点で、ゲームパッドの入力の扱いに関してはノータッチだったし。

で、今日。

体調が優れないのと、キーボードの調子が悪いのダブルパンチで作業はかどらず。

キーボードのEnterキーが、1回押しただけなのに2回入力される現象が稀に発生していた。

しかし、前に壊してしまった同じ型のキーボードからパーツを拝借したところ、どうやら改善できたようだ。

明日こそ本気出す。


2016/05/26 17:00

evdevは地雷だったかもしれない。

とりあえずわけがわからない。

ゲームパッドのボタン数取得方法からしてもうだめ。

かろうじて分かったことは、どうもそんなのなさそう、という空気だけ。

evdevでのゲームパッドの扱いは多分、windowsのxinputに近いんじゃないかなと思う。

決まった仕様にゲームパッドを当てはめていく感じ。

xinputの方はまだいい。

ゲームパッドのボタン数とかも仕様のうちに入っているため、ボタン数や軸数が固定だから。

evdevの場合、とりあえずいくつか用意しておいたボタンのうち、接続したゲームパッドだとこのボタンとこのボタンと…が使えるよ!!みたいな情報を得てどうのこうのとか、なにやらすごいめんどくさい。

多分evdevだと、ボタンが100個とか付いてるゲームパッドに対応できないんじゃないかな。

そんなもの扱う予定などないが、古い仕様やDirectInputにはできた。

evdevとxinputにはそれができなさそう。

もうフォースフィードバックとかどうでもいいんで、古い仕様の方を使うとしよう。

ゲームパッドが振動するみたいな機能、私基本的に嫌いだし。

結構な時間とやる気を無駄にしてしまった。疲れた。


2016/05/26 11:50

ゲームパッド切断については、昨日すぐ作った。

で、pthread_kill()もちょっと扱いめんどうそうだな、というのも大体理解した。

というわけで、今日はゲームパッドの入力の扱いに入ろうとしている。

のだが、いまひとつまとまらないような。

過去のプロジェクトの構成とは、これまた少し変える予定。

過去のプロジェクトでは、ゲームパッドの初期状態に関してもボタンや軸の状態変化イベントを呼び出していたが、これはやめる。

ボタンの初期状態の通知と、ボタンの状態変化の通知というのは別物にするべきだと思うからだ。

具体的には、初期状態についてはゲームパッド接続イベントのイベントデータから取得できるようにする。

状態変化については変えなくてもいいと思う。

過去のプロジェクトと同じく、変化があったものについてどう変化したかのみ通知する。

ボタン数、軸数の取得については、過去のプロジェクトのやり方はさすがに頭が悪すぎる。

要求があった時にゲームパッドから取得して返す、とかちょっと。

ゲームパッドを扱うならまず使用するデータなんだし、接続時にゲームパッドから取得する。

あと、今回は状態変化イベント、ということでボタンと軸の区別をなくそうと思っていたけど、やっぱりだめかも。

変化したものだけ通知する場合、やはりこれは別々の方がいい。

1つにするとなると、例えば変化したのがボタンなのか軸なのか、といったフラグのようなデータが必要になるし。

あるいは、ゲームパッドのボタンや軸の状態を全て記録しておく形か。

しかしそれは扱いにくそう。

どのボタンもしくは軸に変化があったのか知りたい場合、直前のイベントデータと比較しなければならないわけだし。

なにより、そのようなことがしたければイベントハンドラでやればいいと思う。

提供する機能は、必要最低限にしたいのだ。

まとめると、イベントで扱えるデータは、まず共通的なものが

・ゲームパッドID

接続時に扱えるデータが

・ボタン数

・軸数

・ボタンの初期状態

・軸の初期状態

状態変化時に扱えるデータが

・変化のあったボタンもしくは軸

・値

こんな具合だと思っている。

ちなみにゲームパッドIDというのは、一意であればなんでもいい。

デバイスのパスのようなデータになると思うが。

あー、ゲームパッド名も接続時、もしくは共通データとして保持するべきか?

ボタンと軸の数についても、接続時以外でも見られた方が便利だろうか。

それなら、接続イベント時にどっかに退避しておく、というのをイベントハンドラでやればいいとも思っているのだけれど。

さて、どこから手を付けるか。

やはり接続時に参照できるデータから追加していくべきか。


2016/05/25 14:20

ゲームパッド接続検出処理ができた。

過去のプロジェクトよりはましになった気がする。

過去のプロジェクトでは、pthread_cancel()でスレッドをキャンセルして終了させるために、そのスレッド内では動的なメモリ確保を行なわないようにしていた。

pthread_cancel()で終了するスレッドと、そのスレッドからデータを受け取って処理するスレッド、2つのスレッドを走らせていたのだ。

今回は、とりあえず起動するスレッドは1つにした。

スレッド内で使用するデータに関しては、スレッド起動前に生成し、sucrose::GamepadManagerに持たせるようにした。

しかし、pthread_kill()を使えばもっとスマートにできるのではないか?

使ったことないから確証はないが、スレッドに対してシグナルを投げられるので、poll()を起こすのに使えるかな、と。

それがうまく行くなら、sucrose::GamepadManagerにメンバとしてデータを持たせる必要がなくなりそう。

ひとまず、切断検出を先にやってからにしよう。

とりあえずは動いてるわけだからな。


2016/05/25 01:10

ちょっとやる気減退してきているような。

主にudevが悪いと思う。

でも、なんとか初回のゲームパッド接続検出処理はできた。

過去のプロジェクトを参考にしつつ、多少処理は変えた。

デバイスがゲームパッドかどうかのチェックを簡略化した感じ。

しかし、evdevか。

そんなのもあったな、っていう気持ち。

1つのデバイスについて、/dev/input/jsXと/dev/input/eventXの2つが出てくるからなんだろうと思ったら、後者はevdevのデバイスらしい。

過去のプロジェクトでは、確か見た目だけで判断して前者を使ってたんだけど、どうもこっちは古いらしい。

evdevの方がフォースフィードバックにも対応してるとかなんとか。

なので、今回はevdevの方を採用することにした。

明日中には、少なくともリアルタイムのゲームパッド接続検出を仕上げてしまいたい。

切断についても、同じ処理の中に含ませられると思うし、やってしまいたいところ。

で、接続・切断ができたら次はゲームパッドの状態変化検知だけど、これは多少時間かかるだろうな。

デバイスをオープンしてどうの、という処理が必要になってくるわけだし。


2016/05/23 23:50

sucrose::GamepadManagerの作成に入り始めた。

ゲームパッド接続イベントについて、イベントハンドラとかイベントデータとかイベントハンドラ集合とかを作ったのでいよいよ本体。

しかし、午後に野暮用で出かけたせいか、暑かったせいもあり以降やる気出んで途中まで。

なんとか、ただGamepadManagerを生成する部分までは書いたので、明日はその中身。

udevを利用して、ゲームパッドの接続を検出する。

多分、その辺は過去のプロジェクトのソースを流用できるはず。

参考にして手早く済ませたい。


2016/05/20 23:56

昨日の変更は失敗だったかもしれない。

ゲーム固有データ初期化時に、ベースシステムデータを参照できないので、描画イベント内でベースシステムデータ→ゲーム固有データ→OpenGLコンテキストが参照できない、のが問題だったんだけど。

改めて考えてみたら、イベントハンドラにはラムダ式を使えるようにしているので、描画イベント生成前に生成しているOpenGLコンテキストの参照を描画イベント生成時に渡せばそれで見られるわ。

ラムダ式のような構文を使えない、あるいは使いにくい言語とかのために作った、と考えれば全く使い道がないわけでもないか?

それに、ラムダ式の参照だけだと、相互に参照し合う、みたいな状態への対応が難しいか。

いや、そんな構成にすること自体よくないんだが。

あとは、ベースシステム起動時に使うデータが、実行中常に触れる状態になってるのもなんか気になる。

実装済みのデータで言えば、ウィンドウのイベントハンドラ。

これはベースシステム起動時に生成するウィンドウで使用するためのものなので、それ以降は必要がなくなる。

しかし、実行中もsucrose::setWindowEventHandlers()を呼び出せてしまう。

意味は全くないが。

しかし意味がないものを呼び出せるというのはなんだか気持ちが悪い。

そこで、ベースシステム起動時にのみ使用するデータと、実行中も使用するデータの2つに分ける、という案を思い付いた。

前者はBaseArgs、後者はBaseContextとかそんな名前で。

例えばゲーム固有データは実行中も使用するので、後者に格納される。

ゲーム側からは、BaseArgsはゲーム初期化時には参照できるが、以降は参照できなくなる。

今までベースシステムデータの参照を必要としていた部分は、BaseContextの参照に置き換わるような感じ。

せっかくbitbucketに課題管理システムがあるのだから、活用するべきかもしれない。

少なくとも今のプロジェクト作ってからは一度も使っていない。

思い付いた案をここに書いておくだけでも、書かないよりましだとは思う。

しかし、そのうちどこに書いたのかとか、むしろ書いたこと自体忘れてしまうだろう。

そうなる前に、課題として投稿しておくべきだろうな。


2016/05/20 17:05

ゲームパッドの入力取得の構成を考えている。

古いプロジェクトで作ったやつをそのまま使えば楽なのでは、と思いもしたのだが。

前に作ったやつは、いい加減にもほどがあるような構成だった気がする、と思って検索してみた。

古いプロジェクト全てに対しfindでファイルを検索したところ、どうやらdp時代に作ったものが最後だったようだ。

それより後のプロジェクトでは、そこに辿り着く前に作り直してたんだな。

ファイル構成をぱっと見て記憶を探ったが、確かこんな感じだったはずだ。

・ゲームパッド接続管理(GamePadManager)で、ゲームパッドの接続、切断を検知

・接続、切断時には、ゲームパッドに結び付くデータ(GamePadKey)がイベントハンドラの引数として得られる

・GamePadKeyを引数に、ゲームパッド1つを表現するオブジェクト(GamePad)を生成することで、対応するゲームパッドの状態変化(ボタンを押した、離したなど)を検知できるようになる

GamePadがおかしい。

ゲームパッドは人の手で自由に接続したり切断したりできるのに、それをプログラムが任意に生成できるオブジェクトとして表現するのは違和感がある。

ゲームパッドが切断されているのにGamePadが存在し続けることができるし、逆にゲームパッドが接続されているのにGamePadが存在しないことにもできる。

そういう不自然な構成は、実際に利用しようとすると扱いにくく感じることが多いのだ。

そんなわけで、少なくとも物理的なゲームパッドに直接結び付く低レイヤー部分では、任意に生成可能なゲームパッドを表現するオブジェクトなんてのは用意しない方がいいだろうな。

GamePadManagerにゲームパッドの接続、切断検知以外に、ゲームパッドの状態変化についてもイベントを処理させる形がいいかもしれない。

GamePadManager周りについては、古いプロジェクトの処理を参考にしてもいいかもしれないな。

それと、GamePadはGamepadと記述することにしよう。


2016/05/19 21:10

描画イベントハンドラ内で、ゲーム固有データを参照できるようにした。

具体的には、描画イベントデータの中にベースシステムデータを追加した感じ。

描画イベントデータからベースシステムデータの参照を取得し、そこからゲーム固有データの参照を取得する。

これで、昨日の時点で問題になっていた部分は解決した。

2つ関数を呼ばないとゲーム固有データの参照を取得できないとか、なんかめんどうな気もするけど、どうにかするとしたら後でいいだろう。

取得できないよりはずっとましだ。

他に目についた問題点といえば、描画処理に関する点だ。

ウィンドウのサイズを変更すると再描画要求が発生し、再描画のために描画イベントハンドラが呼び出される。

イベントハンドラ内で動作確認用のログをstd::printf()で出力しているのだが、ウィンドウサイズをぐりぐりと変更した後、サイズ変更をやめても少しの間ログが出続ける。

垂直同期するような処理はまだ入れてないはずなのに、描画で処理遅延が出るというのは違和感あったので、調べてみたらどうも垂直同期が行なわれていたようだ。

これはなにか対処すべきか、と思ったけど普通に考えて描画イベント内で描画処理をしなければいいだけなんだよなぁ。

変にイベントをまとめたりしてもおかしなことになりそうだし。

一段落した感触がある。

次はどこを進めようかな。

ゲームとして最低限必要なもの、と考えた場合、操作系を作るべきか。

マウスやキーボード、そしてゲームパッド。

ゲームパッドをメインに据えたいところだけど、ゲームパッドは個体ごとの仕様がばらばらすぎて、うまく管理したいけどまだいい案がないんだよなぁ。

まぁ、管理部分については後回しでもいいだろう。

低レイヤーなものでも、ゲームパッドが扱えればゲームパッドを動かすと画面に変化が出る、ということができるようになる。

今後上に何か被せるとしても、そのまま使えそうな根底部分の処理を作っていこう。

入力ができたら、次は音かな。

画面への描画、プレイヤーの入力処理、音声出力。

この3つができれば、ゲームと呼んでいいものが作れるだろう。


2016/05/18 19:13

ゲーム固有のデータを扱えるようにした。

結局、ベースシステムデータに対し設定する関数を作り、それをゲーム初期化関数内から呼び出す形を取った。

設定ファイルに関数名を記述する形にしなかったのは、簡単に言えばそこまでする必要はないと思ったからだ。

ベースシステムデータの場合は、ベースシステムメイン関数を呼び出す前にゲーム初期化関数が呼び出され、その時点でベースシステムデータが必要になるため、ベースシステムメイン関数とは別に用意しておかなければならないという事情があった。

しかし今回の場合は、似たような形を取ったところでゲーム初期化関数に入った時点ですでにゲーム固有データが生成されている、初期化関数内では生成する処理を書かなくて済む、程度の恩恵しか得られない。

たかがその程度のことのために設定ファイルの要素を増やすこともないだろう。

プログラムに記述する形であれば記述ミスなんかはコンパイラがエラーにしてくれるけど、設定ファイルの場合はその辺も自分でどうにかする必要があるから面倒だし。

さて、まだ問題は解決していない。

というより、大きな修正が必要になりそうな別の問題が出てきた。

今日作った機能を使い、昨日作った表示プログラムを修正した。これ。

valgrindでメモリ解放漏れがないか確認したいが、OpenGLを使っているためかこけてしまう。

想定では解放漏れはないんだけど。

その点はともかく、描画イベント中にベースシステムデータを参照することができないという問題が新たに出てきた。

OpenGLコンテキストはベースシステムデータ内のゲーム固有データの中に持たせてあるため、素直にやろうとするとOpenGLによる描画ができないのだ。

なので、今はその場しのぎな処理で対応している。

ゲーム初期化時にゲーム固有データのポインタをグローバルに配置し、描画イベントでグローバルに配置したゲーム固有データのポインタを参照、OpenGLコンテキストを使用する、といった具合だ。

こんな見苦しいやり方は、解放漏れ並みに容認できないので早急に修正したい。

ぱっと思い付く解決法としては、ウィンドウ生成関数、つまりsucrose::newWindow()に引数としてベースシステムデータの参照を追加し、それをイベントハンドラに渡す、という方法だ。

あらゆる箇所でそんなことをすればベースシステムデータへの依存度がやばくなりそう、とは思うものの、そもそもベースシステムありきのシステムなのだから、むしろよく今までやらずにやってこれたもんだな、とも思う。

ソースの色々な場所に、std::printf()によるデバッグログ出力を記述しているが、これも将来的にはベースシステムデータの中にログ出力用データを配置して、それを使ってログ出力したいとも考えているし。

とりあえず、描画イベントの件については上に書いた通りの方法でやってみるか。

他の方法も思いつかないし、あったところでどうせ余計にトリッキーになるし。


2016/05/18 00:36

とりあえず表示プログラムできた。これ。

今のところソースファイルは1つだけ。これ。

ゲーム初期化処理でウィンドウイベントハンドラを生成し、それをベースシステムデータに設定してるだけ。

OpenGLコンテキストの生成もしてるが、ウィンドウ自体の生成はしていない。

構成としては想定通りだ。

しかし、現時点ではの話とはいえゲーム自体にデータを持たせられないのはやはり問題だった。

おかげで、OpenGLのコンテキストとかイベントハンドラの実体とか、そういうのはグローバルに置いてしまっていて、解放処理もしていない。

ゲーム固有データをベースシステムデータに設定する処理を早急に作るべきか。

どのように構成するべきかな。

作ってみた感触としてはゲーム固有データはほぼ必須になる気がするし、ベースシステムデータみたく設定ファイルにイニシャライザ、ファイナライザの関数名を記述する形にするか?

それで、ゲーム初期化処理の関数内に来た時にはすでにデータは生成されている、みたいな。

あるいは上に書いたように、ゲーム初期化関数内で、ベースシステムデータに設定する形にするか。

この場合設定するのは任意となる。

よく考えて構成を決めるべきポイントだろうな。

よく考えてみることにしよう。


2016/05/16 23:03

XInitThreads()の呼び出しとモジュール分割、両方完了。

それに、ベースシステムデータにデータを1つ追加した。

ウィンドウイベントハンドラだ。

設定関数も作った。

ゲーム側からベースシステムデータにウィンドウイベントハンドラを設定すれば、ゲームのメインウィンドウ生成時にそのイベントハンドラが使われる。

明日は今日作った機能を使って、ウィンドウに表示を行なうプログラムでも作ってみるか。

しかし現時点ではゲーム自体にはデータを持たせられないんだよなぁ。

やるべきことはたくさんある。

どこから手を出したものか。


2016/05/14 01:16

モジュールの初期処理、終了処理の対応ができた。

次は、この機能を使ってsucrose側でXInitThreads()の呼び出しを追加するとしよう。

モジュールの依存関係解決機能も使って、モジュール分割もするべきだろうな。

それらが済んだら、いよいよベースシステム側とゲーム側の通信についても取りかかるか。

いや、その前にまだやっておくべきことがあるか。

現状ではベースシステム側とゲーム側とではモジュールの管理が別々になっている。

そのため、両方で使われるモジュールがある場合、初期処理と終了処理が2回呼び出される可能性がある。

だから、モジュールを集中管理するための仕組みを追加するべきかもしれない。

とはいえ、現時点ではあまり初期処理や終了処理に頼らないため、まだ必要ないかも。

XInitThreads()も、2回くらい呼び出しても多分平気だし。

将来的には、多くのモジュールで初期処理と終了処理を使うことになるかもしれないけど。


2016/05/13 00:30

やる気出てる気がする。

というわけで、モジュールの依存関係解決をやっつけた。

今回の追加では、別パッケージのモジュールに依存するようなことはできない。

あくまで同パッケージ内のみ。

別パッケージのモジュールの指定方法をまだ決めてないから仕方がない。

でもまぁ、これでもある程度はやれるはずだ。

というわけで明日からは、初期化処理と終了処理の対応に入る。


2016/05/11 01:30

ゴールデンウィーク明けからやる気増してきた感ある。

イベントハンドラについて大体処理の追加ができて、あとは実際にイベントが発生した時にイベントハンドラを呼び出すくらいになった。

しかし、現在の仕様ではそろそろ限界な感じがある。

モジュールの初期化処理が存在しないため、XInitThreads()を呼び出せていないので、記述自体は合っていてもX11をマルチスレッドで扱おうとしてこけたりしている。

イベントハンドラが完了したら、モジュールの初期化処理と終了処理の対応を追加するべきか。

いや、それをするにはモジュールの依存関係解決をやってからか?

悩ましい。


2016/04/21 17:10

ベースシステム内で、OpenGLによる描画ができる、というところまで確認できた。

次は描画処理をゲーム側で処理させたいところだが、それには多少手間がかかるな。

流れとしては、ベースシステムデータにメインウィンドウに設定するイベントハンドラを用意し、ゲームの初期処理で描画イベント発生時の処理をイベントハンドラに追加、ベースシステムメイン関数でイベントハンドラを元にメインウィンドウを生成、となるんだろうけど。

まず、イベントハンドラとかを作っていない。

ウィンドウに関しても、イベントを全く処理していない。

なので、作ってしまうとしよう。

これらを作り終えたら、次はモジュールの依存関係の解決をやるか?

現状、ゲームとベースシステム、それぞれ1モジュールしか読み込めないし不便だ。

ベースシステムのライブラリに、ウィンドウの処理もOpenGLの処理も全て含めてしまっている状態だし。


2016/04/14 12:45

必要な処理はきちんと書かれていて、それ以外は書かれてなかったり手抜きだったりのいい感じのソースが書けた。

というわけで、ウィンドウを表示するベースシステムが一応はできた。

一応というだけあって、本当に表示するだけでそれ以外何もできないんだけど。

おまけに表示を維持するために無限ループを回しているため、起動しているとCPU1コアの使用率が100%になる。

しかしこれは大きな前進だ。ようやく表示まで漕ぎ着けた。

次はOpenGLに対応させたいところだ。

それができれば、ウィンドウ内に何かを書いて表示することができるし。

それに関しても、とりあえずはベースシステム内で完結させるか。

ゲーム側で描写処理をしたいところではあるが、それにはベースシステムとゲーム間のやりとりについて固めなくてはいけないので多少めんどうだし。

それがない状態で、とりあえずOpenGLが使えるようになるところまでを、先に確認するべきだろうな。

まぁ、OpenGLについても、基本は古いプロジェクトのソースを参考にすればどうにかなるはずだ。

ウィンドウと同じように、参考にした上で簡略化や省略をして、暫定的なものを小さくまとめて実装するとしよう。


2016/04/13 14:25

とりあえずウィンドウを作らんと始まらぬ、と古いプロジェクトのソースを見たがなんだこれは。

本当に私が書いたのか?とコミットログを見たところ、ウィンドウ周りのソースをいじっていたのは2年くらい前のようだ。

無駄に複雑になってるのはこの際無視するとしても、なんだか構成が頭悪い。

std::unique_ptrの扱いにまだ慣れてなかったのだろうか?

自前のデリータを作ればもっと分かりやすく書けそうな処理を見つけ、もやもやとした気分になった。

自前のデリータが使えることを知らなかったわけではなさそうだ。

ウィンドウの他のデータに関してはそれを使っているところもある。

やはり、昔の自分のソースは他人のソースなのだな。

わけがわからないよ。


2016/04/09 00:50

困ったな、どっから作り始めたものか。

やはりベースシステムメイン関数か?

データはどういう処理にするのかが決まらんことには構成しようもないし。

データに対する処理はベースシステムデータ構築時と、ゲームによる初期処理の2つあるが、それは後にするべきだろうな。

とりあえず表示に関する部分から始めるべきか。

ウィンドウ生成処理を古いプロジェクトから持ってきて構成するか。


2016/03/31 00:40

さくっとできそうだったから、ベースシステムメイン関数についての修正は昨日のうちに終わらせた。

で、今日はゲームの初期化処理についての修正をやった。

とりあえずこれを0.8.0とする予定だけど、テストで使用するモジュールとか、その辺もうちょい整えたいな。

明日それをやってから0.8.0としてpushし、先に進もう。


2016/03/29 21:25

もやもやが多少消えたからか、やる気出てきた気がする。

既存のゲームデータ生成、破棄処理をほぼそのまま引っ張ってきて、ベースシステムデータ生成、破棄処理を追加した。

次はベースシステムメイン関数の引数にベースシステムデータを参照を追加し、利用できるように修正しよう。

現状ではmain()でcandymaker::Basesystem内のベースシステムメイン関数を直接呼び出しているが、ベースシステム実行関数を別に作った方がいい気がする。

main()でベースシステムデータを直接参照するのはレイヤーが違うと思うし。

それが終わったらゲームの初期処理についてか。

こっちは、今の構成は破棄して新しい構成にするわけだから、まずは別のソースファイルに作った方がいいだろうな。


2016/03/29 00:50

さすがにモジュールの扱いを段階分けするのは完了している。

しかしモジュールの依存情報の解釈についてはまだ。

というより、色々考えてたらこれもう後回しでいい感じがしているので放置。

ゲーム生成処理をベースシステム関数内でやるとかいうのもありえんのでやらない。

それしたところで、大した違いもないだろう。

最近は、ゲームとベースシステムの構成が間違っているのではないかと考えている。

ゲームはベースシステムにアクセスする必要があるが、そのうまい方法を思いつかない、というのが現時点での大きな問題点だ。

色々考えた結果、ベースシステムがメイン関数のみの構成なのがいけないのだ。

ベースシステムは処理だけでなくデータも持つべきだ。

逆に、ゲームの方は初期処理だけでいい。

ゲームにデータなど必要ない。

そのように変更する場合、処理の大まかな流れは以下のようになる。

1.ベースシステムデータ生成

2.ゲームの初期処理

3.ベースシステム実行

4.ベースシステムデータ破棄

2は引数としてベースシステムデータの参照を受け取り、それに対して処理を行なう。

3はゲームが動作している段階で、4はゲーム終了後の後処理となる。

さて、どのように作業を進めたものか。

まずはベースシステムデータの生成、破棄を進めるべきか。

これ自体はただの処理追加なので、楽にできるだろう。

むしろそれを先にやっておかないと、他の変更はベースシステムデータの存在が前提なので作業を進めにくくなりそう。

ベースシステム関数の引数にベースシステムデータの参照を追加するのもそうだし、ゲームの初期処理についてもベースシステムデータの参照を引数として渡す。

それらが完了したら、ゲームからベースシステムにアクセスできるようになるわけだし、いい加減ゲームやベースシステムの方の作成に移ろう。

candymakerをいじくるのはうんざりしてきているのだ。

モチベーションが一向に上がらない原因はそこだと考えている。


2016/02/06 00:10

書こうとして、またも違和感。

設定ファイルに関係する処理が置かれているディレクトリの方にソースを配置すると言ったが、それもおかしい。

設定ファイルの解析処理に関係する処理なんて書かんのだから、そんなところに配置するのは不自然だ。

設定ファイルについては、解析結果を参照するだけだ。

ならば設定ファイルのソースが配置されているディレクトリと同列辺りに配置するのが筋だろう。

昨日は違うか、と言っていた方が正しいような気がしている。

やはり頭が茹で上がるとまともな思考にならん感じある。

多少時間がかかっても、深く考えを巡らせるべきだろうか。

そんな考えを認めてしまうと、考えるだけで無駄に時間が過ぎる気がするから、認めたくはないのだが。

ふと思いついて、linuxのインストールCDに含まれているメモリチェックツールを使ったところ、やはりメモリがもうだめな雰囲気だった。

gccがSEGVで死ぬのはおそらくそれが原因だろう。

むしろ、それ以外ではほぼ問題が起こっていない理由が分からない。

並列コンパイルとか高負荷の処理を流さん限り使わないような箇所がおかしくなっているのだろうか。

ともあれ、運が悪いとemergeがこけるというのがいい加減嫌になってきたし、原因がメモリであろうことも特定できたので、交換することにした。

今使ってるのは、安いからという理由だけでよく知らんメーカーのメモリを使っていたので、今回はトランセンドにする。

これまた比較的安い気がする、というのも決めた理由の一つだけど。


2016/02/04 23:50

どうにもうまくまとまらんと思ったら、モジュールの扱いが低レイヤーすぎるのがいけないんだろうな。

パッケージ情報ファイルに依存情報の追加はしたのだが、それをどう扱ったものか考えていた。

現在、モジュールのロードについては、モジュールのパスを引数にして行なっている。

依存情報を扱うなら、例えば依存情報も引数として渡し、そっちのロードを先にやる、という形になるだろうが、現状だとそれはまず無理だ。

モジュールのパスというのはつまり、設定ファイルの内容を解釈した後のものだ。

モジュールのロード処理中では、設定ファイルを解釈するような処理を行なっていない。

依存情報というのは設定ファイルレベルの情報なので、そんなものを渡したところで扱いようがないのだ。

ならばモジュールのパスではなく、設定ファイルレベルのモジュール名やら設定ファイルの内容やらを渡せばいいかもしれないが、それはしたくない。

少なくとも、最終的には現在存在するモジュールのロード処理とかは必要になるのだ。

それをわざわざ壊して複雑化させるなど間違っている。

というわけで、モジュールの扱いについて、現在作ってある処理を利用する、より設定ファイル寄りの処理を追加するべきなのだろう、という結論に達した。

結論に達するのが遅い気がする。やはりやる気が足りてない気がする。

間に土日を挟んだり、健康診断で血を抜かれたりしたからといって、もうちょい早くその結論を出せたはずだ。

それはともかく。ソースを見直したところ、現在あるモジュールを扱う処理だが、これはモジュールと言うよりローダーと言った方が正しい気がする。

この辺は将来的にモジュール化して、様々な形式のモジュールを扱えるようにしたい箇所だし。

だから名前を変えて、これから作る処理を新たなモジュールを扱う処理に…と思ったが、それもちょっと違うか。

これから作るのは、設定ファイルの内容を解釈したりといった処理が入るから、そこに置くべきではないな。

置くなら設定ファイルに関係する処理が置かれているディレクトリの方だ。

危ない危ない。全く、先が思いやられる。


2016/01/28 17:05

やはり想定が甘い。

モジュールの扱いのライブラリ化についてやるなら、暫定的、の部分をもっと細かく考えないと進められないな。

依存関係解決についても、きちんとやるならパッケージ設定ファイルとか必要になるし。

こちらも機能を限定した、暫定的なものから作っていくべきだろうな。

やはり依存関係解決から作っていこう。

パッケージ情報ファイルに依存情報を追加し、同一パッケージ内のみ対応、といった感じか?


2016/01/27 15:43

ベースシステムのメイン取得→ゲーム生成→ベースシステム実行という流れが違う気がしてきた。

ゲーム生成関数の引数に、ベースシステムで使用するデータを渡すということは、そのデータを生成する必要があるけど、そのデータ生成どうすんの、という話だ。

そこで考えたことには、ゲームの生成はベースシステムを実行してから、その中でやるべきか、ということ。

これなら、ゲーム生成関数に渡すデータはベースシステム関数内で生成できる。

しかし、ゲーム生成・破棄関数の取得までは定型処理だし、ベースシステム関数内でやるべきではないだろう。

でも、それで本当にいけるか?ゲーム生成関数のシンボル名はベースシステムに依存するわけだし、関数の取得もベースシステム関数内でないとできないのでは?

となると、モジュールのロードをしてからモジュールの参照をベースシステム関数に渡す?

ということは、モジュールの型や関係する関数はライブラリ化する必要がありそうだなぁ。

ライブラリ化については後回しにしたいところだが、それでできるだろうか?

そもそも現時点での実装では、モジュールの依存関係解決などやっていないのだ。

ライブラリだけ作ってもどうしようもない。

色々と問題点が浮かび上がってきたな。とりあえずまとめてみよう。

a.ゲーム生成処理の呼び出しをベースシステム関数内に移動

b.モジュールの扱いをライブラリ化

c.モジュールの依存関係解決

こんな感じ?

aを実現したいが、そのためにはbとcが必須。

bは実現したところでcがないと活用できない。

cは前提条件なし。

bかcから始めよう。

bはとりあえず暫定的なものでいいだろう。想定ではかなり簡単にできるはずだ。

問題はcか。前のプロジェクトで似たような処理は作ったはずだから、それを活用できれば早いか?

とりあえず現在の状態を0.6.0としてしまおう。


2016/01/26 01:25

ゲームの生成まではできた。

しかし、このままでは生成ができるだけで、ベースシステムとはなんの通信もできない。

どうするかなぁ。通信インターフェースを作るのまで含めるか、それともこの辺で、ソースを整えて0.6.0とするか。

ソースを整えるのはやるとしよう。

ベースシステムとゲームの通信はどうしよう。

ベースシステムのメイン取得→ゲーム生成→ベースシステム実行としているが、ベースシステム実行時に生成したゲームを引数として渡すか?

今の構想ではそれは向かないように思える。

ベースシステムからゲームに対してアクションをかけるということは、ゲーム側に決まった関数でも定義しておかなければ難しいだろう。

そして、ゲームにはできれば決まった関数というのは用意したくない。

ゲーム側の必須関数は生成と破棄だけにしたいのだ。

ゲーム側の生成関数の引数に、ベースシステムで使用するデータを渡し、そこにイベントハンドラを設定していく、という形になるだろうか。

この形なら、決まった関数はベースシステム側に作られ、それを介してベースシステム側からゲーム側を操作できるようになるはずだ。


2016/01/19 00:50

お腹きゅうきゅうする。

raspberrypiはそろそろもういいかなという感じ。

というよりやりすぎた感じ。

やりすぎちゃって、軽く燃え尽きちゃってる感じある。

このままではいかんと思い、candymakerのソース眺めたりなどしていた。

戻らねば。

やりすぎたかいもあり、なかなかのものができた、と思うんだけど、最新の修正を適用したものの動作確認がまだ。

1人では動作確認できないのが厳しいところだ。

理論的にやってできないことはないはずなのだが、なぜかうまくいかなくて困る。


2015/12/19 04:15

最近はraspberrypiをいじくりまくってた。

そのかいあって、常にxlink kaiを動かすraspberrypiがほぼできた。

私の作ったプログラムにより、raspberrypi側の無線LANアダプタを自分で操作しなくても、MACアドレスに対応したPSPのネットワークに自動接続できる。

また、起動時にメモリ上にSquashFSのrootfsを配置する形にした。

これにより、起動後はSDカードを取り外しても動作し続けることができる。

raspberrypiにSDカードは完全には差さらず、出っ張るためうっかり触って抜けてしまったり、カードやスロットなどが破損したりということが起きかねない。

それに、マウントした状態で取り外したり、電源コードを抜いたりすると、ファイルシステムが破損する可能性だってある。

実際、それでSDカードのファイルシステムの再構築が必要になったことが何度かある。

そもそもraspberrypiに電源スイッチなどないし、普通に終了するためには何らかの方法でログインし、shutdownコマンドを叩かなければならない。

それが電源コードを抜いて電源を落としても多分大丈夫になった、というのは大きい。

私の作ったプログラムはもう少し修正する必要がある。

周囲のアドホックネットワークの検索処理を実行する間隔が短すぎて、他の通信に悪影響が出てしまっている。

しかし、どうスリープしたものか。固定時間か、一定間隔毎に処理するように計算してスリープするか。


2015/11/29 00:20

昨日、いつにも増してやる気が出ん、だるいと思ったら微熱が出ていた。

それでも、なんとかパッケージ情報に記述したゲームについての情報を取り出す処理は追加できた。

月曜には、ゲームのロード処理をメイン関数に追加したいところ。

明日はraspberrypiをいじくるとしよう。


2015/11/27 00:27

ショートカットファイルからゲームの参照情報を取り出すのはできた。

まぁ、記述内容がベースシステムの参照情報とほぼ同じだから、処理をコピーして少し修正して作ったんだけど。

次はパッケージ情報にゲームについての情報を追加して、それを取り出す処理かな。

こっちも、ベースシステムの情報と大体似たような感じだから、処理をコピー、修正して作れば楽だろうな。

その取り出した情報を使ってゲームをロードし、ベースシステムの実行時に引数として渡す、というところまで明日中にできればいいんだが。


2015/11/25 19:51

というわけで、0.5.0できた。

ベースシステムの起動までできたところで0.5.0とした。

この次はゲームの生成、破棄とゲームの制御となるわけだが、どうするかちょっと考え中。

昨日の日記書いてた時には、ゲームの生成や破棄はベースシステム内でやろうかと考えたりしていたのだが、それはあまり望ましくない気がする。

ゲームの生成や破棄は、色々な実装方法が思い付くような処理ではない。

簡単に言えば、newとdeleteなわけだ。

ならば、わざわざベースシステム側にそれを任せることもない気がする。

そうすれば、ベースシステム側が設定ファイルを解析したり、モジュールをロードしたりする必要はなくなる。

どちらにせよ、まずはショートカットファイルからゲームについての情報を取り出す処理を追加するところからだろうか。

どこに記述したところで、その処理自体は変わらないだろうし。


2015/11/25 02:30

モジュールのロード、ロードしたモジュールからの関数取得も完了。

これを使ってベースシステムの起動をするわけだが、それにはダミーのベースシステムを作る方が先か。

中身空っぽでいいから、これはさっとできるだろうな。

次はどうするべきかな。

ベースシステムの実行の次、となるとゲームの起動だろうか。

それをするとなると、ベースシステムから設定ファイルを読んだりモジュールをロードしたりする必要があるだろうから、ライブラリを作る必要がありそうだなぁ。

3連休中、raspberrypiをいじくっていた。

とりあえずの成果として、比較的簡単にraspberrypi用のgentooのrootfsを生成できるようになった。

私は出来合いのカーネルとか使いたくないので、というよりカーネルの機能を増やしたい時とかに備えてカーネルは時前でビルドしたいので、その辺は自分でやる必要があるけど。

で、raspberrypi版のxlink kaiとかあったんで、xlink kaiを使うためだけのraspberrypiを作れないか画策中。

xlink kaiは昔windows版を使っていたことがあったが、PSPとパソコンをアドホックで接続するために、わざわざパソコン側で操作が必要になるのが面倒だった。

なので、その辺の操作を自動化してみたい。

しかし、アドホック接続についての情報がうまく見つからない。

特定のPSPを示す識別子みたいのってないのかな。


2015/11/17 00:15

とりあえずテストプログラムのビルドルールを分離させた、のだけど。

今のままでは、configure時にテストプログラムについてもビルドするよって指定しないとビルドしてくれない。

確か前は、そういう風になってしまうのを嫌ってテストプログラムのビルド処理を分けなかったんだった気がする。

実際面倒だし、テストプログラムが増えるたびにconfigureコマンドのオプション指定が増えることになる。さすがに嫌だ。

依存関係を定義できるようにするべきかもしれない。

このプログラムをビルドする場合、他のプログラムもビルドする、みたいな指定。

そういう仕組みを作れば、あるプログラムに関連するテストプログラムの自動的なビルドも可能になる。


2015/11/14 00:18

いかんいかん。典型的な三日坊主じゃないか。

微妙に詰まっている。

モジュールロード機能のテストコードを作ったので、そのテストを通そうとしたところで困った。

テストでモジュールをロードする必要があるので、そのためのダミーモジュールを作る、それはいい。

しかし、現状ではテストコードにライブラリやらなんやらを関連付けることができない。

なので、どう変えるべきか考え中。

よく考えたら、テストプログラムの在り方がおかしい気がする。

なんらかのプログラムに付随するものとしてるから、テストに対して他の何かを関連付けられないのだ。

最初からテストプログラムも独立したプログラムとして扱えば、こんなことにはならないはずだ。

不要にビルド処理を複雑にしてしまっている雰囲気がする。

改善しなければ。


2015/11/11 00:17

0.4.0できた。

パッケージ情報ファイルとショートカットファイルの内容から、取得できる範囲の情報を取得、表示するところまでやって0.4.0とした。

取得した情報を使えばベースシステムの起動までできるはずだが、そのためには起動するベースシステムも中身からっぽでいいから作らないといかん。

ベースシステムの起動まで作ったら、次はどうしようか。

ベースシステムの中身を詰めていくべきかな。

パッケージ設定ファイルの処理とかもないわけではないけど、これ以上同じような作業はきついものがある。

それに前にも書いた通り、パッケージ設定ファイルは今のところ無くても問題ないのだ。

これ以上モチベーションを落としたくないし。


2015/11/10 02:03

やはりそう簡単にはやる気は戻らんらしい。

リファクタリングしたり、パッケージ情報ファイルを解析したデータからデータを取得する関数を追加したりしてたら、今日中に0.4.0を作りきれなかった。

でもまぁ、パッケージ情報ファイルから名前に対応したベースシステム情報を取得する関数の処理を実装したら、あとはメインの処理を追加して、デバッグ出力を追加すれば完成だろうか。

道筋は見えているので、起きたらさくさくっと完成させたい。


2015/11/09 00:38

前回から1ヶ月程度か。結構さぼってしまった。

作業はしてたんだけど、やはり牛歩。

やる気が出なかったのは、退屈な作業というか、前のバージョンで追加したのと同じような作業をやることになったからだろうな。

前はショートカットファイルの解析で、今回はパッケージ情報ファイルの解析。

必要なことではあるのだが、なんとも退屈な作業だった。

パッケージ情報ファイルの解析処理はなんとかできたので、それを使って得られた情報を出力して、それを0.4.0とすることにしよう。

明日にはパパッと作ってしまって、さっさと次に進みたいところ。

ベースシステムの情報は取得できるようになったわけだし、次はいよいよベースシステムの起動に入れるか。


2015/10/03 00:00

機能を実装したと仮定した処理を記述していっているのだが、つまずいている。

パッケージ情報ファイルを読み込む、これはいい。

読み込んだパッケージ情報ファイルからベースシステムの情報を取り出す、これもいい。

この次がしっくりこない。

手順としては、まずモジュールをロードするんだろうけど。

モジュールをロードして、ロードしたモジュールからベースシステムの関数を取り出し、取り出した関数を実行する。

急に処理のレイヤーが低くなるから違和感を覚えるのかしら。

ベースシステムの情報を取り出すのではなく、パッケージ情報ファイルの内容とベースシステム名を引数にベースシステムを実行する、の方がいいのかなぁ。

だったら、パッケージのパスとベースシステム名を引数にベースシステムを実行する、の方がよりいいかもしれない。

後のことを考慮すればもっとまとまるだろうか?

パッケージ設定ファイルを読むようにした場合だ。

パッケージ設定ファイルを読み、使用するパッケージのパッケージ情報ファイルを読み、使用するモジュールを列挙、ロードし、ベースシステムを含むモジュールからベースシステムの関数を取り出し、実行。

関数をどう、とかなると低レイヤーすぎるから、ベースシステムの実行として1つの処理にまとめるべきだろうな。

可変長の引数を取り、それを共有ライブラリから取り出した関数ポインタの引数に渡して呼び出す、みたいなことできればいいんだけどそんな簡単にできるだろうか。


2015/10/01 18:40

0.3.0できた。

設定ファイル要素の集合体からショートカットファイルを表す構造体を生成する処理を追加した。

こういう構成の設定ファイルがショートカットファイル、というのを定めたことになる。

とはいえ、ベースシステム実行に必要な要素だけが記述された、暫定的なものだけど。

具体的には、ベースシステムが含まれるパッケージのパスと、ベースシステム名、この2つ。

この2つの情報が記載されたファイルをショートカットファイルとする。

次は、その2つの情報を使い、ベースシステムを実行する処理を作ろう。

それを0.4.0とする。


2015/09/26 00:55

昨日、方針を固めたのはいいのだが。

実際に作業を進めようとしたものの、なんだかやりにくい。

どうにも、処理が不完全な感じがある。

ショートカットファイルの読み込み、解析を行なっているものの、最終的に生成しているのがショートカットファイルを表す構造体でないのが分かりにくい原因か。

現状、設定ファイル要素の集合体としてしか扱っていない。

データを取り出すにも、例えばマップにキーに対応するデータが存在するか、とかから始めないといけない。

ショートカットファイルとして正しいのかどうかのチェックを行なっていないから、そのようなめんどうなことになるのだ。

設定ファイルとして文法が正しいか、の次にショートカットファイルとして正しい構成になっているか、のチェックが必要だ。

そうすれば、データを取り出す際にいちいちデータの存在チェックとかやらんで済む。

どうしよう、それを0.3.0として作るか?

機能として完全に分離させた方がよさそうだし、そうするかなぁ。


2015/09/24 23:55

考えて考えて、ようやく方針が固まった。

次は、ベースシステムを実行する処理を作る。

ベースシステムとゲームの構成についても変更する。

前のプロジェクトでは、ベースシステムは生成・破棄するもの、ゲームは実行するものという扱いだったが、これは逆にする。

ベースシステムは実行するもの、ゲームは生成・破棄するもの。

ゲームは完全に動作を制御したいのだ。

だから実行する、つまり制御を完全に移す形にするのは適切ではない。

ベースシステムは制御できる形にしたところで、じゃあそれを誰が制御するんだよって話になる。

起動プログラム?そんなめんどうなことはさせたくない。

よって制御を完全に移す形にする。

というわけでベースシステムのライブラリをロード、関数を取り出し呼び出す、ということをすることになるが、まずはできるだけ規模を小さくする。

ライブラリを扱うということはパッケージを扱うことになるのだが、本来想定している処理の流れは以下の通りだ。

・パッケージ設定ファイルを読み込み、利用するパッケージ、モジュールを特定

・利用するパッケージのパッケージ情報ファイルを読み込み、ベースシステム実行関数が含まれるモジュールや、モジュールの実体(ファイル名)などを把握

・利用するモジュールを全てロード、ベースシステム実行関数が含まれるモジュールから関数を取り出し呼び出す

こんな感じだが、まずは最初のパッケージ設定ファイルの読み込みを行なわないことにする。

単にモジュールを読み込んで関数を取り出し呼び出すだけなら、パッケージ情報ファイルを読めばできるのだ。

パッケージ設定ファイルは、モジュールの利用する・しないの判断や、依存パッケージの指定、パッケージとセーブデータの関連付け、パッケージやモジュールへのパラメータの設定などなど、より高度なことを行うために必要となるが、最低限の動作では必要ない。

よって、0.3.0ではパッケージ情報ファイルを読み込み、ベースシステムを実行するところまで作る。

パッケージ設定ファイルを使う前提で考えていたから、どう進めるべきか決まらなかった感じがある。

もし無理矢理その方向で進めていたら、またしても泥沼の展開だっただろうな。

こんなに長く考えたのだから、それを避けられればいいのだが。


2015/09/24 12:40

連休を利用して、マシンの環境を構築し直していた。

今までは、64bitと32bitの環境を完全に分けて構築していた。

64bit環境で32bitプログラムを動かすために、エミュレーションライブラリを使う必要があるのを嫌ったためだ。

しかしながら、今年の3月頃だったか、エミュレーションライブラリの使用は非推奨になった。

64bit環境で32bitプログラムを動かすために必要となるライブラリも、ソースからビルドできるようになったからだ。

わざわざ環境を作り直すのはめんどうなのでやってこなかったが、2つの環境を扱うのも色々めんどうがある。

例えばパッケージの更新は2環境にそれぞれ実行しなければならないし、設定ファイルなんかも2箇所に置くことになるし、そもそも2環境作ると容量結構取るし。

そんなわけで環境を作り直した。

今のところ、問題なく動いているようだ。

skypeなんかは、前は32bit環境で動かしていたため、32bit環境に移行→skype起動、などとするスクリプトとか用意してたんだけど、そんな必要もなくなった。

32bit環境に移行する必要がなくなったからか、前より起動が速くなった気がする。

後は、raidをマシンの外に出したいけれど、これをやるとなるとまためんどうそうだなぁ。

封印してある玄箱T4を使おうと思っているが、これを普通に使おうとすると、4つ入るハードディスクのうち、どれか1つの中に環境を構築しないといけないとかいう残念なやつだし。

それを避けるには、外部に環境を作りNFSでマウントして使う、とかしないといけないんだけど、これまためんどい。

ちょうど使ってないraspberrypiもあることだし、それを使おうと考えているが、結局そっちの環境構築も必要になるわけだし。

やるなら次の土日だろうけど、土日で完了できるだろうか。

いや、まず無理だな。できてraspberrypiの環境構築くらいなものだろう。

ちなみに環境というのはどれもGentooだ。Gentoo Linux。

柔軟で扱いやすくていい。

しかし、パッケージをソースからビルドする形なので時間がかかりがちなのが難点。


2015/09/16 23:50

昨日のうちに、0.2.0は完成した。

のだが、次はどうするべきか決めかねている。

ベースシステム情報が得られているのだから、ベースシステムの構築・起動をするべきだろうか。

しかし、ベースシステムとゲームをどう連携させるかまだ決まってないしなぁ。

最低限決まっているのはベースシステムを起動した後にゲームを起動させるという順番くらいなものだろうか。

とりあえずをそれをやってしまうべきか?

中身はほぼ空でも。

しかし、それはまた行き当たりばったりな感じがするし。

もうちょい考えをまとめるべきだろうなぁ。

ゲームはどこでロードするのか?

今作っている起動プログラムか?もしくはベースシステム内の処理か?

前者の場合、ゲームをロードする必要がある時には起動プログラム側に制御を戻さなければならなくて、なんだか奇妙だ。

後者の場合、起動プログラムからベースシステムをロードして動かし、ベースシステムからゲームをロードして動かす、という流れになって、見た目きれいな感じがする。

しかしながら、ゲームのロードには設定ファイルの読み込みが必要になるものの、そもそもベースシステムからして設定ファイルの読み込みを行なった上でロードするのだ。

設定ファイルの読み込み処理は、普通に考えたら起動プログラム部分に配置することになる。

それをどうやってベースシステムから呼び出すのか?

案はないわけではないが。

モジュールの設定という概念を追加して対応する、というのが今考えている案。

それにより起動プログラム内の関数名を指定し、モジュールロード時に関数を取得、という感じだ。

そんな関数が用意されているかは謎だ。

うーん、設定ファイル形式の解析処理はできているわけだから、解析を行なった次の段階、設定ファイルを読み込みデータを取得するための関数を実装すべきだろうか。

だとして、その目的はどうするべきか?

これまでは、それぞれファイルの内容を出力するためにファイル読み込み処理を追加したし、読み込んだファイルから意味あるデータを取得するために解析処理を追加した。

目的を持たない機能追加はその実用性に疑問が残る。

次にやる事を考えれば、ベースシステムの構築なわけで、つまりモジュールのロードや、ロードしたモジュールからの関数取得か。

それらの処理を行なうための入力データとして、ファイルから読み込んだデータを構造体にまとめる、という感じになるか。

ということで、目的はベースシステムの構築、もといベースシステムの生成・破棄関数の呼び出しか。

それに付随して、モジュールのロードや、設定ファイルの形式を定めていったりする必要がある。

まずは、すごい簡単なベースシステム生成・破棄関数を持ったライブラリを作るところから始めるべきか?

その辺ができてこないと、設定ファイルにどう記述していいか分からないしなぁ。


2015/09/15 01:55

ちょっと不調。データ取得関数を一通り追加したところまで。

多分、これで設定ファイルに関する関数は一通りできたはず。

あとはこれらを使ってメイン処理を組み立てる。

明日には0.2.0を仕上げたい。


2015/09/11 18:40

マップ要素まで完了した。

後は、解析したデータからのデータ取得関数とか追加しながらメイン処理を組み立てて、0.2.0の完成といったところか。

次はどうするべきか。

設定ファイルからベースシステムについての情報とゲームについての情報を得られるわけだから、ベースシステムの生成だろうか。

ベースシステムはどこで作ろうか。

暫定的なものはcandymakerで作ってしまおうか。

それが、とりあえずはコンパクトでいい気もする。


2015/09/11 02:05

リスト要素はできたが、マップ要素はまだ。

来週には持ち越したくないなぁ。

明日中にマップ要素を完成させて、来週からは作った処理を使って読み込んだショートカットファイルの内容を解析したいところ。


2015/09/09 23:40

リスト要素の解析は完成には至らなかった。

しかしもう少しだ。

残件は複数の要素を含むリストの場合の処理。

要素が単一の場合については完了している。

なので、30分、あるいは1時間もあれば十分できるんじゃないかな。

ソースファイルを要素毎に分けたりしたので、作り切れなかったんだろうか。

ならば、明日中にリスト要素の完成に加えて、マップ要素も完成させてしまいたいところだが。

マップ要素の処理はリスト要素と似ているので、案外早く片付きそうな気がする。


2015/09/08 22:15

設定ファイルの文字列要素の解析処理はできた。

想定よりも時間がかかってしまった感じがある。

しかし、これから追加する予定のリスト、マップ要素でも共通して利用することになる処理も含んでいるので、案外こんなものかもしれない。

明日はリスト要素の対応。

ちゃっちゃと片付けてしまいところだが、現状の文字列要素の処理を別ファイルに分離したりとかそういう作業が必要になってくるので、意外と面倒かも。

今回作った文字列要素解析処理のソースはおよそ300行。

全てが文字列要素についての処理というわけではなく、要素共通の処理も含まれているが。

それに比べて、前回のプロジェクトで作ったソースは文字列要素についてのファイルがおよそ150行、要素共通のファイルがおよそ550行。

前回のプロジェクトの要素共通のファイルでかすぎない?と思って中を見てみたら、デバッグ出力に結構行数使ってた。

そういや前回のは、動作確認のために読み込んだデータの内容を1つ1つ出力してたな。

今回はその辺のチェックがテストコードで済むので、こんなでかいデバッグ出力処理はいらないだろう。


2015/09/08 00:05

というわけで、テストファーストで作るのを試している。

前に作ったソースを流用する予定だったけど、テスト駆動開発の練習も兼ねてほぼ1から作っている。

最初にごく単純な処理を実装するために、まずテストを書く。

アサートを先に書き、そのアサートに至るための処理を書いてテストコードとする。

次にそれを失敗するコードを書き、そのテストコードがテストで実行されることを確認する。

次に、テストを通すことだけを目的とした、固定値を返すような不完全な仮実装を行ない、テストが通ることを確認する。

仮実装では不完全ということを示すために、別の入力を行なった場合のテストを書く。

本実装をして、両方のテストが通ることを確認し、完了。

最後の方はなんか違うような気がするけど。

確か、テストは1つで、不完全な仮実装でテストを通し、後はテストが通ることで処理が正しいことを確認する、みたいな感じだったような。

テストを2つ書くのは三点測量とかいう、なんか不安な時にやる方法とかだったような。

でもこっちの方がより納得できるんだよなぁ。

仮実装でもテストが通るというのが気に食わない。

で、仕様を追加する場合も同じ手順で進めていく。

その結果、前に書いた時とは処理方法が変わった。

まだ前に書いた機能には達していないので変わりそう、が正しいが。

単純、コンパクトな実装でテストを通すようにしているためか、前に書いたのより見やすく、分かりやすくなっている気がする。

前はテストとか書いてなかったから、処理ありきで書いていたため、頭の中にある処理をそのまま書き出していたからごちゃごちゃしていた。

今回はテスト、つまり結果が先に来て、その結果にするためにどうするか、という考え方に加えて、機能を細かく1つずつ実装していっているので、ごちゃごちゃしてない感じがある。

これなら、機能を増やしていっても見やすい、分かりやすいコードが書けそうだ。

初日ということもあってかあまり進んでいないが、大体分かってきたので明日からはもっと進められればいいのだが。


2015/09/06 01:25

CppUnit?知らない子ですね。

Google Testに切り替えた。

他にもBoost.Testとかあったらしい。

完全に調査不足である。

Google Testに決めたのは、出力に色が付くのでテストの成否が一目で分かるというのが一番の理由。

その結果、CppUnitをより扱いやすくするために書いたコードは全て不要になった。

悲しい。

元々、CppUnitはJUnitをC++用に書き直したようなものだからか、クラスありきな書き方が気に入らなかった。

Google Testなら、クラスを作らずにテストを書けるし、必要に応じてクラスを使ったテストも書くことができていい感じっぽい。


2015/09/05 13:15

昨日は久々に朝方まで作業してしまった。

その甲斐もあって、CppUnitを利用した自動テスト実行環境は大体整った感ある。

wafの自動テストサポートも使い、ビルド成功時にテストプログラムが自動的に実行されて、テストが通ったか通らんかったか表示されるようにした。

ただ、テストの通った通らないはテストプログラム単位なので、テストが通らなかった時にどのテストが通らなかったのかは表示されない。

なので、その場合は自分でテストプログラムを実行してどのテストが通らなかったのか確認する必要がある。

そこが少し面倒だが、かといって全テストの出力を表示すると量が多すぎるか。

テストコードのファイル数が増えれば増えるほど、テスト対象コードの全く同じコンパイル処理の回数が増えると思われる。

ビルド時間の増大が懸念されるが、全く同じということはコンパイルキャッシュなるものを使えば時間短縮できるんだろうか。

もうちょい整えたらテストファーストで作業を開始するつもりだけど、それは月曜からにしようかなぁ。


2015/09/04 02:45

タグとか初めて使った。

使い方これでいいのかよく分からんけど。

とりあえずリポジトリを作っておいた。

読んだファイルの内容を処理するところまでやろうかとも思ったけど、とりあえずファイルを読み込んでその内容を出力するだけ。

それでバージョン0.1.0ということにした。

次は読んだ内容を処理し、データを抽出して出力する。

それを0.2.0ということにしよう。

基本的には、処理内容は今までに作ったやつから持ってくればいいと思う。

でも今回は、自動テストを作ってから作る、テストファーストというやつをやってみよう。

そのためにCppUnitをインストールしたのだ。


2015/09/02 22:45

超久しぶり。

正直詰まってる感じある。

思うに、やはり行き当たりばったりすぎるのだろう。

筋道が立たずにところどころ肥大化しつつあるような、どうしようもない進め方になってしまっている。

こんなことしても進んで戻ってを繰り返すことになりそうでさすがに躊躇しているのだが、1から作り直すべきかもしれない。

一体何回目になるのだ。4回?5回?

経験はどんどん蓄積されているわけなのだから、それをうまく利用できればいいのだけれど。

まずは単純なものを作らなくては。いつもここが抜けている気がする。

色々考えた結果、とりあえずベースファイルとかいらん。

環境に1つの設定ファイルなんぞ見るとかそんなんもっと後でいい。今はいらん。

コマンドライン引数から設定ファイルのパスを受け取り、そのファイルの内容を処理する。これだ。

いっそそのファイルのパスも固定してしまえばもっと単純になるかもしれないが、さすがに実用性がなさすぎる気がする。

ここまで書いといて今更だが、作ろうとしてるプログラムの大まかな流れは、

・ベースシステムという機能集合体を生成

・ベースシステムを利用して動作するゲームをロード

・ゲームを動かす

という感じになる。

前述のコマンドライン引数で渡す設定ファイルのパスというのは、ゲームについての情報が書かれているファイルだ。

現状では、ベースシステムについての情報は何一つ書かれていない。

これまでの想定としては、ベースシステムについての情報は環境に1つの設定ファイルに記述しておく形だった。

しかしよく考えると、それだと使用するベースシステムが固定的になりすぎる気がする。

別のベースシステムの上でゲームを動かしたいなーとかなった時に面倒だ。

なので、コマンドライン引数で渡す設定ファイルの中に、ベースシステムについての情報も書いておくべきかななどと思った。

そもそもコマンドライン引数で渡す設定ファイルはショートカットファイルという名前だ。

それ1つ読めば、とりあえずゲームが起動するところまでできるべきファイルなのだ。

ならば、ショートカットファイルにはベースシステムの情報とゲームの情報、どちらも記述するべきだろう。

後々既定のベースシステムとか作る場合には、ベースシステムの情報の記述は必須ではないとかにすればよかろう。

そこからまた展開させようとすると、どんどん肥大化していく悪寒がする。

なのでとりあえず決まったそこまで作ろう。

まずコマンドライン引数でショートカットファイルパスを受け取る。

次にそのファイルを読む。

最後に読んだ内容を出力する。

これだ。これで行こう。

ここまで作ったらまた書く。


2015/03/02 20:49

パッケージ設定に対応するパッケージ情報と、依存パッケージ設定の読み込み処理まで作った。

次は、その読み込んだ設定ファイル群からベースシステム情報を取得する処理と、その構築に必要なモジュール群の列挙処理か。

それを終えて初めてモジュールマネージャに取りかかれるな。


2015/02/25 16:02

設定ファイル、JSONじゃない方がいいかもしれない。

思いの他扱いやすいし見づらくもないので大体問題はないんだけど、JSONの仕様には存在しない要素がほしい。

具体的に言うと集合がほしい。

現時点では、やろうとするとリストとして記述し、JSONを読み込んでデータを取り出した後に、重複するデータは削除するなどすればできるけど、なんだか回りくどい。

JSONを読み込んだ時点で、重複するデータは削除するようにしてしまいたいところ。

[]はリストで、{}はオブジェクトだから、適当なところで()だろうか。

pythonと同じような感じになりそうだな。

ただこれをやるとなると、JSONの比較処理も追加しなければならないな。

JSON読み込み処理は現時点ではかなり限定的でJSONとは呼び難いのだけど、この機能を追加するとJSONの定義から完全に外れることになる。

だからどうだということも、特にないが。


2015/02/25 13:01

設定ディレクトリ内にあるコンフィグディレクトリってなんだろうな。

パッケージのモジュールの使用許可やセーブデータディレクトリとの関連付けなどを記述した設定ファイルなんだけど、パッケージ設定とは呼びにくい。

パッケージディレクトリに配置されている各パッケージ内にも設定ファイルが存在するからだ。

現時点では、後者を読み込む時にPackageConfigという構造体にデータをつっこんでいる。

しかし、このファイルは基本的にユーザーが変更することはないため、設定というよりは情報が記述されているだけのファイル、と考えるべきかもしれない。

そう考えると、PackageConfigではなくPackageInfo、パッケージ情報ファイルと呼ぶべきかもしれない。

そうすれば、モジュールの使用許可などを記述したファイルのことをパッケージ設定ファイルと呼べるし。

今まで脳内ではコンフィグ設定ファイルとか呼んでいたが、コンフィグと設定って同じ意味だし、構造体にしようとするとConfigConfigになっちゃうしで困っていたが、これでどうにかなりそうだ。

前の記事に書いた作業については昨日のうちに終わらせておいた。


2015/02/23 23:31

思うに、ソースコードが読みにくい。

情報を表すデータと、情報を参照するための情報を表すデータがほぼ同じ名前で定義されているため分かりにくい。

前者をXXとしたら、後者はXXRefという感じに命名するようにしようかなぁ。

デバッグ出力も、後者もXXとほぼ同じ出力になっちゃってるから分かりにくいし。

モジュールマネージャに取りかかる前に、まずはそこらのリファクタリングからだな。


2015/02/23 19:29

牛歩、牛歩。

ようやくモジュールマネージャに取りかかれそう。

パッケージ設定ファイルからベースシステムの設定を取得するところまではできたので、ベースシステムを生成するために生成関数と破棄関数の取得を行なわねばならない。

関数の取得の前にはモジュールのロードを行なわなければならないし、つまりいよいよモジュールマネージャというわけである。

基本データ型の定義を変えるべきかもしれない。

現時点では、typedefを使ってintをfg::Intと定義したりしてるのだけど、モジュールがエクスポートするシンボルのことを考慮すると、これはあまりよくない気がする。

fg::Intはシンボルとしてはintと同じように扱われてしまう。

これはあまり都合がよくない。

fg::Intはfg::Intとして扱われていた方が都合がいいのだ。

主に、シンボル名のマングリングとかそこらの処理のために。

それをやるためには、fg::Intをtypedefではなくクラスとして定義すればいいのだろうけど、ソースコード上での扱いは今までのから変更したくはない。

演算子のオーバーロードを駆使することで達成できるのかなぁ。不安だ。


2015/02/10 22:35

このところ、raspberrypiをいじくっていた。ちょうど日記が途切れた辺りから。

raspbmcをつっこんでみたり、openelecをつっこんでみたり。

raspberrypiでradiko使ってラジオが聴けるようになったり、インターネットラジオ聴けるようになったり、youtube見れるようになったり、天気予報確認できるようになったりなど。

テレビにHDMIでつなげばテレビのリモコンで操作できるようになったりしておもしろい。

で、bindとdhcpを動かしてるraspberrypiにこれらの機能をつっこめないか、と思って色々試していたのだが、結局今動いているようなgentooにxbmcをインストールするのが一番手っ取り早そう、という結論に達した。

raspbmcはなぜか無線LANがうまくつながらんし、openelecはbindとdhcpを追加するのがかなりめんどそうだし。

しかしながら、gentooをまた構築するのもそれはそれでめんどうだったり。

いい加減dropmakerの方進めたくなってきたし、休みの日とかに気が向いたらちょっとずつ進めてみようかと。

って明日祝日?明日はやらん。どうもraspberrypiに関わると頭が痛くなりやすい気がする。


2015/02/04 00:12

モチベーションが下がっているが、ちょっとずつ進んでいる。

パッケージ設定ファイルも、大部分は処理できている。

例によって、暫定的な実装であるため穴だらけだが、そのうちなんとかする予定。


2015/01/29 21:11

進みが遅くなっている。

パス型の扱いを少し変えたり、パッケージ設定を読み込む際の処理で、今まで書いた処理を共通関数化して使えるようにしてから処理したりなど。

パッケージ設定ファイルを見てて思ったのは、これまた割と適当に決めた感じがあるなぁということ。

でもまぁ、とりあえず全部読み込んで型に落とし込む。

そうしないと始まらん。


2015/01/28 00:28

パス型を文字列に変換する暫定的な処理ができた。

しかし、本当に暫定的だ。

機能も少ない。循環参照エラーの検出ができないため、設定ファイルでまずい記述をすると無限ループが発生する可能性もある。

その辺の問題は後々解決していくとしよう。めんどいので。

とりあえずパス型を文字列に変換し、ファイルを読み込むところまではできたが、読み込んだものの処理はまだ実装していない。

その辺は明日やる。


2015/01/26 19:49

パッケージ設定の読み込み処理を作っているところ。

ファイルをJSONとして読み込む処理とかは、ベース設定の読み込みでも使っているので使い回せるが、パスの扱いは今回が初になるため、そこで少し手間取っている。

具体的にはパス型を文字列型に変換し、ファイルオープンなどに使えるようにする処理なのだが、今回作成するものは限定的な機能を持ったものでいいだろう。

とにかく、パッケージ設定のパスを文字列にできればいいのだ。そのために全機能は必要ない。

後々きちんと全機能作らなければならないだろうけど、今それをやると間違いなくだれる。

今回作らない機能についても、大体どのように実装すればいいのかはイメージできているので多分大丈夫。多分。


2015/01/23 21:06

ひとまず、ベースシステム生成、破棄関数取得までの流れは作った。

ベースシステムの生成、破棄に関わるモジュール群生成までの流れも作ってしまいたいところだったが、これにはモジュールローダの設計が大きく関わってくる。

そして、今のところモジュールローダは中身が空っぽの状態だ。

よってまだ書けない。書くのはモジュールローダの設計をまとめて、というかモジュールローダを作ってからだな。

やはり今週中は無理だったな。来週中ならいけるかしら。

来週の作業手順は、とりあえず流れを作ってあるベースシステム生成、破棄関数取得までの部分の実装を作るところからだろう。

それを終えたら、モジュールローダを作るのとベースシステムの生成、破棄に関わるモジュール群生成を並行して行なう感じだろうか。

大体後者が主導になると思うが。部品を先に作ってしまって、実際に使う場面でやっぱりびみょう、使い物にならんとかなったら目も当てられん。


2015/01/23 14:00

というわけで、サイトをgithub pagesに移行した。

何日か前に書いたような気がしたけど書いてなかったので、経緯を書いておこう。

gaeのツールが動かんくなった。

どうもpythonのバージョンとうまく噛み合っていないらしく、バグ報告も上がっているようだけどツールのバージョンアップが来ない。

現状やってることと言えば静的ページの公開だけだし、記事書いた後にコミットとは別にアップロードコマンド打つのもめんどうなので、github pagesに移行した。

github pagesなら独自ドメイン使用時にサブドメイン付けなくていいし、サブドメインからリダイレクトさせることもできるので、URLをtekuto.netにできていい感じ。

今までのwww.tekuto.netにアクセスすれば、tekuto.netにリダイレクトしてくれる。


2015/01/23 00:15

今週中に終わらせられれば、とか昨日書いたけど早速今日、諸事情により作業できなかった。

明日から本気出す。

でもさすがに明日1日で終わらせるのは無理だろうなぁ。


2015/01/21 18:10

ベース設定ファイルからベースシステムとシェルについての情報を読み込む処理を書いた。

Baroqueのサントラ流しながら作業すると集中できていいな。

歌が入ってるタイプの曲は、作業中の私にはあまり向かないようだ。

気が散りやすいというか、ヘッドホンで聞きながら作業すると頭痛くなったりする。

さて、ベース設定ファイルに記述する内容はひとまず全て読み込む処理を書いたので、次はそれを元にベースシステムを生成するための情報を生成する処理か。

まずはどこからだろうか。ベースシステム情報に記述してある、パスに対応した設定ファイルを読み込む処理からかな。

その設定ファイルには、対応するパッケージについて、そのパッケージのパスや、対応するセーブデータのパス、使用を許可するモジュールのリストなどが含まれている。

ので、その設定ファイルを読んだら次はパッケージの設定ファイルを読み込んで、とかそういう流れになるんだろうな。

なかなか負荷の高そうな内容だ。今週中に終わらせられればいいのだが。


2015/01/21 16:00

パス型の定義変更に対応完了。

昨日に済ませておきたかったところだけど、ちょうどその直前できりがよかったため、昨日の作業はそこで切り上げてしまった。

で、今日その辺をさくっと終わらせた。

次はベースシステムやシェルについての情報をベース設定ファイルから読み込む処理と、ベース設定ファイルの情報を元に、色々設定ファイルとか読み込んで、ベースシステム生成に必要な情報を構築する処理かな。

ベースシステムについての情報が記述されてるんならそれでいいじゃないかと思うかもしれないが、記述されているのは設定ファイルのパスとベースシステム名だけなので、具体的にどのモジュールをロードし、なんて関数を呼び出して生成し、破棄するか、といった情報は他の設定ファイルを読まないと分からない。

なので、その辺どうにかする処理を書く、といった感じだ。


2015/01/20 14:38

やはりきちんと毎日書かんとだめだな。すっかり習慣がなくなってる。

昨日の作業としては、設定ファイルの記述を修正したり、パス型の読み込み処理を独立させたりなど。

パス型の定義を変えてあるため、現時点の処理では対応できないので、使う場面になったら修正することになるだろう。

今日はベースシステム構築のためにコンフィグマネージャから情報を取得する処理とか書くつもりなので、前述の修正はやることになるかも。


2015/01/17 00:38

できるだけ忘れずに書いていくことにする。

早速忘れかけていた上に、ツールがちゃんと動作するようになるまでネット上に上げられんけども。

さて、結局設定ファイルの扱いについては、いっそのこと全ての設定ファイルを1箇所で管理した方が分かりやすいのでは、ということで話が進んでいる。

設定ファイル間で関連性があるものも結構あるわけだし、管理オブジェクトに対し、情報を要求すれば必要に応じて設定ファイルを読み込んで情報を生成して返す、みたいな。

一度読み込んだ設定ファイルはキャッシュしておいたり、もし要求があればキャッシュを削除したりなども考えているけど、前者はともかく後者は後回しだろうな。

いや、前者も別に必須ではないな。

もやもやは晴れつつあるし、ペース上げていきたいところだが。


2015/01/15 20:42

過去ログは年単位で分ければいいのでは、という声が一部でささやかれている。

進みはスローペース。もっとさくさくやりたいところだが。

ベース設定の一部を読み取る処理はできた。

一部というのはパスの別名定義。パスに名前を付けて管理する形を取るので、そう呼んでいる。

これにより、それぞれのデータのパスを指定できるようになった。

最終的には、ベースシステムの構築→シェルの起動→ゲームの起動となるわけだが、それまでにどういう処理が必要になるだろうか。

ベースシステムの構築やシェル、ゲームの起動のためには、やはりモジュールのロードが不可欠。

よって、モジュールマネージャの生成が必要になるだろう。

モジュールのロードには、パッケージディレクトリとコンフィグディレクトリに置かれているファイルの読み込みが必要になってくるはずだ。

しかしその処理はモジュールマネージャ内で行うべきだろうか?難しいところだ。

それを含めてしまうと、モジュールマネージャが肥大化してしまう気がする。

とはいえ、どこかでは設定ファイル間の関連付けを解決する処理をやらねばならない。

いっそ、モジュールマネージャではなく設定ファイルマネージャと考えるべきだろうか。

モジュールのロードとかは、それとは別にモジュールローダというか、モジュールロードマネージャというか、そんな感じの機能を別に作り、そこでやらせる。

パッケージディレクトリの設定ファイルと、コンフィグディレクトリの設定ファイル読み込み処理については、別々の機能に分けることはできないだろうな。

パッケージに含まれるモジュール一覧とその詳細情報は前者に書かれているが、どのモジュールの読み込みが許可されているかどうかは後者に書かれている。

あるモジュールを読み込むだけなら、後者の設定ファイルを読んだ後に前者の設定ファイルを読めばいいだけだが、モジュールによっては依存モジュールが存在する。

依存モジュールについては、また後者の設定ファイルから読み直す必要がある。

これを別々の機能に分けるとなると、循環参照になってしまって気持ちの悪いことになりそうな感じがある。

書いてたら、ちょっともやもやが晴れた気がする。

完全にクリアになったわけではないのだが。


2014/11/26 19:15

難航していたが、ようやくまとまってきた感ある。

今までのファイル構成は、dropmakerのホームディレクトリ直下にベース設定ファイル、パッケージディレクトリ、ゲームディレクトリがあった。

セーブデータディレクトリなんかも置く予定だったけど、まだそれが必要になる段階まで到達していない。

実際には、ベース設定ファイル以外のディレクトリはベース設定ファイル内で指定した位置なので、ホームディレクトリの下に置く必要はないが。

それはともかく、パッケージディレクトリにはゲーム本体、プログラムやら、画像とか音楽とかのリソースやらが配置される。

一旦配置されたら、削除されるまで変更がかかることは基本的にない。

ゲームディレクトリには、ゲームパッケージを起動するための情報を記述した設定ファイルを置く。起動するパッケージ名やらモジュール名やらゲーム名やら。パッケージがなんらかのインターフェースを使用する場合、その実装モジュールの指定もする。

プレステで例えれば、パッケージディレクトリはCD、ゲームディレクトリ(とセーブデータディレクトリ)はメモリーカードである。

今回の構成変更で、とりあえずゲームディレクトリは無くした、というより分割した。

その前に、モジュールの扱いを変えたのを説明するべきか。

今までは、モジュールはゲームディレクトリの設定ファイルでインターフェースとの関連付けを行っていた。

今回の変更で、その関連付けはやめた。

その代わり、パッケージディレクトリの設定ファイルに、各モジュールが実装しているインターフェースを記述しておく形にした。

ゲームディレクトリの設定ファイルでは、使用を許可するモジュールのリストアップのみ行う。

あるインターフェースの使用が要求された場合、使用が許可されているモジュールの中から、そのインターフェースが実装されているモジュールを検索し、使用する。

もし該当するモジュールが2つ以上ある場合には、衝突が発生しているので要求は失敗となる。

該当するモジュールが存在しない場合には、インターフェースを定義するパッケージが提供するダミーモジュールを使用する。

ダミーモジュールを使うことで、例えばネットとの通信モジュールを使用するゲームであっても、ユーザー側でその機能を無効化する、ということも可能になる。

とはいえ、ゲーム側がネットとの通信ができないなら動作しないようにしたりしていれば、そもそもゲーム自体できなくなってしまうわけだが、それはまた別の問題だ。

で、ゲームディレクトリをコンフィグディレクトリとショートカットディレクトリの2つのディレクトリに分けた。

コンフィグディレクトリでは、パッケージディレクトリとセーブディレクトリとの関連付けや、前述の使用を許可するモジュールのリストアップなどを行う。

パッケージが他のパッケージに依存する場合、対象のパッケージについての設定が書かれたファイルの指定などもできる。

ショートカットディレクトリでは、起動に関する設定をまとめる。

起動するゲームの指定、メインウィンドウのサイズの指定など。

まとめると、

パッケージディレクトリにゲーム本体をつっこみ、

コンフィグディレクトリにパッケージの設定をつっこみ、

ショートカットディレクトリにゲーム起動時の設定をつっこむ、といった具合か。

あと、セーブデータディレクトリにゲームのセーブデータをつっこむ。

一部の設定ファイルについては、拡張子が一致していれば複数のファイルに分割することも許可する予定。具体的にはベース設定とパッケージ設定。

コンフィグディレクトリに配置する設定ファイルについても複数のファイルに分割できるようにしたいが、いい案が浮かばない。

前述のファイル分割は、見やすさ、扱いやすさの向上などが目的だが、こちらは違う。

パッケージとセーブデータの関連付けと、使用許可モジュールリストを別ファイルに分けることで、例えば使用するモジュールはそのままに別のセーブデータを使いたいとか、同じセーブデータを使うけど使用するモジュールは変えたいとか、そんな感じだ。

ならばその2つの設定を別のディレクトリに分けてしまえば、と思わないでもないが、そこまですることだろうか。少なくともパッケージとセーブデータの関連付けの方はデータ量が少なすぎる。

細切れになるばかりで扱いにくくなりそう。

その辺は後々対応することにしようかしら。そのくらいなら、全体的に修正をかけなければならない、というレベルのものでもないだろうし。

ともかく、現時点ではファイルとディレクトリの構成を考えただけであり、実際にそれを運用するためのプログラムは存在していない。

今までのdropmakerは断片的にしか役に立たないだろうし、1から作っていくとしよう。


2014/11/22 00:14

色々考えていたが、dropmakerはまた作り直した方がいいかもしらんね。

どうにもモジュールの管理周りがうすらぼんやりとしてよくない。

指定したモジュールから関数のアドレスを取得する関数を、全てのロード済みモジュールから関数のアドレスを探して取得する関数に変えようとするだけでもなんかうまくいかない。

うまくいかないというより、変更が大きくなりすぎるというか、1から作り直した方が早そうというか。

この際、ディレクトリや設定ファイルの構成らへんから練り直すべきかもしれない。

現状では、直接起動するパッケージ以外はセーブデータを持てないし。

依存モジュールの解決も、今は単純な構成だからましだけど、ちょっと複雑な構成になるとすぐだめになりそう。

大まかな構成はテキストに書き出したので、土日に実際にディレクトリや設定ファイルを並べてみるつもり。


2014/11/18 00:40

日をまたいでしまった。

次の日のやる気に影響するかもしれないので、こんな時間まで作業するべきではない。

さて、fg::Windowからfg::Screenを分離した。

デモを使って正常に動作することも確認済み。

ここまでは大したことはない。ファイルの移動と記述の置換、それと多少の修正でできた。

ここからが本番。メインウィンドウの生成と、それをゲーム側から触れるようにする。

sucrose-screen-*モジュールを追加したので、パッケージ設定ファイルに記述を追加していて思ったが、もうちょっと要素を追加した方がよさそうだな。

そのモジュールがなんのインターフェースの実装なのかを示す情報が現時点では存在しない。

今のところはモジュール名を同じにすることでそのインターフェースの実装モジュール、ということにしているが、それだと実装が複数存在する場合に対応できない。

そこで、モジュールの設定ツリーになんのインターフェースの実装なのかを示す要素を追加してみようか、などと考えている。

そこまで優先度が高いわけではないので、後々実装する予定。

あるいはもっといい設計が思い浮かぶかもしれないし。


2014/11/14 12:40

ウィンドウを2つの型に分離することを検討している。

OpenGLコンテキストの扱い方については昨日の調査で大体把握できたので、以降はメインウィンドウをどのように実装するか考えていた。

しかし、どうにもうまくまとまらない。

今のところ、ウィンドウはfg::Windowという型で表現しているが、これを直接使うと色々問題がある。

例えば、fg::Windowはfg::close()を使えばウィンドウクローズ、fg::resize()という関数を使えばリサイズなどの要求が行なえるが、メインウィンドウに関してはこれらは必要ないように思う。

また、fg::free()を使えばウィンドウの破棄ができてしまう。

破棄はメインウィンドウを生成、制御するゲーム起動側でやるので、ゲーム側ではできないようにしたい。

他にも色々あるが、要はウィンドウを表現するという意味ではfg::Windowでいいのだが、その機能などがメインウィンドウと合致しない、といった感じだ。

ぱっと思い付いた対応として、例えばfg::MainWindowという型を作り、内部的にfg::Windowを持たせ、fg::MainWindowにはfg::Windowの持つ関数のうち一部だけを用意すればいいのではと考えた。

しかしこれはあまりいい対応ではない。

簡単に言えば面倒なのである。fg::MainWindowの内部にfg::Windowを持たせ、fg::Windowと似たような関数を用意するということは、fg::Windowに新たに関数を増やし、それがfg::MainWindowでも使えるようにすべき関数である場合、fg::MainWindowにも同じように関数を増やさなければならない。

当たり前ではあるが、こういうのは忘れてしまう可能性があるし、またfg::MainWindowの方の関数はfg::Windowの同じ関数を呼び出すラッパー程度の関数になるとはいえ、記述ミスによるバグを抱えてしまう可能性もある。

そこで考えたのが、ウィンドウを2つの型に分離する、という方法だ。

今はウィンドウを表現する型はfg::Windowのみだが、これとは別に表示領域を表現する型を用意する。

仮にfg::Screenということにするが、fg::Screenは自発的に生成、破棄することができない。

再描画やリサイズなどのイベントについてはイベントハンドラを設定できるようにするが、リサイズリクエストはできないようにする。

例えば、fg::Windowの内部的にfg::Screenを持たせる、という感じにする。

fg::Windowを生成すれば、それに対応したfg::Screenも同時に作られる、ということだ。

それで、fg::Windowの関数としてfg::getScreen()とかいう関数を用意して、fg::Screenの参照を取得できるようにする。

メインウィンドウについては、ゲーム側からはfg::Screenの参照のみを扱えるようにする。

fg::Screenの参照だけ、つまりメインウィンドウの表示領域だけなら、破棄もできないし勝手なクローズやサイズ変更の要求もできない。

おまけに、ラッピングした型でもないのでラッパー関数を作る必要などもない。

うまくいきそうな気はしている。


2014/11/13 16:00

OpenGLのコンテキストについて色々試したので、整理しておこう。

ある1つのウィンドウを、複数のスレッドのカレントコンテキストに設定することは可能。

ある1つのOpenGLコンテキストを、複数のスレッドのカレントコンテキストに設定することは不可能。

やろうとすると、glXMakeCurrent()を呼び出すタイミングでセグメント例外が発生する。

一度、スレッドのカレントコンテキストを別のOpenGLコンテキストに変えるなりすれば、別のスレッドのカレントコンテキストに設定することはできる。

しかしその場合、別のスレッドのカレントコンテキストに設定する前に行なわれ、まだ画面に表示されていない描画処理は無かったことになる。

なので、一度カレントコンテキストに設定したOpenGLコンテキストを、別のスレッドのカレントコンテキストに移すとかいうのは、あまり意味がないように感じる。

少なくとも、ゲーム起動側がメインウィンドウに描画を行なうためのOpenGLコンテキストを、ゲーム側から参照できるようにする必要性は、ほぼないことが確認できたと言っていいだろう。

OpenGLコンテキストを複数のスレッドで使えないので、複数のウィンドウに対して1つのOpenGLコンテキストを割り当てる、とかいう構成も当然無理。

今の構成は、fg::GLContextを生成し、その参照とfg::Windowの参照を使ってfg::GLCurrentを生成、それを使ってOpenGLの関数を呼び出す、といった具合。

別のスレッドのカレントコンテキストに設定し直す意味があまりないということは、fg::GLCurrentなんて作らず、fg::GLContextの生成時にOpenGLコンテキストの生成とカレントコンテキストの設定を行ない、破棄時にカレントコンテキストからの設定解除とOpenGLコンテキストの破棄をやってしまえばいいのでは、ともちょっと思ったけど、それもまたちょっと違うんだろうな。

例えばテクスチャの情報などはOpenGLコンテキストに関連付けられるだろうし、ウィンドウを一度破棄してもう一度ウィンドウを作り、以前と同じような表示をしたい場合、その度にOpenGLコンテキストの生成を行なっていたのでは再度テクスチャの情報なども作り直さなくてはならない。

OpenGLコンテキストの生成・破棄とカレントコンテキストの設定・設定解除を分離しておけば、その辺うまく使い回せそうな気がする。


2014/11/12 23:00

今まで中途半端に作っていたデモをきちんと整えるなど。

メインウィンドウ、どうやって実装しようか考え中。

実質的に、ウィンドウのイベントは再描画要求以外触れないようにしたいところ。

加えて、必要に応じてゲーム起動側、つまりメインウィンドウを生成した側でも画面に描画を行なえるようにしたい。

それはつまり、ゲーム起動側にメインウィンドウで使用するOpenGLのコンテキストを持たせるわけで。

それがカレントコンテキストになっているスレッドも持たせる必要があるわけで。

描画することを考えなければカレントコンテキストの件は無視できるので、とりあえずそれでやってみようかなぁ。

1つのウィンドウを、複数のスレッドでカレントコンテキストにする、とかってできるのかなぁ。

今まで試したことがないから、明日試してみようかな。

その結果次第では、OpenGLコンテキストはゲーム側から参照できるようにしなくても済むかも。


2014/11/11 19:45

昨日書いた通り、OpenGLの関数を使えるようにした。

ほとんど前のプロジェクトで書いたものを流用しただけだが、やはり少し手を加えなければ使える状態にはならなかった。

しかし、OpenGLの関数や定数は数が多いため、一気にファイルの総行数が1万行ほど増えてしまった。

定数が書かれたファイルでおよそ5500行、関数が書かれたファイルでおよそ3500行あり、これだけで9000行に達するので仕方ないが。


2014/11/10 19:50

垂直同期については対応した。

あとはOpenGLの関数だが、前のプロジェクトで書いたものを流用すれば明日にも完了できる気がする。

垂直同期の対応についても、基本的には前のプロジェクトのものを流用したわけだが。

しかしながら、xlibのDisplayをグローバルでなくしたなど、構成を変えているために修正は必要だったが。


2014/11/07 20:20

OpenGLの対応の残件は、OpenGLの関数を使えるようにするのと、垂直同期対応。

今日かコンテキストをカレントに設定する処理を作っていた。

それに付随して、バッファの切り替え処理も対応した。

現時点ではglClear()とか使えないので、バッファを切り替えてもゴミデータが表示されてしまうだけだが。

これであとは、OpenGLの関数を使えるようになれば描画ができるようになる。

OpenGLの残件を対応したら、メインウィンドウ機能を対応したいところだ。

ゲームの実行前に自動的に作られ、ゲーム側に渡されるサイズ変更不可、移動検知不可のウィンドウ。

事前に設定することでサイズを変更できたり、フルスクリーンで実行できたりなどというのを考えているのだが。


2014/11/06 19:15

昨日のは勘違いだった。

見るデータが間違ってて、実際にはおそらく問題なかった。

なんであんな勘違いをしたのか。

あの勘違いをしたやつは直ちに名乗り出ろ。

OpenGLの対応を進めている途中で、試しに動かしてみてどうしてもOpenGLの関数を呼び出すところでこけてしまう問題が起きていた。

1時間程度試行錯誤して、valgrindを使って実行するとこけた気がするのを思い出して、valgrindを使わずに実行したらすんなり動いてがっくりした。

無駄に疲れた。

もうこんなことはしたくないものだが、忘れた頃にまたやりそう。


2014/11/05 19:50

排他処理、スレッドや、ウィンドウについてはとりあえず出来上がっている。

今はOpenGLの対応を進めている。

その途中で、スレッドのライブラリにwaitやnotifyを行なうためのインターフェースを追加したり、その実装を作ったりもした。

とにかく画面に描画をできるようにしたいところ。

valgrind使っててなんかおかしいと思ったら、dlopen()したライブラリがdlclose()されてなかった。

なんかdlclose()にnullが渡されてるから、クローズされないし失敗もしない。

ていうかNewModuleの型がおかしい。

なんでこんな型になっているのか。

この処理を書いたやつは直ちに名乗り出ろ。


2014/10/30 20:35

イベントハンドラの対応、一応できた。

しかし、排他処理のインターフェースを作っていなかったため、まだ実用的でない。

ロックしてないから、データがおかしくなるかもしれない。

やはりスレッドのインターフェースも作るべきだろうか。

ロック関係をそこに含めるか。


2014/10/29 19:35

まためんどくなってた。

sucrose-windowを作成中。あとはイベントハンドラの対応のみ。

色々考えて、また少しイベントハンドラの扱いを変えた。

イベントハンドラ部分については、ウィンドウシステムの実装とは無関係だと思ったので、sucrose-window-commonというライブラリに分離させた。

linux用の、xlibを使う実装はsucrose-window-xlibとして作成してある。

で、イベントハンドラ部分をあまりめんどくなさそうな感じに設計を変えたので、明日ぐらいには作り終えられるのではと考えている。


2014/10/20 19:25

順調、と言いたいがやはりスローペースな気がする。

とりあえず、sucrose-jsonは使えるようにした。

あとはsucrose-mainを使えるようにすれば、dropmakerを動かせるが。

しかし、シンボルの取得とかは処理を書き直さねばならないだろう。

CからC++にした影響だ。


2014/10/17 21:20

よくよく考えたら、イベントハンドラでつまづいただけだったなぁ。

なので、dropmakerに関しては、ほとんどそのままソースを持ってくればいいか、という気分になっている。

細かく修正を入れようとして時間食うよりずっといい。

昨日加えた修正の件も考えて、持ってきたソースの中の不要になるconst_castを消していっているのだが、参照系のクラスは全部2種類用意するべきかもしれないなぁ。

というのも、fg::JsonObjectPairsで似たような状態が発生しているのだ。


2014/10/16 21:00

体調がびみょう。

このところ、そのせいか分からんがびみょうに思考がまとまりにくいし、集中もできてないような。

そんな感じで進みも悪い。

文字列参照型を2種類にした。

std::basic_stringみたいな位置付けのやつだが、std::basic_stringと違い、自身では文字列の領域を保持したりせず、他のところに配置されている文字列を参照する型なのだが。

今までの構成だとコンストラクタがchar *なので、const char *を入れようとするとconst_castしなければならなくてめんどすぎる。

なので、コンストラクタにconst char *をつっこむのと、char *をつっこむやつの2種類の型を作ることにした。

後者の型を前者の型の子クラスにしたので、わざわざオーバーロードした関数を用意しなくても済むし。


2014/10/14 21:30

10日に書き忘れた。

gitのログ見てみたらなんかおかしいな。何回sucrose-commonの生成ルールを追加してるんだ。

直すのもめんどくさいが。

とりあえず、sucrose-commonとsucrose-strconv-iconvを作った。

前のプロジェクトではstrconvは一度に1種類しかビルドできなかったが、今のプロジェクトでは複数の実装を一緒にビルドできるようにしてあるため、名前を変えた。iconvを使っているので末尾にiconvと足してある。

commonとstrconvを作ったので、コマンドライン引数を処理するだけのプログラムがビルドできるようになった。

が、リンクする静的ライブラリ名をハードコーディングしているので、それはどうにかするべきだな。

必要に応じてコマンドライン引数から指定できるようにしたいが、どうやって処理するべきか。


2014/10/09 21:11

前のプロジェクトからソースをどんどん持ってきている。

2種類のライブラリを生成する件についてはどうにかなった。

違うプロジェクト間で、wscriptを同一にしなければならないという決まりがあるでもなし、プロジェクト毎に不要なものは削除し、必要なものは追加して対応することにした。

早いところ、今までに作った部分は移行してしまって、新機能を作成していきたいところ。


2014/10/08 20:10

ビルドの簡略化はできた。

とりあえず前のプロジェクトからソースファイルをそのまま持ってきて、fg-commonの生成がきちんとできるのは確認した。

正確には、fgppからソースを持ってきたのでFGPPをFGに、fgppをfgに置換したりはしたが。

あれ、よく考えたらあるライブラリについて、静的ライブラリと動的ライブラリの2種類作るのはできなくないか?

どうしよう。ぱっと思い付く修正案はあるものの、それでいいのかどうか。


2014/10/07 22:55

早速、作り直し中。

ビルドの簡略化を行なっているが、想定よりちょっとめんどかった。

あるパッケージに存在するモジュールの一覧を取得する処理が、そう簡単にはいかなかった。

dir()はロード済みのモジュールしか取得できないし。

調べたら、ModuleScannerというのを使えばいいというのは分かったので、それを使ってコマンドラインオプションを作るところまではやった。

次は、そのコマンドラインオプションを使用した際に、対象のモジュールのビルドを実行する処理を作る。

うまくいけば、新たにモジュールのビルドルールを追加しても、他のところにその処理を呼び出す処理を追加しなくても済む。

configure時にコマンドラインオプションを追加するだけで、そのビルドルールでモジュールが生成されるようになる。

また、コマンドラインオプションで指定しなければ、モジュールをビルドしないようにもできる。


2014/10/06 22:56

って、いかん。何また難しくしようとしてるんだ。

まずはC/C++だけ、もしくはC++だけ扱うのでもいいじゃないか。

まだ一つも完成させてすらいないのに、最初から事を大きくしすぎだ。

JavaとかPythonとかPerlとか、まだ必要な場面ではないのだ。

また迷走して時間ばかりかけてしまうところだった。

メインのライブラリはどうしよう。また作り直すべきだろうか。

今度は本格的に処理は丸々使えるが、今のプロジェクトに修正を加える形でもいい気がする。

しかし、この機会にビルドの仕組みの簡略化もしてしまいたいし。

それをする場合、やはり作り直すべきな気がする。

というか、インターフェースライブラリはそのままでいいな。

いや、ビルドの仕組みの簡略化はインターフェースライブラリもやるけど、それは修正を加える形でいいだろう。

この際だから、Cのラッパーライブラリも作らず、完全にC++だけの構成にしてしまってもいいかもしれない。

ラッパーというか、他の言語に同じインターフェースがあると、一方に修正を加えたらそちらにも同じ加えたくなるし。

コードの量は増えてもできることは増えてないという、効率の悪いことになるし。

うむ。C++のインターフェースライブラリ「fg」、実装ライブラリ「sucrose」、ライブラリ利用環境「dropmaker」という3つのプロジェクトから成る構成にするかな。

あと、ライブラリ利用デモ「fgdemos」の4つか。


2014/10/06 22:20

結局、C++のライブラリをメインにした方がいい気がしてきた。

イベントハンドラの関係で、C言語のライブラリをメインにしているとラッパーライブラリがうまく作れないのだ。

逆に、C++のライブラリをメインにして、C言語のそのラッパーライブラリにすればうまくいくんじゃないかなぁ、といったところ。

そもそもC言語のライブラリをメインに持ってきたところで、それを直接使うわけでもないし。

C言語を直接使ってゲーム作るのとかやりたくないし。

しかし、その程度で大きく変更をかけるのは場当たりすぎる気がする。

もうちょっとこう、他の言語との連携周りなのだから、その辺どのように対応するのかを考えてから処理したいところだが。

現状ではどうあがいてもC/C++などで作られた、lib*.soとか*.dllとかのライブラリしか対応できないわけで。

例えば.jarやら.pyやら.pl、.pmやらも使えるようにしてみたいところ。


2014/10/03 21:52

ウィンドウ制御処理、大体はできたのだが。

ウィンドウ内全てについて再描画処理をリクエストする処理についてはまだ。

XGetGeometry()の処理が完了せず止まってしまうことがある。原因はまだ不明。

おそらく、このへんも昔に通った道のはずなのだが。

もしかしたら、xorg-serverのバージョンアップが影響しているかもしれないが、多分そんな大げさなことはないだろう。

というか、この関数本当に必要だろうか。なんとなく必要な気がする、というだけで存在させている感は否めない。

やりたいなら、ウィンドウサイズ変更イベントのイベントハンドラを設定しておいてウィンドウサイズを取得し、それを使ってウィンドウ内全てに再描画リクエストを投げてもいいのだ。

ウィンドウの位置についても、どうもxlibではうまいこと制御できない感があるので、というか前にもこれは体験した気がするので、ウィンドウの位置は制御できないようにした。

これと同じように、関数自体を消すという対応でいい気もする。


2014/10/02 23:25

イベント発生時のイベントハンドラ呼び出し処理を追加している。

イベントハンドラの設定とかその辺については、ウィンドウ制御側からは触らんわけだし、イベント発生時の処理を書いた後でもいいかなって感じで。

イベント発生時の処理はリセット前のプロジェクトとほぼ同じで大丈夫なので、さくっと片付けてしまいたいところ。


2014/10/01 19:12

おかしいな、イベントハンドラの形式が古い。

set形式は色々だめだと判断して、add/remove形式に変えたはずなのだけれど、その形式にしたソースが見つからない。

そんなもんだから、今のAPIはset形式になってしまっている。

直さないといかんなー

ウィンドウ制御については、とりあえず表示と、イベント処理スレッドの起動までは作った。

で、イベントハンドラの呼び出しとかが必要になってきた時点で、前述の問題に気が付いた感じ。


2014/09/30 19:45

終了関数については、結局後回し。

xlibを使ったウィンドウ制御について実装を始めている。

リセット前のプロジェクトを参考にしているものの、前の物よりは分かりやすいものにしようと考えながら記述している。

その中で、ラムダ関数への変数のムーブキャプチャを使ったのだが、なんかエラーが消えないと思ったら、どうやらconstでキャプチャされるらしい。

参照キャプチャではそんなことはなかったようなのだが。ふしぎ。


2014/09/29 20:40

ひとまず、初期化処理呼び出しの位置変更は完了した。

しかし、終了処理についてはまだ考え中。

初期化関数の引数に、関数ポインタの参照を渡してそれに終了関数のアドレスを設定するという方法はあまりよくない気がする。

直感的でないというかなんというか、分かりにくいというか。

そんな回りくどい方法を取るくらいなら、設定ファイルに初期化関数名と終了関数名のペアを書いておくとかの方がいい気がする。


2014/09/26 19:20

どうも暴走していたようだ。

昨日書いたことはどうにも浅はかすぎる。終了処理の呼び出しは同じように書くべきではないと思った。

初期化処理の呼び出しと同じように、終了関数を設定ファイルで指定することで、モジュールをアンロードする前に終了処理を呼び出す、というのは安直だが、安直すぎてだめだ。

それだと、初期化処理が途中で失敗した場合、どの終了処理を呼び出すべきで、どの終了処理は呼び出すべきでないのか。

こういうのはよく、終了処理は全て絶対に呼び出し、終了処理の中で、初期化してあるなら処理を行ない、初期化していないなら何もしない、と書くべきなどと言われるが、私はそういうのが嫌いなのだ。初期化してないなら終了処理は必要ないのだから、最初から呼び出さない方がすっきりする。

例えば、初期化処理の引数として関数ポインタの参照を渡しておき、初期化処理が正常終了する場合に対応する終了関数のアドレスを設定する、などすればいい感じになりそう。

しかしながら、現状では安直な方法ですら行なうのが困難な状況だ。

モジュールのアンロード処理で、ロードしたモジュールを表現するvoid*しか情報をもらっていないため、どこかに終了処理の関数名を含めるとかいったことができないのだ。

構成を間違えた感じがある。モジュールのロード、アンロード処理に、初期化、終了の処理を含めるべきではなかったのだ。

単純に巻き戻してしまってもいい気がする。


2014/09/25 21:00

初期化処理できあがり。

次は、初期化処理と共通の部分は共通化して終了処理の呼び出しを作成する。

厳密には、現時点ではまだ必要ないと思われるが、ほぼ同じ処理なわけだし、ちょっとしたらすぐ必要になると思うし。

作っておいて損ないだろう、といったところ。


2014/09/24 23:36

初期化処理の追加、途中までできた。

初期化処理を走らせるところはできたので、次は走らせる処理を指定するところ。

それが出来たら、終了処理についても同じように追加する。

しかし、ModuleInfoとModuleKeyを分けている意味がないような気がする。

一緒にしちゃってもいいんじゃないかな。

ビルドの仕組み、簡略化すべきかも。

現状では、あるモジュールについて、configureする時に実装を指定することで、その実装を使ったモジュールをビルドするのだが、モジュールの名前を別にすることで、複数の実装を同時に存在できるようにしようかと。

現状では、例えばウィンドウ管理のモジュールは、linux用のxlibを使った実装でも、windows用のwin32を使った実装でも、作られるモジュールの名前はlinuxならlibfg-window.so、windowsならfg-window.dllになる。

でも、例えばxlibを使った実装ならfg-window-xlibとか、win32を使った実装ならfg-window-win32とかにすれば、実装が異なる複数のウィンドウ管理モジュールを共存させることができる。

その環境はビルドできない実装の場合は、configureでビルドしないように指定すればいいのだし。

この変更をすることで、多分ビルドの仕組みは今より簡単になるはずなのだ。


2014/09/19 20:02

困った。

初期化が必要なモジュールについての考慮が足りていなかった。

今まで通り、各OSに用意されている機能を使ってもいい気がするが、あれはあまりよくない。

初期化時に処理が失敗した場合にどうするとか、そういったことができない。多分。

きちんと調べたわけではないのだが、少なくともwindowsでは関数が1つ固定、関数名すら固定だし、それを使うくらいならば自分で機能を作ってしまった方がいい気がする。

今のところの考えでは、パッケージ設定に記述するモジュールの設定に、初期化関数を指定できる形にしようかと考えているがどうなんだろう。


2014/09/18 20:47

総ソースファイル行数が1000行ほど減った。

今まで、共通化できそうだけどめんどうなので放置していた場所を、マクロで共通化した結果、そんな感じになった。

これで、あとは実装部分をリセット前のプロジェクトから持ってくればウィンドウを扱えるようになるだろう。


2014/09/17 20:50

というわけで、ウィンドウの対応を始めた。

リセットする前のプロジェクトからファイルを持ってきて、ちょっと修正を加えて使えるようにしたりなど。

若干インターフェースやマクロの仕様が違うので、完全にそのまま使うわけにはいかない。

一気にファイル数が増え、総ソースファイル数が300に迫る勢い。

明日には300を越すだろう。

しかし、メインウィンドウの生成はどこでやるべきか。

コンテキストに参照を持たせることは決まっているが、コンテキスト生成処理に混ぜるか、生成後に参照をコンテキスト生成処理に渡すか。

前者でいい気がするのだが、なんかしっくりこないような。


2014/09/16 19:08

とりあえず、コマンドライン引数対応は終えたのだが。

この次、本当にパスの扱いについてやるべきだろうか。後回しでもいい気がしてきた。

いい案がぱっと浮かばないし、なによりやる気があまりしないのだ。

それよりも、リセットする前のプロジェクトには実装されていたウィンドウや入力機器、音声機器の管理機能をサクサクッと実装して、試しにゲームでも作ってみるべきな気がする。

ゲームを作らんと、いつまで経っても話が進まんのだ。


2014/09/12 20:23

どうにも作業速度が思うように上がらないと思ったら案の定だった。

そんなわけでまだ出来上がっていないが今日は疲れた。

このまま出来上がるまで続行するというのは昔はよくやっていた気もするが、これをするとその後一層気分がよくなくなるのだ。

よくない連鎖は発生する前に止めるに限る。


2014/09/11 20:00

とりあえずコマンドライン引数対応を始めた。

一応、リセットする前のプロジェクトでは実装されていた機能なので、大体はそこから持ってくればいいだけなのだが。

その後の処理は完全に1から書くことになるわけで、出来上がるのは早くて明日だろうな。

今日はこれ以上続けるとだらだらしちゃうからやめやめ。

TODOコメントをいくつか、ヒントとして追加しておしまい。


2014/09/10 22:10

パスの扱いについてまだ考え中。

今日はバグの修正やら細かい変更などをしていた。

パスについては後回しにして、先にコマンドライン引数で起動するプログラムの指定をできるようにしてしまった方がいいかもしれない。

実際に必要になる場面を先に作ってしまえばイメージしやすそうな気がする。


2014/09/09 19:40

静的リンクしていたライブラリを、モジュールとして動的リンクして扱うように修正した。

当初の予定では、静的リンクしているライブラリ5つを全て動的リンクさせたかったのだが、よく考えたらそのうち4つはモジュール管理処理から使っているので分離できず、結局1つのライブラリしか取り外すことができなかった。

しかしながら、そのおかげで奇妙な処理の仕方をしていた箇所を削除することができたし、成果は悪くない。イメージのサイズも小さくなったようだし。

複数のライブラリを修正する予定だったのでマクロとかも作って修正しやすくしたのだが、結局1つのライブラリしか修正できなかったので、ちょっと大げさになってしまった感はある。

とはいえ、今後別のライブラリをリンクさせる予定があるので、その時には役立つかも。


2014/09/08 19:26

プログラム起動前のモジュール読み込みについても、依存関係を解決した上で読み込むようにした。

これにより、プログラム起動前に読み込むモジュールについても、別のモジュールに依存させることが可能になった。

今までは対象のモジュールのみ読み込む形だったので、他のモジュールに依存させていると正しく動作しなかったが、それが解決された。

現状では、プログラム起動前に読み込むモジュールは他のモジュールに依存できないのを前提とした書き方をしていたはずなので、その辺は修正していくべきだろうな。

次はコマンドライン引数で起動するプログラムの指定をできるようにしたいところだが、これをするとなるとパスの扱いをきちんと考えんと。


2014/09/06 13:18

おとといバージョン上げて、昨日プログラム起動前に読み込むモジュールのどうのこうのの前準備をした。

というのを昨日書けばよかったのに忘れていた。

今日明日はあまり作業しないようにする。

のんべんだらりとなってくると、余計にやる気が減退してしまってよくない。

そんな感じで、土日やら祝日やら、あとは平日の夜とかも、意図的に作業しないようにしている。

せいぜい、なんか思い付いたらメモしておく程度。

その方が、作業中集中できるし気分的にもいい気がするのだ。


2014/09/04 17:16

やることは色々思い付くが、ここらでバージョンを上げて区切っておくべきだろうか。

依存解決ありのモジュールロード処理のプロトタイプは出来上がっているわけだし。

今後、コマンドライン引数で起動するプログラムを指定したりとか、プログラム起動前に読み込むモジュールも依存解決ありの形にしたりだとか、その他諸々を予定している。

後者の機能を実装するために、ファイルの配置を変えたりしていたが、そろそろバージョンを上げてネット上のリポジトリにpushしておくべきだろうな。

調子が良さそうに思える時ほど、冷静にならねば無意識のうちに暴走、迷走して失敗するのだ。


2014/09/03 19:59

あるモジュールが複数モジュールから依存されている場合に、無駄にメモリ食ったり無駄な処理したりしないように修正した。

簡単なデモプログラムを作ってみて、問題なく動作するのを確認した。

しかし、必要なモジュールを依存モジュールリストから外しておいて、動作に失敗するはずのプログラムが普通に動いた、というのが起きた時はびびった。

原因を調べたら、プログラムを実行するコアプログラム側に、必要なモジュールの処理が含まれており、プログラムがコアプログラム側の処理を呼び出しているために、普通に動いているように見える、ということだった。

しかしコアプログラムはシンボルを全くエクスポートしていないはずなのに、なぜプログラム側から呼び出せているのか謎だったが、コアプログラムのリンク時に-rdynamicオプションを指定しているのがまずかったらしい。

このオプションを付けているとバックトレースの表示を詳しくできるため、デバックビルドのリンク時には付けていた。

しかしこのオプションの機能は「生成したファイル内に動的リンク用のシンボルを残す」というものであるため、今回のような問題が発生してしまったようだ。

で、バックトレースを見る機会とか今のところほぼないし、別にいいかということで問題のオプションを使わないことで対応した。

そもそもgrep backtraceとかやっても1件もヒットしなかったし、この記述自体が以前に作っていたプログラムの名残だったと思われる。


2014/09/02 18:44

やたー動いたー。

もうちょい処理を追加する必要があるが、とりあえず動作するのを確認できた。

依存モジュールのロードを行ない、プログラムを起動させることに成功。

依存モジュールの指定方法をもうちょい種類増やしたりだとか、そもそも今のインターフェースで他の言語のプログラムを扱えるのかなど問題は色々あるものの、とりあえず一段落した気がする。

あるモジュールが複数のモジュールから依存されている場合の処理をまだ書いてないので、それは追加する必要がある。

それにしたって、効率的な処理にならない、というだけであり、想定では問題なく動作するはずだが。

その辺確認するためにも、デモプログラムをいくつか作ってみる必要がありそう。

モジュールの依存関係が循環してしまっている場合、現時点では正しく動作しない。多分無限ループみたくなって、そのうちスタック食い潰して落ちる。

そもそも循環した依存関係というのが、他の言語とかでも常に許容されるのか分からんし、動作するように対応するかどうかはびみょう。循環を検出して、起動失敗にしたりなど、なんらかの対策は必要だろうけど。


2014/09/01 15:36

もうめんどいから過去ログに分割しなくてもいいんじゃないかな。

パッケージシステムの暫定的な根幹ができあがりそうな感じ。

また今日も、私の頭の中から湧き出た何かを形にするべく、その正体不明の何かを解析する作業。

妄想なんだろうけど、見てはいけない何かを見つめ続けてしまっている気がする。

そのうちもっと頭おかしくなるのではないだろうか。

ポケモンエメラルドで捕まえられるポケモン全部捕まえた。

あとはルビーやらサファイアやらでしか出現しないポケモンを捕まえて送り込まねば、ホウエン図鑑を埋めることはできない。

送り込むだけならそれぞれのカートリッジと、安価で購入したゲームキューブとポケモンボックスを持っているのでできるのだが、通信ケーブルがないため通信進化ができない。

アドバンスのケーブル、通販だと中古でも新品並みの値段になってたりするから困る。新品が定価の2、3倍とか頭おかしいと思う。手を出しがたい。

さて、こわいこわい言ってないで作業せんと。クトゥルフ神話じゃないんだから未知に対する恐怖なんてあるものか。