【時計画像素材など】画像素材整理中

フォルダ整理していたら自作でそこそこ使えそうなのがちょろちょろ出てきたので、
素材として配布しようかと思います。

時計素材。横方向に3分割して使ってください。
オススメはりくがめさんの「アナログ時計表示コモン」。
tokei.png

ボタン素材。お手軽ウィンドウで「加算」にして使うとちょうどいいかもしれません。
button.png


・ウディタ以外でも使用可能
・二次配布禁止
・加工可能
・加工した素材の再配布可能
・著作権表記不要
・利用報告不要(あると嬉しいです)
スポンサーサイト

ウディタでエフェクトを音楽に合わせてみよう!【midi編その1】

※その1と書いてしまいましたがその2以降は未定です。てへぺろ

演出が音楽に合わせてバシっと決まるとかっこいいですよね!
というわけで今回は、エフェクトを音楽に同期させてみましょう(簡易的に)。
(本当にがっつり合わせようと思うなら並列実行で「音楽がいま何秒流れているか」を監視しないとだめなんですが、ここはまず入門編ということで)

やること:「XXフレームごとに主人公をシェイクさせる」
必要なのは主人公の画像とイベントひとつだけです。ね、簡単でしょ?
問題は、「XXフレーム」の方をどう算出するかです。

用意するもの:最初から最後までテンポが変わらないmidi音楽ファイル
素材屋さんのmidiの中には、途中で曲の速さが変わるものもあります。メリハリのついた、凝った曲ですね。
今回は、そういった曲は使いません。ウディタに最初から入っている「Battle02_Kagamiyomi.mid」あたりが適任でしょう。

確認すること:ウディタのフレームレート
フレームレートというのは1秒に何フレームあるか、という値で、
FPSという単位で表されています。
「ゲームの基本設定」を開くと、確認できます。
今回は60FPSを基準にして計算します。

さて、いきましょう。
1.曲のテンポを確認する
Dominoか何かを使って、midiファイルを開いてみましょう。
2小節目にカーソルを合わせて、テンポ欄を見てみます。
2013-05-18説明用_テンポ

この曲の場合はテンポが180ですね。
これは、「1分あたり180拍」ということです。(180BPMとも言います)
逆に言えば、1拍あたり1/180分ですね。
1分は60秒ですので、1拍あたり 60/180秒 になります。
さらにさらに、フレームレートは1秒あたり60フレームなので、1拍が3600/180=20フレームになります。
まとめると、1拍あたりにかかるフレーム数は3600/BPMになります。(30FPSのときは1800/BPM)

2.セットアップ時間の分だけウェイトする
midiファイルには、楽器をセッティングするために少なくとも1小節が用意されています。
その時間は音楽が鳴らないので、ウェイトをかける必要があります。
このセットアップの時間は曲を作る人によってまちまちですので、これも確認しましょう。
2013-05-18説明用_セットアッ

この曲の場合、4拍ぶんを180BPMで取っているので、ウェイト時間は3600/180*4=80フレームとなります。

これでぴったり曲のはじまりからシェイクが始まるはずです。

こんな感じに組んで動かしてみれば、同期しているのがわかります。

■サウンド:BGM ファイル[BGM/Battle02_Kagamiyomi.mid] 音 100% 周 100% ル 0ms 再生 / 処理時間:0フレーム
■ウェイト:80 フレーム
■キャラエフェクト:主人公[シェイク] Xシェイク 0 / Yシェイク 20 / 999回 (20)フレーム


速すぎると感じる場合は、シェイク間隔を2倍や4倍にしてみるのもいいかもしれません。

【ウディタ2.02a】DB文字列の不具合対処法+α

2013-03-17 追記しました

シナリオフラグ管理コモンの新バージョンを出しました。
こんどは文字列条件に対応しています。「主人公の名前がNPCと被ったとき限定のイベント」も簡単になりましたよ!
詳しい説明はコモン内にみっちり書いてありますのでここでは省略します
(ご質問等あればこちらにでもコメントいただけましたら幸いです)

さて、このコモン用の新しいデータベースはこちらです
シナリオ管理DB

「条件」のところが文字列変数になっていますが、ここに数字を入れてもかまわないという仕様です。
例えば「条件」に\cdb[0:0:5](主人公0のレベル)、「閾値」に5を入れて、「以上/以下」を1(以上)にすると、
「主人公0のレベルが5以上のとき」という条件で判断できるわけです。
数字か文字かはアレコレゴニョゴニョして、判別できるからいいとして…

問題は、ウディタ2.02でのDBの仕様
「特殊文字列を含む文字列をDBから呼び出すと正常に表示されない」でした。
正確に言うと、2.02a以前はDBの文字列に特殊文字列がくっついてしまっているらしいのですが…
(2.10では修正されている模様です)

廿面骰子でいうと、アイテム名の後ろについてしまうコレですね(おそらくたぶん)
(進行に支障がないので特に修正しない予定ですが)
ten.jpg

これの何が厄介かというと、
「文字列の数字化機能」(公式マニュアル、「変数操作」の一番下)が上手く使えなくなる ということです。
特殊文字列のついた文字列を数字化しても常に0になってしまうというわけですね。これは困った。

