■吉里吉里／ＫＡＧ／ＴＪＳ雑談質問スレ■その25

**名前は開発中のものです。** · 2011/12/16(金) 09:12:24.47

ノベルゲーム製作ツール吉里吉里/KAGのユーザーが雑談・質問をするスレです。
自作ゲームの進行状況や製作ツールについての話、TJS等の話題もどうぞ。
マルチポストはやめましょう。個人叩きも禁止です。

※スレで質問をするときは※
KAG/TJS/吉里吉里ドキュメント、スレの過去ログ、公式掲示板のログ、
FAQ、Google等で調べてからにしましょう。
努力の形跡が見られないとスルーされがちです。初心者？でも頑張れ！

吉里吉里スレ過去ログ倉庫
ttp://bbs.bokunatu.com/krkr/
吉里吉里２／ＫＡＧ３雑談質問スレ＿過去ログ
ttp://www.geocities.jp/kirikiri_log/

吉里吉里ダウンロードページ
ttp://kikyou.info/tvp/

ダウンロードしたアーカイブに含まれる「KAG System リファレンス」は
初心者にとって最も頼もしい教科書です。何度も繰り返し読みましょう。
■タグリファレンス … KAGの機能が網羅的、辞書的に載っています。
大よその機能(KAGでどんなことが出来るか)は把握しておきましょう。
■Tips/その他 … 陥り易いミスやより高度な使い方への足掛かりになる
数々のTipsが記載されています。
■TJSをもっと使うために
ゲームのインターフェイスをカスタマイズしたい、また
KAGの命令に無いことをしたくなったらまずここを読んでみよう。

必要に応じて>>3-5の公式掲示板や講座等を併用してください。
(併用に、紙媒体の参考本が欲しい人は、ダウンロードページにリストがあります)

前スレ　■吉里吉里／ＫＡＧ／ＴＪＳ雑談質問スレ■その24
http://toro.2ch.net/test/read.cgi/gamedev/1307083588/

**名前は開発中のものです。** · 2012/03/10(土) 18:40:58.29

吉里吉里本体のマルチスレッドは、最初の一回だけCreateThread()したら、あとは破棄せずにプールしてますよ？

**名前は開発中のものです。** · 2012/03/10(土) 18:54:57.87

と思いつつ、作った人にきいて＆眺めてみたらプールしてますがな＞マルチスレッド描画
既定値とずれてるときに増減してるだけで、通常はすっとばされるはずだからこれは誤差の範囲じゃないかな……

以下を stub 側に公開すれば事足りそう

GetThreadNum/GetAdaptiveThreadNum/BeginThreadtask/ExecThreadTask/EndThreadTask

**名前は開発中のものです。** · 2012/03/10(土) 18:56:34.50

ちなみに吉里吉里の描画スレッド処理がそこまで極端に効率の
上がらない理由は、スレッド処理が「レイヤの１命令実行単位」
になっているせいで、元々マルチスレッド化される処理の時間
単位がかなり短めなせいです。

特に吉里吉里はその部分はもともとコード最適化されちゃってるんで(^^;

重いアフィン処理を面積の大きいレイヤに対して適用すると理論値に
近い速度が出るようになりますよ。

**名前は開発中のものです。** · 2012/03/10(土) 19:04:34.18

GetAdaptiveThreadNum() は、実際にスレッド分割する必要があるかどうかを
実行する処理の処理ピクセル数から事前予測する関数なんだけど、処理ごとに
負荷がどのくらいかピクセル数に任意の「係数」をかけて計算するという極めて
adhocな実装なので、公開してもあまり意味が無いかも…。

公開するなら GetThreadNum/BeginThreadtask/ExecThreadTask/EndThreadTask の4つで。

**名前は開発中のものです。** · 2012/03/10(土) 19:15:55.53

ちなみにGetAdaptiveThreadNum()の実装はこんな感じ。

static tjs_int GetAdaptiveThreadNum(tjs_int pixelNum, float factor)
{
if (pixelNum >= factor * 1000)
return GetThreadNum();
else
return 1;
}

処理ピクセル数がfactorに1000掛けた値以下なら分割処理するように
してます。

一番軽いFill処理でfactorが150くらいなので、割と大きな面積でない
と分割処理がされないようになってるのがわかるかと思います。

**名前は開発中のものです。** · 2012/03/10(土) 19:16:24.36

こういう風になっている最大の理由は、「あらゆるＰＣ環境でパフォー
マンスの悪化を起こすことなく最大限のパフォーマンス向上を達成する
ため」です。

Corei7などの最近のCPUならこんな回りくどいことをせずに「必ず分割」
してしまっても最大限の高速化効果が得られるんですが、特に古いマルチ
コア環境の場合、スレッドを起こす処理だけでもけっこうなオーバーヘッド
があって、処理面積が小さいのにスレッド処理を行うとむしろパフォー
マンスが悪化するケースが多々ありました。

本当はスレッドを起こす速度を計測したりして個々の環境で敷居値を決定
するべきだったのですが、精密に測定する方法が思いつかなかったので断念。

吉里吉里コアは様々なPC環境で動かされるプログラムなので、古い環境で
実行速度が遅くなるような変更を加えるわけにはいかず、最大公約数的に
現在の実装に落ち着いています。