今日は書くことがあります！
「ふにゃふにゃ」で、上層ビットマップを表示できるようにしました。
つまり、主人公よりも手前にある物体を表示できるってことです。
画面写真も新しいものと取り替えました。
中華料理店で「四川山椒入りラーメン」を食べました。
見本が美味しそうなので注文したのですが、その時父がボソリ。
「おまえ、辛そうなもの頼むなぁ・・・・」
そのラーメンが運ばれてくると、確かに辛そうな香辛料の匂い。
そして父が先に一口食べてまたボソリ。
「このラーメンは味が濃いなぁ・・・・」
一体どんな味のラーメンなんだ!?
と思いながら食べてみると、さほど変わった味ではない。
ところで、山椒入りラーメンでわざわざ山椒を残すのって駄目ですか？
本当に久しぶりにタクシーに乗りました。
しかし普段乗らずたまに乗ると、このタクシーはもしかしたら事故を起こすんじゃないかを不安になってしまうことがありますね。
プログラミングに「IntersectRect」を追加しました。
最近開発が停滞しているRPG「Bomber丸World」の戦闘は、終了する条件が色々あったりします。
敵を倒した、逃げ出した、なども勿論ありますが、他には仲間が死ぬ(即ゲームオーバー)、仲間全員が大ダメージにより戦闘不可能になる、戦意喪失、その他特殊な条件、など。
「ふにゃふにゃ」と同じく、一部にスクリプトを使っている(予定)ので、色々特殊な戦闘を作れます。
「ふにゃふにゃ」で、ロージャンプバグの一つを解消しようとしましたが、駄目でした。
今使っている動作確認用のステージの左上には風が吹いているんですが、今まで弱い風だったのを様々な強さの風にして試してみたところ…
弱い風：ジャンプ中にやや影響を受ける
やや強い風：風下に向かって走ってそれもやめても止まりにくい、空中で操作が効きにくい
強い風：風下に向かって走ってそれをやめても止まれない、空中で操作が効かない
かなり強い風：その場で止まっていられない、空中で風に流される
とても強い風：風上に向かって走れない
さらに強い風：何をやっても同じく吹き飛ばされる
そんなことはともかくとして、ビットマップ表示処理を作らねば!!
「爆ボン」でゴールドパーツ入手。
どきどきモードで1時間57分かかりました。
ゴールドパーツ入手条件が3時間以内に完全クリアだからこれってスゴイ？
今日は「爆ボンバーマン(以下爆ボン)」をやっていました。
「爆ボン」は私の最も好きなゲームの一つです。
昨日日記に書き忘れていたことを今日書きます。
昨日万有引力について勉強していたんですが、その中で全く理解不可能な式が出てきました。
今まで問題の解き方がわからないことはあっても物理の性質や現象について全く理解できないことは無かったのに！
その問題の式は、次のようなものです。
万有引力定数をGとする時、質量M[kg]の地球の中心からr[m]の距離にある質量 m[kg] の物体が持つ万有引力による位置エネルギー U[J] は無限遠の点を基準に取ると、
U=-GMm/r
こんなもん、「こんな公式があるから覚えてね。」なんて言われても自分で全く理解できないことを覚えられますか？
エネルギーが負なんですよ！
一秒当たり Gmm/r[N] の地球から遠ざかる力を受けるんですよ！
私は考えました。
帰宅中歩きながら考えました。
家で宿題をやりながら考えました。
ゲームをやりながら考えました。
風呂に入りながらも考えていました。
そもそもなんで基準点が無限遠なんかにあるの?!
と思いながら、地球上のちっぽけな空間で考えた場合の位置エネルギーを万有引力の公式から求めてみると…
あら不思議、矛盾無く見慣れた E=mgh という公式が出てきたじゃありまえんか。
そこで私はまた考えました。
確かに引力は距離の関数だ。
しかし、その力が地球に向いているからには普通の重力と本質的には代わらないのではないか。
例えば、普通の位置エネルギーの公式 E=mgh は mg[N] の力でh[m] 上に持ち上げたという意味だ。
それと同じように考えれば、U=-GMm/r という公式の意味は平均 GMm/r*r[N] の力を外向きに加えながら、しかし r[m] だけとんでもなく遠い場所から内側に引きずり込まれて、その時に外側から引っ張った力が行った仕事が E=-GMm/r だったのでは？
ちなみに、引きずられる時に行う仕事の符号は負です。
それで最後に万有引力の公式のせいでプログラミングが出来なかったんだと言い訳をしてみたり(ゲームのせいだろ！)。
今まで散々ふにゃふにゃっとしたことばかり書いていて今日突然「MusicPlayer5」をアップしました。
「Windows Media Player」の最新版がやたら重いだけが取り得のような感じだったので「こんなもん使ってられるかーー！！」ということで作ったものです。
…にしてもちっこいですね～。
まあ、そんなもんです(どんなもんなんだ!?)。
「ふにゃふにゃ」のビットマップ読み込み部分をyanePackExに対応させました。
実は昔日記にはビットマップ読み込み部分を自作していたと書いたんですが、それがうまくいかなかったので暫くの間標準APIを使っていました。
そしていつしかその事を忘れ、自作関数を使っているつもりにずっとなっていたんですが、この前プログラムをざっと見直してみたら、標準APIのままになっていたので自作関数に戻したんですが、当然うまくいきませんでした。
しかしその原因がCreateDIBSectionにあることはわかっていました。
でもCreateDIBSectionはDIBから普通のビットマップ(DDB)を作るものだし…
と思いながらインターネットで検索すると、これはDDBからDIBを作るための関数だということがわかりました。
逆じゃん！！
とは思いつつも、もう一つ思い当たる関数、CreateDIBitmapについて調べてみることにしました。
しかしこれはDDBからDIBを作るものだし、と思っていたら…
ハイ、これもまた逆でした。
まあ、そんなわけでめでたく自作関数はうまく動いたわけです。
どこがめでたいんだなんて言わないでくださいよ！
今日は何故かスクロールバーの動きがおかしいです。
使いにくくて仕方がありません。
「ふにゃふにゃ」で使う文字を描いていました。
このゲームでは結構決まりきった文字が使われるのと、グラデーションを施す必要があるのと、環境に依存せずどこでも同じ文字の形にするためにビットマップで描いています。
たいした変化は無いんですけどね。
ちなみに、「ふにゃふにゃ」は二人用アクションゲームですが、内容は格闘ゲームとは限りません。
二人で協力してプレイしたり一定の条件を満たすことで勝敗が決まったりもします。
「ふにゃふにゃ」で、ビットマップの任意の場所を背景として使えるようにしました。
これをうまく使えばアニメーションする背景、なんていうのも作れます。
また、ジャンプの準備動作中には加速関数が無効になるようにしました。
これが有効だと前に低く跳ぼうと思ってもいつのまにか後ろに向かって跳んでいってしまうことがあります。
さて、まだまだロージャンプバグ(低いジャンプの時に起こるバグ)が残っているから早く直さねば。
昔日記に書いたことがありましたが、ホルスト作曲の「木星」はループさせることのできる音楽です。
プログラミングコーナーと同じ書き方をすれば、
A→B→C→A'→B→D
となります。
二番目のBから最初のBにループさせています。
プログラミングコーナーを更新しました。
でも以前にも日記に書いたように、音楽用語には全然自信が無いのです。
音楽は好きですが音学は嫌いなのです。
しかも重要な用語に限って中学や高校の教科書には書いてないし・・・・
だから間違いを見つけたら、一人で「フフフ、ときおのバカめ」なんて思いながら黙って見ていないですぐに報告してください。
「ふにゃふにゃ」には連立方程式が多く使われています。
例えば、線を表示するかどうかを判定するだけで約20個使っています。
殆どコピペだけど。
「Bomber丸World」のBGMの音程がずれているのを発見したのでいつか修正するつもり(今じゃない)。
「ふにゃふにゃ」で、ウィンドウが非アクティブになった時にポーズをかける機能をつけました。
ウィンドウプロシージャでメッセージがWM_ACTIVATEの時にパラメータが0ならば非アクティブです。
今日、旧「Tokio's Web Site」が閉鎖されました。
掲示板の書き込み少ないなぁ…
ここ一ヶ月何も書き込まれてない。
ヨッシーアイランドで！
とうとう！
やりましたよ！！
999ヨッシーを！！！
で、その後なんですが、ミニゲームなどで1UPなんかを取ると一時的に残りヨッシーが0匹になってその後すぐに戻ります。
よって、最大残りヨッシーは999匹です。
ウィルスバスターを買ってきてウィルスに感染していないか確認したら、ニムダウィルスに感染していました。
もしかしたら既にウィルスをばら撒いているかもしれないので、これを見ている人はすぐにウィルスチェックをすることをお勧めします。
「ふにゃふにゃ」に加速関数を追加しました。
風などの処理に使えるはずです。
今日は何か複雑な関数のグラフを描いていたんですが、第二次導関数を求めると、明らかにグラフの予想図とは矛盾する式が出てきました。
普通はグラフを描くために第二次導関数を求めるものなのですが、グラフから第二次導関数の間違いが判明したのです。
グラフを導くために求めた導関数がグラフに導かれてどうすんだ！！
こんな出鱈目な導関数なんて無視だ！！！！
・・・・とはいえ、やはりそれでは納得がいかないので、もとの関数を良く見てみると・・・・そうだ、すっかり忘れていた！
このグラフはy軸に対して対称だったんだ！！
ここからわかることはつまり、第一次導関数は原点対称で(これはあっている)、第二次導関数はy軸に対して対称であるということです。
ということは第二次導関数にxの一次式が出てくるはずはないから・・・・わかった！
合成関数の合成関数の導関数だったから少々混乱していたようです。
こんなことで数学が得意なんて言ってていいのか・・・・？
グラデーションの処理を高速化することが出来ました。
表示をする前に予めソース画像にグラデーションを施したものを作っておくという方法をとりました。
[白黒画像読み込み]→[マスク作成]→[グラデーション]→[普通に表示]
というプロセスで表示をしています。つまり
[毎回グラデーション]→[最初だけグラデーション]
ということです。
「ふにゃふにゃ(形容動詞の語幹ではない)」の制作をしていました。
今日は早く学校から帰ることが出来たのでいろいろしてみました。
まず画面サイズを変えました。
今までは画面サイズが小さすぎてすぐ足を踏み外していたので画面サイズをかなり大きくしました。
次に、グラデーション部分を改良しました。
速度的にはかなり改悪された雰囲気ですがまあいいでしょう(どこが)。
最後に、主人公の絵を追加しました。
こんなもの絵のうちに入っているかどうか怪しいものですが・・・・
ついでにサイズも変更しました。
これで多少枠からはみ出るようなポーズを取らせても平気です。
ゲームプログラミングやりました。
「ふにゃふにゃ」で、地上にいる時の足元の当たり判定を作りました。
要するに、足を踏み外していないかどうかを調べるものです。
まあ、ジャンプ時のものをコピペしてちょっと変えただけなんですが。
で、ここからはプログラムの内容に深く入り込むので解りにくいかと思うんですが、主人公の落下速度がほぼ等速だったので、副産物として当たり判定で同時に坂の上り下りの処理が出来てしまいました。
話は変わって、私は今「MusicPlayer」は2以外全部愛用しています。
2を使っていないのは、3より明らかに低機能、だからです。
「リダクター」のファイル読み込み部分を作りました。
今度は8ビット(256色)ビットマップの減色を出来るようにします。
ちなみに、ここでいう減色とは、パレットの使われていない要素を削除して、パレットの分だけファイルサイズを小さくすることです。
こんな物を作っているのは、今使っている減色ソフトが何故かパレットにバリバリ未使用の色を加えていくという、結構解り易い理由からです。