スキップしてメイン コンテンツに移動

HSPでスプライトの試作

昨日書いて、今日もかくという異例の更新頻度を達成したぞ!ヽ( ´¬`)ノ ワ~イ !!
動機などは昨日のブログに書いたが、便利な 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"

tBegin = 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 で計測を始めたときの時刻(ミリ秒)を保持する。
処理が終わった時刻から tBegin を差し引いて経過時間 tElapsed を計算する。
timeGetTime のほうが精度は高まるが、手軽なほうを選んだ。

コメント

このブログの人気の投稿

QTableView で表を表示してみる

タイトルは駄洒落を狙っているわけではありません。 こんばんわ SakuraCrowd です。 今回は今作っているソフトの経過報告です。 最近のブログのパターンは、 「XXX作ったよ。これがスクリーンショットね。あとこんなこと思ったよ。」 という流れですが、 今日はできていないソフトの部分的な話なので、 いつもよりもプログラムちっくな話になると思います。(´Ծ_Ծ´)メガネノトキハマジメブッテル QTableView は GUIライブラリ Qt のクラスです。 それを Python で使うための PySide というライブラリを使っています。 某表計算ソフト っぽい表の GUI です。 このデータの日付が 09/01 なのでおそらくその日に   QTableView 使うぞ!(`・ω・´) とサンプルデータを作ったのでしょう。 Qt Designer という GUI エディタを使うとポトペタでウィンドウを設計できます。 選択できる GUI の中に QTableView と QTableWidget があります。 どちらも上のような表の GUI です。 QTableWidget は 簡単 に値をいれたりできます。 Qt Designer 上で直接編集 することができるので、 サンプルの表を簡単に作ることができます。 それに対して、 QTableView は Qt Designer 上では値を編集できません。たぶん。 QTableView の強みは MVC の構造 を使えることです。 名前のとおり QTableView は View です。 これにデータを管理している Model オブジェクトを設定して使います。 Model クラスを作る手間がかかりますが、 GUI の細かな操作をしなくても Model に応じた表を表示してくれます。 Model は QAbstractTableModel を 継承 して作ります。 コンストラクタで基底クラスの処理を呼び出し、いくつかの純粋仮想関数をオーバーライドします。 def __init__ ( self , parent= None , *args):...

和風狩ゲー「WildHearts」プレイ日誌(ツイートまとめ)

幻想的な和風のおとぎ話の世界のような雰囲気で始まる、カラクリで戦略が広がる狩ゲー 「 Wild Hearts 」のプレイ感想(主にツイート)のまとめです。 通常価格は1万円近くしますが、Steam のスプリングセールで 85 % オフの 1, 455 円で購入しました。 カラクリは思ったより全然簡単に出せて面白い!幻想的なマップと御伽噺のような獣たち 20250317 https://x.com/SakuraCrowd/status/1901213871937134633 カラクリ(最初はハコ)を一瞬で配置してそれに乗ってジャンプ強攻撃したり、高い壁のぼったりする要素が新しい。 すごく感動したのが、マップのおとぎ話のような幻想的なデザイン。 フィールドには入れる小屋があったり、それを壊されたり、ダイナミックなステージの変化も楽しい #WildHearts 武器強化や図鑑がこれから増えていくのを思うとワクワク!20250316 https://x.com/SakuraCrowd/status/1901215264269906190 武器を細かく強化していけそうなのがわくわくする 野営地に置く鍛冶の施設とかも少しずつ解除して、好きな位置に配置できる あと討伐した敵の情報も倒した数で詳細な情報が見られる #WildHearts 1バトル5分だけどハラハラ!初の武器強化! 20250317   https://x.com/SakuraCrowd/status/1901597289082405135 ハナヤドシを5回狩ると図鑑が詳しくなって、生態の説明の他に、レアなアイテムを落とす部位もわかった。 しっぽの先についている塊に栄養を吸い取られているためにいつも貪欲らしい。 その塊を何とか3回部位破壊して今作れる一番強いからくり刀できた 一戦5分くらいでできるのがいい #WildHearts コハクヌシを倒して氏繁救出!マグマみたいなのは琥珀だったのかー 20250317 鍛冶師のなつめが言っていた、氏繁をコハクヌシから助ける コハクヌシの住処の洞窟の上から声がして、探してたらやられてしまったw そのあとまたその場所に戻ってバトル再開して勝った 氏繁はなんか飄々としていて、まじめななつめとの3人の旅が面白くなりそう #WildHearts カラカラとなったらコダマを探すの...

LibreOffice Writer 文書の差分 (WinMerge x TortoiseGit) + 社畜PCの原因と対策

お久しぶりです。皆様におかれましてはお風邪などをひかれてはいませんでしょうか。 春と秋だけあればいいのにヽ(`Д´)ノとつい思ってしまう SakuraCrowd です。 今日はいつものような製作日記ではなく、ちょっとした役立つメモを書きました。 タイトルにもあるとおり、 TortoiseGit への WinMerge の導入の仕方です。 今まではソースコードくらいしか差分で確認しなかったので、 TortoiseGit 標準の Diff ツールで問題なかったのですが、 LibreOffice の Writer が最近自分の中で便利だと話題になっていて、それを差分表示するためにちょっと調べてみました。 #Writer は、文章書いて、ちょっと絵をいれたり表を作るのに便利だと思います。 #リッチテキストのエディタを探していて、これが一番よさそうな気がしたので使ってます。 それとブログを書くときはあまり長く書かないつもりだった、 Win7 PC が社畜PCになってしまった際の原因と対策も後半に書きました。割と有用な情報かもしれませんので、時間がありましたらご覧下さい。 まずは TortoiseGit で Writer の odt ファイルを管理して、差分も普通に表示させる方法です。 WinMerge(+plugin) 導入手順 すでに TortoiseGit はインストールしてある前提ではなします。 1.信頼と実績の窓の杜様から WinMerge 日本語版をダウンロードします。 WinMerge - 窓の杜ライブラリ 私の PC は 64 ビット版なのでそちらを選びました。 2.WinMerge をインストールします。 フォルダを指定し普通にインストールできます。 インストール直前の設定で TortoiseGit をチェックしておくと自動的に TortoiseGit の利用する Diff ツールの設定を置き換えてくれるようです。 これの設定は TortoiseGit の設定の Diff ツールの項目で確認できます。 3.LibreOffice Writer のファイルを読むためのプラグインをダウンロードします。 ぐぐって出てくる英語版のDLサイトは応答がなかったりしましたが、日本...