2004年10月


10月1日
 前回の制作記録更新以後、色々なプレイスタイルでリプレイ録ってると、たまーにスローかかるべき場面でかからなくなったり、 いきなり自機の動きが発狂してありえない死に方をかましやがったり…なわけで、 あれこれ手を打って狂い所を調べてみたところ、10進数で表すと26になる1Byteのデータを fgetc関数でファイルから読み出すと、何故かそのデータを入れた変数が全Bitまとめて 1になりやがる…というかなり謎な真相が判明しました。
 しかも、これがどぅガンパっても、当のデータを読み出すと確実に先のオール1に変貌してくれやがるもので、 どぅしてくれよぅか…と悩みに悩んだ末、再生用データの記録形式にややっこしげなモノを採用してよーやく解決。
…しっかし、処理落ち再現を抜きにしても、1Frame分の再生用データに1Byte丸々費やしてる皆様って、 この26問題をどぅやって解決なさってるんでしょうねぃ?
 こーゆートラブルに陥ってるのがわたしだけだったら、反ってお笑いモノですが(ォォィ)。


10月2日
 マニュアルに加筆したりそっち用のSSを撮り直したりで1日終了ー(早)。
 とりあえず一言。スローリプレイつけたの大正解でしたょ。
 ホント、SSが撮りやすいの何のでもぅ。


10月3日〜7日
 微妙なトコロを変更して納得いく内容のサンプルリプレイ録り直して…を夜な夜な繰り返し。
 念のため、Ver.0.35付属のサンプルリプレイ、一応わたしとしてはそれなりにガンパってみたものの… 正直言って、全体的に多少なりとも改善の余地アリです。
 あれらを1つの参考に、スローリプレイも活用しつつ、御自分なりにベストパターンを 編み出しちゃってみましょぅ(クド)。


10月8日
リロードしないとこんな風に怒られちゃいますょ?  リプレイセレクト画面でファイル名を変更した後、迂闊にも一旦タイトルメニューへ戻らず そのまま再生しようとしちゃってプログラムを発狂させちゃう人、絶対現れそうなので… そういうときのために、左のような画面を用意しました。
 これで、迂闊なマネをしでかしてプログラムが発狂することもなくなりましたが… それでも、リプレイファイル名を変更した後は、御手数ながら一旦タイトルメニューへ戻って リロードするクセをきっちりとつけましょぅ。
 余計な御世話ながら、こんなんで怒られてばっかりも凹みものですからねぃ…


10月9日
 今日までの制作記録を簡潔に書いてVer.0.35を公開して現在に至ります。オシマイ(ォォィ)。


次の月の記録を見てみる

戻る

インデックスに戻る