スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

オーバーフロー時の計算処理調査

Lifemaxが1000のカンフーマンに
LifesetでLifemaxまで回復させた後に
Lifeaddで回復させるとどのような変化を起こすかの実験

条件 1 value=-(-2147483648)/10

これはUフランのダメージ処理の
gethitvar(damage)の部分を-2147483648に置き換えたパターン
これはライフが減少して即死

条件 2 value=-(-2147483647)/10

んでこっちはgethitvar(damage)の部分を-2147483647に置き換えたパターン
これもオキ氏が調べたのと同じで即死しない

条件 3 value=2147483648/10

続いて-(-2147483648)=2147483648になるだろうと予想
でも結果は即死しなかったので
条件1、2、3の実際の計算結果がどうなってるか
displaytoclipboardで表示、結果は下記の通り

条件1 -(-2147483648)/10=-214748364
条件2 -(-2147483647)/10=214748364
条件3 2147483648/10=214748364

これだけだとどういう処理が行われてるか判断に困るので
形を変えた式を3つ用意して調査

条件4 value=-1*-2147483648/10=-214748364
条件5 value=-1*-2147483647/10=214748364
条件6 value=-1*2147483648/10=-214748364

上記の結果を考慮すると
マイナス方向のオーバーフローが発生してる数値を含む場合
符号部分の計算処理がスキップされてるんじゃないかなと
Uフランが即死したのは除算処理の関係ではなく
符号部分が計算されずにライフが減ったのが原因
それでこれはLifeaddやLifeset等で数値の計算を行う際に発生するので
あゆあゆキラー等の場合は既存の式でも問題ないはず



まぁ調査してる時にてんこ達のフロー関係上手くいってないって気づいたから
そこら辺の調整をちょっとしなきゃいけなくなったんだけど
まぁクロウの技と神カラーを弄りながらやってきますかね

コメントの投稿

非公開コメント

No title

mugenでは+方向の2147483648は存在しないのでそこら辺が計算処理に変化あるんじゃないかなーと睨んでる

ちなみに除算処理なければ-2147483647でも即死しますね
普通なら-2147483648+lifemaxの値以内で即死する

-2147483648のみ無視して通すのはまだよくわかんないですね(´・ω・`)

No title

どうも、ドライアイスです

Uフランの即死原因全然わからなくて難航していたところでした・・・w

Re: No title

あー、そうか、2進数での正負の管理の関係で2147483648を作れないから
-2147483648だけは例外処理をしてるのか
そうなるとこの処理が発生するのは
数値に直接マイナス符号を付けてる場合に限られそうですねぇ

Re: No title

ドライアイス氏

ここら辺の処理は分からない事が多いですからねぇ・・・

No title

ttp://hitachi5300.blog.fc2.com/blog-entry-147.html
自分も考えてみたんですがこういうことじゃないでしょうか

Re: No title

単純に-2147483648を2147483648に変換できないのが原因なんじゃないかと
-(-2147483648)/10=-214748364になってしまうので
ライフを214748364減らして死亡って感じじゃないですかね
ライフを最大まで回復させた状態で
value=-(-2147483648)/10000000でLifeaddすると214減るだけでですし
プロフィール

macbeth

Author:macbeth
リンクは報告なしでもOKです
公開中のキャラは可能な限り最新版を使用してください

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
リンク
検索フォーム
FC2カウンター
RSSリンクの表示
ブロとも申請フォーム

この人とブロともになる

QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。