約 135,930 件
https://w.atwiki.jp/clan_su/pages/24.html
援軍処理について wizを使った援軍処理 援軍は攻撃可能な最も近いユニットを攻撃します。 この習性を利用して、射程の短いバーバリアンを囮に、Wizで援軍を焼きます。 この方法のメリットは、援軍処理に使うユニット数を節約でき、Wizをそのまま攻撃に生かすことも可能である点です。 1.援軍をつり出す 2.援軍をまとめる 3.バーバリアンを2体ほど近くに出す 4.Wizを1~2体バーバリアンより距離を置いて出す ドラゴンの処理もこのほうがユニット数を取りません。ドラゴンを処理する場合は、ドラゴンの影(ドラゴンの真下)にバーバリアンもしくはアーチャーを囮として出すと良いです。 参考動画
https://w.atwiki.jp/sevenlives/pages/1422.html
処理系 読み:しょりけい 英語:implementation 別名:実装系 意味: 処理系とはそのプログラミング言語の仕様に基づいて実装させるためのソフトウェアのこと。 コンパイラやインタプリタなど。 基本的にはその言語に基づく仕様に適応しているが処理内容にはそれぞれ特徴もあり動作速度などが異なったり、独自拡張をするものもある。 2009年01月15日 処理系依存? コンパイラ インタプリタ? VM? GCC
https://w.atwiki.jp/agrist/pages/38.html
ラウンド開始時の処理順 ラウンドカードのオープン(ラウンドカードの上に置かれている資材の回収) ラウンド開始時に行われる職業効果の処理フェイズ(学者、鋤職人、馬手、木材配り、職場長、etc) 毒見役の毒見宣言 ラウンド開始時の処理フェイズに、学者で鋤職人を出した場合は即発動できる。 学者で召使を出した場合、召使の効果は『ラウンドカードの上に食料を置く』なので、そのラウンドには食料は貰えない。 複数のカードが場に出ている場合、スタートプレイヤーから順に処理を行う。 資材を取るアクションの処理順 資材を取る(taken)、というアクションが発生 資材を取ること(taken)をトリガーとする本人のカード効果の発生(木こり、レンガ混ぜ、かご、出来高労働者、etc) 林、各種買い付け人等、他人が資材を取ること(taken)をトリガーとする他人のカードの効果の発生 資材が使える状態で手元に残る(飼えない家畜の場合は、このタイミングで焼ける、資材商人はこのタイミングで追加の資材を得る)
https://w.atwiki.jp/aniwotawiki/pages/43819.html
登録日:2020/01/26 Sun 04 20 24 更新日:2024/05/02 Thu 18 26 56NEW! 所要時間:約 12 分で読めます ▽タグ一覧 ぼくらのウォーゲーム! PC STG カクカク ゲーム ゲーム用語 コマ落ち シューティング ステルス スローモーション ディレイ ラグ 処理落ち 処理速度 処 理 落 ちと は 処理落ちが解消されたのでここから改めて解説する。 処理落ちとは、コンピューターなどの電子機器において、処理速度が極端に遅くなってしまう現象のことである。 ●目次 概要 処理落ちの種類処理速度低下 ラグ フリーズ 対処法 ゲームと処理落ち処理落ちが印象的なゲーム達 その他 概要 まず前提として言っておくと、コンピューターとは「ものすごく性能の良い電卓」と「コンピューター専用のお仕事リスト」が合体した装置である。 我々がたとえばパソコンを立ち上げたとしよう。その時コンピューター内部では「画面映像を流してくださいね」「ログイン画面の準備をしてくださいね」「ハードディスク内のデータを読み込んでくださいね」……などなど、様々な命令が発信されお仕事リストに溜まってゆく。で、コンピューターはこれらの作業を順番に処理してゆくのである。 一見すると同時にこなしているように見えるが、それはコンピューターの処理スピードが速すぎて同時に見えるだけに過ぎないのだ。 だが、そんなコンピューターにも限界はある。 お仕事リストが小さ過ぎて全てのタスクを一気にこなせないとか、あるいはコンピューターの処理速度に対して仕事量が多くなり過ぎたりすると、さしものコンピューターも数秒〜数分止まってしまうことはある。 これが処理落ちというものだ。 単純な話、コンピューターの処理速度に対して要求される仕事量が多くなれば処理落ちが起きるのだ。 パソコンなどの場合、ウィルスが侵入していることが原因(*1)という可能性もあるので、急に処理落ちしたらヤバイサインであることも。 あとは単純にPC内に余計なファイルが多すぎても処理落ちする。定期的に掃除しよう。 また、通信のラグのことを指して「処理落ち」と言うことも割と多い。 内部的な意味合いは違っても、見ている/プレイしている側からすると起きている現象はほとんど同じなのであまり区別されない傾向にある。 処理落ちの種類 処理落ちにもいくつかパターンがある。 処理速度低下 断続的な処理は行われているものの、進行速度が低下している状態。しばしば「重い」と言い表される。 熟知したものでなければ見逃してしまうようなごく一瞬の処理落ちから、映像にスローがかかったようにガクガクになるような誰でも検知できる処理落ちまで様々に存在する。 ラグ 入力(インプット)に対する反応(リターン、レスポンス)に遅れ/遅延が見られる状態を主に指す。 上記の速度低下と併合して発生するケースもよく見られ、例えば何かの作業で処理中に「Enterキーを押したのに画面上のOKボタンが押下されるまで5秒ほどかかった」のような状態。 フリーズ 「凍ってしまった」かのように動かなくなること。 どんな操作をしても無反応であり、この状態になったら処理する事自体が止まっている事もある。 時間停止の如く動かなくなるが、エッチな事できるわけでもないので歓迎されない。 オーディオ関係はそのまま流れる、ぶつ切りになる、同じ音を鳴らし続ける等多種多様。 稀に意地を見せて復活してくれるが、大体はそのまま強制終了することになる。もしくはソフトorハード側が無理矢理落とすか。 対処法 例えば、1秒24枚再生のアニメで何かしらの理由で1秒辺り12枚しか再生できなくなったとして、対処方法は大別すれば2種類である。 ①2秒かけて1秒分の動画を描画する 当然2倍スローモーションになる ②24枚を半分切り捨てて本来の時間で再生する スローにはならないが、こちらはいわゆる「コマ落ち」状態になるため異様にカクカクする どっちがいいかはそのメディアの種類にもよるため一概には言えない。 一応根本的な解決策として「処理速度そのものを引き上げる」というのがあるが、これはコストも嵩むし、PCならともかく家庭用テレビゲームなどではまず無理な手法である。 ゲームと処理落ち 処理落ちにはファミコン時代から多くのプログラマが悩まされていた。 というか、ファミコンの頃だと処理能力の関係で横に4キャラ以上を同時に並べることができず(*2)、 無理矢理5キャラ以上を横に並べると同時に描画ができないため交互に表示して対処したりしていた。 ファミコン世代のハードを中心としてよく言われる「ちらつき」はこれが原因である。 ドラクエで5人パーティーが長い事実現せず、したらしたで「十字編隊」という変わった隊列で描写されていたのはこのちらつきを抑えるための努力だったのである。 しかし、 処理落ちも仕様の内 ということで、「わざと」処理落ちを起こして演出として使っていたケースもあったりした。 例えば『ドラクエ4』の4章ラストの出航シーンでは、さりげないがわざと処理落ちを起こすことで船の動きと波の動きをファミコンの限界を超えて描写している。 また、RTAやTASなどのゲームを極めるタイプのプレイではかなり重要な存在と言える。 最速を目指すor最高得点を目指す場合、「処理落ちの回避」または「処理落ちの利用」が必要な場面がでてくる。 そのため、「ゲームハードが違う」「DL版かどうか」で進行方法がまるで変ってしまう例も多々あり、 なかには処理落ちがなくなったことで「かえって難易度あがる」「むしろ従来より遅くなる」こともある。 処理落ちが印象的なゲーム達 シューティングゲーム シューティングゲームにおける処理落ちは、プレイヤーにとって有利に働くことが多い(*3)。 特に大量の弾幕で押される場面では、敵の弾速が遅くなるのに加えて、高速で自機を動かすよりもゆっくりと動かした方が断然避けやすいため、ボス戦を始めとした難所での処理落ちは基本的に歓迎される。 むしろ、開発段階から処理落ちさせる事を前提として製作、調整されている事も非常に多い(*4)。 一方で、処理落ちが有利に働くという事は、解けた瞬間が危険という事でもある。怒首領蜂の「火蜂」が著しい例なのだが、ボスの攻撃の変化の合間に処理落ちが切れて残りの弾が一斉に加速して襲ってくるのだ。 また巨大ボスで処理落ちするのはボス敵の強大さを演出するのに役立っている面もあった。 とはいえ、雑魚戦でも頻繁かつ恒常的に処理落ちするレベルとなると、テンポを損ない「もっさりしすぎている」と言われる。 近年のアーケードからの移植作品やリメイク版においては、ハードスペック的に処理落ちを起こさないのが当たり前になっていても、当時の難易度を再現するためにオプションで「処理落ちモード」を搭載している作品も少なくない。 上述したように処理落ちのかかり加減は弾よけのバランス調整の一部であり、これの再現性が低いと難易度が格段に上がってしまうので当然ではある。 (サンダーフォースⅣ、R-TYPEⅡなどが代表的) 逆に再現性にこだわらない人には、処理落ちがない方がサクサクプレイできて爽快なことも多いのでオプションで選べるようにしているのである。 THE 地球防衛軍シリーズ 真の敵は処理落ち と言われるぐらい処理落ちと縁の深いゲームシリーズ。 というか初期は低予算ソフトだったので、色々と作り込みが甘く巨大怪獣が出現したりするとものすごい勢いで処理落ちしていた。 ただし、一面から見るとこの処理落ちによるスロー動作は怪獣映画「らしい」重厚感を生み出すのに一役買っており、特に敵の巨大円盤を撃墜したりするとゆっくりと火を噴きながら墜落していく円盤がよく映えて非常にカッコイイ。高難易度だと見とれているうちにまず殺されるが 同社の『ギガンティックドライブ』『鉄人28号』(PS2)『超操縦メカMG』(ニンテンドーDS)『斬撃のレギンレイヴ』(Wii)といった他の作品でもそのダイナミックな演出と物量ゆえに処理落ちはつきもので、 PS2より大幅にスペックの上がったXbox360やPS3でも余裕で処理落ちしているので、もはや故意としか思えない……。 こんな調子なので 「処理落ちのないEDFはEDFじゃない」というクレームが本当に寄せられた とか。 とはいえ『4』の処理落ちは相当に不評で、PS4で発売されたリメイク『4.1』では歴代でもっとも処理落ちが少ないと言えるほど改善された。 しかし『5』ではグラフィック効果の強化などの影響でまたも発生。まあそれでもだいぶマシになっているが。 無双シリーズ 「敵の数」が爽快感に直結するゲームなので、処理落ちが起きるかどうかが評価に大きくかかわる。 基本的に処理落ちでスローモーションになることはあまりないのだが、その代わりこのシリーズだと 処理落ちすると雑魚敵のポップ数が減少する ことが多い。いわゆる「ステルス」。 場合によってはスッカスカなステージを散発的に敵を殴りながら進むだけ、という事態も起きるためプレイヤーからは特に嫌がられる。 ゲームバランス的にも雑魚敵を倒した数は育成にも影響するため重要。 「こっちの攻撃は通り抜けるのに、敵が攻撃する時だけ突然判定が出現する」という嫌がらせのようなパターンも。 また、複数ハード同時発売の格差が特に大きいゲームシリーズでもあり、ものによっては難易度が激変するため複数ハード持ちのプレイヤーにとってはどのソフトを買うかの判断が難しいシリーズ。 移植版ではハードの変更に伴いステルスの度合いが変わってくるため、その辺りも気にされる。特に、「下位ハードへの追加要素あり移植」という離れ業をやらかしているいわゆる「Special」版はかなりひどいものも見受けられる(『真・三国無双5・Special』とか)。 オーディンスフィア ヴァニラウェアのアクションRPG。 横スクロールの2Dアクションなのだが、美麗なグラフィックのせいか処理落ちが多発する。 ステージによってはプレイヤーキャラも敵もスローモーションに動くというのがザラで、本当にアクションゲームなのか分からなくなるときがある。 リメイク版ではハード性能の向上もあって処理落ちはほぼ解消されている。 FINAL FANTASY ⅩⅡ リアルタイムで進行する戦闘のため、PS2のスペックの限界もあって処理落ちを誘発しやすい。 それを防止するための隠し仕様としていわゆる「順番待ち」が存在する。 これはグラフィックリソース(通称エフェクト量)の大きな魔法が連発されると一時的に発動されるアクションが制限されるというもので、上位魔法が地雷と呼ばれる大きな要因である。 順番待ちが発生している間は、「たたかう」「遠隔攻撃」「1.5倍撃」以外のアクションが行えない。アイテム使用も止まるため、必然的に回復も遅れていく。 上位魔法を連発してくる敵と対峙した場合順番待ちが何重にも重なることがしばしば起こり、「渋滞」と呼ばれる。 一方で、意図的に敵の魔法に割り込み順番待ちを発生させて足止めする「詠唱妨害」というテクニックも確立されている。 仕様ではあるものの正式なシステムというよりは一種のガード処理であるため、ゲーム内では一切説明はない。しかし、バトルに与える影響は極めて大きく、本作の戦闘を分かりにくくする一因にもなってしまっている。 HDリマスター版の『THE ZODIAC AGE』では撤廃されている。(*5)そのため、オリジナル版・IZJSとTZAでは戦闘の感覚が異なっている(キュクレインやエクスデスが顕著)。 モンスターハンターシリーズ ちなみにこれは複数シリーズで共通だが、大型モンスターが乱入してきた場合に処理が重くなり動作が鈍くなる。 ゲームプレイに影響が出るほどの遅延ではなく、むしろ乱入のわかりやすいサインであるためこれに関してはそこまで嫌われてはいない。 というかわざと残されているような感もある。 MHXでは、連射タイプの弓でこの処理落ちが関連しており、3DSのスペックの限界により、同じポイントにほとんど同時に攻撃判定が発生すると複数発の攻撃が単発ヒットと処理されてダメージが減少してしまう。 理論上は他の武器でも起こり得るが、実質的に対象になるのは連射弓のみである。 New3DSだと起きない、という報告もありどうやら純粋に3DSのスペックの問題である模様。 また、MHWorldではゲームエンジンの仕様により、映像のフレームレートによってはダメージ判定などの処理タイミングが狂う場合がある。 特に顕著なのがLV3貫通弾であり、1/20秒周期にピッタリ収まらないとダメージ判定が遅くなるため、タイムアタックの理論値がハードで優劣(*6)が付いて単純比較できないという問題が出ている。 不思議のダンジョンシリーズ(ローグライクゲーム) 階段を降りて次のフロアを準備している暗転時間が異様に長い。高速移動(いわゆるダッシュ)中に引っかかりを感じる。 という処理落ちが発生すると、まず間違いなくそのフロアにモンスターハウスがある。機種や作品にもよるが、初期の作品ほど顕著。 どちらも通常ではありえない数のモンスターが配置されることによる処理落ちが原因。 小規模なモンスターハウスでは、その差がわからない場合も多いが、 一部屋が広くなりがちな2分割、4分割フロア(*7)では露骨に暗転時間が長くなり、 慣れた人だと暗転中に「モンスターハウスのド真ん中に降りないでくれ!」と祈り始めたりもする。(祈ったところでどうにもならないのだが) またその場で高速でターン送りをする足踏みも、敵が近くにいると速度が遅くなるため、敵の接近を感知出来てしまったりもする。 ジョジョの奇妙な冒険 黄金の旋風 第一話『ブチャラティが来る』におけるチュートリアルにて、「するどい痛みがゆっくりやってくるッ!」のシーンではブチャラティの感覚がスローになっていたが、ゲームではブチャラティの感覚ではなくゲームが処理落ちを起こしてスローになっている。 ジョルノの能力でスローになっていることを表現するとはいえなにもそこまでやらんとも… 協力プレイゲーム 近年だと上記『モンスターハンターシリーズ』などが代表的だが、通信ゲームだと「ディレイ」「ラグ」と言われることが多い。 この場合、単純な処理落ちというよりも「同期待ち」という要素が強い。 複数のプレイヤー間で同等にデータを処理するために、「ゲームは進んでいるのに画面上では動いていない」という時間が発生することがある。 プレイヤーからすると、突然モンスターがテレポートしたり、気付いたら予備動作なしでいきなり大技に入っていたりという怪現象に見舞われることがあるため大変迷惑である。 特にオンラインゲームだと、処理落ち・同期待ちでも結果的に予定通りの行動に入ればマシであり、最悪サーバーとの接続が切られ、その間に倒されてセーブポイントに死に戻り…なんて悲劇もある。 死に戻りしないまでも、復帰までにパーティー半壊とか… 『MHF』では、「最初にモンスターのいるエリアに入ったプレイヤーが基準になって同期が行われる」という仕様から、 特定の部位を狙いたい武器の人が優先してエリアに入る「エリアホスト」という独自の概念が産まれたりした。 アーケード、特にアクションゲームでは「大技を撃った場所に敵がいない」とか「敵がムーンウォークして攻撃が外れる」とか非常に致命的な事が起こるためご法度である。 人間 人間も、目の前で起きた様々な物事を脳で「処理」をする。 コンピュータ程効率的ではないものの、臨機応変に処理できるのは人間の利点であり…欠点でもある。 そして目の前で起こった現象が余りにも突飛過ぎる場合、処理できずフリーズしてしまう。 例えば、意中の女性の着替えを覗いてしまったり、突風でスカートがめくれてパンツが見えた時。 この場合は女性も男性もフリーズするが、男性側は早く処理落ちを解消しないと女性の格闘を食らう羽目になるだろう。 ちなみに漫画などでよくある『身の危険に遭遇したときに周りがスローモーションに見える』という現象も脳のリミッター解除云々ではなく単に処理落ちしてただけである。 その他 ダイナミックコード(アニメ版) 1話で依都が階段を下りるシーンがコマ飛びのように妙にカクカクしており視聴者から「処理落ち」と呼ばれた。 影を見ると分かりやすいが明らかにワープか何かしたのかと思うほどにはコマが飛んでいる。 映像出力に問題があったのではなく単なる作画ミス(に近いもの)なので円盤では作画修正が行われ比較的自然な動きになっている。 追記・修正は処理落ちしないようにお願いします。 △メニュー 項目変更 この項目が面白かったなら……\ポチッと/ -アニヲタWiki- ▷ コメント欄 [部分編集] アニメならデジモンのディアボロモンに大量のメールを送って処理落ちさせ動けなくなった所にトドメの一撃 -- 名無しさん (2020-01-26 06 50 55) PCで余計なファイルが多すぎても処理落ちするとあるけど関係ないのでは? -- 名無しさん (2020-01-26 07 01 29) ドンキーコング64のミニゲームみたいな「VC配信で処理落ちが解消されてスピードアップしたらかえって難易度が上がってしまった」例もあるとか。 -- 名無しさん (2020-01-26 07 03 20) ↑×2高スペックPC自慢かオメー -- 名無しさん (2020-01-26 10 20 49) ラグとフリーズは処理落ちとは別の現象っていう説明を小項目作ってみてもいいかもね。ラグはスペックじゃ解決しないし、フリーズは時間じゃ解決しない -- 名無しさん (2020-01-26 12 09 33) 時オカとかドンキー64も処理落ち前提で作ってた作品だな。前者はエンディング映像が、後者はタイトルデモがVCとかだと処理落ちが軽減されたせいでずれる。 -- 名無しさん (2020-01-26 13 56 11) 1コメ 無印による新作発表でディアボロモン倒せなくなるんじゃね?とか言われてたな -- 名無しさん (2020-01-26 15 02 26) 無双5スペシャルはほんと酷かった。 -- 名無しさん (2020-01-26 15 35 08) マイナーだがデザエモン2を推しとく。有志の中には処理落ちを前提にしたゲーム設計どころかBGMまで処理落ち前提にしてたりするのがしゅごい。 -- 名無しさん (2020-01-26 17 55 36) オーディンスフィアがあって安心した。冥界は特にレブナントのせいだかで酷かった -- 名無しさん (2020-01-26 19 23 34) EDFはPS4でも大量の敵を爆殺したりすると処理落ちするが達成感がある。むしろ処理落ちなしだと一瞬だから味気ない -- 名無しさん (2020-01-26 19 58 22) フィリスのアトリエもよく起こす -- 名無しさん (2020-01-26 20 07 27) 開発が地球防衛軍と同じサンドロットである斬撃のREGINLEIVも、わざとじゃないかってぐらいの処理落ちだったな。同じく演出として成立してる部分はあるが、リモコン操作とはちょっと相性が悪い部分もある -- 名無しさん (2020-01-27 02 34 55) サンダーフォースⅣだとわざと処理が重くなるようにプログラム組んでるんだっけか -- 名無しさん (2020-01-27 07 08 15) シャイニング・ティアーズ が無双に近いのだがこれもしょっちゅう処理落ちしてたな。ダメージ食らってないのにゲームオーバーになってたことが多々ある。まあそれ以前にシナリオがアレなんだけど・・・ -- 名無しさん (2020-01-27 12 18 33) なんか説明足りてなくない? -- 名無しさん (2020-01-27 14 21 09) 説明書いてくれてありがとう。 -- 名無しさん (2020-01-27 22 30 33) AC版グラディウスIIIが、まさに処理落ち前提で作った感がある。 -- 名無しさん (2020-01-28 02 02 52) ↑ファイアー面の弾よけは処理落ちが完全に組み込まれているよね。なおキューブは… -- 名無しさん (2020-02-18 19 01 03) ポケモンスナップ学会ではVC版は処理落ちがほぼないためにRTA完走できたらバケモノとか言われていた時代もあったな。というか、スタッフハイスコアの一部が処理落ちとか利用しないと撮影できないし…w -- 名無しさん (2020-04-25 21 30 37) 蒼穹紅蓮隊は2Dシューティングなのに処理落ちでボンバーボタンの入力がスキップされるという恐ろしいゲームであった… -- 名無しさん (2020-11-03 01 22 29) なにかのシューティングで見かけたけれどスコアの欄に「処理落ち」した回数が表示されるのあった -- 名無しさん (2023-02-04 11 10 30) ポケモンSVがオープンワールドの弊害で処理落ち起こしまくってるよな -- 名無しさん (2023-05-24 14 50 14) 「ゲームと処理落ち」の項、なんで処理落ちに直接関係ないスプライトオーバーの話だけしてんの? -- 名無しさん (2024-03-03 01 11 40) フレームスキップを処理落ちに含めたから生えたのかな。なおフレームスキップは加速に見える罠 -- 名無しさん (2024-05-02 18 26 56) 名前 コメント
https://w.atwiki.jp/hamaosenmatome/pages/60.html
下水処理のしくみ http //www.city.yokohama.lg.jp/kankyo/gesui/syori/ 標準活性汚泥法による下水処理 http //www.city.yokohama.lg.jp/kankyo/gesui/syori/hyoujun/ 横浜市西部水再生センター・藤沢市大清水浄化センターにおいて災害時汚泥処理の相互協力に関する協定を締結しました! http //www.city.yokohama.lg.jp/kankyo/kisha/h23/111213-1.html →この説明から、汚泥の処理プロセスがわかります。 2011/11/24 東北大学 下水汚泥処理の工程を大きく省略、無機粉体の添加と加熱で高純度の水素を高効率で発生させる手法を発見 http //news.livedoor.com/article/detail/6072824/
https://w.atwiki.jp/novpat/pages/19.html
画像処理の分類 高速画像処理 2値画像処理用語の定義 画像処理の分類 画像処理の種類は多岐に渡る.ここでは,目的別に画像処理を分類する. 生成画像再構成(可視化.Ex.医療CT) 変換コントラストの改善 輪郭強調・平滑化 復元(ぼけ・ノイズ除去) 幾何変換(Ex.ひずみ補正・アフィン変換) カラーモデル変換 圧縮(符号化)・伸張 特徴計測:情報の圧縮や所望の特徴を際立たせることが目的エッジ検出 領域分割(二値化を含む.)しきい値処理 領域統合法 分離等合法 テクスチャ解析(結果に対してエッジ検出or領域分割を施したりする.) 線検出 二値画像処理ラベリング 境界追跡 収縮・膨張 骨格抽出と距離変換 縮退 細線化 形状特徴(面積,周囲長,複雑度,凹凸度,モーメント特徴,フーリエ記述子) 物体認識テンプレートマッチング ベイズ推定 ニューラルネットワーク 物体検出 点対応テンプレートマッチング スネーク法?? 立体情報ステレオ法(→距離画像の特徴計測) 陰影からの形状復元(こう配空間) テクスチャからの形状復元 オプティカルフロー エネルギー最小化法とベイズ推定法 不良設定問題を良設定問題に変換できるという理由から,エネルギー最小化にもとづいて特徴計測をおこなうことがある(正則化理論).エネルギー最小化にもとづく画像処理は不良設定問題の多い視覚情報処理で使われることが多い.エネルギー最小化にもとづいて特徴計測をするためには,所望の解が最小値となっているエネルギー関数を定式化しなければならない.その方法として,ベイズ理論を利用するといい.ベイズ理論には 自然な形でエネルギー関数が定式化できる, 学習は確率分布の関数近似と見なせるので,パラメトリックorノンパラメトリックな分布を問わず学習の概念を自然に導入できる, 統計力学の計算技法をはじめ,様々な計算技法が提案されている, 最適値ではなく平均値を利用したほうが良い場合があることがわかる, というメリットがあるからだ.詳しくは機械学習を参照のこと. 高速画像処理 高スループットの画像処理装置を実現することで,応答の速いロボットビジョンやカービジョンに応用することができる.現在,求められているサンプリングレートはだいたい 1 kfpsなので,1フレームあたりの処理時間(レイテンシ)が 1 ms以下であればよい.ハードウェアを多重化することでもサンプリングレートを高めることができる. 2値画像処理 用語の定義 4-近傍, 8-近傍 |隣接画素を注目画素の上下左右のみと考えるとき4-近傍といい,斜めの画素も隣接していると考えるとき,8-近傍と呼ぶ. n-連結 |同じ濃度値の画素間A,Bにn-近傍で繋がりがあるかどうかの指標である.画素Aから4-近傍の画素をとおって画素Bまで同じ濃度値の画素が連結しているとき,4-連結しているという.同様に8-近傍の画素をとおって同じ濃度値の画素が連結しているとき,8-連結しているという.
https://w.atwiki.jp/karaiknowledge/pages/17.html
.net Frameworkでのエラー処理 1.グローバルエラーハンドラ グローバルエラーハンドラを追加することによって未処理の例外を処理することが可能になる。 方法は「Windowsフォームアプリケーション」と「それ以外(コンソールアプリケーション、マルチスレッド)」の場合で異なる。 1.コンソールアプリケーションの場合 1.グローバルエラーハンドラの追加 Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException); // UnhandledExceptionイベント・ハンドラを登録する Thread.GetDomain().UnhandledException += new UnhandledExceptionEventHandler(Application_UnhandledException); 2.未処理例外を処理するメソッドの追加 public static void Application_ThreadException(object sender, ThreadExceptionEventArgs e) { ShowErrorMessage(e.Exception, "Application_ThreadExceptionによる例外通知です。"); } 2.それ以外のアプリケーションの場合 1.アプリケーションのメイン関数内にグローバルエラーハンドラの追加 Thread.GetDomain().UnhandledException += new UnhandledExceptionEventHandler(Application_UnhandledException); 2.未処理例外を処理するメソッドを追加 private static void Application_UnhandledException(object sender, UnhandledExceptionEventArgs e){ ............... } 2.ADO.netにおける例外処理 ADO.netを利用してデータアクセスを行った場合の例外処理は以下の二つのパターンに分けられる。 Severityが10より小さい場合の処理 Severityが10以上の場合の処理 3.参考リンク Visual C# .NET および Visual C# 2005 で構造化例外処理を使用する方法 Edited By Karai 2008年02月28日 プログラミングMicrosoft Visual Basic 2005(言語編 上) プログラミングC#
https://w.atwiki.jp/mugencns/pages/213.html
■フレーム処理 フレーム(F)とは:60f/秒 処理の単位であり全体の処理を1周することが1フレーム。 フレームが連なり処理表示を繰り返すことでコンピューターは「動いている・操作している」ように見える。 基本1秒につき60フレーム(=処理60周分)である。(設定で調整はできるが基本は60F/秒。) 例えながら砕いて言うと映画フィルムの1コマ、あれが1フレームに相当します。 表示を毎秒60コマ変えていくことで動かしているわけです。ちなみに映画フィルムは24コマ/秒が一般的な規格。 ただし 手間の関係上キャラの画像も1枚/F、60枚/秒というのは困難。 一応、表示の最小単位が1Fごとと覚えておけばいい。、 映画フィルムレベルでも2~3Fに1枚表示で同レベルになる。 (アニメに関して言えば、最低限あるなら枚数よりも全体の流れの方が重要。) ■MUGENのフレーム処理 MUGENでも決まった順番で処理をしていく。 作っていてあまり気にしない部分だが、細かい処理にはとても重要。 ※かなり大雑把な表 ※内部を解析したわけではないため、一部順序は実際と異なる可能性あり ※検証の足りない部分は多いです※ 基本 フレーム開始処理Ctrl=1系統の処理・ガードフラグ キャラ・ステート処理順番はスロットID参照 中身は後述する表を参照※Damage処理や生死判定自体はキャラ側で行われている フレーム終了処理SC-/BindToTargetなどのBind系の移動を行う? 攻撃の命中処理を行う。 SC-/Projectileの処理をする。※キャラ側ではないので注意 SC-/Explodの処理をする。※キャラ側ではないので注意 その後描画処理する フレーム終了フレームレートに合わせて待機するかすぐ次のフレームを処理する。 状態 内容 備考 ↓■フレーム開始時点■↓ フレーム開始処理 Ctrl=1による移動処理 ステート変更。Commonステート参照 ↑自動振り向き処理 AutoTurnが可能である場合に、振り向く判定を行う。 手動ガード判定 ステート変更。ガード参照 自動起き上がり処理 ステート変更。Commonステート参照 ↓■キャラ処理■キャラ同士の順番はスロットID参照↓ 常時監視ステート -3番(ステート処理補助) ※ステートを奪われている状態では読み込まない -2番(常駐処理) ステートを奪われていても読み込む。その関係上T-/StateNo条件などは基本使わないこと -1番(基本コマンド認識) ※ステートを奪われている状態では読み込まない。-2ステートでSelfStateで戻した場合は読み込むとのこと 番号ステート 現在のステート(StateNo) 番号ステート。細かくはFile-/Stateファイルから参照 ステート移動実行後 実行したステートの読み込みを中断し次のステートを読み込む。 番号ステート後 ステ移動数リセット 2500Loopエラー用のカウントがリセット ガード戻し処理 特定条件で140番からステート移動し再度番号ステート処理。詳しくはCommonステートの該当項目参照 速度処理・Vel反映 Velのページを参照 速度処理・Physics反映 速度処理・自動着地処理 一定条件で52番ステートへ移動。再度番号ステート処理。詳しくはVel参照。 ダメージ反映 T-/MoveType=HでGetHitVar(Damage)がある場合、その数値分体力を減らす。 生死判定 T-/Life=0かつSC-/AssertSpecialのNoKOなどが無ければ死亡判定となりT-/Aliveを0に、他試合終了判定を行う。 SC-/DestroySelf Helperキャラの消去を行う(少なくとも自動着地の後) ↓ キャラ処理後 次ヘ 次のキャラの処理を行う。無ければステート終了処理へ キャラ処理 順番は基本スロットIDに応じて決定される。T-/IDではない。詳しくはスロットIDを参照。 1.既存キャラの内、Movetype=AでスロットIDが若い順 2.既存キャラの内、MoveType!=AでスロットIDが若い順 3.新規Helperの射出された順番 SC-/Pauseなどが実行されている間は該当MoveTimeが無ければ処理スキップ。ただし新規Helperは例外的にPause中でもスキップされない。 ↓■ステート終了処理■↓ 終了時点 ※キャラごとの順番処理など詳しくは不明 Bind系処理? Bind判定 SC-/BindToTargetなどのBind系の処理をする。※検証不足。押し出し判定よりも優先、のはず 押し出し 衝突判定 重なっているキャラの押し出し判定を行う。キャラごとの処理順については※調査不足※ ↓ SC-/Projectile処理 MoveTime判定 SC-/PauseやSC-/SuperPauseに対するMoveTimeの残量確認残量無し・もしくは本体停止状態の場合は処理をスキップする※射出したフレームではスキップを行わない? Time消失判定 ProjRemoveTime -経過時間 = 0がなら消失する。 速度処理 Velの分移動させる。 加速度処理 Accelの分Velに加算。※射出時点では加算しない? 画面外消失判定 消失する条件を満たしている場合消失する。※画面外による消滅には移動が必要? 時間経過 Time系パラメータの残りを-1する?RemoveTimeは不変。代わりに経過時間に1加算。※他は調査不足 表示について 本体停止中にProjRemoveTime=1+MoveTime有りで射出すると、停止中表示されず停止解除後に1F表示される表示は無くても命中はする。RemoveTimeが2以上やMoveTime無しなら射出時点から表示される。 ↓ 攻撃判定 攻撃の処理はT-/GameTime偶数,奇数で確認処理が逆順にみたいな状態?他、属性について細かくは攻撃属性なども参照 SC-/ReversalDef判定 最も早い。ヒットしたら相手のSC-/HitDefやSC-/NotHitBySC-/HitByの無敵などを無効化する。 命中判定1攻撃判定処理 SC-/HitDef、SC-/Projectileについて相手くらい判定へ攻撃判定が重なりHitFlagが適合しているか。StateType属性が変化。 命中判定2無敵 SC-/NotHitBy、SC-/HitByの無敵に適合していないかどうか。 命中判定3HitOverride無敵 攻撃のP1StateNo指定かP2StateNo指定の有無とSC-/HitOverrideを確認 。重なっている場合命中しない。 命中判定4Target限度 既にTargetが8体あり、かつそのTargetの相手かどうか。 命中判定5Priority 全員の攻撃のPriorityを確認し優先ヒット・回避を判定 攻撃処理 判定の結果、攻撃が命中していれば。※細かい処理の順番は不明※ 命中処理1基本 判定に従い攻撃を受けた側をMovetype=HのCtrl=0にして、汎用のくらいステートへ飛ばす。詳しくはCommonステートを参照。SC-/ReversalDefのヒットでは変更せず?Ctrlは不明 命中処理2ガードフラグ 攻撃のGuardFlagに適合するガードをしており、SC-/HitOverRideが不適合なら、対応ガードくらいステートへ。 命中処理3ステート奪取 攻撃のP2getP1Stateのフラグを確認しステートを奪う。省略時、通常0、P2StateNo指定有り1。0指定でステートを奪わない。 命中処理4相手ステート奪取 攻撃にP2StateNo指定がある場合ヒットした相手をP2StateNoへステート変更。 命中処理5相手ステート変更 攻撃にP2StateNo指定が無くガードでなければ対応くらいステートへ飛ばす。Commonステート参照SC-/ReversalDefのヒットでは行わない。 命中処理6自分ステート変更 攻撃にP1StateNo指定がある場合ヒットしたら自分のステート変更。 命中処理7攻撃情報付与 攻撃の情報を相手に与える。 命中処理8Damage加算 相手のDaamge量に攻撃のDamage数値を加算する。 SC-/HitOverride処理 属性が適合している場合発揮され、StateNoが変更される。StateNo指定が-1の場合変更しない。少なくとも通常対応くらいステート移行処理の後 Target SC-/HitOverrideが発揮していないなら対象の相手をTargetとして認識する。 命中フラグ T-/MoveContact系のフラグを立てる。T-/MoveHit,T-/MoveGuardedはもちろん区別。 Proj時消滅処理 Projによる攻撃を消滅させる 恐らく攻撃キャラ(対象キャラ順番)→次の攻撃キャラの処理順?SC-/HitDefSC-/Projectileの順序・優先度は不明。 ↓ SC-/Explod処理 MoveTime判定 SC-/PauseやSC-/SuperPauseに対するMoveTimeの残量確認残っていない場合は処理をスキップする※射出したフレームではスキップを行わない? Time消失判定 RemoveTime -経過時間 = 0がなら消失する。 OnGetHit消失判定 RemoveOnGetHitが1で親キャラが攻撃を受けたなら消滅。 速度処理 Velの分移動させる。※Bindの影響をこの後に受ける 加速度処理 Accelの分Velに加算※射出時点では加算しない? Bind判定 BindTime中、基準位置へ移動する 時間経過 BindTimeなどTime系パラメータの残りを-1する?RemoveTimeは不変。代わりに経過時間に1加算。※他は調査不足 その他 雑多な処理判定? 表示処理 アニメ表示 命令に従ってキャラの描画をする デバッグ表示 基本デバッグ表示を決定する。SC-/DisplayToClipboard系でない。※デバッグPauseでのFRAMESは停止後+1増えて停止する模様 処理完了 フレーム経過 フレームレートが合うよう待機時間を整える。※フレームレートが高い場合、その分待機せず次フレーム処理へ。 ↓フレーム処理完全終了後、次のフレームへ移る↓ ※あくまで大雑把な推測を含む表なので鵜呑みにしないこと
https://w.atwiki.jp/soyjoynice/pages/117.html
一定期間(もしくは一定量)データを集め、まとめて一括処理を行う処理方式。 または、複数の手順からなる処理において、あらかじめ一連の手順を登録しておき、 自動的に連続処理を行う処理方式。 http //e-words.jp/w/E38390E38383E38381E587A6E79086.html 参考: http //www.atmarkit.co.jp/fjava/rensai4/javabatch01/javabatch01_1.html
https://w.atwiki.jp/bokuyo/pages/27.html
例外処理 try/catch/throw、それと__finally 例外処理とは言っても。 MSさんがWindowsにおいてサポートしている例外処理(例外ハンドラ)は大きくわけて3つある。構造化例外処理 システムデフォルト例外処理 ベクトル化例外処理(ベクタ例外処理) この中でtry/throw/catchのようなコンパイラレベルで実装されるものを、構造化例外処理と呼んでいる。 システムデフォルト例外処理というとこういうの→MSDN - SetUnhandledExceptionFilter こんな感じ。 try{ if(boku != Riaju){ if(boku == kagikko){ throw "Liaju"; } else{ throw "Not Bakuhatsu"; } } std cout "Bakuhatsu" endl } catch(const char* errorMessage){ std cout errorMessage; } try{}の直後、catch{}の直後なら、catchはいくつも作れる。 MSのマネージ拡張C++なら、__finallyが使える。__finallyの中では、try{}の中で使用した変数などの後始末を記述する。 tryがthrowを投げようが投げまいが、どのように処理されようが、____finallyは関係なく呼び出される。 自作例外クラスはいかにして作るべきか? Ogre 3D ではどうしているか? OGRE Ogre Exception Class Reference - OGRE Documentation 標準の例外クラスを継承してつくる 標準の例外クラスの中でも継承して使えそうなにおいがするのはstd exceptionstd logic_error std runtime_error std logic_error と std runtime_error は stdexcept 内で宣言されてるのでそれをインクルード std exception やそのほか派生クラスのstd bad_cast とかは exception 内で宣言されてる。 stdexcept 内で exception をインクルードしてるからstdexceptさえインクルードしとけばよさそう。 標準の例外クラスをとりあえずtypedef して使うとか。 #include stdexcept namespace bokuyo { typedef std runtime_error Exception; } 参考文献 MSDN - 14.3 __finally キーワード C/C++セキュアコーディング(Robert C. Seacord 著) .