コンティニューしたときに、0じゃなくなるって話じゃなかった?

推測が正しいのかどうか調べたくても、資料が無くて滂沱。ふゆざきです。
9桁と思い込んでるから、訳のわかんない挙動も、内部処理では8桁だと考え直せば、一気に理解出来そうな気がするのです。


推測ってのは、昨日ネタにした、「加点値が10億を超えると、オーバーフローどころか、ロールオーバーを引き起こす」って奴。
この話に関しては、大往生まとめwikiXBox360版での不具合にも上がっている話なんで、詳しい話は、そこと、そこで提示されている真月氏のblogを見に行ってもらうと判るんだけども、
起き抜けに、ふと考えたことがあったんさね。
昨夜の段階では、BCDで管理しているにしても、9桁36bit長では不自然だよなぁ、って思ったわけよ。
けどね。ふとひらめいたことがあって、実は、見かけの数値の10%、つまり、一の位は切り捨て対象になる数値で、内部処理的には8桁32bit長で管理しているのではないのか? って事にね。
で、それを確認するために、黒往生の攻略DVDのブックレットでスコアシステムを確認してみると、『9桁に見えているだけで、実は8桁32bit長で管理している』って事に確証を持てそうな感じになったわけよ。
それだったら、なおさら、10億カット、というか、1億カットが発生するのはおかしいのではないのか? って事になるだろうけど、そこはそれ、データの格納法の違いで、素直に二進数として格納するのではなく、BCD、つまり、二進化十進数で格納していると、あら不思議。1億カットが発生しても何ら不思議じゃないし、蜂アイテムに限らず、緋蜂撃破のボーナスがほぼ0になる、って話にも合点がいきそうだな、って事になってくるわけさ。


んじゃま、検算って事で、Xモード・1面・5530hit時に、10個目の蜂をゲットし、パーフェクト成立で、1億600満点しか加点されなかったという、昨日採り上げた真月氏のblogでの条件で、先の仮説『処理は表示値の10%で、32bit長のBCDで格納。』として計算してみると、
1万*1×5530×2で、1億1060万。
これは、十六進表現、いわゆるバイナリ値なら、
0x0697 9F40
となって余裕で納まるけども、BCD表現で格納されているとなると、
0x0001 1060 0000
となって、32bit長の範囲を軽々と超えてしまい、基本的な符号無し32bit長整数の扱いに従い、下位32bit分のデータ、つまり、
0x1060 0000
だけが有効になると考えられる。この格納データは、BCD表現なので、十進数としては、そのまま読めばいいので、1060万。表示値は、この値の後ろに0をつける、つまり10倍すればいいので、1億600万となって、見事に一致すると……


まぁ、BCDで格納なんかしてたら、それ以外の数値を使わないのでもったいないじゃないか、って意見もありそうなんだけど、BCDで格納してると、表示形式に持って行きやすいという利点があるもんで、処理速度を稼ぐ必要があるアーケードゲームなんかでは、結構有用な手段だったりするんだけどね。
でも……格納範囲を超えてしまうってのは、結構根が深いだろうから……
パッチでなんとかできる問題じゃなさそうだよな……
いや、修繕出来るのなら、修繕して欲しい不具合ではあるんだけどさ。スコアシステム周りってのは。
あと、XBox Live GameでAllしてしまうと、リプレイ保存出来ないってのも、なんとかして欲しいね。


とかなんとか、無駄に踏み込んだネタで区切り更新に変えてみたり。
はぁ……これからバックアップ作業に取りかからなきゃならないのか……ダウナーだなぁ……

><

*1:素点の段階で10%にしておく。