キノコの自省録

日々適当クリエイト

YMZ294のエンベロープについて

ちょっぴりとっつきにくいYMZ294のエンベロープについて。

YMZ294には、音量を増減させるためのエンベロープ機能が用意されています。音量だけなので、今ならソフトウェア的に強引に変えたり、回路工夫すればこれ使わなくても表現できますけど、せっかく用意されている機能なので、使わない手はないでしょう。

PSGのエンベロープとの出会いは、私が小学生の頃、MSX時代に遡ります。しかし、当時はエンベロープパターンと周期の関係がいまいち理解できず、謎の機能としてなんとなく使用していました。

どうでもいい話はおいといて、エンベロープの設定は、次のように行います。

エンベロープ周期

エンベロープ周期は、16bitで設定します。0~65535です。確か、MSXMMLでも、この値を入力していた記憶があります。

YMZ294の値指定はだいたいどれもそうなのですが、この値が直接使われる、つまり、この値=周波数ということはありません。仕様書に記載の通り、

fe =  fsc / 256EP(Hz)

です。EPは入力値、fscは2,000,000です。つまり、65535を入力すると、fe=0.1192(Hz)となります。値が大きいほど、周波数が小さくなります。

EPの値域は0~65535のため、エンベロープ周波数の値域は、0.1192 < fe < 7812.5と求まります。

fe=1Hzだと、エンベロープパターンを1秒に1回繰り返す、fe=1000Hzだと、エンベロープパターンを1秒に1000回繰り返すということです。念のため。

エンベロープパターン

エンベロープパターンは、仕様書に書いてある通りです。単純に減衰したり、ギザギザの音量変化をしたりといった具合です。ただ、これエンベロープ周期との関係がいまいちわかりにくいです。

一応書いてあるのですが、最初見たとき意味がわかりませんでした。この赤線のところに書いてあります。

f:id:kinokorori:20170405232017j:plain

何を言っているのかというと、fe=1Hzの時、→| |←これで示される幅が1周期分だということです。例えば、単純な減衰の場合、fe=1Hzだと、ちょうど1秒で音量が0になります。山型のエンベロープの場合、fe=1Hzの時、2秒で登って下ります。

エンベロープ使用上の注意

これも仕様書に書いてありますが、エンベロープパターンをレジスタに書き込むと、YMZ294内部のカウンター(5bit)をクリアして、カウントを開始します。繰り返し系のエンベロープの場合は問題ありませんが、繰り返しのないエンベロープパターン(0, 4, 9, 11, 13, 15)は、一度カウンタが上がりきってしまうと、そこでストップしてしまいます。

つまり、メロディーを1音鳴らすたびに、エンベロープパターンをYMZ294に書き込んで、カウンタをリセットする必要があります

エンベロープサンプルムービー

エンベロープなし、9番0.8Hz, 10番10Hz, 10番100Hzです。ギザギザ系のエンベロープは、周波数を上げると歪んで聞こえるようになります。ちなみに曲は風色メロディ。

youtu.be

YMZ294で音が鳴らないときのチェック項目

一通り鳴らないやらかしをやったので、備忘録的に。

配線は間違っていないか

YMZ294以前の話というか基本中の基本ですが、何しろ線が多いので、よくミスります。例えば、Arduino NanoでPORTDを使用する時、D0とD1を逆にしないよう気を付けましょう。

また、ブレッドボードでの確認を最初にすると思いますが、配線が浮いていないか、導通しているか確認しましょう。

秋月で買った場合、C012100という水晶がついてきますが、脚を間違いやすいので、よく確認しましょう。

SO-GND間の抵抗

SOはソースフォロワだそうです。1KΩ程度の抵抗をGNDにつながないと、電圧が変化せず、音が鳴りません。

WRCS, A0

レジスタアドレスやレジスタ値を変更するときは、以下の手順で行います。

  1. /WR /CSをLOWに落とす
  2. A0やD0~D7のLOW/HIGHを設定
  3. /WR /CSをHIGHに変更

/WR /CSがLOWでセットアップ、HIGHでホールドということです。ホールド時に値を変更しないようにしましょう。

また、A0はLOWでレジスタアドレス、HIGHでレジスタ値です。逆にしないよう注意しましょう。

ボリューム、ミキサー、楽音

出力したいチャネルのボリュームを設定しましょう。チャネルAの場合、レジスタアドレス0x8に対して、0xfを書きましょう。レジスタ値を0x10とするとエンベロープモードになりますが、エンベロープは直感的にわかりにくい上、音が鳴らない原因にもなるので、音出し確認までは避けた方が無難です。

ミキサーの設定(0x7)は、鳴らしたいチャネルのビットを0にします。チャネルAのみを出力するのであれば、とりあえず0x7に対して0x3e(=0b00111110)を書き込みます。

