Repo

kjana00@gmail.com

older <-

2020-09-24 01:47:57

今朝は晴れ。朝ごはんはパンとトマトとソーセージ。何かまた暑くなったなというのが台風があたたかい湿った空気を連れてきたからだ、というのに思い至ったりしつつ。

時間でお仕事開始。あれこれちまちま調べていじって、上手く行ったり行かなかったりと。とりあえずちゃんと設定出来なかったからか、変な #define 入れてみつつ余分に API 呼び出し入れてるから二倍の周回になってるぞこれ、というのの「ちゃんとした設定」の仕方は分かった。やってみてから見直したらちゃんとドキュメントに書いてあった……

お昼にパプリカ、オリーブ、ほたてのトマトソーススパゲティ食べて、ちまちまと短い打合せを挟まれつつそんなのを続けてたら、別プロジェクトの方で相談を受ける。判定時間をいじって欲しいっていうのは全然問題無いけど、ちょこちょこフラグが落ちる様子が見えるのは何だか分かるかというのはちょっと問題あるかもしれないんで真面目に調査。

で、この辺はここのコールバックで処理してて、とその関数を見てすぐ、このカウンタは 4 bits しか使ってないから 0xFF を INVALID 値としておいて前回値が INVALID 値だったら前回値の更新だけして今回は前提条件外れ扱い、としてたところが問題になってるのに気付く。カウンタが 8 bits 使うバリエーションなんで。そりゃ周期的に前提条件外れるわ、と。

それでもそこそこまともに動く分には問題無いよねと言いたいところだったけど、カウンタが 0xFF で固まったら検出出来ないわけだと言われると修正せざるを得ないわけで。しょうがないんで普通に前回値がまともに埋まってるかどうかを示すフラグを導入。最初からそうしておけっていう話はあるけどこれ作った当初はカウンタのビット数が変わる予定無かったからね……

動作確認もしてもらってコミットしておしまい、後はまた打合せがあって終了。今月末のリリースに向けた作業が一応まとまったけど、今日まで設定をちまちま直してたのはどうしようね? 入れた方がいいと言えばいいんだけど、ほぼ何も検査しないでリリースになりそうっていうのを考えるとちょっと前に最低限の検査はした上で出したものに必要最小限の修正だけ加えたものを出す方がいいような気がしなくもない。うーん?

ちょっと休憩の後買い物へ。で、戻って晩ごはんに豚の角煮の汁のそば。やっぱりこの角煮はおいしいのだよね。それで後は WWW 見たりゲームしたり。微妙にひやひやしつつ柳じじいを倒した後、森に向かって 25 階まで。ネクサスハウンドの群とか出始めると、そういえばまだ耐因果混乱無かったねっていうのが気になりだしたりするわけで。辛い。

older <-

goto

hint can be:

Tags

old

2007-05 -- 2006-12

ゲーム関係の古い記録

before 2005-12