2016.12.30(Fri):PC/Program
前回タスクシステムの大まかな概要を書きましたが、実は大きな欠点があります。
あるひとつのタスクに時間がかかりすぎると他のタスクは待たされるということです。
処理落ちもこの類です。

ではどうするか?
実際はひとつひとつのタスクはものすごく小さなことしかしてなくてPCに言わせればごくわずかな時間でしかありません。
ここでもシューティングを例題に上げますが
自機の移動、敵の移動、玉の移動や消滅・・・
与えられた座標を移動するにすぎません。

では何が時間使うのか?
弾幕系でいうところのあたり判定などです。
これは基本敵本体と玉、及び自機の座標で判定します。
100個の玉があれば100回判定をするということ。
1つ1つが微々たるものでも数が増えればそれは大きな時間となります。
もちろん敵に放った玉のあたり判定も必要です。
ホーミングやレーザーなどアルゴリズムはあれど増えれば処理負荷は増えます。

現状のPC能力では気にすることもないでしょうが・・・

ここで判定をどこでやらせるか?処理が速いのは?
って問題にぶち当たります。

私としては自機や自玉はグローバルな存在として敵、敵の玉などは各個判定って考えます。
合ってるか間違ってるかは置いておいて、自機はどこからでも参照できるものとしておけば敵玉はそれを参照してあたり判定を計算できることになります。
もちろん引数で回してもいいですが全てのタスクの引数領域が固定だった場合には役にたちます。

さて、タスクシステムというのはプログラミングというPC内に限ったことではなくて人間社会でのシステム構築にも通用すると思っています。
最近のアジャイル開発もそうですがどこにどうのような役割のタスクを生成してそれを受け継ぐのはどこか?
当然同時進行ということもあるでしょう。

この同時進行はプログラミングで言う並列処理にあたります。
ちなみにプログラミングの世界では並列処理のことをタスク、スレッドと呼んだりします。
並列処理はPC任せな分タイミングは自分ではなかなか把握しずらいですが空き時間さえあれば処理を実行してくれ、かつ優先順位はメインのほうが高いという使いどころでは優秀なシステムです。
私もスレッドや並列処理は多用してます。

人に置き換えても同じで、ある決まった時間に次のタスクに渡せるのはものすごく優秀だと思います。
むしろ並列処理でここまでにこの結果を返してほしい、またはメインが動くときにレスポンスが欲しいってのが多いかと思います。
そのレスポンスに対して次にどう支持するのかがメインの手腕の見せ所ですね。
あまりにもレスポンスが返ってこなければ別のタスクを立ち上げればいいわけです。

世の中簡単にはできてないので主軸がどう動くかで大きく変わりますね。

【ゆめじのひとこと】

【Read More...】

2016.12.28(Wed):PC/Program
タスクシステムとはプログラムでタスクを管理システムで、主にシューティングゲームが主流で作成されたものです。
私も独自のタスクシステムを構築したことがあります。
例えば1フレーム当たり1/30とすれば30fps(Frame per Sec)となるわけですね。

シューティングが一番楽なのでそれで説明すると
タスクは単純な1フレームの単純などうさになります。
敵の移動量、玉の移動量、次機の移動量など様々ありますがそれぞれをタスクとしてます。
画面に出てくればその分のタスクを追加、玉など画面外に消えればタスクの消滅。
全てのタスクが終われば1フレーム終了です。
もし1/30でタスク全体が終了しなければ処理落ちとして次のタスクまで待たされます。
昔のシューティングでは弾幕が多かったら遅くなるのはそれが原因です。
もちろん敢えて遅くすることもできます。

このタスクを追加したり削除したりってシステムはRPGでも応用がききます。
タスクに必要なデータはUNION(共用体)型で持てばどのタスクでもメモリ空間は同じになります。

私が作ったとときは結構古いので(かつDirextX対応)なので現在受けるシステムとしては流用が難しいところですが、面白いシステムなので使ってみたいとは思いますね。
それの現状の業務向けに発展形でタイマー+シーケンス制御ってのができてるわけですが。

まぁ、シューティングゲームとかでも半分はシーケンスですよね。
そのシーケンスで敵を出す(タスクを追加する、しない)ってだけで。

もう一回作り直そうかな?
でもフレーム単位でのタスク制御って受けてる仕事ではあまり関係ないかなぁ?
それでも1mSとかかなり高速な処理ループを作ったりしますけど(笑

【ゆめじのひとこと】

【Read More...】

2016.12.15(Thu):PC/Program
今まではExcelのCOMオブジェクトを利用して作成してたんだけど、ClosedXMLというライブラリがあるらしい。
コアはMicrosoftのものなので手順が楽ならそちらを選んだほうがいいかも?
というのもInterop.Excelはエクセルがインストールされていないとダメ。
しかもバージョンが異なったら動かないときもあるので開発環境と実実行環境でバージョンが異なるときに困る。

実はWordもExcelも圧縮されたXMLなので解凍してXMLのDOMを操作、その後圧縮すればできたりもするけど超めんどい。
それを単純にラッピングしてくれてるのがCOMオブジェクトであり、ClosedXMLライブラリ。

今回も含め今まではInterop.Excelを使用して処理してたんだけど実はこれ遅いんですよね。
かつOffice2013でやってもOffice2016で動くのでそのまま使ってました。
解放処理さえ忘れなければ遅いだけで問題にはなりません。

ただ、今後は速度の速いClosedXMLも検討しないと。
これはOfficeが入ってなくても操作可能。
かつ速度が速いというのであれば言うことなしですね。
プログラムの書き方は手続き以外ほぼ同じです。

まぁ、実はその前に問題があって・・・
エクセルファイルを開かれてると書き込みできない!!
ファイルにロックがかかっちゃうんですねぇ。

実はこっちのほうが厄介でCSVでも直接エクセルで開かれると操作不可。
テキストファイルにしてもインポート途中だとエクセルがロックかけちゃいます。
なので開いてない状態で書き込みを行うという判定、データ保持が必要になっちゃいます。

このエクセル処理を本来の目的の処理の中に入れるのは本末転倒。
だったらエクセルが単純に開けないファイル形式で保存しておいて、別のアプリでエクセル処理したほうが単純。
Readerは一瞬ですし書き込み可でのオープンもできますから。
見るだけならアプリ上に表示しても問題はないはず。

ってことを考えながらめんどくさいなぁ・・・と思う今日この頃。

【ゆめじのひとこと】

【Read More...】