楽音の設定は、チャネルAの場合、鳴らしたい音をレジスタ0x0, 0x1に書き込みます。秋月の資料にならって、0x0に0x1c, 0x1に0x1を書くのがとりあえず良いかと思います。

ソフト的には、これらボリューム、ミキサー、楽音の設定が最低限必要です。

Raspberry piでYMZ294を鳴らす

ArduinoでYMZ294を鳴らした記事はよく見ますが、Raspberry piで試した人は見当たらなかったので試してみました。

ちゃんと鳴ります。

3.3V問題

Raspberry piのGPIOは3.3Vです。YMZ294は基本5V動作っぽいので、3.3Vで大丈夫か、と思ったのですが、大丈夫でした。

データシート的には、こうなっています。

  • 4/6, /IC, /TEST以外は最小2.2Vでラッチ
  • 4/6, /IC, /TESTは最小3.5Vでラッチ

なので、ロジック電圧を印加するD0~D7, /WR, /CS, A0は2.2V以上でラッチします。/TESTは無接続、4/6はロジックで弄らない、ということで、/IC(リセット)が使えない程度です。

リセット使えなくても特に問題ないですし、どうしても使いたい場合でも1ピンだけなら割と何とでもなるでしょう。

Arduinoとの違い

鳴るとはいえ、正直YMZ294を扱うなら、Arduinoの方が楽です。理由としてはこんな感じです。

  • ピン配が面倒(ラズパイだとD0~D7がどうしても飛び飛びになる)
  • YMZ294のデータ入力に、ArduinoだとPORTDがそのまま使える
  • リセットがラズパイGPIO直だと動かない

ただし、Arduinoだと、PSG鳴らしながら何かするのは結構しんどいと思います。 Rasperry piはプロセス切っちゃえばいいので、その辺は楽ですね。

動作映像

とりあえずやっつけでドレミファソラシド

youtu.be

f:id:kinokorori:20170331234554j:plain

回路図も書こうと思いましたが、要らなさそうだしGPIOピン書くの面倒なので省略。

ちなみに、スピーカーは直結ではなく、D級アンプを嚙ませています。SOはドレイン接地かなにかだと思うんですが、SO-GND間に抵抗を挟まないと、スピーカーが鳴らないので注意してください。

パーティクルで魔法エフェクト(1) - 炎魔法編

f:id:kinokorori:20170327235357p:plain

ウィッチクライドでは、いくつかの魔法をParticle Systemを使って表現しています。

今回は炎魔法を紹介。

動画の1:02あたりで、炎魔法が発動しています。火炎弾ですね。手元でポッと点火して、モンスターに向かって発射、着弾と同時に破裂といったエフェクトです。

ちなみにウィッチクライドはCocos-2dを使っていますが、パーティクルの基本的な考え方は、どのSDKでも一緒です。例えば、Qtにもパーティクルシステムが用意されていますが、パラメタが若干異なるものの、使い方や考え方はやはり一緒です。

CCParticleSun

Cocos-2dでは、いくつかのパーティクルがテンプレートとして用意されていますが、火炎弾は、すべてCCParticleSunをベースに作っています。

CCParticleSunは、ある点を中心とした所定半径内に、速度・加速度ともに0の赤色パーティクルを発生させ続けるテンプレートです。ブレンド条件がスクリーンなため、重なれば重なるほど色が白くなります。そのため、中心部は白色に発光して、円周部は若干赤みを帯びます。円周もいい感じで揺らぐため、さながら太陽のように見えます。

着火エフェクト

CCParticleSunをベースに、いくつかパラメータをいじっています。

CCParticleSun* charge = [CCParticleSun node];
charge.scale = .8f;
charge.position = ccp(startPos.x+40, startPos.y);
charge.texture = [[CCTextureCache sharedTextureCache] addImage:@"flame@2x.png"];
charge.startSpinVar = 360;
charge.endSpinVar = 360;
charge.totalParticles = 100;
charge.duration = 0.8f;
charge.gravity = ccp(charge.position.x, charge.position.y + 100);

動画で確認すると、手元の炎が若干左上に流れているのがわかると思います。

これは、charge.gravity = ccp(charge.position.x, charge.position.y + 100);で、左上に重力点を置いているため、パーティクルがそっちに引き寄せられています。

また、パーティクル自体も、通常のCCParticleSunは半透明の正円(fire.png)ですが、ここではブーメランに近い形状のパーティクルを使用しています。

これがそうですが、真っ白で見えませんね。

f:id:kinokorori:20170330213530p:plain

射出エフェクト

着火エフェクトとは別のCCParticleSunインスタンスを使用しています。これは、CCParticleSunのパラメータそのままで、サイズだけ小さくしています。

