「ふにゃふにゃ」で、ロージャンプバグの一つを解消しようとしましたが、駄目でした。
今使っている動作確認用のステージの左上には風が吹いているんですが、今まで弱い風だったのを様々な強さの風にして試してみたところ…
弱い風：ジャンプ中にやや影響を受ける
やや強い風：風下に向かって走ってそれもやめても止まりにくい、空中で操作が効きにくい
強い風：風下に向かって走ってそれをやめても止まれない、空中で操作が効かない
かなり強い風：その場で止まっていられない、空中で風に流される
とても強い風：風上に向かって走れない
さらに強い風：何をやっても同じく吹き飛ばされる
そんなことはともかくとして、ビットマップ表示処理を作らねば!!
「爆ボン」でゴールドパーツ入手。
どきどきモードで1時間57分かかりました。
ゴールドパーツ入手条件が3時間以内に完全クリアだからこれってスゴイ？
「ふにゃふにゃ」のビットマップ読み込み部分を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」が閉鎖されました。
掲示板の書き込み少ないなぁ…
ここ一ヶ月何も書き込まれてない。
ウィルスバスターを買ってきてウィルスに感染していないか確認したら、ニムダウィルスに感染していました。
もしかしたら既にウィルスをばら撒いているかもしれないので、これを見ている人はすぐにウィルスチェックをすることをお勧めします。
「ふにゃふにゃ」に加速関数を追加しました。
風などの処理に使えるはずです。
今日は何か複雑な関数のグラフを描いていたんですが、第二次導関数を求めると、明らかにグラフの予想図とは矛盾する式が出てきました。
普通はグラフを描くために第二次導関数を求めるものなのですが、グラフから第二次導関数の間違いが判明したのです。
グラフを導くために求めた導関数がグラフに導かれてどうすんだ！！
こんな出鱈目な導関数なんて無視だ！！！！
・・・・とはいえ、やはりそれでは納得がいかないので、もとの関数を良く見てみると・・・・そうだ、すっかり忘れていた！
このグラフはy軸に対して対称だったんだ！！
ここからわかることはつまり、第一次導関数は原点対称で(これはあっている)、第二次導関数はy軸に対して対称であるということです。
ということは第二次導関数にxの一次式が出てくるはずはないから・・・・わかった！
合成関数の合成関数の導関数だったから少々混乱していたようです。
こんなことで数学が得意なんて言ってていいのか・・・・？
グラデーションの処理を高速化することが出来ました。
表示をする前に予めソース画像にグラデーションを施したものを作っておくという方法をとりました。
[白黒画像読み込み]→[マスク作成]→[グラデーション]→[普通に表示]
というプロセスで表示をしています。つまり
[毎回グラデーション]→[最初だけグラデーション]
ということです。
「ふにゃふにゃ(形容動詞の語幹ではない)」の制作をしていました。
今日は早く学校から帰ることが出来たのでいろいろしてみました。
まず画面サイズを変えました。
今までは画面サイズが小さすぎてすぐ足を踏み外していたので画面サイズをかなり大きくしました。
次に、グラデーション部分を改良しました。
速度的にはかなり改悪された雰囲気ですがまあいいでしょう(どこが)。
最後に、主人公の絵を追加しました。
こんなもの絵のうちに入っているかどうか怪しいものですが・・・・
ついでにサイズも変更しました。
これで多少枠からはみ出るようなポーズを取らせても平気です。
ゲームプログラミングやりました。
「ふにゃふにゃ」で、地上にいる時の足元の当たり判定を作りました。
要するに、足を踏み外していないかどうかを調べるものです。
まあ、ジャンプ時のものをコピペしてちょっと変えただけなんですが。
で、ここからはプログラムの内容に深く入り込むので解りにくいかと思うんですが、主人公の落下速度がほぼ等速だったので、副産物として当たり判定で同時に坂の上り下りの処理が出来てしまいました。
話は変わって、私は今「MusicPlayer」は2以外全部愛用しています。
2を使っていないのは、3より明らかに低機能、だからです。
ジャンプ中の足元の当たり判定をつけました。
これで飛び上がっても落ちっぱなしにはなりません。
立っている地面が斜面で動いていたりすると立ち位置がずれたりもしますがこの辺は慣性で滑ったと言うことでごまかしておきます。
回転する正方形の上に乗ると大変なことになってしまいますがこれは後で調整するということにしておいて、別の話題でも。
世界史のテストが返ってきました。
思ったよりいい点数でした。
それでもかなり悪い点数でしたが。
ビットマップ読み込みの部分を自作しました。
前に作っておいたものを使うように設定しなおしただけですが。
それと、プログラムそのものとは関係ありませんが、画面写真に写っている正方形は、静止画像ではわかりにくいですが、実は回転しています。
64フレーム(約3秒)で一回転します。
中間テストがやっと終わりました。
世界史やばい…
昨日日記に入ることができなかったので昨日の分の日記。
02/05/22
「ふにゃふにゃ」(今作っているゲームです)の主人公の移動速度を前作の「ふにゃ」と比べて少し調整しました。
ジャンプの処理を作りました。
足元の当たり判定が無いのでジャンプしたらいつまでも落ちっぱなしになってしまいますが…
やっとゲームらしい動きになってきました。
って、中間テスト期間中なのにこんなことやってていいのか！？
やっと主人公の動きのプログラムに入りました。
走ります。
しかも結構不思議なことがあるもので、走っている方にしてみればたいしたスピードでなくても、止まって見ている方から見ればかなりのスピードが出ているように見えるのです。
・・・・そうか、スクロールの遅れからそう見えたのか！！
書きながら原因に思い当たってしまいました。
今日から中間試験です。
一応数学は全問回答欄を埋めたので計算ミスがなければ100点です。
90％以上計算問題でしたが。
プログラミングなんかやっとる場合か、自分…
先程日記を書き込もうとしたらエラーが出て終了してしまいました。
「ふにゃふにゃ」で、表示位置を少しずらすようにしたら少しどころでなくずれるようになってしまいました。
「Bomber丸World」はyaneSDK2ndを使ってはじめから作り直すつもりです。
画面写真を更新しました。
背景は「ふわふわふにゃ」の使い回しです。
ビットマップ読み込みの方は何とか誤魔化しておきました。
NormalとTransを間違えていた、条件判断の位置がおかしい、\\とすべきところを\としていた・・・・
などなどいろいろの条件が組み合わさっていた模様です。
ちなみに、三角関数なんかも使えるので回転床などの処理など、少々複雑な処理もできてしまいます。
今後の課題としては・・・・
・主人公をちゃんと動かすようにする
(現状では直立姿勢のまま飛び回っています)
・ステージ定義ファイルの使用
(いちいちスクリプトに書き込むのが大変なので)
・攻撃の処理を作る
(攻撃には「頭突き」、「氷の息」、「押し出し」などがあります)
・動く床の動きに主人公をついてゆかせる
(床がどう動こうとその場を離れないというのは変なので)
と、こんなもんです。
シャーペンがまた普通に使えるようになりました。
まだビットマップの不都合は直りません。
だから自前でビットマップを読み込む処理を作ったのですが余計に悪くなりました。
でも私は諦めません。
圧縮ファイルを使うのでいつか遅かれ早かれ自前で読み込む処理を作らねばならなかったのでこの機会に仕上げてしまいます。
紙を汚す消しゴムはもう捨てました。
「ふにゃふにゃ(もう省略しません)」で、斜め線を表示できるようにしました。
この辺は25%ぐらい作ってしまえば残りの75%はコピーして必要なところだけちょこっと変更を加えるだけでよいので楽でした。
と言いたかったのですが、変更部分が複雑な場所だったり線の向きが右上がりか左上がりかで条件判断の順番まで変更しなくてはならなかったりと大変でした。
それでうまくいったので画面写真を更新しようと思って、それなら背景ぐらいもうちょっとまともな絵を使おうと外部ファイルを背景に使おうとしたところ、エラーが出るようになりました。
そんなわけで、画面写真の更新はもうちょっとまって下され！
f2(解らぬ者は過去の日記を参考にするが良い)で、主人公の向きを変えられるようにしました。
StretchBltなんて使ったことがなかったので結構苦労しました。
後は斜め線の処理と当たり判定とビットマップ表示と勝敗の判定と画面外処理とユーザー公開関数の追加と設定とステージファイルを作るだけで完成です！
大丈夫、厄介なのは斜め線だけの筈だから…
ついに画面写真を公開しました。
更新履歴には書いてません(書いてたら次の日になってしまう)。
暗い色の方が相手キャラクターです。