昨日書いて、今日もかくという異例の更新頻度を達成したぞ!ヽ( ´¬`)ノ ワ~イ !!
動機などは昨日のブログに書いたが、便利な hspdx を使わずにスプライトを動かしてみたいと思う。
今日はスプライトの細かな仕様を決める前に、実際に処理速度が十分出るかを検証してみた。
基本的には、昨日のプログラムと同じで、パーツ画像をバッファに読み込み、それを重ね合わせてコピーしていく。
昨日は、パーツ画像全体を重ねたが、今回は、キャラ1個分の 24x32 ピクセルだけを重ね合わせて、1個のスプライトを描画する。
そして、そのようなプロセスを繰り返して、スプライトを縦横に画面いっぱいに並べて配置した。
1フレームは 330 ミリ秒だ。
フレームごとに、一度、白い四角で塗りつぶしてからキャラを1つずつ書いている。
それだけだと、画面がちらつくので、ダブルバッファリングをしている。
具体的には一度バッファ(id=9)に書いてからそれをウィンドウ(id=0)にコピー転送した。
おおまかなプログラムはこんな感じだ。
この処理の前に昨日のパーツ画像の読み込みとバッファ(id=9)の初期化処理をしている。
*ScSpTest1
dim frameIdx, 4
frameIdx.0 = 0
frameIdx.1 = 1
frameIdx.2 = 2
frameIdx.3 = 1
for animeFrame, 0, 4, 1
gsel 9 // バッファにかく
color 255, 255, 255
boxf 24 * 0, 32 * 2, 320, 480
for spX, 24 * 0, 320 - 24, 24
for spY, 32 * 2, 480, 32
for partsIdx, 1, 9, 1
pos spX, spY
gmode 2, 24, 32
// 下向きの歩行アニメーション
gcopy partsIdx, frameIdx(animeFrame) * 24 + 0, 0
next
next
next
gsel 0 // バッファからウィンドウに転送
pos 0, 32 * 2
gcopy 9, 0, 32 * 2, 320, 480 - 32 * 2
wait 33
next
goto *SCSpTest1
と思ったが、処理時間を計測していなかった。
見た感じはスムーズに見えるので問題なさそうだが、1フレームの描画にかかる時間を計測してみた。
上に出ているのが、1フレームの描画にかかった経過時間だ。単位はミリ秒だ。
330ミリ秒に1回の更新を目標にしているので 13x13=169個のスプライトを15ミリ秒で処理しているのだから、これでいいかもしれない。
30FPSとか60FPSを出すようなアクションゲームを作るならば描画で15ミリ秒はぎりぎりな感じかもしれないが、今回は十分な速さだ。
速度計測には GetTickCount を使った。
// GetTickCount を使うための準備
#uselib "Kernel32.dll"
#cfunc GetTickCount "GetTickCount"
tBegin = GetTickCount() // 計測開始
// 経過時間の表示
tElapsed = GetTickCount() - tBegin
pos 0, 0
color 255, 255, 255
boxf 0, 0, 96, 16
color 0, 0, 0
mes(tElapsed)
tBegin で計測を始めたときの時刻(ミリ秒)を保持する。
処理が終わった時刻から tBegin を差し引いて経過時間 tElapsed を計算する。
timeGetTime のほうが精度は高まるが、手軽なほうを選んだ。
動機などは昨日のブログに書いたが、便利な hspdx を使わずにスプライトを動かしてみたいと思う。
今日はスプライトの細かな仕様を決める前に、実際に処理速度が十分出るかを検証してみた。
基本的には、昨日のプログラムと同じで、パーツ画像をバッファに読み込み、それを重ね合わせてコピーしていく。
昨日は、パーツ画像全体を重ねたが、今回は、キャラ1個分の 24x32 ピクセルだけを重ね合わせて、1個のスプライトを描画する。
そして、そのようなプロセスを繰り返して、スプライトを縦横に画面いっぱいに並べて配置した。
1フレームは 330 ミリ秒だ。
フレームごとに、一度、白い四角で塗りつぶしてからキャラを1つずつ書いている。
それだけだと、画面がちらつくので、ダブルバッファリングをしている。
具体的には一度バッファ(id=9)に書いてからそれをウィンドウ(id=0)にコピー転送した。
おおまかなプログラムはこんな感じだ。
この処理の前に昨日のパーツ画像の読み込みとバッファ(id=9)の初期化処理をしている。
*ScSpTest1
dim frameIdx, 4
frameIdx.0 = 0
frameIdx.1 = 1
frameIdx.2 = 2
frameIdx.3 = 1
for animeFrame, 0, 4, 1
gsel 9 // バッファにかく
color 255, 255, 255
boxf 24 * 0, 32 * 2, 320, 480
for spX, 24 * 0, 320 - 24, 24
for spY, 32 * 2, 480, 32
for partsIdx, 1, 9, 1
pos spX, spY
gmode 2, 24, 32
// 下向きの歩行アニメーション
gcopy partsIdx, frameIdx(animeFrame) * 24 + 0, 0
next
next
next
gsel 0 // バッファからウィンドウに転送
pos 0, 32 * 2
gcopy 9, 0, 32 * 2, 320, 480 - 32 * 2
wait 33
next
goto *SCSpTest1
frameIdx という配列では、 0, 1, 2, 1 をいれている。
これは、アニメーションのフレームの表示の順番だ。
歩行のアニメーションは3フレームだが、
一度真ん中のフレームに戻ったほうが自然にアニメーションするので、
このようにフレームの順番を指定している。
ループが一杯あるが、 animeFrame 変数のループが今いったアニメーションのフレーム番号のループだ。
このループの終わりのところで 330 ミリ秒待って繰り返している。
spX, spY 変数のループは、スプライトを縦横に並べるための描画位置を表すループだ。
24 とか 32 というマジックナンバーはスプライトの幅だ。
partsIdx 変数のループは昨日書いた、パーツ画像の組み合わせのループだ。
テクニックも何もなく素直に書いて実行してみたが、十分速度は足りているようだ。
これから音楽やキャラのAIや判定などを足していったら足りないかもしれないが、ひとまず安心した。
と思ったが、処理時間を計測していなかった。
見た感じはスムーズに見えるので問題なさそうだが、1フレームの描画にかかる時間を計測してみた。
上に出ているのが、1フレームの描画にかかった経過時間だ。単位はミリ秒だ。
330ミリ秒に1回の更新を目標にしているので 13x13=169個のスプライトを15ミリ秒で処理しているのだから、これでいいかもしれない。
30FPSとか60FPSを出すようなアクションゲームを作るならば描画で15ミリ秒はぎりぎりな感じかもしれないが、今回は十分な速さだ。
速度計測には GetTickCount を使った。
// GetTickCount を使うための準備
#uselib "Kernel32.dll"
#cfunc GetTickCount "GetTickCount"
///// ここに計測する処理をかく。今回は gsel 9の前 ~ wait 33の前まで /////
tElapsed = GetTickCount() - tBegin
pos 0, 0
color 255, 255, 255
boxf 0, 0, 96, 16
color 0, 0, 0
mes(tElapsed)
処理が終わった時刻から tBegin を差し引いて経過時間 tElapsed を計算する。
timeGetTime のほうが精度は高まるが、手軽なほうを選んだ。
コメント
コメントを投稿