そのCCParticleSunをそのままターゲットに向かって移動(CCMoveTo)させているだけです。中心点を移動しながらパーティクルを発生させ続けているため、いい感じに炎の尻尾が表現されています。

爆発エフェクト

これも素のCCParticleSunです。サイズを0.6から3.0倍に150msでアニメーションしているだけです。

魔法詠唱ゲーのキャラデザ遷移

f:id:kinokorori:20170327235357p:plain

今回はゆるく、ウィッチクライドのキャラデザ遷移を紹介するなど。

ウィッチクライド ~君の声が魔法となる~を App Store で

バージョン1

f:id:kinokorori:20170328232439p:plain

一番最初に描いたバージョンです。名前も決まっておらず、とりあえずマジ子と呼んでいました。ピンクの髪と魔法使いの三角帽は最初の段階から固定。結構飄々とした性格という設定でキャラデしたので、なんだかちょっとイラっとくる顔をしています。

バージョン2

f:id:kinokorori:20170328232725p:plain

これは今でも戦闘画面で使用しています。ゲーム画面で使用する絵を先に描いた感じです。なぜコートが半脱ぎなのかは永遠の謎。

バージョン3

f:id:kinokorori:20170328232952p:plain

バージョン1が幼過ぎたので、少し年齢を上げたらなんか変な感じになったバージョンです。純粋に変な絵なので割と即お蔵入りに。

バージョン4

f:id:kinokorori:20170328233149p:plain

バージョン3が変にねっとりしてしまったので、バトルの3頭身キャラに合わせて幼くしたバージョンです。ちょっと幼くし過ぎたので、再びボツ。

バージョン5

f:id:kinokorori:20170328233554p:plain

最終バージョン。ちょっとサイドの髪が気になるんですが、それ以外は大体イメージ通りになったので、これでFix.

こうして見比べてみると、バージョン4とバージョン5は結構似てますね。

その他

姫様はバージョン2、師匠はバージョン3、マリは1発。ということで実は結構描き直してます。描いているうちに画力が上がったり、前の描き方から変えたりしたので、そういう意味でも安定しませんでした。

ちなみにキノコ兵も一発です。素晴らしい。

f:id:kinokorori:20170328234256p:plain

規模の大きな個人ゲームを作る時に大切だと思ったこと

f:id:kinokorori:20170327235357p:plain

ウィッチクライドを開発して感じたことです。

ウィッチクライドはこちら。

ウィッチクライド ~君の声が魔法となる~を App Store で

個人開発だと、思いついたまま適当に開発してしまうことがほとんどだと思います。なにしろ結局全部自分でやるので、業務管理なんか面倒なことはしないでしょう。せいぜい機能の○×表やリソース管理表くらいじゃないですかね。

しかし、ラン系のミニゲーム程度ならば、適当に作り始めてもなんとかなってしまいますが、ウィッチクライドくらいの作品規模になると、適当に作ると途中でわけがわからなくなる、というか気持ちが乗ってこなくなります。

イデアを膨らませるために

ウィッチクライドの基本のアイデアはこうです。

「自分の声で魔法詠唱がしたい。魔法で敵を倒したい。」

魔法詠唱機能は、魔法作成フェーズと魔法実行フェーズとを明確に分けることを初期段階から考えていたので、認識エンジンの方向性についてはある程度ブレませんでした。

問題は、魔法実行フェーズ、つまりゲームでどう魔法を使うか?ゲーム性を持たせるか?というところについては、右から来る敵を適当に倒せばいいんじゃない?程度にしか考えませんでした。

ということで、ろくにゲーム性を検討せずに、ゲーム画面を適当に実装してしまい、結果酷いものが出来上がりました。それがこれです。

f:id:kinokorori:20170327235133j:plain

これはもう、次に何をすればいいのかも頭に浮かばず、完全に開発の手が止まりました。魔法エフェクトはとか敵とか主人公の動きとか、ノーデザインでプログラムで適当にやろうと思ったのが間違い。

そもそも魔法作成が必要なのに、そっちの画面を考えずに、いきなりゲーム画面出しても仕方ないのですが、画面遷移とか設計とか後回しでいいやとか思った結果、こんな適当なゲーム画面をまず作ってしまいました。

画面設計をしよう

途轍もなく当たり前の話ではありますが、プログラミングしながら画面デザインはできません。「とりあえず四角い箱動かせばいいや」はNGです。四角い箱を出すことすら面倒くさいです。

ということで、まず画面設計をする。これが物凄く重要だと感じました。Unreal Engineがブループリントという簡易画面設計ツールを用意しているように、画面の叩き台は最初に作っておくべきものなんですよね。

