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

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):...

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サイトは応答がなかったりしましたが、日本...

HSPで画像の重ね合わせをしてみた

あいにくの曇り空だったが、 スーパームーン を少し見ることができた。 なんとなくだが、月明かりがいつもよりも強い気がする。 中秋の名月とほぼ同時に月が地球に 接近するのは稀らしいので何かありがたい(-人-) 先週ブログを書いていたときに、 ハロウィン にちなんだゲームを作りたいなー と思っていて、ふわっとした企画を考えて、少し作り始めた。 まだできるかどうかわからないけど、初めて HSP で絵を出せたのがうれしいのでブログを書いてみる。 HSP 自体はだいぶ前から知っていて、ちょっとしたGUIのツールを作ったりしていた。 GUIアプリケーションをここまで短く実装できる言語は自分の中ではこれが一番だと思う。 もっと短くできるかもしれないが、ビギナーな私でもこのくらい短くかける。 screen 0, 160, 64 // ウィンドウ作成 button "greet", *OnGreet // ボタン作成&イベント関連付け stop *OnGreet // イベント dialog "Hello!" stop バージョンアップして今では WebGL や  iOS や Android でも実行できる。 そのときは HSP3Dish という環境を使うために  #include "hsp3dish.as"  でスクリプトを読み込む。  参照: HSP3Dish プログラミングマニュアル・基本仕様ガイド 制限として、拡張プラグインやCOM/Variant型や外部DLL呼び出しやモジュール変数については未サポートのようだ。 ゲームでスプライトを用いるため es_set などのスプライト用の関数を使いたかったが、これは hspdx という拡張プラグインなので HSP3Dish には対応していないと思う。 そんな理由から、スプライト系の処理を自作しようと思う。 先週ちまちまとドット絵を描いたので、それを HSP のウィンドウに描画してみた。 なんかドット絵を作っている最中は、わりと良く思えたのに、 ウィンドウに出してみると何か微妙 (´・ω・`) ちなみに、キャラは4コマにも描いている大砲ゲーム「お団子キャノン」に出てくるキャラクターだ。 キャラの...