今回はこれがなきゃ始まらないので苦労しましたが、見つけた対処法は実に簡単でした。
「DBからコモン内の文字列変数に読み込む」→「別の文字列変数に移す」→「戻す」
つまり、読み込んだままでは特殊文字列がくっついたままですが、
一旦他の文字列変数に移すことで特殊文字列が外れるみたいです。

今までの苦労はなんだったのだー、ってくらい簡単でした。ハイ。
DBから読んできた文字列が上手く表示されなくてお困りの方は、ぜひお試しください。



追記:移し替えなくても特殊文字列を外せるのか
結論から言うと、できます!

拍手コメでご質問がありましたので実験してみました。
引っ張ってくる数は基本システムの「主人公0のレベル限界値」です。外せてたら99、そうでなければ0が入るはずです。
デバッグ文を右の画像のように挟んでおきます。
引数はコレデバッグ文

まずこのまんま実行してみましょう。
試行1
読み込み時点では特殊文字列を外せていなくて、0になっていますね。

次に、「文字列操作」で自分に代入する処理を最初のデバッグ文の前にはさんでみます。
挟んでみます

できたー!
ちゃんと99になっていますね!
試行2

自己代入でも特殊文字列が外れるので、貴重な文字列変数を消費せずに済みますね。
ご質問ありがとうどざいました!

ウディタ関連でよく(?)使われる略語まとめ

今ちょっと書くことがないので、
とりあえずググっても出て来なかった「ウディタ絡みの略語」でもまとめてみようかなと思います。
普段当たり前に使ってますが、初心者さんには分かりにくいかなーと思って。

こちらも参考までに。
単位・用語集 - はじめてのウディタ 挫折して再び Wiki*
変数・データベースとは? - はじめてのウディタ 挫折して再び Wiki*



【ツール編】
ウディタ→WOLF RPG エディター
今更感ありますが、Readmeに正式名称書くときに「エディター」はカタカナだったよね?って迷ったりするんですよ。
ウディタ2→バージョン2.00以降のウディタ
単に「ウディタ」と言った場合、ウディタ2のことかそれともウディタ1のことなのかは文脈や日付などを見て判断する必要があります。
バージョン1台のウディタとウディタ2の違いはこちらに書かれています。→WOLF RPGエディター更新履歴
こっちの方が分かりやすいかも?→ウディタ2.00に迫る! - はじめてのウディタ 挫折して再び Wiki*

ツクール→RPGツクールシリーズ
株式会社エンターブレインが出しているRPG制作ソフト。


【コモン編】
コモン→コモンイベント


【DB編】
DB→データベース
変数を入れておく箱をいっぱい並べた倉庫みたいなものですね。
ウディタには以下の3つがあります。
CDB→可変データベース
UDB→ユーザーデータベース
SDB→システムデータベース


【変数編】
変数
単に「変数」といったとき、どの変数のことなのか?というのは文脈によります。
例えばある処理を作りたくて質問したところ、「変数を作ってそこに入れてください」と回答をいただいた場合。
これが通常変数なのか、予備変数なのか、セルフ変数なのか?というのは処理を作る人次第です。
例えば私はこんな感じの自分ルールで使っています。(例外はありますけど)
変数の使い分け
でも、1コモンで扱う数の設定にCDBや通常変数を使う方もいらっしゃいます。
「その人の使いやすいように使う」でいいと思います。

コモンセルフ→コモンセルフ変数
コモンに100個変数枠ついてますよね。アレです。
(マップ)セルフ→セルフ変数
マップイベントに10個ついてる変数です。
単に「セルフ変数」と言ったときはコモンセルフ変数のことも指し得ますけど、
コモンのこと言ってる文脈じゃないときはこっちでしょうね。


他に何か分からない略語とか単語があってまとめてほしい!という方は
コメント頂けますと幸いですー。

近づくほど高い数値を返すコモンできたよー

近づくほど高い数値を返すコモン(ウディタ公式サイトコモン集)

接触範囲を拡張したマップイベントで、たとえば「近づくほどBGS/BGMの音量が大きくなる」なんてことができます。こんな感じに。
設定例
他にもフキダシ型メッセージの表示/消去とか、近づくと明かりがついてだんだん明るくなるランプなんかにも使えると思います。

イベントとの距離がゼロなら最大値、離れるほど小さな値を返します(接触範囲の縁は必ず-1を返します。消音や消去処理のため)

中心については以下の4通りから選べます。
0:EV半径最大
0EV半径最大
そのイベントの接触範囲の長辺を一辺とする正方形の対角線の長さを基準として算出します。
もともとの矩形の範囲にきちっとおさまる感じ。

1:EV半径最小
1EV半径最小
そのイベントの接触範囲の短辺を基準として算出します。
擬似的に円形っぽくなるので接触範囲の補正としても使えるかも?

20:EVからヨコ一列
20EVからヨコ一列
真ん中の横ラインから縦に広がる感じで設定できます。
川の音なんかに使えそうですね。

30:EVからタテ一列
30EVからタテ一列
こっちはタテバージョン。

付属の「ApproximateDistance」は平方根を使わずに高速で2点間の距離を近似する方法をウディタ用に移植してみたものです。
精度を求めるなら普通にSQRTとか使ったほうがいいとは思いますが、ピクセル単位で測るわけじゃないから精度は別にいいかなと思ってこっち使ってます。軽いですし。1コモンで済みますし。

というわけで是非是非使ってみてください。
近づくほど高い数値を返すコモン
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。