最低限必要な画面遷移と、各画面の画面設計をして、必要な部品をプロジェクトに取り込み、配置する。これを先にやらないと、気持ちが萎えます。

そんなわけで、まずは絵で画面設計とゲームデザインをしました。次に作ったのがこちらの画面。

f:id:kinokorori:20140501135530j:plain

右にモンスターを配置、左サイドの前衛キャラが防衛しつつ、魔法使いが魔法を撃ち込むという感じです。もうほぼ今の形に近いです。

もう少しデザインを詰めて、できたのがこちら。

f:id:kinokorori:20170328224521p:plain

キャラクターの絵柄やヒロインの位置など、デザイン面は大きく違いますが、ゲームコンセプトとなるベース部分はほぼほぼリリース版と一緒です。とりあえず、初期段階でここまで詰めました。

いきなり戦闘画面に行っても魔法が撃てないので、戦闘画面は一旦置いておいて、メニュー画面系も作りました。初期イメージはこんな感じです。

f:id:kinokorori:20170328225029j:plain

f:id:kinokorori:20170328225028j:plain

※ヒロインの絵柄がバラバラですが、なかなか納得がいかず、最終バージョンになるまで、何度もリテイクしました……。

デザインの差はあれ、ここはそれほど大きく変わる部分ではないので、こちらも基本は大差ないです。

ここまであれば、ゲーム性を確認できるまでの基本画面は繋がります。コード開発はそこからが本番、といった感じです。

ということで、まずは最低限ゲームが成り立つまでの画面設計をすることをお勧めします。特に多少規模が大きいゲームで画面設計がないと、どうにもうまくいかなくなります。

実際、ウィッチクライドの前に別のゲームを作りかけていたのですが、ゲームとしての全体像を最初に作らなかったために、途中で心が折れてしまいました。

個人での特許出願のために必要なプロセス(4) - 出願編

残すは出願のみです。

個人での特許出願のために必要なプロセス(1) - 識別番号取得編 - キノコの自省録

個人での特許出願のために必要なプロセス(2) - 提案書作成編 - キノコの自省録

個人での特許出願のために必要なプロセス(3) - 出願費用の支払い編 - キノコの自省録

1. 特許庁のWebページから、電子出願サポートソフトをダウンロードしてインストールする

2. 電子証明書をゲットする

3. 申請人登録を行い、識別番号を取得する

4. 提案書ひな形ファイルをダウンロードして、ガイドラインに沿って提案書を作成する

5. 出願費用を支払って、提案書に納付番号を記載する

6. インターネット出願アプリで出願を行う

6-a. 記載不備がある場合は修正して再度出願

出願処理

インターネット出願アプリから行います。

出願アプリを立ち上げて、「出願」タブを選択し、「送信ファイル」フォルダを選択します。

すると、左上の「文書入力」ボタンと「合成入力」ボタンが有効になります。

f:id:kinokorori:20170327223148p:plain

1つのhtmlファイルを送信ファイルに変換する場合は「文書入力」ボタンを、複数のhtmlファイルを合成して送信ファイルに変換する場合は「合成入力」ボタンを選択して、提案書ファイルを入力します。

提案書ファイルを入力すると、変換処理とともに、チェッカーが走ります。なお、この段階では特許庁にファイルは送られません。

f:id:kinokorori:20170327223618p:plain

正常ならOK, 警告なら内容を確認して、問題なければ特許庁に出願OK、エラーがあるならば修正して再度変換処理を行う必要があります。

この例の場合は警告ですので、中身をチェックして、必要に応じて修正を行います。警告やエラーの具体的な内容は、html形式で出力されます。

f:id:kinokorori:20170327224258p:plain

大抵の場合、一発じゃうまくいかないと思います。頑張って修正しましょう。特に、【国際特許分類】は、全角スペースを使って正しく桁数を合わせないといけないので、蹴られた場合は良くチェックしてみましょう。

また、一度は印刷して確認してみることをお勧めします。特に図が意図通り出ているか、潰れていないか、小さすぎないかを確かめましょう。

f:id:kinokorori:20170327223150p:plain

もう問題なしという場合、出願したい提案書ファイルを選択して、「オンライン出願」ボタンを選択します。これでようやく特許庁に実際に出願が行われます。

ちゃんと受理されていれば、2, 3日もすると、ステータスが「接受」に変わります。これが完了状態です。

もし、チェッカーには引っかからない類の書類不備等ある場合、「接受」にならず、差し戻しされるようです。

f:id:kinokorori:20170327224920p:plain

出願までの一連の流れは以上です。かなり手間は多いですが、それほど難しくはないという感想です。

出願までならば費用もそれほどかからないので、(業務発明に該当しない)良い特許ネタがあれば、出願してみるのもよいと思います。

なお、審査請求は10万飛ぶので注意してください……。