FC2ブログ

 |   | 

親変更の処理軽量化

8/29
22:03 (emeru) 重くなるのを何とかしたいなぁ・・・
22:04 (emeru) 親変更で相手がヘルパー出し消しするとどうしても重くなるんよなぁ・・・
22:06 (_609z) 重くなるのは神上位の必然
22:06 (_609z) Randomとか使えばすこしは軽くなるんじゃないかな
22:07 (emeru) んー、ヴェスタのコンセプトとして「如何に試合を軽く進行させるか」を課題にしてるんですよ(
22:08 (emeru) ちょこちょこ記述弄りながら試すか・・
22:09 (_609z) 無条件親変更は絶対重いからRandom%15=0とかにすれば少しは軽くなる
22:10 (emeru) 0F親変更できないじゃないですかーw
22:11 (_609z) 0Fって効くやついるのかね
22:11 (_609z) 海外キャラが多いらしいが
22:11 (emeru) 割とね ガードステートにヘルパーを固定させて居るキャラって居るものよっ
22:12 (emeru) 何となく安心感があるし<ガードステート固定
22:12 (_609z) 0Fしたいなら無条件じゃないとむりやな
22:13 (_609z) 重くなるのは必然だねぇ
22:13 (emeru) 試行錯誤してみよう・・
22:33 (emeru) 200回親変更でヘルパー奪う事に失敗した場合にのみ、そのヘルパーに親変更しないように・・と
22:33 (emeru) その間は重くなってしまうけど仕方ない

リンク:親変更の処理軽量化[MUGEN神キャラ置き場]
スポンサーサイト



NumExplodとHelperの出し消し

7/9
13:47 (ryusei_school) ちょっち~重さ関係で質問したいのですが
13:47 (ryusei_school) NumExplodを出し消しとかするとhelperとか同様な重さになるのですかぬ?
13:48 (DRM) NumExplodの出し消しとは何ぞや
13:49 (ryusei_school) NumExplod出現→出現後Explod消去→以下繰り返し
13:50 (DRM) NumExplodってトリガーですが、それを読み込んでExplodを消去ですかな?それだと重いと思いますけど
13:50 (ryusei_school) ほむ、重くなるのか
13:51 (DRM) まぁNumExplod読んでる時点で重くなりますが・・・
13:52 (ryusei_school) [State ,世紀末救世主]
13:52 (ryusei_school) type = Explod
13:52 (ryusei_school) trigger1 = 1
13:52 (ryusei_school) anim = 5557
13:52 (ryusei_school) ID = 4
13:52 (ryusei_school) removetime = -1
13:52 (ryusei_school) supermovetime = 9999999999999
13:52 (ryusei_school) pausemovetime = 9999999999999
13:52 (ryusei_school) ignorehitpause = 1
13:52 (ryusei_school) \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
13:52 (ryusei_school) [state ,DRM氏に敬礼!]
13:52 (ryusei_school) type = removeexplod
13:52 (ryusei_school) trigger1 = NumExplod(4)
13:52 (ryusei_school) id = 4
13:52 (ryusei_school) ignorehitpause = 1
13:53 (ryusei_school) Explodが重いのか NumExplodのトリガーが重いのかが分からなくなってきた・・・・
13:54 (ryusei_school) もうちょっと試行錯誤するか・・・
13:58 (DRM) Explodの出し消しはそんな重くないかも
13:58 (DRM) ヘルパーの出し消しの方が重いですね、多分
14:00 (DRM) OwnPal = 1で50個出して即消しでも全然重くない
14:00 (ryusei_school) やっぱおもくないのか・・・
14:03 (DRM) ヘルパー重いなやっぱりw
14:04 (ryusei_school) (´・ω・)

numexplod

7/9
01:36 (macbeth_) ちなみに重さはExplodの数自体が問題じゃないんですよ
01:36 (Nanayan) 他にあるんですか~
01:36 (macbeth_) 確かにExplod大量に出せば重くなるけどそれよりnumexplodがやばい
01:37 (nankotsu) そういえば以前色々な方が記事書いてましたね
01:37 (macbeth_) numexplodの管理ってexplodを出せる場所全てを一度チェックするというとんでもない方法なんですよ
01:37 (Nanayan) それを大量に使うと重くなるって感じですか?
01:38 (simotsuki) 多分ヘルパーと同じように領域で処理してるんでしょうね~
01:38 (macbeth_) だからnumexplod1個でexplod最大値分のリダイレクトをシテル計算
01:38 (macbeth_) 簡単な話、explodの最大値が10000ならトリガー1万個読み込んでるようなものだと思ってもらえれば
01:39 (Nanayan) うわぁ・・
01:39 (macbeth_) んで最上位勢って管理にnumexplodを使ってるキャラが結構いるのでそれで重くなるんです
01:40 (Nanayan) なるほど~
01:40 (nankotsu) numexplodはexplodの存在を確かめるトリガーだから、どうしても使いたくなってしまう・・・
01:41 (macbeth_) まぁ毎フレーム何十個も読み込むとかじゃなければ問題ないです
01:41 (macbeth_) てんことかの場合毎フレーム100以上読み込んでるんで(混線等含めて)
01:42 (simotsuki) それを知ってから
01:42 (simotsuki) [State -2]
01:42 (simotsuki) type = null
01:42 (simotsuki) triggerall = !ishelper
01:42 (simotsuki) trigger1 = var(29) := ifelse(numexplod(132392843) > 0,var(29) | 1,var(29) -(var(29) & 1)) && 0
01:42 (simotsuki) trigger2 = var(29) := ifelse(numexplod(68723873) > 0,var(29) | 2,var(29) -(var(29) & 2)) && 0
01:42 (simotsuki) trigger3 = var(29) := ifelse(numexplod(90840903) > 0,var(29) | 16,var(29) -(var(29) & 16)) && 0
01:42 (simotsuki) ignorehitpause = 1
01:42 (simotsuki) こんな感じで代入して後はvar(29) & ○ で処理するようにしました
01:42 (macbeth_) 自分自身が使うなら変数変換でいいね
01:42 (macbeth_) ただこれが相手のヘルパーとかだとそうもいかないのよ
01:43 (nankotsu) なるほどなるほど
01:43 (macbeth_) 変数使うってことは変数弄りするってことだからね
01:43 (simotsuki) 相手には使えませんなぁ
01:44 (simotsuki) 私の場合とにかく自分が使ってる数が多かったのできるだけ対処した感じです
01:44 (macbeth_) うむ、だから相手の状態チェックの方法が多い最上位勢は必然的に重くなる
01:44 (macbeth_) 自分自身が使うならしもつき氏の方法が最善なんだけどねー
01:45 (Nanayan) ある程度の重さは最上位だとしょうがない という感じみたいですね
01:46 (nankotsu) 神下位くらいまでならそういう管理方法も珍しいだろうから、まだ安心なのかな
01:46 (macbeth_) ある程度は妥協せざるを得ないってところかな
01:46 (macbeth_) 下位神くらいなら必要ないし、あってもしもつき氏の方法で軽くできますね
01:51 (ryusei) numexplodのトリガーで重くなるのか
01:51 (simotsuki) まぁ格ゲーやってれば平気w
01:53 (ryusei) そういやnumProjのトリガーでもnumexplod同様に重くなるのですかね?
01:53 (macbeth_) Projはそうでもないみたいだね
01:53 (ryusei) む、そうなのか
01:53 (macbeth_) ただProjは消せないって事と本体管理になるってのが不便
01:54 (ryusei) まあ、確かに・・・

処理軽量化:混線

5/15
01:40 (obelisk) うむむ・・・
01:41 (obelisk) watchモードで二人目から重くなる
01:41 (obelisk) 混線かなぁ
01:42 (ni-san) 別に関係ないようなあるような
01:43 (obelisk) vsモードだと問題ないんですよね・・・
01:44 (ni-san) あー
01:44 (ni-san) AI封印してないで余計なもん出しちゃってるとか
01:46 (obelisk) なるほど・・・
01:46 (ni-san) とりあえずAI作るといいかもですな
01:49 (obelisk) でもAIはデフォのがあるんですよ
01:49 (ni-san) デフォのというのはmugenのではなく別の?
01:49 (obelisk) はい
01:49 (ni-san) 多分それが余計なもん出して
01:49 (ni-san) そのせいで重くなってるんじゃねいかと
01:50 (ni-san) 例えば余計なヘルパーとか
01:50 (ni-san) 混線って自分のヘルパーも喰らいますからぬ
01:51 (obelisk) とりあえずnullして試してみます
01:51 (ni-san) 後はエラメ出しまくってるとめっちゃ重くなるかも
01:58 (obelisk) おー 戦闘中は治ったー
02:00 (ni-san) おk
02:00 (obelisk) 二人目以降登場のイントロだけ重い・・・
02:00 (ni-san) watchってサバイバルです?
02:01 (obelisk) サバイバルみたいな感じです
02:01 (ni-san) サバイバルだと前の情報を引き継いじゃうので
02:01 (ni-san) リセットせんとクッソ重いかも
02:01 (ni-san) ふつうのwatchで1vs1やるぶんには大丈夫なはずです
02:02 (obelisk) 大丈夫です
02:03 (ni-san) サバイバルで軽くしたいなら2ラウンド目とかでもイントロやるようにすることと
02:03 (ni-san) なんだっけな相手が違ったら全リセットするといいです
02:03 (ni-san) やり方は忘れた(
02:03 (ni-san) 多分IRCログにありんす
02:04 (rakurai) enemy,roundexisted=0から
02:04 (rakurai) かな
02:09 (obelisk) いろいろとありがとうございました
02:12 (ni-san) いえいえー

処理軽量化

2/21-22-23
20:02 (DRM) 上位神チャレ更新です。
20:02 (DRM) http://drmugen.seesaa.net/article/253427241.html
20:05 (DRM) 青針鼠が重すぎて泣ける
20:05 (ryusei) (´;ω;`)
20:05 (DRM) FPS1.5くらいしかなかったw
20:05 (ryusei) 重すぎだな・・・・
20:05 (ryusei) まだPMAがマシなのだろうか・・・
20:06 (DRM) RoundState <= 1かとあるエフェクトが出ると超重い
20:06 (ryusei) (((( ;゚Д゚)))ガクガクブルブル
20:06 (DRM) PMAの方がマシなレベルですなw
20:07 (DRM) qegさんには早急に更新してもらいたいところ
20:07 (qeg) 青針鼠さんはうちのPCじゃ軽かったから確認できていないが何が悪さしてるんだろ
20:07 (DRM) にゃんと
20:08 (DRM) あの竜巻エフェクト出るとメッチャ重いです
20:08 (DRM) あとは相手のヘルパー奪った後とか
20:09 (qeg) 絶対に混線だ!!でもどーすれば......

18:09 (qeg) 見てないかもしんないので一応言っておくと青針鼠さん更新しましたよ<DRM氏
18:09 (DRM_) 更新完了ですぬ
18:10 (qeg) 返しproj数に制限入れましたがまだ重いですか?
18:12 (DRM_) ちょっと待ってね
18:15 (DRM_) RoundState <= 1での重さは変わらず
18:15 (DRM_) あ、重くなった
18:16 (DRM_) 治ってませんねぇ・・・
18:17 (qeg) んー?proj数が重さの原因では無いのか?
18:18 (qeg) helpermaxは56に設定しててそれで軽いんだがな
18:19 (DRM_) 何かしらのヘルパーが間違って大量に消去召喚されているとか・・・
18:20 (DRM_) あとマニーの専用対策でroot,name="many"になっているところがありますよ
18:21 (DRM_) あー、この重さは間者とか偽装ヘルパーがある程度絡んでるかも。他の要因もありそうだけど
18:25 (qeg) 「root,name="many"」に関連するミスは確認出来なかった...のか?
18:31 (DRM_) んー、やっぱり問題は22101ステートにありそうねぇ
18:32 (DRM_) このステートの何かが問題になっていそう・・・
18:36 (DRM_) あー、多分間者が重さの原因かなこれ・・・
18:38 (DRM_) あー、やっぱそうだ。間者関連のステートで何か重くなることしてるなぁ
18:45 (DRM_) qegさん、大体の原因分かりましたよ
18:45 (qeg) おぉ
18:45 (DRM_) Projと間者や偽装ヘルパーの出し過ぎと竜巻エフェクトが重いのですね
18:46 (DRM_) Projと偽装ヘルパー無し、間者を1つだけにして竜巻エフェクトなしでようやく50前後ですけどw
18:47 (DRM_) Projっていうのは混線で相手ヘルパーが出すやつです
18:48 (DRM_) あと重さには関係ないですけど、試合後にソニックがガーステやジャンプステートに引き籠って試合が終わらない事態が多いです
18:48 (qeg) あれー?ヘルパーはまだしもProjは制限入れた筈なんだが。
18:48 (qeg) 引き籠りはAIの問題か
18:48 (DRM_) きっと制限入ってないんじゃないですかね
18:49 (qeg) root,numprojid(2000000) < 5 || random < 70
18:49 (DRM_) そのRandom<70が大問題でしょw
18:49 (DRM_) 結構頻度高いと思うよそれ
18:50 (Momizi_) randomそのまま使うのはお勧めしないですね
18:50 (qeg) triggerall=root,numprojid(2000000) < 7 最低限の返しProjが出るよーに
18:50 (qeg) 因みにroot,numprojid(2000000) < 5 || random < 70はStickhumanからのコピペ(
18:50 (DRM_) 多分時止め食らってProjが消えてないんだと思いますよ
18:51 (DRM_) ていうかソニック時止め耐性ないですよね?w
18:51 (Momizi_) lunatic現象ですね(
18:52 (Momizi_) あの子Alive=0になるのに時止め耐性ないからProjがひどいことになる
18:52 (qeg) 間者減らしたらF1が殺せなくなった件
18:53 (qeg) 専用にしたくないしどーしよ
18:53 (DRM_) 精度を上げざるを得ない
18:53 (macbeth) そもそも間者減らしたら倒せなくなるってのが理解できないんだが…
18:54 (Momizi_) 混線領域内に入ってないだけじゃないかな
18:54 (DRM_) 混線がうまく行ってない可能性も
18:54 (DRM_) 前から言ってるけど、開幕超重いですしw
18:54 (qeg) Proj制限の影響でしたとさ
18:55 (qeg) 間者の量関係無かったわー
18:56 (DRM_) でも間者5つ+1007ヘルパー5つ+偽装最大20個くらいって結構多いですよね
18:56 (DRM_) いや、多いですw
18:57 (qeg) <1だと汎用偽装が死ぬ
18:57 (qeg) enemy,numhelperで取得してるんで
18:57 (DRM_) それはもう精度上げるしかないと思うの
18:58 (qeg) というか間者含めてProj総数が18個(
18:59 (DRM_) とりあえず相手に出させるヘルパーが28個を超えるのは異常だと思うの・・・
19:00 (qeg) 今多少減らした
19:00 (Momizi_) 間者(1)+リダイレクト偽装(最大4)+探査(3)くらいかなぁ。最大でも
19:00 (qeg) numhelper(1007)<2 numhelper(451007)<2
19:01 (qeg) 1007は探査でも何でもなくただ多いんで偽装しやすくしてるだけです
19:01 (qeg) 使用してる奴が
19:04 (DRM_) 1007って偽装汎用化するなら数Fで調査できる範囲だと思うの・・・

19:22 (qeg) 今んトコ 専用以外全て<2でヘルパー出してる
19:22 (qeg) ファントムの100500を<2にすると死ななくなってしまいそーでものすごく不安。
21:01 (DRM_) でもqegさん、開幕の占有ヘルパーがまだ悪さしてるみたいですよ
21:03 (qeg) えー、それの解決法マジでわかんないんだよな
21:04 (DRM_) とりあえず記述段階から直してみるべき
21:05 (DRM_) 因みに開幕はこれくらい重い
21:05 (DRM_) http://drmugen.up.seesaa.net/image/mugen1-76403.jpg
21:05 (DRM_) 5.6FPS
21:07 (qeg) これはひどい、しかしあの占有一個ではリダ偽装が死ぬ
21:07 (qeg) drm氏の言うとおり組み直ししかなさそーだが....上手い改良法が解らぬ
21:08 (DRM_) 最終ヘルパーで占有して組み立てる
21:09 (DRM_) 最終ヘルパーだけで占有して、NumHelper(XXX) > 1で消去

19:30 (qeg) airmanみたいな奴には非常に便利だから1007はこのままにしとこう、量だけ減らそう
20:58 (qeg) DRMさんへ http://
21:00 (DRM_) おー、FPSが20前後に

21:03 (qeg) あ、DRM氏ー
21:03 (DRM_) はいな
21:04 (qeg) 占有改良してみました
21:06 (DRM_) んー、前よりかは軽いですなぁ
21:06 (DRM_) まだ30FPSくらい
21:10 (DRM_) enemy(1)のところをenemy(numenemy>1)に変えた方が良いですよ~
21:12 (qeg) 調べてみたところ警告諸々か
21:12 (DRM_) リダイレクト系使う時は
21:12 (DRM_) 数を調べるトリガーがあると良いですね
21:13 (DRM_) ただしNumHelper(XXX) && Helper(XXX),~はダメ
21:14 (DRM_) TriggerAll = NumHelper(XXX)
21:14 (DRM_) TriggerAll = Helper(XXX),~
21:14 (DRM_) こんな感じでしっかりと分けないとやっぱり警告メッセでます
21:15 (qeg) んー、警告で支障が出てるわけでも無いので保留って事で
21:15 (DRM_) いや、これが結構な重さになるのよ
21:15 (qeg) ドブッホ
21:15 (DRM_) まぁこの重さはまだ別なのがありそうですけどw
21:16 (qeg) 南斗、だったら修復せねば
21:16 (macbeth) エラメ、特に混線のエラメは影響が大きいよねぇ
21:16 (YANMAR) ヘルパー数があるからねぇ
21:19 (macbeth) 最近は混線というより親変更のエラメが大きいみたいだけど
21:20 (DRM_) Parentのあのエラメを消すのはなかなか出来ぬぅ
21:20 (DRM_) エラメじゃなくて警告メッセかw
21:20 (macbeth) あの辺は親変更理解しないでやろうとすると親変更が動かなくなるからねぇ

処理軽量化

2/20
01:15 (okihaito) 禍たん前より重くなったという意見が多いなぁ・・・個人的には今のがずっとずっと軽いんだが・・・
01:15 (T-S-Nameless) こっちでは前より軽いですねぇ
01:16 (T-S-Nameless) フルパワーモードでも
01:16 (Rick___) NumExplodトリガーを使っているならExplodMaxの数にもよるかもしれません
01:16 (T-S-Nameless) 私は1500でやってますなw
01:16 (Rick___) ヘブンズ12Pが起動したときによって重さが数倍違うのもそれのせいですし
01:17 (T-S-Nameless) リック氏のところだと軽いのに他だと超重力だったって意見ばっかでしたしねぇw
01:17 (Rick___) 軽い時はctrl+Sで100出ますが重い時はヘルパー出さない相手にも20とか出ますしねー
01:17 (okihaito) 私はMax200でやってるなー
01:17 (Rick___) 200w
01:17 (T-S-Nameless) すくなっw
01:17 (half_m) 私はExolodmax2000ですが、前より軽いかもしれないです。ただ10000だと前より確実に重いです。
01:17 (Rick___) せめて1000にしましょうw
01:17 (okihaito) Projは1000くらい
01:18 (T-S-Nameless) Projmaxは10000にしてますねぇ こちらは重さにほとんど影響しなさそうなので
01:18 (half_m) 同じくです
01:18 (Rick___) http://mugenrick.seesaa.net/article/235615807.html
01:18 (okihaito) デフォ環境になるべく近い状態で作成してる たまにMUGEN設定デフォで使われるし
01:18 (T-S-Nameless) あ、ジェネラナイ起動する時は500まで落としますけど(
01:19 (half_m) 7回おまけでジェネラナイをproj4000で動かしたときは死ぬかと思いました
01:19 (T-S-Nameless) プロジェクタイルとかexplodはいいにしても、ヘルパーがデフォだとこの世界は問題だらけですなw
01:19 (okihaito) ん~・・・やっぱnumexplodトリガーかなぁ・・・これでも少なくした方なのにな~
01:20 (Rick___) 一応ヘルパー数32ならなんとか動いて相手にヘルパー4つくらい出させることはできますが・・・
01:20 (okihaito) ヘルパー上限56は基本だけど2P側配置考えると上限対応はやっといて損はないよ
01:21 (Rick___) それ以下はさすがに動作保障外
01:21 (Rick___) 当然55とか奇数でも形が崩れないようにはやってますよ
01:21 (YANMAR) 動きはするけど殺傷力は保障しかねるなぁ
01:21 (okihaito) 禍たんはヘルパー2個出せればもう十分
01:22 (YANMAR) 2個だねぇ、相手に時止め耐性あるなら0個だけど
01:22 (okihaito) 理想は10個以上だけど
01:22 (Rick___) 殺傷力はどうしようもないですな 見た目は崩れないのはまあ普通

処理軽量化

1/23
04:10 (okihaito) selfanimexistも重くなるのか・・・禍たん自己判別にnumexplod,numproj,selfanimexist全て使ってる件
04:10 (okihaito) こりゃ帰ったら作業が大変だなぁ
04:10 (macbeth) selfanimexistの方はairの個数次第ですねぇ
04:10 (okihaito) Explod化予定です お察し下さい
04:11 (macbeth) 把握しました
04:11 (macbeth) まぁanimの数=explodの最大数みたいなものだと考えて調整するしかないですねぇ
04:12 (macbeth) いくら重くなるっていってもanimを大量に登録して毎フレーム大量に読み込みでもしない限りそこまで重くならないはず
04:12 (okihaito) 全ステコンに自己判別あるからなぁ・・・
04:12 (macbeth) あー、全ステコンに入れると耐え難いレベルになりそうですね
04:12 (macbeth) ってか現状で重いのってそれが原因だったりするんじゃないですかねぇ
04:13 (okihaito) gametime変数もう一つ用意してそれで自己判別した方がいいかもしれん
04:13 (macbeth) うーん
04:13 (macbeth) 全てのステコンに入れるんじゃなくて・
04:13 (macbeth) 自己判断チェックで問題がなかったら変数をセット、でいいんじゃないですかねぇ
04:14 (macbeth) 毎フレームその変数をリセット、判断を繰り返せばselfanimexistの個数を減らせると思いますし
04:15 (okihaito) 常時フラグ代入でそのフラグ判断か?良いかもしれないな
04:15 (macbeth) 流石にリダイレクトでの自己判断には使えないですけど、自分自身で読み込む分にはありなんじゃないかなぁと
04:15 (okihaito) 今はまだヘルパー未使用同然なのでとりあえず自己判別すればいいかな
04:16 (okihaito) ヘルパーはヘルパーで本体同様自己判別フラグ立てればなんとかなりそう
04:16 (macbeth) ですねー
04:16 (okihaito) うまくいけば処理が軽くなる上記述容量も下げられそうだ 今日来て正解だったな

numexplodの重さ

1/23
02:31 (macbeth) あー、オキ氏
02:32 (macbeth) Explodなんですけど
02:32 (macbeth) mugenの設定のexplodの最大数に比例して重くなるそうです
02:32 (okihaito) それはリック氏の記事でご存じです
02:32 (macbeth) だからexplodhozonn ha
02:32 (okihaito) うちの設定はたしかExplodmax=200程度
02:33 (macbeth) explod保存は場合によっては酷いことになりますね
02:33 (YANMAR) 使いまくると大変なことになるっぽいなぁ・・
02:33 (YANMAR) 重要なのだけexplodでやるのが無難なんだろうか
02:33 (okihaito) ですよねー でも保存しなくてもFPS7くらいしか上がらんのよね
02:34 (macbeth) 200くらいでそれだと
02:34 (macbeth) 1000、2000になるともっとかなぁ…
02:34 (ni-san) 20000とかにしてるなあ
02:34 (ryusei__) 自分は200000だぬ
02:34 (okihaito) 保存してるのはstate,time,pos,vel,facing,その他もろもろで約40個ほどExplod常駐してる
02:34 (ryusei__) あ、ひとけた多かった
02:34 (YANMAR) 1000だったけど更新前の聖者とかかなーり重かった
02:35 (macbeth) explodの数というよりnumexplodの方が影響大きいのかな
02:35 (macbeth) 変数に変換する際にnumexplodを大量に読み込むから…
02:35 (okihaito) ん~?どうだろ 個人的にはExplodの消去→召喚の処理が多すぎるからだと思う ヘルパーもそれするとクソ重いし
02:36 (okihaito) とりあえずステコン数が多いから重いと見てる
02:36 (macbeth) ステコン数の多さは重さに響きますねぇ…
02:36 (YANMAR) numexplodトリガーがあった時点でモロにくるっぽいなぁ
02:37 (okihaito) ですね だからプレイヤーヘルパーはあまり常時監視読ませないようにしないと処理が酷い酷い
02:37 (macbeth) てんこも常に一番上でステ抜けさせてますねぇ
02:37 (YANMAR) ヘルパーのステコン数減らすのと同じくらい、numexplodトリガーも減らしたほうがいいのかなぁと
02:38 (macbeth) ただそれ差し引いても1フレームで3000くらいのステコン読み込んでるけど
02:38 (okihaito) numexplodトリガーか・・・処理に関係してるとなると厄介だな・・・かなり使うし
02:39 (okihaito) numexplodとnumprojidはかなり使いやすいから処理に関係して欲しくないが…実際どうなんだろ
02:39 (YANMAR) projはまだ軽いみたい?検証してないけども
02:39 (macbeth) とりあえずnumexplodが関係してるのは間違いないっぽいですねぇ
02:40 (YANMAR) 親変更しかりある程度重くなるのは仕方無いってことで割り切るのもありかなぁ
02:40 (okihaito) 帰ったら一度無駄にnumexplodトリガー詰め込んでみるかな
02:41 (macbeth) そこら辺はしもつき氏のブログに詳しくあるかな
02:41 (YANMAR) http://simotukinew.blog135.fc2.com/blog-entry-655.html
02:43 (okihaito) なるほど・・・かなり差が出るんだな・・・
02:43 (YANMAR) まさかここまでとは思わなかったという感想ですなぁ
02:43 (okihaito) 変数節約してるし こりゃ処理軽量化の為に変数化しといた方がいいかもしれんなぁ
02:43 (okihaito) トリガーだけで重くなるのは初耳だったわ
02:44 (macbeth) 重さに関しては
02:44 (macbeth) トリガー自体が重いって話もあったね
02:44 (okihaito) それもまぁあるけど 変数代入やnumexplodトリガーは群を抜いて重いっぽいね
02:44 (macbeth) あー…代入を多用すると酷いですね
02:45 (macbeth) てんこが重いのも多分そこら辺が原因…
02:45 (okihaito) うちの深淵蛟が代入多用者ですからね
02:45 (macbeth) ショトカ3は狂気の沙汰ですね(
02:45 (okihaito) つかあれぶっちゃけ要らない
02:46 (ni-san) ひでえw
02:46 (okihaito) 基本OFFでデバックしてるし
02:46 (macbeth) ショトカ3で観戦してた通りすがり氏ェ…

処理の軽量化

11/8
18:09 (macbeth) やっぱトリガーを纏めた方が軽いみたいだなぁ…
18:10 (simotsuki) あれ?この前纏めない方が軽いって誰か言ってませんでしたっけ?
18:11 (macbeth) ちょっと調べて見たんだけど纏めたほうが軽いっぽい
18:11 (Tomitakezihou) こんばんわ
18:11 (simotsuki) そうなのか~
18:12 (macbeth) てんこのトリガー片っ端からまとめたら少し軽くなったわ
18:12 (Rick_Hong) それは意外
18:12 (macbeth) トリガーそのものが重いっぽい
18:12 (Rick_Hong) 同時に満たす可能性の高いものはまとめた方が良いかもしれませんね
18:13 (simotsuki) 全部満たす場合は纏めた方が軽くて満たさない物が多い場合はまとめない方が軽いのかな
18:13 (Rick_Hong) 逆に滅多に満たさないものはまとめ無い方が良いかと 理論的な話で実験してませんが
18:13 (macbeth) あと何故かtrigger x よりもtriggerallの方が重いという…
18:13 (Rick_Hong) 実際そうっぽいです
18:13 (macbeth) ちなみに
18:14 (Rel) allと1,2,3...の分?
18:14 (macbeth) trigger1~5まで分けるより||で纏めたほうが軽いってのもあるっぽい
18:14 (Rick_Hong) なるほどー
18:14 (macbeth) トリガーを増やすよりとにかく1行に纏めてトリガーそのものを減らしたほうが効率がいいのかも…?
18:15 (macbeth) てんこも可能な限り纏めてみたら相手がヘルパー出してない時でも出してる時でもFPSが1増加したので
18:16 (Rick_Hong) 見やすさとのトレードオフかな・・・
18:18 (simotsuki) うーん。確定したら纏める事も考えよう
18:19 (Rel) 完成したら纏めてスパゲッティソース
18:19 (simotsuki) やっぱちょっとでも軽い方が使う人にとっては良い
18:20 (macbeth) もうちょっと軽量化出来そうだなぁ
18:20 (macbeth) 親変更使用した専用対策用のステート作るとか
18:20 (macbeth) 無駄に読み込むくらいなら直接用意したステートに飛ばす方がいいし
18:21 (Rick_Hong) あと必ずステート移動するなら邪眼キラーを入れないという手もありますね
18:22 (macbeth) 親変更だけ必要な場合は邪眼の記述を読み込む前にselfstateした方が良さそうだね
18:22 (Rick_Hong) 今私はループステートしか邪眼キラー外していないですけどね
18:27 (macbeth) うーん
18:28 (macbeth) 混線ヘルパーにもスイッチ変数作るか
18:28 (macbeth) 無駄にenemyリダイレクトがあるのはよろしくない
18:31 (Rick_Hong) そういえば混線でTargetStateを実行するのとトリガー増やすのはどっちが軽いんでしょうね
18:31 (Rick_Hong) 今はPlayerIDExist(Parent,ID)入れていらない時はTargetState実行させていないのですが
18:32 (macbeth) ふむ
18:32 (macbeth) トリガー1個ってか
18:32 (macbeth) PlayerIDExist(Parent,ID)&&の形で入れれば軽くなりそうだけど
18:33 (macbeth) トリガーとステコン、どっちが重いんだろうねぇ…

処理の軽量化

11/7
16:51 (macbeth) うーん、やっぱ混線が重いんだよなぁこれ
16:51 (macbeth) 混線off時 gamespeed = normal Ctrl+S無し 試合中FPS50~15
16:51 (macbeth) 混線on時 同上       同上 試合中FPS10~3
16:51 (Awamizu) 混線だけなら60いけるなじゃないかな(
16:51 (macbeth) ちなみに言っておくと
16:52 (macbeth) 最新版のヘブンズさん
16:52 (macbeth) 私のPCじゃFPS8以下です
16:52 (Awamizu) 私のPCでも10切る。
16:52 (Awamizu) いいときで15くらい(
16:52 (macbeth) あぁ
16:52 (macbeth) ちなみにgamespeed=fast 9 Ctrl+Sでね
16:53 (Awamizu) んー・・・なんで試合終わったらExplod増えるの・・・
16:53 (Awamizu) 3000超える(
16:53 (macbeth) normalでCtrl+S押さない状態のヘブンズさんとか考えたくない
16:55 (macbeth) そういえば
16:55 (macbeth) 最新版のてんこって少しは軽くなってるのかなぁ…
16:56 (macbeth) 更新するたびに警告メッセージ削減とトリガー調整してるんだけど
16:56 (macbeth) もみもみのところだとてんこどのくらいの重さ?
16:56 (Awamizu) ん、どうだろ。結構重かった記憶
16:56 (macbeth) 前はFPS30くらいって言ってたけど
16:57 (Awamizu) 前30もあったかな(
16:57 (macbeth) あぁ
16:57 (macbeth) 相手が何もしてないリメイク版黒い子って話だった
16:58 (Awamizu) 見てみよう。
16:58 (macbeth) ん?
16:58 (macbeth) やっぱり&&使ったほうが軽いのか?
16:59 (macbeth) うーん、邪眼はやっぱり&&の方がいいのかな
16:59 (Awamizu) トムさん相手に10~17FPS
16:59 (macbeth) ふむ
16:59 (Awamizu) うぇ、うぇーい・・・
17:00 (macbeth) トムキラーの時間判断にexplod使ってる影響を考えても重いなぁ…
17:00 (Awamizu) Explod増えるの絶対これやん・・・
17:00 (Awamizu) デバック文字に!NumExplod(XXX)なくてRoundState!=2で消してねぇ(
17:00 (Awamizu) おまけにremovetime=-1
17:00 (macbeth) おいィ?
17:01 (Awamizu) 今まで試合後重かったのお前のせいかよ(
17:01 (macbeth) あー
17:01 (macbeth) triggerallが重い乗って
17:01 (macbeth) 重いのって
17:01 (macbeth) もしかして内部では分割されて処理されてるのかなぁ
17:01 (Awamizu) trigger1=1で1回1回関数呼び出してるんかね。
17:02 (macbeth) 例えばtriggerallが3個あってtrigger1~trigger5まで各2個ずつだったら
17:02 (macbeth) trigger1の前にtriggerallを読み込み、trigger2でも…みたいな感じでやってるとか?
17:02 (Melt) 5*(3+2)de
17:02 (Melt) でやってると私も思います
17:03 (Awamizu) ふむ
17:04 (Awamizu) んー
17:04 (Awamizu) 重くなると思って分割したけど&&のがいいのかねぇ・・・
17:04 (macbeth) これを見る限りではそうなのかなぁ
17:04 (macbeth) http://drabs.blog40.fc2.com/blog-entry-427.html
17:04 (vesperAFK) [script] 制作日記 重さの検証
17:04 (Awamizu) あれmまだ増える(
17:05 (Awamizu) &&に変えるのめんどいよままん・・・
17:05 (macbeth) trigger1を10000個とtrigger1=1&&1&&1&&1&&1じゃかなり違うってさ
17:05 (Awamizu) みたいだねぇ
17:05 (macbeth) トリガーを読み込むっていう処理が重いらしい
17:06 (Awamizu) トリガー1つにまとめると必ずそのトリガー分は読み込むから重くなると思ってた・・・
17:06 (macbeth) それ以上にトリガーを読み込むのが重いってのは盲点だったね
17:06 (Awamizu) そんでallを極力減らすと。
17:07 (macbeth) 予想なんだけど
17:07 (macbeth) triggerall、トリガーが分割されてるとさらに重くなるんじゃないかな
17:07 (macbeth) triggerallとtrigger1が200個よりも
17:08 (macbeth) triggerallが200個でtrigger1~trigger50が各4個の方が重いのかも?
17:08 (macbeth) ちょっと実験kfmde
17:08 (macbeth) 試してみる
17:08 (Awamizu) んー
17:08 (Awamizu) こんだけ違うならやっぱり&&にしたいなぁ・・・
17:08 (macbeth) 最近実験KFM大活躍だな…
17:09 (macbeth) 未だにライフの最大値マイナスでしかも常時nokoだけど…w
17:09 (macbeth) あれでエラメが出ないのが未だに信じられないんだよねw
17:09 (Awamizu) よくわからんねぇ
17:09 (macbeth) ちょっと実験してみるよー
17:09 (Awamizu) Defenceとかもそうだけどパラメーター関係が(
17:10 (macbeth) Defenceにマイナスが使えるとはこの海の(ry
17:10 (Awamizu) 0の時点で落としてください・・・
17:11 (macbeth) さて
17:11 (macbeth) エラメが全く出てないKFMで
17:11 (macbeth) triggerallの実験開始っと
17:11 (Awamizu) triggerX tirggerXXよりも||のが軽くなるんかな。
17:11 (macbeth) たまにはこういう実験も大事だよね
17:12 (macbeth) んー
17:12 (macbeth) &&の方が軽いってのはあるけど||はどうなんだろう
17:12 (macbeth) ちょっと待ってそれも見てみる
17:12 (Awamizu) やっと試合後60.0FPSになった・・・w
17:12 (macbeth) お~
17:12 (macbeth) いいなぁ軽そうだなぁ
17:13 (Awamizu) んー・・・試合中は20切るの普通なんだけどね(
17:13 (macbeth) やっぱ
17:13 (macbeth) ヘルパーそのものが重いよね
17:13 (Awamizu) そういえばこういう実験のときもぬるめーかー役立つよねぇ
17:14 (Melt) 試合後で60fpsってすごいなあ・・・
17:14 (Awamizu) 変数リセットくらいしかしてないからなぁ
17:15 (Awamizu) 私もトリガーの実験してみるかー
17:15 (Awamizu) -2におけばいいや(
17:16 (macbeth) 200個くらいじゃ差がわからんな
17:17 (Awamizu) 2000とかじゃないとねぇ
17:17 (Awamizu) とりあえず1000でちゃれんじ。
17:18 (Awamizu) うおw糞おめぇw
17:18 (macbeth) うわ露骨に重くなった
17:19 (Awamizu) 1000で1.5FPSだは
17:19 (Awamizu) 2.2まではあがった。
17:19 (macbeth) 3000個+3000個で2.5
17:20 (Awamizu) ん、これ10000個じゃね(
17:20 (macbeth) 吹いた
17:20 (macbeth) それは死ぬわw
17:20 (Awamizu) 10000だったw
17:21 (Awamizu) うおwこんなに違うのかw
17:21 (macbeth) あ、私のPCでこの実験死ぬわ(
17:21 (Awamizu) trigger1=1&1&1&1&1&1&1&1&1&1 1000個で90~95FPS
17:22 (macbeth) えーっと
17:22 (macbeth) triggerall=1を3000個に
17:22 (macbeth) trigger1~3000=0を投入するという暴挙
17:23 (Melt) うわあ・・・。
17:23 (macbeth) あー…やな予感がするぞー
17:23 (macbeth) 死ぬ
17:23 (macbeth) 1切った
17:23 (macbeth) 0.9
17:23 (Awamizu) www
17:23 (Melt) あらまあ
17:23 (macbeth) tteka
17:23 (macbeth) PCが糞スペ過ぎて参考にならん
17:24 (macbeth) 火狐消してCPUやメモリ全てmugenに投入
17:24 (Awamizu) お?
17:24 (Awamizu) trigger1=1 10000個で2.2FPS trigger1=1&&1 5000個で9FPS
17:25 (Awamizu) 私もマクベス氏のでやってみるか。
17:27 (Awamizu) まーちゃんの実験したら5.3FPSだったにゃ(
17:28 (Awamizu) ん、やっぱり||でも軽くなるなぁ・・・
17:29 (Awamizu) triger1~1000=0||0||0で20FPS前後だは。
17:29 (Awamizu) やっぱり単純にトリガー数増える=重くなるって考えてええんかなぁ・・・
17:49 (Awamizu) まーちゃんの実験やってみたのでログどうぞ。
17:49 (macbeth) 逆に軽くなった?
17:50 (Awamizu) trigger1~3000で5.3くらい。
17:50 (macbeth) triggerallの個数も3000?
17:50 (Awamizu) んですよ
17:50 (macbeth) ふむ…
17:50 (macbeth) 6000でそれってことは
17:50 (macbeth) 相当重いみたいだね
17:50 (Awamizu) んだねぇ
17:51 (macbeth) 5000 5000で10000とか想像もしたくないな…
17:51 (Awamizu) とりあえず、trigger数は減らしたほうが軽くなるかも。
17:51 (macbeth) えーっとここまでの纏めだと
17:51 (macbeth) 1 triggerallはtrigger xの処理ごとに読み込む
17:51 (macbeth) 2 トリガーの読み込みは&&や||で纏めたのより重い
17:52 (macbeth) こんな感じ?
17:52 (Awamizu) かなぁ
17:52 (Awamizu) 私1人だとなんともいえないけど。
17:54 (macbeth) トリガー数減らして再実験
17:54 (Awamizu) とりあえず更新したらトリガー減らす作業が始まる・・・
17:55 (Awamizu) -2とか混線ヘルパーステートとか、重くなるところだけでもしておかないと・・・
18:04 (macbeth) うー…てんこ邪眼の数ぱねぇ…
18:04 (macbeth) 準汎用が73個くらいあった
18:04 (macbeth) trigger74まであったお…
18:09 (macbeth) ふと思ったんだけどさ…
18:09 (macbeth) triggerxとtriggerall、どっちの処理が優先順位高いんだろうね
18:10 (Awamizu) triggerall=var(0):=1
18:10 (Awamizu) trigger1=var(0):=2
18:11 (DRM) triggerallでリセットして、triggerXで条件付けてセットするのはよくあるけど
18:11 (macbeth) triggerxの方が下かー
18:12 (Awamizu) でしょうねぇ
18:12 (Rel) そりゃまぁねぇ
18:14 (macbeth) んー、内部の処理的にはtriggerallが複数回読み込まれてるような感じの重さなんだがなぁ
18:14 (Awamizu) んー
18:15 (Awamizu) triggerall=var(0)!=1
18:15 (Awamizu) trigger1=var(0):=1||0
18:15 (Awamizu) trigger2=var(0):=2||0
18:15 (Awamizu) こんなんで確かめられんかね。
18:17 (macbeth) 確かめるなら||じゃなくて&&かな
18:17 (macbeth) ふむ、2になるか
18:17 (macbeth) となると複数回読み込まれてる訳じゃなくて何か他の要因があるのかな
18:17 (Awamizu) んーどうだろ・・・
18:17 (macbeth) とりあえず今のところわかってるのはtriggerallは何かよくわからないが重いってことだけなんだよなぁ
18:18 (Awamizu) あや?私1になったんだが。
18:18 (Awamizu) あ
18:19 (Awamizu) var(0)本体Explod管理してる(
18:19 (Awamizu) ん、それでも1か。
18:19 (macbeth) 上ので?
18:19 (Awamizu) んだねぇ
18:19 (macbeth) そもそも
18:20 (macbeth) 上のだとtrigger1で終わると思うんだ
18:20 (Awamizu) &&だね(
18:20 (Awamizu) うむ、2になった(
18:21 (Awamizu) というか、単純にtirggerall=var(0):=var(0)+1にすればよかったといまさら思った
18:21 (Awamizu) -2とかにおくとあれだけど(
18:22 (macbeth) 邪眼が重い…減らしたい…
18:22 (Awamizu) んー・・・allはよくわからんねぇ
18:22 (Awamizu) 極力減らしたほうがいいのは確かかなぁ
18:23 (macbeth) しかし10000まであると威力が全然違う…
18:23 (macbeth) 本音を言えばスペックさえ許せば25000まで欲しい…
18:23 (Awamizu) 載せても強化式かな(
18:23 (macbeth) ってか
18:23 (macbeth) 邪眼キラーが必要じゃなくなる
18:24 (macbeth) normal化の利点はそれもあると思うんだ…
18:24 (macbeth) 親捏造のね
18:24 (Awamizu) んだねぇ
18:24 (macbeth) このクッソ重い邪眼がなくせるのはいいことなんだが…
18:25 (Awamizu) しかし強制Normal化はなぁ・・・
18:25 (macbeth) そもそも本体親変更も強制normal化も許容したらどこまでも許容されるわ…
18:26 (Awamizu) 邪眼がどうにか軽くできればええんだがねぇ・・・
18:37 (macbeth) てんこの混線ってPossetのトリガー多いんだよなぁ…
18:38 (Awamizu) そういえば
18:38 (macbeth) 最初の1回だけPossetするって事出来ないのかなぁ
18:38 (Awamizu) &&と+ってどっちが軽いんだろうか。
18:38 (macbeth) &&と+じゃちょっと意味が違うからなぁ…
18:38 (Awamizu) ishelperの場合だと+使ってたからなぁ
18:38 (Awamizu) ||だった(
18:39 (macbeth) んー
18:39 (macbeth) そうなんだろう
18:39 (Awamizu) そうなのかー
18:39 (macbeth) どうなんだろう(
18:39 (Awamizu) 試してみるかー
18:40 (macbeth) そうそう
18:40 (macbeth) ちょっと考えたんだけどさ
18:40 (macbeth) enemy用のステート軽量化のためにステート返しも変数管理にしたらどうなんだろう
18:41 (Awamizu) あー
18:41 (Awamizu) それはやろうとしてる
18:41 (Awamizu) 周期とかも変数管理で。
18:41 (macbeth) あれの方が合理的だよね
18:41 (Awamizu) 垂れ流しも変数管理に変えたからのぉ
18:42 (Awamizu) Enemyリダイレクトも何度も使うよりかは変数に入れたほうが楽だし(
18:44 (macbeth) あー
18:44 (macbeth) ヘブンズさんは基準の位置にpossetしてからposaddしてるのね
18:44 (macbeth) そういう方法もあるのか…
18:44 (Awamizu) 私はPosAddしか使ってない(
18:45 (macbeth) てんこは常時Possetで本体追従だからなぁ
18:45 (macbeth) でもあれ止めようかなぁって思ってるんだよね
18:45 (macbeth) 鬼巫女Xみたいに真ん中に集めて置いたほうが便利そう
18:45 (Awamizu) リメイクは真ん中だなぁ
18:45 (Awamizu) Xとやるとかぶるからちょいとずらしてるけど。
18:47 (Awamizu) trigger1~10000=IsHelper(1)+IsHelper(1)+IsHelper(1)+IsHelper(1)+IsHelper(1)で2.7FPS
18:48 (Awamizu) 読み込みはんぱねぇ(
18:48 (Awamizu) んー||に変えても2.6FPSか。
18:48 (Rel) 文字数の違いかな
18:49 (macbeth) そこまで差はないってことなのかな
18:49 (Awamizu) たぶん文字数の差でしょうねぇ。
18:49 (Awamizu) 内部処理的には変わらなさそう。
18:50 (Awamizu) まぁ、文字制限考えると+のがいいのかな。
18:51 (Rel) んだぁね
18:53 (Awamizu) うーん、triggerall=(!)IsHelperは&&使うのと使うのどっちがいいのだろうか・・・
18:53 (Awamizu) あんまりこれは&&でつなげたくないのよねぇ
18:56 (Awamizu) ん、文字数って256までだっけ
18:57 (macbeth) 256…だったかな?
18:57 (Rel) 255
18:57 (Awamizu) ほむ
19:07 (Awamizu) んー軽くするために仕方なしとはいえ、見にくくなるトリガー・・・w
19:08 (macbeth) 元々酷いので気にしてない(
19:08 (Awamizu) んー・・代入は&&で結ばないほうがいいかな。
19:09 (macbeth) := は流石に&&でつなげない方がいいんじゃない?
19:09 (Awamizu) だよねー
19:09 (Awamizu) 無条件に代入しそう。
19:09 (macbeth) てんこの記述かなり見にくいはず
19:09 (macbeth) 記述整理にスペース削除の嵐で(
19:10 (macbeth) うーん
19:10 (macbeth) 本気で軽くするならtrigger1~xまでを||でつなげるべきなんだが…
19:10 (macbeth) 余裕の256文字オーバー
19:11 (Awamizu) そこはtrigger2で我慢してる(
19:11 (macbeth) いや
19:11 (Rel) || 0 && Var(X) := やれば代入されてもスルーできるん
19:11 (macbeth) trigger1でまとめられればtriggerall使う必要なくなるじゃない?
19:11 (macbeth) だから全部纏めちゃいたいんだけど…
19:11 (Awamizu) あー
19:12 (Awamizu) んでも正直どうにも(
19:12 (macbeth) ですよねー
19:12 (macbeth) あぁでも
19:13 (macbeth) 文字数に余裕があれば
19:13 (macbeth) 各トリガーの最初にtriggerallの条件入れちゃうって手も
19:14 (Awamizu) triggerallとtrigger1,trigger2両方に書くのどっちがかるいんかね。
19:14 (Awamizu) 普通だとallのが軽いとおもうが(
19:14 (macbeth) 相手旧鬼巫女、gamespeed=fast 9、ctrl+sでFPS11~12…
19:15 (macbeth) ちょっとだけ軽くなったなぁ…
19:15 (macbeth) いや普通に考えたら重いんだけど
19:15 (macbeth) オキ氏も言ってたけど軽いってステータスだよね
19:16 (macbeth) しかしヘルパーそのものが重いって問題もあるからなぁ
19:21 (Awamizu) 注釈が消えていくぅ~・・・
19:21 (macbeth) 注釈は投げ捨てるもの
19:45 (Awamizu) やっと-2の書き換えおわた・・・
19:45 (Awamizu) どんくらい軽くなったのかしらん・・・
19:46 (Awamizu) エラー(
19:46 (nisanka) どんまい
19:56 (Awamizu) んー・・・・軽くはなった・・・のかな(
19:57 (nisanka) わからんのか
19:57 (Awamizu) まぁ、-2だけだしねぇ・・・
19:57 (Awamizu) そんなに大きく変わるとは思ってなかったし。
19:58 (nisanka) ほむ

リンク:軽くしたければ[製作日記]

処理の軽量化

11/3
12:30 (Rick_) ちなみに警告メッセージを出してた時よりFPSが20ほど上がってた(
12:30 (Rick_) ターボモードですけどね
12:30 (DRM) ほへーw
12:31 (Rick_) やっぱり記述次第でいくらでも軽くできるんですねー
12:32 (Rick_) ヘブンズさんも公開版より結構軽くなったと思います
12:32 (DRM) ですねぇ。次回は余分なName保護も外そうかと思っています
12:32 (Rick_) トリガーは工夫が大事ですねー
12:33 (Rick_) そういえばtriggerallって重くなりやすいんですかね?
12:34 (DRM) それは分からないけど・・・イメージ的に重くなりそう(
12:36 (Rick_) trigger1とtriggerallだけで構成されたトリガーはtrigger1だけで構成されるより重くなるんですかねー
12:37 (Rick_) ちょっと実験キャラ作ってみます
12:43 (Rick_) trigger1=1を30個並べたNullを2000回ループさせてターボモードにした時のFPS:93
12:43 (Sance) 自分も一回やってみよう
12:43 (Sance) 気になる(
12:44 (Rick_) そのtrigger1をtriggerallにした時のFPS:93
12:44 (Rick_) 変わらなかった(
12:44 (DRM) お疲れさんですw
12:44 (Rick_) もう1つ実験
12:44 (Rick_) VarSetとNullの代入はどっちが軽いか
12:45 (Melt) ほー・・・
12:45 (Rick_) Nullによりvar(1):=1で2000回ループ:174
12:49 (Rick_) うーん・・・ほとんど差は無いように感じられますねー
12:50 (DRM) VarSetもNullも変わらないと・・・
12:50 (Sance) テストキャラを重くしすぎたw 重くしすぎた
12:50 (Rick_) ただこのIRCのソフトで重さが変わることもあって、正確なFPSを図れないので一旦落ちます
12:50 (Sance) 大事な事なので(ry
12:50 (DRM) それじゃあVarAddも変わらないのかな
12:50 (Rick_) 実験終わったら戻ってくるよー
12:56 (Sance) trigger1を100個、2400ループ、45.8fps, triggerallを99個,trigger1を1個、2400ループ 46.2fps
12:56 (Sance) 謎なんだが(
12:57 (Sance) あー、2キャラ同時にやってたからその倍か(
12:57 (Sance) 結論:ぶっちゃけ殆ど変わらん
12:58 (Melt) ほむー!
12:59 (Sance) 自分で調査した結果:何故かtriggerallの方が微妙に軽かった
12:59 (Rick_) 実験結果:代入とVarSetの重さは変わらない
13:00 (Rick_) あら?
13:00 (Sance) 両方とも3かいずつやって、数値は安定してたので・・・
13:00 (Rick_) 誤差の範囲内では?w
13:00 (Sance) 誤差やろうねw
13:01 (Rick_) ちなみにもう1つ実験してました
13:01 (Rick_) var(0):=1のステコンを5個並べたのを2000ループさせたのと
13:01 (Rick_) var(80):=1のステコンを5個並べたのを2000ループさせたの
13:02 (Rick_) つまり警告メッセージがどれくらい重いか、ですね
13:02 (Sance) ほむ
13:02 (Rick_) ターボモードでの結果…前者:120FPS、後者:20FPS
13:02 (Rick_) 思って以上に重かった
13:02 (Sance) 結構変わりますねぇ
13:07 (Sance) varsetとnullの代入自分でも試してみたけど全然変わらんねw
13:12 (Sance) explodmaxを適当に高くしてみたら本当に重くなったわ・・・100000あたりでターボモードがあまり意味を持たなくなった(
13:12 (Rick_) メモリ確保の時点でかなり重くなりそうですねー
13:13 (Sance) explodの重さで実験してみようと思ったけどそれ以前の問題だなぁこれは・・・
13:15 (Rick_) Explod出し消しの実験もした方がいいかも?
13:15 (Rick_) でもなんかつかれちった
13:20 (Sance) 出し入れって結構重いのねぇ・・・
13:20 (Sance) explod10000出しても全く問題なかったのにremoveexplod一つ入れただけでFPSが死んだ(
13:21 (Rick_) ですねー
13:21 (Rick_) 本体sysvar保護も必要無い時はExplod維持して軽くなるようにしたらいいかなー
13:22 (Sance) とりあえず、テストはこれで終わり。もうやる気が出ない(
13:22 (Sance) 後で気になった事があったらまた試すかなぁ
13:24 (Rick_) だぬー
13:24 (Rick_) 後で記事にしておこう

参考1:ちょっとした実験[虹格な海底宝物庫]
参考2:重さの検証[制作日記]

処理軽量化

11/21
22:22 (piyoll) ん~、なんでSS衣玖さんroundstate4でこんな重くなっちまうんだ…?
22:23 (nanagami0) あら、アレって意図的に何かしてると思ってたけど違ったのか
22:23 (okihaito) ヘルパーのデストロイ条件の見直し explodやprojを出しすぎてないかのチェック ループしてないかのチェックをするといいよ
22:24 (piyoll) roundstate=3では八百長キラーしてる
22:24 (SAIKEI) 八百長キラーってなんだ?
22:25 (piyoll) 定期的な時止めみたいな
22:25 (okihaito) 八百長阻止なんて時止め無視とroundnotoverだけで十分
22:25 (okihaito) うちのキャラほぼ全員八百長阻止持ってるけど 皆軽いよ
22:26 (SAIKEI) 時止めって必要だっけ ただの時止め無視とroundnotoverでもいいと思うけど
22:26 (piyoll) まぁそこは特に原因になってるわけじゃないと思う
22:27 (okihaito) 予想だけど numhelper(XX)=0のヘルパー召喚トリガーと roundstate>2でのデストロイが重なって 出してすぐ消すの繰り返しになってると思うんだよなぁ
22:27 (piyoll) 八百長キラーはインフルエンザの記述見て適当にやってみただけだから(
22:27 (piyoll) ん~もしかしてそれかな、調べてみよう
22:28 (okihaito) ヘルパー召喚トリガーとデストロイが同時に起こらないようにしないと
22:28 (piyoll) あ、やっぱそうかも
22:29 (SAIKEI) そういえばたしかにそれ重くなる原因だけど時止め無視時は大概そうなるよね
22:29 (piyoll) -2で勝利演出中destroyしてた
22:29 (SAIKEI) type=helper triggerall=!ishelperを入れればいいのかな
22:29 (SAIKEI) てか色変え時も出してすぐ消すものだけど
22:30 (okihaito) 私はヘルパー召喚トリガーと逆の状況でデストロイするようにしてるな
22:30 (okihaito) あと数制限もかけてる  時止め解除とかは5個以上出さないとか 色変えヘルパーは3以上出さないとかね
22:31 (SAIKEI) まあ1Fに出す数決めるだけで抑えられるね 二個ぐらいまでなら出して即消去してもほとんど重くならない
22:32 (piyoll) とりあえずヘルパー出す条件にroundstate<=2つけといたほうがよさそうね
22:33 (okihaito) よくあるのがalive=0の条件でデストロイするのにヘルパー召喚にはaliveのトリガー無かった時とか
22:35 (piyoll) おし、軽くなった
22:36 (piyoll) 確かに出しては消してのループをしてたみたい
22:37 (okihaito) 軽くなって何より
22:40 (piyoll) んじゃ修正ってことで更新すっか、ついでに途中経過ってことで黒イクさんも

処理の重さ

11/10-11
22:22 (okihaito) BCで多重混線やってた時に思ったんだけど ただの多重混線ってそんなに重くならないんだね
22:22 (okihaito) でも何でCC蛟やH霊夢はめっちゃ重いんだろうなぁ・・・ 謎だ
22:39 (lunatic__) H霊夢の混線そんなに重いの?まあ無条件に相手のヘルパー消す場合、たまに重くなることあるが・・・
22:44 (okihaito) ヘルパーを殆ど使わない相手だとまぁ軽いんだけど 常駐ヘルパーが少しでもあるとアホみたいに重くなる
22:45 (okihaito) カルマさんも同じように重いんだけど H霊夢はカルマさんよりも重いのがなぁ・・・
22:46 (okihaito) 参考になるかわからんけど 先ほど公開したBC2P側配置でH霊夢12P選ぶとFPSが10未満に・・・
22:49 (Yanmar) 確かにH霊夢は妙に・・・
22:49 (Yanmar) ヘルパー2、3個しか使ってないんですけどねぇ
22:50 (okihaito) あー・・・1Pでも重いな・・・
23:03 (okihaito) 思えばこんな酷いことする紙キャラってSTG鬼巫女以来になるか?w
23:03 (okihaito) 数発で死ぬとはいえ容赦なく混線使うしねぇ
23:03 (okihaito) ただ即死技しかないから見事に神キャラにダメージが通らないというw
23:04 (lunatic__) うーん1Pは混線使わないんだけどねぇ
23:12 (okihaito) んー 殆どのキャラが1発殴るだけでも一苦労か・・・ 1Pでも運次第で活躍できそうだ
23:13 (okihaito) うーむ 混線使わないのか・・・? 相手が宇宙意思でも結構重くなるから混線してると思ったんだけど
23:19 (lunatic__) H霊夢1Pが重いのは多分火の鳥弾幕じゃないかな?前のパソコンだとあれが重かった。
23:20 (okihaito) 弾幕? それどころかイントロの時点で重いから多分違うと思う   あ キンクリとかで時止めしてる時だけ軽かったな
23:23 (lunatic__) 1Pがイントロ重い?一応占有するけど別にそれだけで重くなるとも・・・。1Pならシステマーのほうがむしろ重いと思うが
23:26 (okihaito) システマーの方が明らかに軽いんだよなぁ・・・ roundstate=1の時 H霊夢FPS平均6 システマーFPS平均58  2P側は宇宙意思ね
23:27 (okihaito) 念のため再DLしてみますか・・・
23:28 (lunatic__) それ宇宙意思が発狂してるから?は関係ないのかな
23:35 (okihaito) 発狂は関係ないっぽい どうやら常駐があるか無いかで処理落ちが変わる 宇宙意思、レアアクマ、MCS、オニワルド 全部1P側配置でもFPS6
23:36 (okihaito) FPS60キープしたのはKFMとサワキちゃんくらいだのう・・・
23:37 (okihaito) PCスペックが低いのはわかってるけど カルマさんでもFPS平均12ぐらいなんだよね
23:37 (lunatic__) 馬鹿な、1Pは混線などしてないのだが・・・
23:39 (okihaito) ver1.06だよね? オプションとか全く弄ってないんだけどな
23:48 (lunatic__) あー、ヘルパーリダイレクト偽装のID調査が重いんだな。自分のところだと普通に60fpsだから気にしなかったが
23:49 (lunatic__) これの条件がenemy,numhelperだ
23:50 (okihaito) じゃあ重い原因はループになるのか・・・ ホントに重くなるんだな ますます汎用でやる気が失せたわ
23:52 (mosa) ある程度重くなるのは仕方無いねぇ
23:53 (nanagami0) ループ処理って普段なら気にならないコストも馬鹿にならなくなってくるから作り方が難しい
23:54 (okihaito) 殺傷力上げる為とはいえ 極度に重くなるとその分やる価値がなくなってくるんだよね 直死とかその代表だし
23:58 (lunatic__) うーん、やはりこのパソコンで60保てる程度ってのはつらい場合があるのか
23:59 (okihaito) 中には私のようにボロPCの人も居るからね 環境の違いってのは辛い
00:02 (nanagami0) やりだすとキリが無いとはいえ、ある程度は低スペックPCも考慮したいよね、
00:03 (nanagami0) 肝心のPCが無いと検証しようが無いのがつらいのだけども・・・
00:03 (okihaito) 前にもCC蛟は軽い方とかjun氏に言われたときは素直にありえん(笑)って思った
00:04 (okihaito) FPS平均20のどこが軽いんだよってね
00:04 (nanagami0) まぁ、jun氏の環境は上から数えたほうが早い特異環境ですしw
00:04 (okihaito) 羨ましい限り・・・
00:05 (lunatic__) CC蛟は開幕混線が微妙に重い以外は軽い感じ
00:06 (okihaito) ホントはうちの環境でもFPS30台いきたかったんだけどねぇ・・・ そうすればほとんど環境では快適に動くはずだし
00:07 (okihaito) SレミとBCは軽い自信があるんだが CC蛟と禍霊夢は他の環境でも重いんじゃないかと心配
00:07 (nanagami0) CCは開幕に一瞬だけで後は問題なさそうな感じ
00:43 (lunatic__) 本気霊夢更新。重さ対策とループ減少スイッチ。でもあまりこのスイッチは入れないでほしいところ
00:43 (lunatic__) https://www.webfile.jp/dl.php?i=628966&s=1169f44178952aa3aebc
00:43 (SMH) 乙です
00:43 (Yanmar) おつです
00:44 (okihaito) おつです
00:58 (okihaito) おお H霊夢凄い軽くなってる ありがてぇ・・・
01:00 (lunatic__) あー、やっぱID調査なのな。ちなみに大幅減少で10分の1、さらに大幅減少で30分の1のループ
01:02 (okihaito) 12PはID調査してるから変わらずか・・・ だが1Pがぬるぬる動くようになったのは嬉しい
01:08 (lunatic__) 変わらず・・・だと?スイッチ変更してもそうなのか?
01:09 (okihaito) ん?いや デフォルトだよ スイッチは後から見てみようと思う
01:27 (okihaito) H霊夢ループ減少スイッチ1と2あまり変わらない気がするのう・・・w  1にした瞬間ぬるぬる動く ホントはデフォが一番いいんだがあれだとFPS5だしなぁ
01:32 (okihaito) あ なるほど 試合開始してしばらくすると差が出るな・・・
01:33 (lunatic__) ループ終了タイミングも微妙に違ったはず
01:35 (okihaito) ふむふむ・・・どちらにせよ0と1の差だけでも十分だなぁw 2が必要な環境はまずないだろうな・・・

処理の軽量化

8/9-10
20:54(okihaito) FPS平均4.7ってやっぱり重いよなぁ・・・ う~む・・・
20:55(okihaito) 人形無し&常時混線なら平均23.3なんだが・・・ やはり常駐増えるときついな
20:57(_A) う?
20:57(_A) 混線でそんなに?
20:58(okihaito) 常駐ヘルパー12個なんだけど・・・ 12個でこんなに重くなったっけなぁ
20:59(okihaito) 人形のゲージ表記全部パレット共有とかしたら少しはマシになるのだろうか・・・
20:59(_A) 共有パレはしたほうがいいねぇ
21:00(_A) 自分は最初天魔ちゃんのリドミにあったのを参考にしたけど
21:00(Jun) 独立パレは500枚くらいから死にそうになる
21:01(_A) んだけど何か重くてあきらめたなぁ
21:01(okihaito) ゲージ表記最大9個だけど それでも結構重くなる?
21:01(Jun) 全然関係ないくらい
21:02(_A) 混線の内容によってもおもくなったりするからねぇ
21:02(Jun) 氷牙オロチみたいなのだと精度悪い上に重い
21:02(okihaito) 大分軽いはずなんだけどなぁ・・・ ヘルパー独占しないし
21:03(okihaito) 一度ゲージ表記のヘルパー無しで見てみよう
21:03(nanagami0) となるとやはりゲージ関連が原因かも
21:05(okihaito) ゲージ無しだとFPS平均5.8・・・ まだ重いな・・・
21:06(okihaito) 常時混線が大きな原因かなぁ・・・ 混線も一度無しにしてみよ
21:06(_A) うんうん
21:06(_A) 俺的には混線が原因じゃないのかなぁっと思ってるんだが
21:06(_A) どうだろうか・・・
21:06(Yanmar) H神奈とか軽いから不思議ですよね
21:07(nanagami0) 切り分けて考えるのが勝利への早道アルヨ
21:08(okihaito) 常時混線無し&人形有りで FPS平均11・・・ これなら少しはマシかな 体感的には宇宙意思と同じくらい
21:09(_A) うぅ・・・ん
21:09(_A) さっきにくらべちゃマシかもしれないけど・・・
21:09(nanagami0) でもそれでも半分って結構重い印象
21:09(okihaito) 人形無しでもFPS20なんだよな
21:09(Jun) Xてんこはfps78くらいで動作するけどMれーむはその半分くらい
21:09(_A) ためしにさ
21:09(_A) SFFをコピーして、違うフォルダにおいて
21:10(_A) 今使っているSFFの中身をすべて共有パレにチェックしてみるといいかも
21:10(_A) 勿論色化けおきるけど
21:10(_A) 確認には便利だよ
21:10(_A) 必ず予備にコピーしておくことだね
21:10(okihaito) 全共有してどれくらい軽くなるか?ってことか
21:10(_A) うんうん
21:10(_A) 因みに俺前々
21:10(okihaito) 試してみる
21:10(_A) エフェクト全部共有してなくてさ
21:10(_A) 共有のしかたわからなくて(
21:11(_A) んで共有したっけ
21:11(_A) 超軽い
21:11(_A) それだけの差があるね。パレ共有
21:11(nanagami0) 実は一番馬鹿にできない原因ですよね >パレ共有
21:12(_A) そそ
21:12(_A) 次にHelperで透過処理や回転処理をするヘルパーを何十もだしたりとか
21:12(_A) 後はエラメの垂れ流しとか・・・
21:12(Jun) X天子はsffほとんど共有してないはず
21:19(okihaito) パレット全共有 常時混線無し&人形有り&人形のゲージ無しでFPS平均16になった
21:19(_A) ふむ
21:20(_A) それでも16か・・・
21:20(Yanmar) 人形が重い?
21:20(_A) 人形が原因という結論に至るなぁ
21:20(okihaito) 人形と本体に透過かけてるからかねぇ・・・
21:21(okihaito) ちなみに人形無しだとFPS平均42・・・ 全然違う
21:21(_A) 人形だなぁ・・・
21:21(_A) あ
21:21(_A) もしやその人形って
21:22(_A) AIRでAによる透過じゃなくて
21:22(Jun) trans使ってる?
21:22(nanagami0) お
21:22(okihaito) そりゃあアニメは本体と同じですから
21:22(_A) Transつかってたり?
21:22(_A) 実はこの命令地味に重いオチ
21:23(okihaito) transですね statedef-2にあります
21:23(Yanmar) ウチの子とか常時Transですぜ…
21:23(Yanmar) でも重くなかったり、やはりヘルパーだから?
21:23(okihaito) 3体分だもんなぁ・・・
21:23(_A) んじゃ因みに
21:24(_A) そのTransをコメントアウトしてみて?
21:24(okihaito) 了解
21:24(okihaito) 処理軽くするのって大変だよなぁ・・・
21:25(_A) まぁねぇ・・・
21:25(_A) かならず人形に原因があるから
21:25(_A) 虱潰しで原因をさぐるしかないね
21:26(okihaito) 混線無しでもこんなに重くなるのは流石になぁ・・・
21:26(_A) だのぅ
21:26(nanagami0) 画像処理って重いからね
21:28(okihaito) 平均15.7 あまり変わってない?
21:28(_A) なるほい
21:28(_A) じゃあ他に原因があるのぅ
21:28(_A) 例えば
21:28(okihaito) 色変えも問題あるのかな・・・ こっちも無しにしてみよう
21:28(_A) 人形を召還した瞬間に重くなるのか
21:28(_A) 人形出して一定時間たってから重くなるのか
21:29(_A) 人形が一定の行動を取ると重くなるのか
21:30(okihaito) 色変え無しにしても全くかわらんな・・・ まぁ色変えしないと人形区別できないからこれが原因だと困るんだが
21:31(nanagami0) そうなると当たり判定とかそっちかな?
21:32(okihaito) 当たり判定? 普通・・・だと思うんだけど
21:33(kamase) エラメを発見する時にやった方法だけど人形に関する記述をある程度消しながら試してみるといいかも
21:34(okihaito) 他のヘルパーと違って規模が大きいからなぁ・・・ きついけど頑張ろうw
21:34(_A) だねぇ
21:34(_A) 軽くなる、と考えれば
21:34(_A) 頑張って損はないはず
21:34(_A) でもそういうのってさ
21:35(okihaito) んー 何か原因になりそうなステコンからNull化しないとな
21:35(_A) どーでもいい奴とか、こんなものが原因だったのかよーっていうのが
21:35(_A) あたtりするから怖い・・・
21:35(kamase) エラメでもそういうのが結構ありましたよw
21:35(nanagami0) トリガー条件ミスっててて1回実行すればいいのに常時実行してたりとかあった
21:36(okihaito) ホント人形のこの重ささえどうにかできれば 少しはマシなキャラだと思うんだがな
21:39(okihaito) 毎フレームの変数の変動は処理重くなったりしないよね・・・? んーじゃあどれをNull化すれば・・・
21:41(kamase) 俺は上から順に消してたね。問題ありそう、なさそう関係なく
21:41(okihaito) あれ? 人形出してないのにFPS平均が30に・・・ なんでだろ
21:41(okihaito) 棒立ちのOTHってFPSどれくらいだ
21:42(_A) 60.0じゃね?
21:42(okihaito) KFMと同じか
21:42(_A) 基本なんもしなければ60.0になるはず
21:42(_A) そっから重いもんだしたりすれば
21:43(okihaito) とりあえず人形の常時監視全てコメントアウトだな
21:44(_A) ふむ
21:45(lunatic__) 前のパソコンだとデフォが30だったっけw
21:45(_A) !?!?
21:45(okihaito) KFMの軽さは凄いなぁ・・・ 羨ましい・・・w
21:45(_A) そういや
21:45(_A) 未共通パレで
21:46(_A) 回転・透過処理を常時しているヘルパーをだしまくったら
21:46(_A) トマルトイウ
21:46(okihaito) デフォ30ならあらゆるキャラが重過ぎてさぞかしカクカクだったことでしょうね・・・
21:47(Yanmar) デバッグのときは便利そうなw
21:47(okihaito) 鬼巫女の軽さも羨ましい・・・ 混線してるのに何で軽いんだか
21:48(_A) 混線は
21:48(_A) 重かったり軽かったりするのぅ
21:48(_A) ウチの奴も常時混線でも60.0キープじゃから
21:52(okihaito) はぁ~・・・ 不具合報告から手直し始めてどうせだからできるだけ動作軽くしようとしてこんなに長引いてるとは・・・
21:53(_A) 例えば何か技を出すとき
21:53(okihaito) しかも途中で報告になかった不具合まで見つけたし 早く更新したいのう
21:53(kamase) 未だに原因がわからないエラメがあるから問題なし
22:04(okihaito) 半霊OFFにしたら30から平均43くらいに上がったわ
22:07(okihaito) アーマー外してようやくFPS60到達・・・ くっ・・・アーマーから作り直しか
22:07(_A) とりあえず
22:07(_A) 原因がわかったっぽいから
22:07(Yanmar) アーマーとな…
22:07(_A) そこからじゃね
22:07(okihaito) BGMとブレインは関係ないのは助かった
22:07(kamase) アーマーが原因とは予想外
22:08(okihaito) 処理重くならないアーマーか・・・ どうやって作るんだ・・・
22:08(_A) きっとアーマーの中身の何かが
22:08(Yanmar) アーマーヘルパーが1個以上出てたりとか?
22:09(_A) 原因かもしれんな
22:09(okihaito) アーマーは削減して2個から1個に減らしたんだがなぁ
22:10(nanagami0) 常時実行してるのが怪しいのか、意図せず常時実行してるのが怪しいのか
22:10(okihaito) とりあえずアーマー有りでFPS60を目指さなければ・・・
22:11(kamase) まずアーマーの記述をある程度消して試すことから始めるべきですな。アーマーの記述が原因かどうか…からね
22:12(okihaito) アーマーだけで平均50になるからなぁ・・・ とりあえず全部Null化してみよう
22:13(okihaito) う~ん? アーマーの記述全てNull化しても変わらない・・・ 常時監視に何か原因が・・・?
22:13(okihaito) あぁ・・・どんどん作業が膨大になってゆく・・・
22:14(_A) ハハ・・・
22:21(okihaito) -2に片っ端から!ishelperのトリガー入れてみた これでどうだ
22:24(okihaito) 平均49か・・・ -2だけじゃないのか・・・?
22:31(okihaito) ヘルパータイプをnormal型に変えただけでFPS平均が49から56に・・・ プレイヤー型は止めろってか?
22:32(kamase) いや、むしろ-2、-3に原因があるってことじゃね?
22:32(_A) 本体への命令がプレイヤー型ヘルパーにも適応されている、とか
22:32(nanagami0) ということはヘルパーが常時ステートで余計な計算してるのかね
22:33(Jun) プレイヤー型の方が重くなるのはしようじゃない?
22:33(nanagami0) 常時ステートの量多いので結構ロスになってるのかも
22:33(Yanmar) 全てのトリガーにishelperと!ishelperつけて判別させるとか
22:34(okihaito) うーむ・・・今さっき常時監視に!ishelperのトリガーつけたばかりなんだがな
22:37(okihaito) お アーマーのNullを外すとFPS60になった ノーマル型だけどw  Nullでも少しは重くなるんだな
22:37(okihaito) 軽くするような記述があったってことなのかねぇ・・・
22:43(okihaito) statetypeset、AssertSpecial=Invisible、ChangeAnim この3つのステコンで少し軽くなる気がする
22:45(okihaito) うーむ・・・何故プレイヤー型に変えただけで少し重くなるんだろ・・・ 常時selfstateも原因なのかな
22:47(okihaito) 平均49か・・・ もう何が原因なのかわからん・・・
23:53(okihaito) 一番軽い透過処理ってなんだろ・・・
23:59(okihaito) 考えたらBGMヘルパーに常時混線やらせればまた1つ常駐減らせそうだな・・・
00:22(okihaito) ・・・常時監視にステコン沢山あるとプレイヤー型ヘルパーが読み込まなくても重くなったりするのかな・・・
00:22(okihaito) FPS平均50かー・・・ アーマーはこれで我慢するしかないのかねぇ・・・
00:37(okihaito) explod出すだけでもFPS少し下がるな・・・ まぁ当然ではあるが
00:45(okihaito) う~む・・・ アニメはexplodで代用よりも直接やった方が軽いのかな
00:46(okihaito) とりあえず半霊も軽くできそうだ
00:51(okihaito) あれ?angledrawでサイズ半分にすると透過処理できない?
00:56(okihaito) う~む・・・ 点滅してくれないし・・・ 薄くなっちゃうけどexplodは1つにしよう
01:00(okihaito) 棒立ちで人形無し&常時混線無しでFPS平均37だけど・・・ 重いかな?
01:08(okihaito) んー やっぱり読み込まなくてもステコンとして存在するなら少し重くなるな・・・ 人形の常時監視のステコン全部復活させたら棒立ちでも平均34になった
01:09(lunatic__) 自分はヘルパーは常時監視の一番上で無条件selfstateしてるけど
01:10(okihaito) ヘルパー別でそれぞれのステートに返せないんじゃ・・・? 一度見てみよう
01:11(okihaito) ADSみたいに迷子センターでもつくってあるのかな
01:12(pkrs) ぶっちゃけそれが一番良いよね>無条件ss
01:13(lunatic__) 無条件で迷子センター飛ばしてそこから動かすのが基本
01:14(okihaito) ステート5150か・・・ やはり迷子センターでやった方がいいのか
01:15(okihaito) 軽く見たところADSと同じのようだ・・・ やった方がいいのかねぇ
01:17(okihaito) 問題はやはり人形か・・・ -2使わないで常時監視ってできる?
01:17(pkrs) できないまへん
01:18(okihaito) ですよねー・・・ 人形だけはそのままか・・・結構な量だから減らしたかったが
01:18(okihaito) とりあえず普通のヘルパーは迷子センター作ってそこに飛ばすか
01:27(okihaito) さっきと同じ条件でFPS平均47・・・ これはかなり効果出たんじゃないか!?
01:30(okihaito) あ でも3つほど攻撃ヘルパーに影響出てるな・・・ 誰も混線してないのに混線受けたときと同じようになってる
01:31(okihaito) まぁこれは後で修正すればいいか・・・
01:32(okihaito) 常時監視減らしただけでも処理軽くなるんだな・・・ 他にもっと削減できないかなぁ
01:33(okihaito) あれ? 混線受けるようになるな・・・ 何故だ
01:40(okihaito) う~む・・・ やはり混線を受けるようになるな・・・ 人形以外のヘルパーを5150にselfしてそこから常時監視にあったヘルパーのselfstateを行ってるんだがこれじゃだめなのか?
01:47(okihaito) ヘルパーを無条件で5150に送っても同じか・・・ これじゃ保護できなくないか?
01:55(okihaito) 常時監視は削減できないか・・・ 混線受けるんじゃ意味が無い
01:56(lunatic__) 無条件でselfstate出来てる時点で保護は出来てるかと
01:56(okihaito) 鬼巫女R発狂の前に立たせるとAIが暴発する=変数弄り食らってる だから混線は受けてることになるかと
01:58(okihaito) う~む・・・やり方が悪いのかなぁ・・・
01:59(S_9on) こちらの出したあるヘルパーが敵の混線のタゲに入っているかどうかを、敵がtarget系の干渉ステコンを発動する前に察知するのってやはり無理でしょうか?
02:00(okihaito) 何もされてないなら無理だと思うな・・・ ターゲットを持ってるかどうかってのしか感知できないと思う
02:01(okihaito) それに察知できたとしてもヘルパー消さない限りターゲットは外れないと思う
02:02(okihaito) そういえば同じヘルパーを複数個出したときに新しい方のヘルパーを優先して消すってできないかな?
02:04(S_9on) ヘルパーを出した先でprojでも出させてやれば後にいるヘルパーほど感知する個数が多くなるからそれを利用すれば出来そう
02:04(pkrs) IDでおk
02:05(lunatic__) うーん、てか-2でtrigger1=shelperでselfstateしてステート奪われるってのがよく分からないな
02:05(lunatic__) trigger1=ishelperね
02:06(okihaito) というか普通に奪えると思うんだけどな 鬼巫女の賽銭箱らしきヘルパーもヒドイことするステートに送らなければステート奪えるし
02:06(okihaito) 変なことしようとしたら即5150だから結局なにも効かないんだけどね
02:07(okihaito) AI暴発してるから変数弄り食らってると思うんだけどなぁ
02:08(lunatic__) 賽銭箱のステートは奪えないと思うけどなぁ。あれ条件ishelperのみだし
02:09(okihaito) あぁ・・・ もしかしたらアレかな・・・ 黄色表記だけど奪えてないってやつ・・・ とにかくデバックでは黄色になった
02:09(lunatic__) あー、それはガードしない限り仕方ないけどそれだけだと奪えたことにはならないからねぇ
02:11(okihaito) んー・・・じゃあやはり迷子センターがちゃんと機能してないのかねぇ・・・ -2で5150に送って5150では常時監視にあったヘルパーのself使ってるのに・・・
02:13(lunatic__) ところでselfstateのトリガーってどうなってます?
02:15(okihaito) -2の方はtrigger1=ishelperのみ 5150・・・というか元々のものは triggerall=ishelper trigger1=ishelper(XX)&&stateno!=XX ってやってます
02:17(lunatic__) それでどうやってステート奪うというんだ・・・
02:17(okihaito) ヘルパーのデバック見てないんだよなぁ・・・w もう一度試してみますわ
02:19(okihaito) あーでも一部特殊なやつあるんだよな・・・ でも-2のままだと保護できてたし・・・意味わからん
02:29(okihaito) あれ? 今度はAI暴発しないな・・・ 何でだ? もうわけが分からん・・・
02:29(okihaito) う~む・・・何故だ・・・ もしかしたちゃんとリロードしてなかったとかそういうオチか?
02:30(okihaito) Shit+F4でしっかりロードしたはずだが・・・ むむむ・・・
02:33(okihaito) 処理軽くなって一応保護もされてるから喜ぶべきなのか・・・? 原因不明のまま終わってしまった
04:46(okihaito) 人形有り&ゲージ表記無しでFPS平均16か~・・・
04:48(okihaito) 軽くできるはずなんだが・・・ 常時監視がやっぱ原因なのかな・・・
04:53(okihaito) んー・・・ -2と-3を全て消しても平均23か・・・

処理の軽量化

8/9
01:36(okihaito) 霊夢の混線手直ししなきゃな~・・・ どうやったら処理軽くできるんだろ
01:36(mosa) 画像を共有するのが一番だよ
01:37(geese_) ヘルパーのownpalを共通化するとか
01:37(Len_chan) ループをし過ぎないコトとか
01:37(mosa) そういえばループって何なんだろうか
01:37(Len_chan) 100roop/fとかやってるとカクカクですす
01:37(Jun) 常駐helperを出しすぎないとか
01:38(okihaito) 常駐ヘルパーは7個まで減らせた 人形抜きでだけど
01:38(okihaito) あれ?7個だったけな・・・?
01:38(Len_chan) ←常駐12個な人
01:39(geese_) 常駐20個
01:39(mosa) 常駐5個
01:39(Jun) 常駐10個
01:39(lunatic__) みんな多いなw
01:39(mosa) 4だ
01:39(Jun) あ、11個だ
01:39(okihaito) ブレイン、アーマー、半霊、BGM、常時混線・・・後何があったっけなぁ
01:40(mosa) 核、アーマー、当身、被弾用
01:40(okihaito) とりあえず3個は減らせた 少し大変だったけどFPS少し上がった気がする
01:40(lunatic__) 自分はシステマーが2で鬼巫女Rが3だな
01:40(mosa) ライフ管理も本体のすざる仕様だからかなり少なくて済むわ
01:40(S_9on) リニューアルカルマさんが9個ほど
01:40(nanagami0) うちはやってることシンプルだから2個
01:41(Jun) ゆゆさまは2個しかない
01:41(Len_chan) システム*1 AI*1 常時当身*2 混線*2 hitdef垂れ流し*1 全画面対策*5 ('A`)
01:41(pkrs) ADSもっと減らしたいんだけどなー
01:41(okihaito) よくそんなに少なく出来るな
01:41(okihaito) 普通に2ケタいくから困る
01:41(geese_) 常時4つだった
01:42(okihaito) 人形をどうにかして減らせれば少しはマシになるはずなんだが・・・
01:42(lunatic__) システマーは本来ヘルパー1なんだけどヘルパー占有時に鬼巫女でないと悲しいので出しっぱなしに
01:43(geese_) naruhodona-
01:44(okihaito) んー・・・混線ってヘルパー1個でできるよね・・・?開幕&常時を
01:44(S_9on) 演出用とか見た目に関わるのは最初に確保してずっと置いてますね
01:45(okihaito) 常に変数とかアニメが変動してる常駐ってやっぱり少し重くなる?
01:45(Len_chan) 変数やアニメよりもループが重い
01:46(Len_chan) 例えば、ヘルパー8個で1Fで各20ループとかさせると結構重くなる
01:47(okihaito) 1個だけなら20ループ程度は気にならないけどね
01:48(Len_chan) みらくるさん式のアニメ取得方法の弱点でもありますし。ループしすぎて重くなるのは
01:49(Len_chan) しかし、鬼巫女やH神奈はどうやってアニメ取得してるのかしらん?
01:49(okihaito) そのみらくるさん式ってどういうのかわからん みらくるさん持ってないしなぁ
01:49(S_9on) みらくるさん式でもselfanimexistの数増やせばループ数はちょっとは減らせると思う
01:49(Len_chan) ナルhド
01:50(S_9on) みらくるさんって一度に60っ個ぐらいアニメチェックしてますよね
01:50(Len_chan) ですね

 |   | 

 検索フォーム


 全記事表示リンク

 全記事表示(500件ずつ)


 プロフィール

vesper

Author:vesper

IRCチャンネルの
#凶悪MUGEN
#凶悪MUGEN_雑談
のログからMUGENに関するものを編集・公開しています。
修正した方が良い箇所があった場合は知らせてもらえると助かります。
MUGEN界隈からはリンクフリーです。
その他からのリンクはご遠慮ください。
このブログをリンクに追加

IRCへの入り方などは
IRCに関する記事
をご覧ください。

簡易凶悪MUGEN IRC情報
・ホスト名
 [irc.friend-chat.jp]
・ポート番号
 [6664]
・チャンネル名
 [#凶悪MUGEN]
 [#凶悪MUGEN_雑談]
 (以下はお好みで)
 [#凶悪MUGEN_艦これ]
 [#凶悪MUGEN_スマブラ]
 [#凶悪MUGEN_麻雀]
 [#凶悪MUGEN_緋想天]
 [#凶悪MUGEN_アカツキ]
 [#凶悪MUGEN_小説]
 [#凶悪MUGEN_絵チャ]

・推奨IRCクライアント
 LimeChat2


 カテゴリ

記述の子カテゴリは目安程度に考えてください。

 最新コメント


 最新記事


 カウンター

累計の閲覧者数:

現在の閲覧者数:

 RSSリンクの表示


他ブログ更新情報(最新70件)

仕様上、下記のリンク一覧でサイトリンクにあるサイトはこの一覧に出ません。

Twitter


基礎リンク集


リンク

サイトに断り書きがない限りリンクさせてもらっています。
リンクしてほしくない場合はお気軽におっしゃってください。