ブローヴちゃん

GV-HUVC を買った

2018-06-20T22:51:00.000+09:00

http://www.iodata.jp/product/av/capture/gv-huvc/index.htm

USB 3.1 Gen1 接続で、USB Video Class 対応の HDMI キャプチャーデバイス。
専用のドライバーを必要としないので Windows 以外でも動作し、メーカーからのドライバーや専用ソフトの継続的な更新を必要としないため OS の更新などでデバイスが使えなくなる心配が薄い。
ただ USB 3.1 Gen1 が実質的に必須でAMD製チップセットなど非対応なものもあるようなので、そのあたりでトラブルが起きる可能性は少なくない。

この手の HDMI キャプチャーデバイスでは近年では AVerMedia 製のデバイスが特にメジャーだと思うが、専用のドライバーやソフトウェアがあるタイプの製品はあまり好きではないので、今回は GV-HUVC を買うことにした。
AVerMedia の UVC 対応デバイスは7月に出るらしい。

ffmpeg でフォーマットを列挙すると以下の通りで、MJPEG には非対応。

> ffmpeg -list_options true -f dshow -i video="I-O DATA GV-HUVC, Video Capture USB":audio="@device_cm_{33D9A762-90C8-11D0-BD43-00A0C911CE86}\wave_{4CFE616A-B674-474C-B539-907085A96B08}"
ffmpeg version N-91317-gb41b6b3234 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 7.3.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
  libavutil      56. 18.102 / 56. 18.102
  libavcodec     58. 20.102 / 58. 20.102
  libavformat    58. 17.100 / 58. 17.100
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 25.100 /  7. 25.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
[dshow @ 0000022f7989ac80] DirectShow video device options (from video devices)
[dshow @ 0000022f7989ac80]  Pin "繧ｭ繝｣繝励メ繝｣" (alternative pin name "0")
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1920x1080 fps=6 max s=1920x1080 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1920x1080 fps=6 max s=1920x1080 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=800x600 fps=6 max s=800x600 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=800x600 fps=6 max s=800x600 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1024x768 fps=6 max s=1024x768 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1024x768 fps=6 max s=1024x768 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1152x864 fps=6 max s=1152x864 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1152x864 fps=6 max s=1152x864 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1280x960 fps=6 max s=1280x960 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1280x960 fps=6 max s=1280x960 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1280x1024 fps=6 max s=1280x1024 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1280x1024 fps=6 max s=1280x1024 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1440x900 fps=6 max s=1440x900 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1440x900 fps=6 max s=1440x900 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1600x900 fps=6 max s=1600x900 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1600x900 fps=6 max s=1600x900 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1600x1200 fps=6 max s=1600x1200 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1600x1200 fps=6 max s=1600x1200 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1680x1050 fps=6 max s=1680x1050 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1680x1050 fps=6 max s=1680x1050 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1280x720 fps=6 max s=1280x720 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1280x720 fps=6 max s=1280x720 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=720x480 fps=6 max s=720x480 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=720x480 fps=6 max s=720x480 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=720x576 fps=6 max s=720x576 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=720x576 fps=6 max s=720x576 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1280x800 fps=6 max s=1280x800 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1280x800 fps=6 max s=1280x800 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1360x768 fps=6 max s=1360x768 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1360x768 fps=6 max s=1360x768 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1366x768 fps=6 max s=1366x768 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1366x768 fps=6 max s=1366x768 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=640x360 fps=6 max s=640x360 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=640x360 fps=6 max s=640x360 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=768x576 fps=6 max s=768x576 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=768x576 fps=6 max s=768x576 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=856x480 fps=6 max s=856x480 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=856x480 fps=6 max s=856x480 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=960x540 fps=6 max s=960x540 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=960x540 fps=6 max s=960x540 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1024x576 fps=6 max s=1024x576 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1024x576 fps=6 max s=1024x576 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1920x1200 fps=6 max s=1920x1200 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=1920x1200 fps=6 max s=1920x1200 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=640x480 fps=6 max s=640x480 fps=60.0002
[dshow @ 0000022f7989ac80]   pixel_format=yuyv422  min s=640x480 fps=6 max s=640x480 fps=60.0002
[dshow @ 0000022f7989ac80] DirectShow audio only device options (from audio devices)
[dshow @ 0000022f7989ac80]  Pin "Capture" (alternative pin name "Capture")
[dshow @ 0000022f7989ac80]   min ch=1 bits=8 rate= 11025 max ch=2 bits=16 rate= 44100
    Last message repeated 22 times

レイテンシーはそれなりにあるので、アクション性の高いゲームのキャプチャーなどを行う場合には HDMI スプリッターは必須だと思われる。
キャプチャーした映像には品質的な問題はない。

拡張編集と Shift_JIS

2018-03-04T06:09:00.001+09:00

PSDToolKit を作っていて「ダメ文字」問題と向き合うことになったので、思い出がてら記録しておく。

拡張編集は多くの箇所で MBCS 文字列を使っていて Lua スクリプトでも Shift_JIS が使われるので、例えば

A = "サシスセソ"

みたいなスクリプトはそのまま記述されると上手く動かないことが容易に予想できる。

ところが、実際にはテキストオブジェクトに

<?mes("サシスセソ")?>

と書くと上手く動き、

<?dofile("test.lua")?>

として、test.lua の中に同じ内容を書くと、こちらは動かない。

内部で何が起きているのかを知るのは簡単で、ダブルクォートの代わりに

<?mes([[サシスセソ]])?>

このようにすると、画面には

サシスセソ\

と表示される。

つまり、拡張編集では拡張編集が用意したダイアログ内に入力されたテキストに対しては独自にダメ文字対策を行っていて、その対策方法は恐らく単純に「ダメ文字を探して \ を足す」という形で行っているので、実際にエスケープする必要があるかどうかに関係なくエスケープしようとした結果、画面に「サシスセソ\」と出た。

この方法は変なことをしようとしなければ概ね上手く動くので大抵のケースでは問題にならないし、誤ってエスケープされたものも余分な \ を消せば復元できるので大きな問題にはならないはずだったが、PSDToolKit の特殊な事情により厄介な問題に発展した。

やりたかったことは、文字列をクリップボードにコピーしておいて、拡張編集のダイアログや *.lua ファイル内に貼り付けて使う、というだけの処理だった。

何が問題なのかというと、コピーした時点ではどちらに貼り付けようとしているのかがわからないので、貼り付けられた場所次第で得られる文字列が変わってしまう。
最初は「こっちからの場合は \ を消して……」みたいな場当たり的な措置でお茶を濁そうとしたのだが、置換処理が結構な回数必要になるし、気をつけて扱わないとすぐ事故る勢いだったのでこれはまずいと思ってアプローチを変えることにした。

対策は単純に「ダメ文字が出てこないようにする」というだけ。

処理の都合上、元々文字列では Unicode の範囲全てを扱える必要がありエスケープ処理を行うロジックを作っていたので、それにダメ文字用の対策も加えることによって事なきを得た。

上手く動くようになってよかったなあ。

「CeVIO Creative Studio」のフォント

2017-07-11T00:11:00.000+09:00

CeVIO Creative Studio のパッケージやサイトなど、様々な場所で使われている

こういう感じのロゴ

このロゴ、今までちゃんと見ずに漠然と「futura」辺りのフォントを使っていると勝手に思っていたんだけど、真面目に見てみると i の上の点が丸くないし、C の形すら違う。

何だろうと思って気になって調べてみたら、これは「URW Gothic」というフォントだった。
（※追記：系譜も含めて考えると実際に使われているのはもしかしたら ITC Avant Garde Gothic かもしれないけど、自分には全然区別がつかなかった）

このフォントは ghostscript の urw-core35-fonts.git という git リポジトリに登録されているのだが、ライセンスは特例付きの AGPLv3 となっており、ライセンスの範囲内で自由に使うことができる。
「URWGothic-Book.otf」や「URWGothic-Book.ttf」が目的のフォントなので、興味があればお試しください。

追記:
もう１つ、このページの左上にある Project CeVIO の部分は r とか c の形状から察するに Handel Gothic をベースに o や e を自作したり、j を J をベースに差し替えたり、CeVIO の部分は横長にした上で太さが極端にならないように修正したものじゃないだろうか、という感じで疑っているんだけど、もし仮にそうだとすると同じフォントを使ってもすぐに同じものを再現できなくて面白くない感じに。

追記 2018-01-11:
jamバンドについても調べた。

［絵を描く人向け］PSDTool の使い方

2016-08-29T07:21:00.001+09:00

先日投稿した動画は主に「公開されている PSD ファイルを使う人」にスポットを当てたものだったので、今回は「PSD ファイルを公開する人」に向けた PSDTool の使い方をブログで紹介しようと思います。

ターゲットは絵を公開するために PSD ファイルを扱ったことがあるが、動画制作には詳しくない人です。
動画制作においては使うツールや設定、内容などによって最適な画像の用意方法が変わってきますが、PSD ファイルの時点で無難な状態にしておくと色々なケースに対応しやすいので、この文書ではベストオブ無難を目指します。

この文書で PSDTool が単なる PSD ファイル表示ツールではないことを少しでもお伝えできれば幸いです。
ちなみに、全体的にはそんなに目新しい情報はありません。

なお、この文書では解説のため零度の青空 air さんの「立ち絵 2」をお借りしています。

[はじめに] なぜ PSDTool を使うと嬉しいのか

ざっくりと言えば、恐らくこの辺が PSDTool を使うべき大きな理由だと思います。

表情などのパーツの切り替えがしやすいから
PNG ファイルで保存しやすいから
ブラウザだけで PSD ファイルをいい感じに読み込めるから

この文書ではこれらのメリットを最大限に活用するためのテクニックみたいなものを紹介していきます。

表情などのパーツを切り替えしやすくするコツ
PSDTool で扱いやすい PSD ファイルを作る方法
PNG ファイルで保存するコツ
効率よく PNG ファイルをたくさん作る方法
ブラウザで PSD ファイルを読み込むコツ
ダウンロードせず PSD ファイルを開く方法

1. 表情などのパーツの切り替えをしやすくするコツ

立ち絵の場合、色々な表情が必要になることが多いと思います。
顔全体とか、眉毛、目、口などのパーツ毎とか、やり方は様々ですが、色々な表情パターンのレイヤーを PSD ファイルに入れることになると思います。

以下の画像は単純にレイヤーを並べた時の例と、これを PSDTool で開いた時のスクリーンショットです。

そのまま縦に並べているので、PSDTool でもレイヤーは縦に並ぶ

PSDTool にはレイヤー構造で厳守すべきルールは存在しないため、基本的にはこのままでも読み込めます。
しかし PSDTool で使いやすい形に整理することはできるので、その方法を紹介していきます。

1.1 ［準備編］PSDTool で読み込めるのはどんな PSD ファイル？

PSDTool は基本的な機能のみを使っている PSD ファイルと PSB ファイル全般が読み込めます。
Photoshop でしか使えないような機能の大半には対応していません。
カラーモードは RGB カラーのみ対応しているので、CMYK カラーのものなどは読み込めません。

機能としては基本的なレイヤー合成と、クリッピングマスクと、レイヤーマスクが使えます。
レイヤー合成とクリッピングマスクだけなら FireAlpaca で読めて、レイヤー合成とレイヤーマスクだけなら GIMP で読めるので、使う機能をこの辺だけにしておくとフリーウェアで扱う時も安心です。

ただし、次に紹介する内容でも触れますが、PSDTool はフォルダーレイヤーの使用を前提としています。
そのためフォルダーレイヤーを作れないソフトから PSD ファイルを書き出すことは非推奨です。
（書き出した PSD ファイルが使えないわけではなく、便利な機能が使えないからです）

オススメは Windows と Mac の両方に対応していて動作が軽快な FireAlpaca です。

1.2 レイヤーをフォルダーで分けよう

まずはお絵かきソフトでフォルダーレイヤーを使って、項目ごとに整理してみましょう。
整理して保存した PSD ファイルを PSDTool で読み込んだのが、以下のスクリーンショットです。

フォルダーに入れたレイヤーは、PSDTool 上でもフォルダーの中にある

このように PSD ファイル側でレイヤーをフォルダーに入れれば、PSDTool でもフォルダーに入ります。
これは見た目を整理するだけでなく、次に紹介する機能を使うための重要なステップです。

1.3 同時に表示しないレイヤーの切り替えをもっと使いやすくしよう

フォルダーに入れたレイヤーをよく見てみると、恐らく「くち_1」「くち_2」「くち_3」「くち_4」「くち_5」を同時に表示したい事はほとんどありません。

全部にチェックが入ると表示がぐちゃぐちゃになっちゃうよね

こういう「同時に表示したくない」または「切り替えるように表示したい」というレイヤーは、PSDTool の独自拡張機能を使う絶好の機会です。
使い方は、単にレイヤーの名前の先頭に半角の「*」を付けるだけです。

レイヤーの名前を変更して PSDTool で読み込んだのが、以下のスクリーンショットです。

チェックボックスじゃないから、１クリックで表示の切り替えができる

半角の「*」を付けるだけで、PSDTool ではチェックボックスがラジオボタンに変わります。
ラジオボタンにすると同時にレイヤーが表示されないだけではなく、今までは「くち_1を非表示に」→「くち_2を表示に」と2回クリックしないと切り替えられなかったのが、１回のクリックでできるようになりました。
しかもキーボードの上下キーで切り替えることもできます。

なお、レイヤーの名前を変えただけなので、これで他のソフトで読み込めなくなることはありません。

補足ですが、ラジオボタンはフォルダー単位でグループ化されているので、例えば右目と左目でそれぞれ１つずつ選択したい時は「右目」「左目」でそれぞれフォルダーを作って、パーツをその中に入れてください。

1.4 消す必要がないレイヤーやフォルダーはチェックボックスを隠そう

多くの場合、眉毛、目、口などは、パターンの中からどれか一つを必ず表示します。
（もちろんコミカルな表情など、消すことで味が出るパターンもあると思いますが）

現時点では PSDTool の画面でフォルダーレイヤーにはチェックボックスがあり、このチェックを外すと子階層のパーツを消せるため、目や口がない状態にもできます。
これを試しにチェックボックス自体を隠すことで消せなくしてみましょう。

レイヤーの名前の先頭に半角の「!」を付けるとPSDTool の独自拡張機能でチェックボックスがなくなります。
実際に「!」を付けた PSD ファイルを PSDTool で表示したのが、以下のスクリーンショットです。

フォルダーからチェックボックスが消えました

触る必要がないチェックボックスを隠せたので、変更できる項目が減り画面がシンプルになりました。
ちなみにこの機能はフォルダーだけではなく、レイヤーで使うこともできます。

これもレイヤーの名前を変えただけなので、PSD ファイルを他のソフトで開く時には影響はありません。

1.5 「表情などのパーツの切り替えをしやすくするコツ」のまとめ

これで読み込んだ PSD ファイルの表情を変えるのが簡単になりました。
しかもこれをやっておけば、「シンプルビュー」を作るのもとても簡単になります。

この他にも、例えば左右反転などをした時だけレイヤーを自動で切り替える機能もあります。
普通、画像を左右反転するとテキストやアクセサリー、髪型なども逆向きになってしまいますが、予め逆向きの時に表示するためのレイヤーを準備しておけば、左右反転時に自動的に逆向き用レイヤーになります。

PSDTool のトップページにあるサンプルは、左右反転すると髪の結び目が自動で切り替わります。
トップページから PSD ファイルもダウンロードできるので、使い方の参考にして下さい。
その他、ニコニコ静画にも左右反転に対応した立ち絵が投稿されています。すごい。

結月ゆかり立ち絵素材弦巻マキ立ち絵素材東北ずん子立ち絵素材さとうささら立ち絵素材【立ち絵】CeVIOのささらさん

なお左右反転以外ならニコニコ静画には PSDTool の「*」「!」を使用していただいているイラストがたくさんありますので、実際に作る上でレイヤー構造の参考になると思います。

1.番外編依存関係があるレイヤー切り替えはどうする？

例えばポーズと服がそれぞれ2種類ずつある場合、上で紹介した手順に従うと多分こうなります。

ポーズのパターン数だけ服装にもパターンが必要になるから……

これでもそこそこ使いやすいとは思いますが、「体が『ポーズ1』で、服装が『制服(ポーズ2)』」みたいに、体と服で別のポーズを選ぶこともできてしまいます。
こういう時は、ポーズ毎でまとめると変な組み合わせになるのを避けることもできます。

ポーズが異なる組み合わせが避けられるようになった

パズルみたいな感じですが、工夫によって変な組み合わせを避けられました。
変な組み合わせが作れないようにすると「一瞬合ってるように見えるけど、よく見るとキャミソールの肩紐が浮いてる」みたいな見落としがちなミスを回避することができます。

ちなみに、もしここから更に服を脱がせられるようにしたい場合、「*制服」「*私服」を「服」フォルダーを作って入れるか、「*服なし」という空白レイヤーを服装の選択肢として追加するといいと思います。

もうひとつ複雑なパターンも考えてみます。

ブログに載せるには縦長過ぎる…

右腕と左腕がそれぞれ「上げ」と「下げ」で選べるパターンです。
これは例えば腕ごとにまとめようとすると重ね合わせ順が変わってしまったりするので、現状の PSDTool でこれ以上エレガントに表現するのは結構難しいと思います。

（一応この辺を補助するための機能もアイディアとしては考えているものの、機能が必要になる状況の複雑さ、扱いの難しさ、機能を使うユーザーの少なさなどを鑑みて今のところ実装を保留中……）

とはいえ、これは「!」を活用しているので PSDTool で見ると案外そんなに複雑ではありません。

クリックできる場所は少なめ

その他ゴリ押しに近いアプローチとしては、この場合それぞれの服装の「両腕下げ」「左腕上げ」「右腕上げ」「両腕上げ」が上手く用意できればいいだけなので、それぞれのパターンに合わせたお気に入りを作って、エクスポートしたお気に入りデータを PSD ファイルと一緒に配布するという手段もあります。
つまりお気に入りを読み込んでもらうことで、破綻した組み合わせを避けようというアイディアです。

全パターンのお気に入りを作って、フィルターで服装と腕関係にチェックをつけておく

このようにフィルター機能を使って影響範囲を絞っておけば、表情を変えずに服装とポーズだけをまとめて一発切り替えという使い方ができます。
フィルターの使い方については下の方でも少し紹介しています。

2. PNG ファイルで保存するコツ

「PNG ファイルで保存しやすくするツールなのに保存にコツがあるのか？」と思うかもしれません。
意外とあります、より効率的になるヤツが。

2.1 画像を１枚１枚手動で保存しない

PSDTool では画面上部にある「.png」というボタンを押すと画像を保存できますが、基本的には動画で紹介しているように、１枚１枚ボタンを押して保存するより、お気に入りに登録してエクスポートする方が効率的です。

これなら左右反転バージョンを改めて保存しなおしたり、縮小率を変えたバージョンも一斉に保存できるし、ファイル名はブックマークにつけた名前で保存されるので、いちいちリネームする必要もありません。

特に左右反転で専用のレイヤーに切り替わる場合、外部ツールの左右反転では正しい結果が得られません。

2.2 フィルターを活用する

フィルターは動画ではシンプルビュー用の機能みたいな扱いでしたが、実際には単独でも使える機能です。
以下は PSDTool のマニュアルで使われているフィルター機能の紹介動画です。

このように、お気に入りを読み込んだ時の適用範囲を、フィルターで絞ることができます。

この動画のように口の様々なパターンのお気に入りをフィルター越しに用意しておくと、例えば「レイヤータブで目を変更」→「お気に入りをエクスポート」という手順を繰り返すことで色々な目のパターンで口の様々なパターンを書き出すことができます。
（しかし、もっと大量に書き出したい場合は後述する方法でもっと適したものがあります）

2.3 シンプルビューを活用する

シンプルビューを使うと表情の切り替えなどが便利になりますが、たくさんの PNG ファイルを作る時にも使える便利な機能でもあります。

「表情などのパーツの切り替えをしやすくするコツ」の内容に従ってレイヤーの名前に「*」とか「!」をつけておけば、この動画のようにシンプルビューは1分未満で準備できます。

シンプルビューには動画で紹介したように「パーツ毎に PNG ファイルを書き出す」といった使い方の他に、シンプルビューで表現可能な全てのパターンを PNG で書き出すという過激な使い方があります（2016-05-01 実装）。

使うにはシンプルビューが使える状態でこれを選ぶだけ

これを使うと存在し得る全てのパターンを書き出します。

こんな感じで、合成済みパターンが大量に書き出されます（今回は250パターン）

しかし、パーツ数が多いと総容量が数GBレベル、書き出し所要時間も1時間を超えるスケールに割と簡単に発展します。5GB 程度までは動作確認しましたが、そんなに凄いパターン数を書き出しても使う側も大変です。
そういう時は必要に応じてシンプルビューで選べる数を減らして、現実的な数に調整しましょう。
例えば20分程度で終わるセットを数回に分けて書き出すとか、中断しやすい感じでやると安全です。

2.4 「PNG ファイルで保存するコツ」のまとめ

PNG ファイルを作る色々なアプローチを紹介しましたが、全パターン網羅した PNG ファイルは大抵容量が膨らみすぎるので程々にしておくのが良さそうです。

ちなみに PSDTool は

絵を描かない人でも PSD ファイルが扱いやすくなるように
絵を描く人が頑張って PNG ファイル化しなくて済むように

という両側面から労力を削減するために作っています。
PNG ファイルを作る作業は絵を描かない人でもできますが、あなたの絵はあなたにしか描くことができないので、絵を描くことに時間を割いたほうが建設的だろうというコンセプトに基いて制作されています。

3.ブラウザで PSD ファイルを読み込むコツ

3.1 ダイレクト読み込み機能を試そう

自身のサイトで PSD ファイルを配布しているなら、ダイレクト読み込み機能も使えるかもしれません。
ダイレクト読み込み機能とは、要するにこういうのです。

http://goo.gl/1RxjAz

リンクをクリックすると、特にダウンロードなどしたことがないファイルを開いた状態になります。

ダイレクト読み込み機能の準備方法はマニュアルや動画でも紹介していますが、

http://s.oov.ch/blog/20160825_test.zip

例えばこういう URL で zip ファイルを配布するなら

http://s.oov.ch/blog/20160825_test.html
（HTML ファイルをダウンロードする場合は右クリックメニューからどうぞ）

同じ場所にこんな感じの HTML ファイルも設置します（ファイル名は任意）。すると、

http://oov.github.io/psdtool/#load:xd:http%3A%2F%2Fs.oov.ch%2Fblog%2F20160825_test.html

この長い URL で直接 zip ファイルに入った PSD ファイルを開くことができます。
ちょっと URL が長くて扱いにくい場合は https://goo.gl/ で短縮しても使えます。

http://goo.gl/1RxjAz

この URL の後ろに + を付ければアクセス解析もできます。
PSD ファイルは配布用に用意したものをそのまま流用できるし、実質的に必要になる追加作業は HTML ファイルを編集して上げるだけです。
ただ zip ファイルのサイズを小さくしないと待ち時間が長くなるので、大きなファイルはオススメしません。

というわけで、ダイレクト読み込み機能を使えばダウンロード用のリンクとファイルを開くためのリンクを並べて設置したりできるので、「とりあえず」のクリックで開いてもらうこともできます。

なお、設置された HTML ファイルは

HTML ファイルをブラウザで開いた時にダイレクト読み込み用の URL を伝えるため
PSDTool に PSD ファイルの内容を転送するため

この2つの目的で使用されます。
そのため、URL が正しくても HTML ファイルが削除されていると開けなくなります。

全体のまとめ

PSD ファイルでできる工夫は「*」と「!」、PSDTool でできる工夫はシンプルビューを使うことです。
細かい話は色々あるけどざっくり言うとそういうことです。

もしお気に入りが消えてしまったら

PSDTool のお気に入りは、PSD ファイルの内容が少しでも変わると別のファイルとして認識されてお気に入りが真っ白になりますが、慌てずに「お気に入りのインポート」機能を使うと、最近使ったお気に入りなら別のファイル用のものでも手動で読み込むことができます。

ただしお気に入りはレイヤーの名前を基準に判定しているので、以前とレイヤーの名前が変わっていると、その周辺部分は上手く読み込まれなくなるでしょう。

もし構造自体は同じで単純にレイヤーの名前が変わっただけなら、お気に入りをエクスポートしてテキストエディタで開いて、名前を置換して、お気に入りをインポートし直すことで対応することも一応できます。

このように PSDTool は「完成した PSD ファイルを触るためのツール」という側面があるので、お絵かきソフトと PSDTool の両方で並行して同じ PSD ファイルを使う時は、お気に入り機能はあまり触らないのがオススメです。

ZIP ファイルに内容の似た PNG ファイルを大量に突っ込む話

2016-08-19T07:18:00.002+09:00

2016年から PSDTool というツールを作っている。

これは端的に説明すると PSD ファイルをブラウザで読み込んで、レイヤーごとにバラして保存したり、レイヤーの表示状態を切り替えた画像をたくさん保存したりするためのツール。

PSDTool にはブラウザのブックマークに似た機能があり、レイヤーの表示／非表示の切り替えを行った状態を保存しておくことができる。
更にエクスポート機能を使うことで登録した項目を PNG ファイルで ZIP ファイルに詰め込むことができる。

メインの用途は古典的な立ち絵イラストを、各種ツールで扱いやすい形式、構造に変換すること。
（ここでいう古典的とは、モーフィングのような機能を含まないという意味）
立ち絵を使うツール側で高度な画像合成ができるなら PSD のレイヤーごとに書き出すのもいいが、合成済みの画像を得られた方が便利なケースも当然多い。

合成済みの画像をたくさん ZIP ファイルに保存する場合、表情だけがちょっと違うような、似た内容の画像をたくさん保存することになる。これを ZIP にそのまま突っ込むのは扱いやすい反面ファイルサイズが全然縮まないので、色々考えてみた話。

要するに、こういう感じのファイルセットを効率よく圧縮したい。

ちなみに PSDTool 上で「シンプルビュー」を使えるようにして、エクスポートで「シンプルビューの全パターンをエクスポート」を選ぶと、このようにたくさんのパターンの PNG ファイルを簡単に得ることができる。

ZIP ファイルに内容が似た PNG ファイルをたくさん入れた時の圧縮効率の悪さ

まず、ZIP ファイルにちょっとだけ内容が違う PNG ファイルをたくさん入れた時の問題点を整理する。

ZIP ファイルではファイル毎に圧縮するので、2つのファイルが似ているかは考慮されない。
例えば圧縮後に 2KiB になるファイルを2つ ZIP に入れれば 4KiB ぐらいになるし、10個入れれば全部同じ内容のファイルでも 20KiB ぐらいになる。
ZIP ファイルで最も一般的な圧縮メソッドである Deflate は LZ77 のウィンドウサイズが最大でも 32KiB と小さい。
だからもし ZIP ファイルで PNG ファイル同士が似ていることが考慮できたとしても、ファイルが 32KiB を超えると似た場所を上手く見つけられなくなる。
画像が既に PNG ファイルとして圧縮されているので、表示した時に見た目がほぼ一緒でもファイルのデータ自体には結構差があって、似ているかどうかの判断が難しい。

ZIP ファイルが縮まない原因として大きいのはこの辺だと思う。

どのような対処方法が考えられるか

1 や 2 の問題は 7z ファイルなどのような新しいファイル形式や、TAR 形式のように複数のファイルを1つのファイルにまとめてから圧縮するような形式である程度解決する。

しかし汎用的なコンテナフォーマットとしては ZIP ほど普及していないので、OS を問わずツールを準備せず簡単に展開できるというレベルではなく、ZIP に比べて取っ付きにくい。

自作プログラムで展開するケースを考えても、色々な言語で扱いやすい実装があることが多い ZIP に比べ普及率や速度の面で扱いづらいし、TAR だと上から圧縮すると任意のファイルへランダムアクセスもしづらい。

3 の問題は無圧縮の画像データにすればデータ的に似ている場所の検出は簡単になるけど、例えばほとんど内容が同じ BMP ファイルを 7z ファイルに大量に入れてあるとしたら、一度に全てを展開したりするとちょっとした高圧縮ファイル爆弾になりうるので危険が危ない。

自分でアーカイブフォーマットなどを自作するのももちろん考えたが、世の中にあるツールが全て使えないことになるのでこれもまたつらい。

そんなこんなで ZIP や PNG でもっと縮める方法を考えた末、ちょっとしたアイディアが浮かぶ。

Tiled 用の形式で書き出す

Tiled はマップエディタで、ドラクエみたいなマップとか、マリオのステージ構成とか、ああいうタイル状に並べたデータを作るためのツール。これ用のデータとして立ち絵を書き出す試み。

例えば立ち絵画像2枚をそれぞれ 16x16 のマスで切り分けていくと、表情とか変化があった部分はマスの内容が異なるけど、ほとんどのマスは同じ内容になるのが容易に想像できる。

ほとんどのマスが同じということは、多くの場所でタイルチップの使い回しができる。

立ち絵画像1枚だけで考えても、余白の透明部分などはかなりの場所で使い回しができる。

こうして PNG や ZIP のまま Tiled 形式を上手く使って、似た部分を効率よく格納できるようになった。

画像を元の形に復元するためには当然タイルを並べないといけないが、レイヤー合成ほど複雑で多彩な処理は必要としないし、レンダリング済み画像だから元画像のレイヤー数が多くても表示の際にメモリ消費や描画負荷が増えることはない。
タイルチップを並べた画像1枚に相当なバリエーションのデータが詰まっているため消費メモリ面で見ても結構アドバンテージがあるように思う。

PNG ファイルを ZIP ファイルに詰めた場合大体 82MB ぐらいになるデータが PNG + TSX + TMX で 1.24MB まで縮み、今回は 512x512 のテクスチャに全てのタイルが収まった。
TMX の書き出し方などはテスト段階なので最終的にはサイズが変わるかもしれないが、なかなかの結果だ。

まあこの方法で書き出せるようになっても需要はほとんどなさそうだけど。
この機能は準備ができたらそのうち公開する予定。

---- 2016-08-21 追記

処理を整理し別の PSD ファイルでも試してみたところ、PNG ファイルを ZIP ファイルに詰めた場合 1.22GB になるデータが PNG + TMX の ZIP で 18MB、ZIP ではなく 7z に入れると 534KB まで縮んだ。
テストに使った PSD ファイルが 826KB で ZIP に入れると 539KB、7z に入れると 291KB なのでなかなかの健闘ぷり。

---- 2016-10-28 追記

ここで得られた知見を元に改めて独自のアーカイブフォーマットを試作してみたところ、上記のテストで 1.24MB だったものは 234KB、追記で書いた 18MB のものは 733KB に縮めることができた。
自分が作った専用ビューワ以外で開けないので今のところ実用性はアレではある。

Go言語の -buildmode=c-archive と Lazarus でのスタティックリンク（Windows/Linux）

2016-04-27T06:05:00.001+09:00

前回の記事では Windows で -buildmode=c-archive を試した。今回はそれと同じことを Ubuntu 上でも行ってみて、最終的に同じソースコードで両方の環境でコンパイルできるところまで持ち込む。

最初の一歩

前回の話を踏まえると、Lazarus(Free Pascal Compiler) で go build -buildmode=c-archive でコンパイルしたバイナリをリンクしようとする時は、概ね以下のようにすると最低限処理が動くようになるはずだった。

FPC のリンカだと上手く動かないので Use external linker オプションを付ける必要がある
→ プロジェクトオプションのコンパイラオプション → Custom Options から -Xe を追加
ライブラリのファイル名が lib*.a でなければ上手く認識させられない
→ Go言語側で main パッケージのディレクトリ名を libhoge という感じにしておく
初期化処理が呼ばれないので自分で呼ぶ必要がある
→ _rt0_amd64_linux_lib を呼びたい（呼べなかった）

というわけで、_rt0_amd64_linux_lib が呼べなくて最初に躓いた。

もう少し詳しく見てみると、Windows では

nm libhoge.a | grep _lib

などとすると _rt0_amd64_windows_lib は外部シンボルとして定義されているのだが、Ubuntu で同じことをすると _rt0_amd64_linux_lib は内部シンボルとして定義されていた。そして、FPC で

procedure _rt0_amd64_windows_lib(); cdecl; external;

みたいな形で定義したものは外部シンボルでなければ参照できず、このままでは無理、という状況。

「この問題を解決するためにどうするのがいいか」という以前にそもそもこの辺あまり詳しくないので、わかる範囲で少し調べながら対応方法を検討した。

その上で一番正しいっぽい道のりは多分「FPC 側でオブジェクトファイルの .init_array / .ctor セクションを参照して初期化処理を実行する」みたいな感じだと思うのだが、ちょっと話のスケールが大きい上に既存の振る舞いとの互換性の問題もありそうで手を出しにくいので、この方向は諦めた。
もし実現させるならプログラム固有のコードじゃなくてランタイム側のコードを変える話になりそう。

次に考えたのは「Go言語側でのビルド時に Windows では外部シンボルになっているんだから、挙動が違う原因を突き止めて両方外部シンボルにできれば解決するのでは？」という方向性。
しかし、そもそも外部シンボルになっているものを nm -g libhoge.a で列挙してみると、むしろ Windows 側が不必要な部分まで外部シンボルになってしまっているのではないか、と思えるぐらいに差があったので、将来的には逆に Windows 側で多くが内部シンボルになる方が正しそうな予感がして、このアプローチもやめた（だから挙動が違う原因もわからないまま）。

最終的に選んだアプローチは「_rt0_amd64_linux_lib を外部シンボル化する方法を探る」という感じ。
Linux 側で nm -g libhoge.a した時に出てくる cgo 関係の外部シンボルを見る限り、この辺りで使われている機能を上手く利用すれば外部シンボルにできそうだった。
最初はGo言語のソースコードの src/runtime 辺りにファイルを追加して、全体を make し直して使えるようになることを確認していたのだが、もう少し調べてみると別に src/runtime に置く必要は全然なかったようなので、github.com/oov/rt0 という、コードが全然ないパッケージを作った。
darwin とか試してないものもあるが、取りあえず _rt0_GOARCH_GOOS_lib が現状定義されているものに関しては全部揃えておいた。

これで、-buildmode=c-archive を使う main パッケージ辺りで

import _ "github.com/oov/rt0"

だけで外部シンボルになるようになった。

初期化処理を正しく呼ぶ

Windows の時はパラメータを特に定義せずに呼んでいたのだが、同じように Linux で _rt0_amd64_linux_lib を呼んでみると、プログラムの起動時に

runtime: kernel page size (134593276374883) is larger than runtime page size (4096)

という、なんか値の差が大きすぎて何かが根本的に噛み合ってなさそうな気配のするエラーメッセージが出て上手く動かなかった。
Go 1.6.2 で同じことをしてもエラーメッセージが出ずに実行されたのだが、つい最近追加された部分だったらしい。

そこで rt0_linux_amd64.s のコードを読んでみると、tip の rt0_windows_amd64.s とは違い DI と SI には本来 argc と argv が入っているらしいことがわかった。呼び出し規約を確認してみると2つの引数が渡されてきた時の形なので「あ、これ要するに main 関数じゃん！」などとやっと気付いた勘の悪い自分であったが、結果的に

procedure _rt0_amd64_linux_lib(argc: Longint; argv: PPChar); cdecl; external;

initialization
  _rt0_amd64_linux_lib(argc, argv);

という形に辿り着くことができたので良しとしよう。

動いたー　やったー

前回の記事で SIGFPE で止まっていた問題は Windows でもいつからか再現しなくなってしまったので、Linux 上でも起こるかどうかなどは謎。

処理をまとめる

これで Windows と Linux で同じ地点まで辿り着いたので、あとは同じソースコードで動くようにしたい。

まずはGo言語側。前回より少しメモリコピー回数がマシになっている。
OS によって処理が分かれている部分も特にないのであまり見どころはない。

package main

// #include <string.h>
import "C"

import (
 "bytes"
 "image/png"
 "os"
 "unsafe"

 "github.com/oov/psd"
 _ "github.com/oov/rt0"
)

//export PSD2PNG
func PSD2PNG(filename *C.char, buf *unsafe.Pointer, ln *C.int) C.int {
 file, err := os.Open(C.GoString(filename))
 if err != nil {
  return 1
 }
 defer file.Close()

 img, _, err := psd.Decode(file, &psd.DecodeOptions{SkipLayerImage: true})
 if err != nil {
  return 2
 }

 var b bytes.Buffer
 pe := png.Encoder{CompressionLevel: png.BestSpeed}
 err = pe.Encode(&b, img)
 if err != nil {
  return 3
 }

 *buf = C.malloc(C.size_t(b.Len()))
 C.memcpy(*buf, unsafe.Pointer(&b.Bytes()[0]), C.size_t(b.Len()))
 *ln = C.int(b.Len())
 return 0
}

func main() {}

そして Lazarus 側。初期化処理用のシンボル名は環境毎に変わるので、まずそれに対応する処理が必要。
あとは Windows の時はリンクするファイルが増えるのでそれも ifdef で囲っておく。
Windows では argc / argv を参照していないが、呼び出し規約的に動作に影響はないはずなので処理は分けてない。

unit psdtest;

{$mode objfpc}{$H+}

interface

function PSD2PNG(Filename: PChar; Buf: PPointer; Len: PInteger): Integer;
  cdecl; external Name 'PSD2PNG';
procedure Cfree(P: Pointer); cdecl; external Name 'free';

implementation

{$linklib libpsdtest.a}

{$ifdef WINDOWS}
  {$linklib libntdll.a}
  {$linklib libws2_32.a}
  {$linklib libadvapi32.a}
  {$linklib libwinmm.a}
  {$linklib libkernel32.a}
  {$linklib libmsvcrt.a}
{$endif}

const
  ARCH = {$ifdef CPU386}'386'{$endif}{$ifdef CPUAMD64}'amd64'{$endif}{$ifdef CPUARM}'arm'{$endif}{$ifdef CPUAARCH64}'arm64'{$endif};
  OS = {$ifdef WINDOWS}'windows'{$endif}{$ifdef LINUX}'linux'{$endif}{$ifdef DARWIN}'darwin'{$endif};

procedure GoInit(argc: longint; argv: PPChar); cdecl;
  external Name '_rt0_' + ARCH + '_' + OS + '_lib';

initialization
  GoInit(argc, argv);

end.

まあ Lazarus 側はこのままだと扱いにくいので、もうちょっと使いやすくしたのがこちら。

unit psdtest;

{$mode objfpc}{$H+}

interface

uses
  Classes;

function PSD2PNG(FileName: string): TStream;

implementation

uses
  SysUtils;

function PSD2PNG(Filename: PChar; Buf: PPointer; Len: PInteger): integer;
  cdecl; external Name 'PSD2PNG';
procedure Cfree(P: Pointer); cdecl; external Name 'free';

{$linklib libpsdtest.a}

{$ifdef WINDOWS}
  {$linklib libntdll.a}
  {$linklib libws2_32.a}
  {$linklib libadvapi32.a}
  {$linklib libwinmm.a}
  {$linklib libkernel32.a}
  {$linklib libmsvcrt.a}
{$endif}

const
  ARCH = {$ifdef CPU386}'386'{$endif}{$ifdef CPUAMD64}'amd64'{$endif}{$ifdef CPUARM}'arm'{$endif}{$ifdef CPUAARCH64}'arm64'{$endif};
  OS = {$ifdef WINDOWS}'windows'{$endif}{$ifdef LINUX}'linux'{$endif}{$ifdef DARWIN}'darwin'{$endif};

procedure GoInit(argc: longint; argv: PPChar); cdecl;
  external Name '_rt0_' + ARCH + '_' + OS + '_lib';

// --------------------------------

type
  TCMemoryStream = class(TCustomMemoryStream)
  public
    constructor Create(const P: Pointer; Sz: PtrInt);
    destructor Destroy; override;
  end;

constructor TCMemoryStream.Create(const P: Pointer; Sz: PtrInt);
begin
  inherited Create;
  SetPointer(P, Sz);
end;

destructor TCMemoryStream.Destroy;
begin
  Cfree(Memory);
  inherited Destroy;
end;

function PSD2PNG(FileName: string): TStream;
var
  Errno, Size: Integer;
  Buf: Pointer;
begin
  Errno := PSD2PNG(PChar(FileName), @Buf, @Size);
  if Errno <> 0 then
     raise Exception.Create('cannot convert psd to png: '+FileName);
  try
    Result := TCMemoryStream.Create(Buf,Size);
  except
    Cfree(Buf);
  end;
end;

initialization
  GoInit(argc, argv);

end.

ファイル名を string、戻り値を TStream にすることでフレンドリーに使える形になった。 TCustomMemoryStream を継承したストリームを作る事で無駄なメモリコピーも抑制できて一石二鳥。
入力もファイル名の代わりに TStream にできると思うけど、巨大なファイルをメモリの固まりじゃなくてストリームとして綺麗に渡すのは結構面倒な話になりそうなのでここでは触れないでおく。

使う側は

procedure TForm1.Button1Click(Sender: TObject);
var
  S: TStream;
begin
  if not OpenDialog1.Execute then
    Exit;
  S := PSD2PNG(OpenDialog1.FileName);
  try
    Image1.Picture.LoadFromStream(S);
  finally
    S.Free;
  end;
end;

みたいな普通な感じで使えて、これで両方の環境でコンパイルできるソースコードになった。

Go言語の Windows 版で -buildmode=c-archive を使う

2016-04-05T08:18:00.000+09:00

安定版のリリースはまだ先だけど、tip で Windows 上での -buildmode=c-archive が動くようになったらしい。早速試してみることにする。

1. 安定版のGo言語をインストール

tip のGo言語をビルドするために、まず安定版をインストールする。
これは普通にインストーラー版を使ってインストールするだけでいい。

2. GCC をインストール

後々のために入れる。
build.golang.org で動いている Windows のビルダーは winstrap で環境を構築しているようなのだが、ここを見る限りでは TDM-GCC を使っているようなので、これを入れることにする。

3. Git をインストール

このご時世インストールしてない人はいないと思うけども。
これもインストーラから。

4. tip 版のGo言語をビルド

ここまでの段階でインストーラによって環境変数 GOROOT が設定されていると思うので、コマンドプロンプトを開いて go version を打てば安定版のGo言語のバージョンが表示されるはず。
この安定版を最新版のビルドに使うことを示すために、set GOROOT_BOOTSTRAP=%GOROOT% などとして環境変数に入れておく。
そして適当な深すぎないディレクトリで git clone https://github.com/golang/go/ でGo言語をクローンして、go\src\all.bat を実行すればビルドは始まる。

ビルドが完了したら、今度は最新版をGo言語を使うために set GOROOT=clone先 として GOROOT を書き換えて、更に set PATH=%GOROOT%\bin;%PATH% として PATH も再優先で通しておく。

改めて go version して go version devel という感じでバージョン情報が変わっていたら準備完了。

5. テストプログラムを作る

c-archive モードを使うためのテストプログラムを作ってみる。
適当なディレクトリを作って、その中にこんな感じのファイルを作成する。
今回は carchivetest というディレクトリの中に main.go というファイル名で作成した。

package main

import (
 "C"
 "log"
)

//export testInt
func testInt() int {
 log.Println("testInt")
 return 42
}

//export testStr
func testStr() *C.char {
 log.Println("testStr")
 return C.CString("OK")
}

func main() {
 log.Println("Hello world")
}

//export から始まるコメント行はエクスポートすることを明示するアノテーションなので必ず必要。
文字列を返したい場合、そのまま string を渡すと GoString 型になるけど、C.CString で変換すると char ポインタで渡すこともできる。この場合受け取った側で free する必要がある。
ちなみに文字列を返さない場合など、この例では import "C" がなくてもコンパイルはできるものの、その場合C言語側から呼ぶ時に必要になるヘッダーファイルが生成されないし多分エクスポートも動かない気がするので import "C" は必須だと思う。
なお、ここでは main で Hello world を出力するようなコードを書いているが、main は無視されるはずなので実際には出力されない。

main.go があるディレクトリで go build -buildmode=c-archive とすると、carchivetest.h carchivetest.a というファイルが出力される。

次にC言語側のプログラムを作る。
生成されたヘッダーファイルを使って、エクスポートされた関数を呼び出す。

#include <stdio.h>
#include <stdlib.h>
#include "carchivetest.h"

int main(int argc, char *argv[]) {
 printf("main\n");
 printf("testInt -> %lld\n", testInt());
 char *r = testStr();
 printf("testStr -> %s\n", r);
 free(r);
}

特に意外性のない普通のプログラム。
これをコンパイルするには gcc main.c carchivetest.a -lntdll -lws2_32 という感じにする。

これで a.exe が生成されているので、実行すると以下のような出力が得られる。

main
2016/04/04 18:30:16 testInt
testInt -> 42
2016/04/04 18:30:16 testStr
testStr -> OK

予定通り "Hello world" は出力されず、それぞれに書いた出力は正しく出力されている。

6. テストプログラムをもっと作る

せっかく Windows 上で使えるようになったんだし、GUI プログラムでも試してみようと思う。
今度は GCC じゃなくて Lazarus を使ってプログラムを作ってみる。
Lazarus は 1.6 の 64bit 版をインストール（Go言語も 64bit 版を使っていたから）。

ある程度試してみたところ、以下のような感じにすると動いた。

FPC のリンカだと上手く動かないので Use external linker オプションを付ける必要がある
→ プロジェクトオプションのコンパイラオプション → Custom Options から -Xe を追加した
ライブラリのファイル名が lib*.a でなければ上手く認識させられなかった
→ 単純に carchivetest.a を libcarchivetest.a をリネームした
TDM-GCC に付属している libntdll.a libws2_32.a libadvapi32.a libkernel32.a libmsvcrt.a にリンクする必要があるようなので、ライブラリパスを追加する
→ プロジェクトオプションのコンパイラオプション → パスのライブラリにパスを追加
Go言語側の初期化処理のために initialization 句辺りで _rt0_amd64_windows_lib を呼ばなければいけない
→ 呼ばない場合エクスポートされた関数を呼び出しても処理が返ってこなくなる
文字列をC言語のサンプルプログラムのように受け取る場合、free もC言語のランタイム側で定義されているのを呼ばないと多分駄目
→ 定義して呼べるようにしておく

以上の点を踏まえた上で、carchivetest を呼ぶためのユニットファイルは概ね以下の様な形になった。

unit carchivetest;

{$mode objfpc}{$H+}

interface

function testInt(): Int64; cdecl; external name 'testInt';
function testStr(): PChar; cdecl; external name 'testStr';
procedure Cfree(P: Pointer); cdecl; external name 'free';

implementation

{$linklib libcarchivetest.a}
{$linklib libntdll.a}
{$linklib libws2_32.a}
{$linklib libadvapi32.a}
{$linklib libkernel32.a}
{$linklib libmsvcrt.a}

procedure _rt0_amd64_windows_lib(); cdecl; external;

initialization
  _rt0_amd64_windows_lib();

end.

新規プロジェクトからアプリケーションを選び新規プロジェクトを作成し、更にファイルメニューから新規ユニットを加えて上記のユニットファイルを作成。
このユニットファイルを Unit1 の uses 句に加え、ボタンを一個配置し、そのボタンをダブルクリックし、追加されたコードを以下の様に書き加える。

procedure TForm1.Button1Click(Sender: TObject);
var
  P: PChar;
begin
  P := testStr();
  Caption := IntToStr(testInt()) + ' / ' + P;
  Cfree(P);
end;

これでコンパイル・実行して、ボタンを押した時のスクリーンショットが以下のもの。

Caption にGo言語側から渡した値が正しく表示されている

7. テストプログラムをもっともっと作る

ここまで動くようになったら、もう少し発展的な実験もしてみたい。
最近Go言語用の Photoshop 形式の画像読み込みライブラリを作ったので、これを使って画像データを読み込んでみる。

改めて libpsdtest というディレクトリを作成し、その中に以下のファイルを main.go として作成。

package main

import (
 "C"

 "bytes"
 "image"
 "image/png"
 "os"

 _ "github.com/oov/psd"
)

//export PSD2PNG
func PSD2PNG(filename *C.char, buf **C.char, ln *int, errno *int) {
 file, err := os.Open(C.GoString(filename))
 if err != nil {
  *errno = 1
  return
 }
 defer file.Close()

 img, _, err := image.Decode(file)
 if err != nil {
  *errno = 2
  return
 }

 var b bytes.Buffer
 err = png.Encode(&b, img)
 if err != nil {
  *errno = 3
  return
 }

 *buf = C.CString(b.String())
 *ln = b.Len()
 *errno = 0
}

func main() {}

プログラムとしてはやはり単純。
Go言語側で戻り値を複数返した場合、Cのヘッダーファイル上で構造体が定義され、それが返されるような形になる。しかし FPC 側でそれを正しく受け取る方法がよくわからないので、今回は素直にポインタを複数渡すことにした。

これを呼ぶためのユニットファイルは以下の様な形。

unit psdtest;

{$mode objfpc}{$H+}

interface

procedure PSD2PNG(Filename: PChar; Buf: PPointer; Len: PInteger; Errno: PInteger);
  cdecl; external Name 'PSD2PNG';
procedure Cfree(P: Pointer); cdecl; external Name 'free';

implementation

uses
  Math;

{$linklib libpsdtest.a}
{$linklib libntdll.a}
{$linklib libws2_32.a}
{$linklib libadvapi32.a}
{$linklib libkernel32.a}
{$linklib libmsvcrt.a}

procedure _rt0_amd64_windows_lib(); cdecl; external;

initialization
  SetExceptionMask([exInvalidOp, exPrecision]);
  _rt0_amd64_windows_lib();

end.

目新しい点は SetExceptionMask なのだが、これは後述する。

そしてまた新規プロジェクトに今度は TOpenDialog と TImage と TButton をフォーム上に配置して、ボタンのクリックハンドラを以下のように実装。

procedure TForm1.Button1Click(Sender: TObject);
var
  Buf: Pointer;
  Len, Errno: integer;
  MS: TMemoryStream;
begin
  if not OpenDialog1.Execute then
    Exit;

  PSD2PNG(PChar(OpenDialog1.FileName), @Buf, @Len, @Errno);
  if Errno <> 0 then
    Exit;
  try
    MS := TMemoryStream.Create;
    try
      MS.WriteBuffer(Buf^, Len);
      MS.Position := 0;
      Image1.Picture.LoadFromStream(MS);
    finally
      MS.Free;
    end;
  finally
    Cfree(Buf);
  end;
end;

実行させた結果がこちら。

後ろの FireAlpaca で読み込んでいるのと同じ PSD ファイルを読み込んで表示している

しかしプログラムを走らせて色々な PSD ファイルを読み込ませていたところ、どうも runtime.deductSweepCredit の中で SIGFPE で動作が停止してしまうことがたまにあった。

止まるときは毎回ここらしい

ここだとすると383行目で int64 に変換している辺りの部分でコケているっぽいことになりそうだけど、ちょっと状況がよくわからない。exInvalidOp をマスクすれば止まらなくなるものの、そもそもなんで止まるのか、普通にGo言語で実行している時は起きているのか、そのへんがよくわからない。
そういう状態で自分の手には余る感じなので問題は解決できておらず、ひとまずマスクして回避するために SetExceptionMask([exInvalidOp, exPrecision]) を入れている、というわけ。

この PSD2PNG プログラムのソースコードとコンパイル済みバイナリはこちら。

ブラウザから別のソフトに画像をドラッグ＆ドロップ

2016-02-17T11:26:00.001+09:00

Windows におけるブラウザでの OLE Drag & Drop に関するメモ書き。

ブラウザで表示している img タグをドラッグアンドドロップで他のソフトに持ち込むことが出来たりすることがある。この仕組みでブラウザからファイルを受け付けたい場合、受け取り側では主に RegisterDragDrop で IDropTarget インターフェイスを登録しておき、呼ばれたら適宜必要な形式で抽出したりすることになる。

ただし、この周辺の挙動はブラウザごとにまちまちであるため、それぞれに対応が必要になる。
ここではケースごとに各ブラウザでどのように振る舞われているのかを簡単にまとめておく。

src に URL を指定した img タグの場合

いわゆる普通の img タグの場合。

Microsoft Internet Explorer 11.63.10586.0
以下のフォーマットが利用できる。

CF_TEXT
CF_DIB
CF_UNICODETEXT
CF_HDROP
RegisterClipboardFormat("HTML Format")
RegisterClipboardFormat("DragContext")
RegisterClipboardFormat("UniformResourceLocatorW")
RegisterClipboardFormat("msSourceUrl")
RegisterClipboardFormat("UntrustedDragDrop")
RegisterClipboardFormat("DragImageBits")

CF_TEXT / CF_UNICODETEXT / RegisterClipboardFormat("UniformResourceLocatorW") は画像の URL が入っている。
RegisterClipboardFormat("msSourceUrl") は画像の URL ではなく、ドラッグ元のページの URL らしきものが格納される。
RegisterClipboardFormat("UntrustedDragDrop") はこの辺に解説がある。
RegisterClipboardFormat("HTML Format") は HTML が画像タグの他にいくつかのタグがセットになった断片で格納されている。HTML の前にヘッダ情報がテキストで付いていて、恐らくこれを利用すると img タグのみを抜き出すこともできるのだと思われる。contentEditable なエレメントで利用される形式のような気がする。
RegisterClipboardFormat("DragContext") は未調査。
CF_DIB / RegisterClipboardFormat("DragImageBits") には未テストであるものの恐らくデコード済みのビットマップデータが取得可能だと思う。
CF_HDROP からはデコードされていない画像へのパスが取得できる。

ただし、IE には保護モードがあり、これが ON の場合フォーマットの列挙はできるが読み取ろうとすると API 呼び出しでエラーが起こる。これに関してはこの辺に解説があるようだけど細かい部分に関しては未調査。
Microsoft Edge 25.10586.0.0 EdgeHTML 13.10586
以下のフォーマットが利用できる。

CF_TEXT
CF_DIB
CF_UNICODETEXT
CF_HDROP
RegisterClipboardFormat("HTML Format")
RegisterClipboardFormat("Preferred DropEffect")
RegisterClipboardFormat("UniformResourceLocatorW")
RegisterClipboardFormat("msSourceUrl")
RegisterClipboardFormat("UntrustedDragDrop")
RegisterClipboardFormat("msSourceTopLevelWindow")

IE と概ね同じで、RegisterClipboardFormat("Preferred DropEffect") と RegisterClipboardFormat("msSourceTopLevelWindow") が増えて RegisterClipboardFormat("DragContext") がなくなった。
格納されている内容も IE と同じで、かつ Edge には保護モードがない。
Google Chrome 48.0.2564.103
以下のフォーマットが利用できる。

CF_TEXT
CF_UNICODETEXT
RegisterClipboardFormat("FileContents")
RegisterClipboardFormat("FileGroupDescriptorW")
RegisterClipboardFormat("HTML Format")
RegisterClipboardFormat("UniformResourceLocator")
RegisterClipboardFormat("DragContext")
RegisterClipboardFormat("UniformResourceLocatorW")
RegisterClipboardFormat("text/html")
RegisterClipboardFormat("DragImageBits")
RegisterClipboardFormat("chromium/x-renderer-taint")
RegisterClipboardFormat("text/x-moz-url")

CF_TEXT / CF_UNICODETEXT / RegisterClipboardFormat("UniformResourceLocator") / RegisterClipboardFormat("UniformResourceLocatorW") / RegisterClipboardFormat("text/x-moz-url") は全て URL が取得できる。
RegisterClipboardFormat("HTML Format") は IE と同じフォーマットのデータが取得できる。RegisterClipboardFormat("text/html") も似たようなデータだが、これは純粋に掴んだ画像タグがそのまま手に入る。
とりあえず RegisterClipboardFormat("FileContents") を使うと画像の元データが手に入る。RegisterClipboardFormat("FileContents") のデータを読み取る時はここにあるように FORMATETC 構造体の LINDEX は -1 ではなく 0 から始まるインデックス番号にしなければいけないようだ。また、ファイル名として使うべき名前を RegisterClipboardFormat("FileGroupDescriptorW") から知ることができ、複数のファイルがドラッグされる場合は本来ここでの登場順とインデックス番号が対応するものと思われる。
Firefox 44.0.1
以下のフォーマットが利用できる。

CF_DIB
CF_UNICODETEXT
CF_HDROP
CF_MAX
RegisterClipboardFormat("FileContents")
RegisterClipboardFormat("FileGroupDescriptorW")
RegisterClipboardFormat("HTML Format")
RegisterClipboardFormat("Preferred DropEffect")
RegisterClipboardFormat("DragContext")
RegisterClipboardFormat("UniformResourceLocatorW")
RegisterClipboardFormat("text/html")
RegisterClipboardFormat("DragImageBits")
RegisterClipboardFormat("application/x-moz-file-promise-url")
RegisterClipboardFormat("text/_moz_htmlinfo")
RegisterClipboardFormat("application/x-moz-file-promise-dest-filename")
RegisterClipboardFormat("text/_moz_htmlcontext")
RegisterClipboardFormat("application/x-moz-nativeimage")
RegisterClipboardFormat("text/x-moz-url")
RegisterClipboardFormat("text/x-moz-url-data")
RegisterClipboardFormat("text/x-moz-url-desc")
RegisterClipboardFormat("text/uri-list")

RegisterClipboardFormat("application/x-moz-nativeimage") は読み取り時にエラーが起きるので何が入っているのか確認することはできなかった。
CF_UNICODETEXT / RegisterClipboardFormat("UniformResourceLocatorW") / RegisterClipboardFormat("application/x-moz-file-promise-url") / RegisterClipboardFormat("text/x-moz-url-data") / RegisterClipboardFormat("text/x-moz-url-desc") / RegisterClipboardFormat("text/uri-list") には大体画像の URL っぽいものが入っている。
RegisterClipboardFormat("HTML Format") / RegisterClipboardFormat("text/html") は Chrome と同じデータ。
RegisterClipboardFormat("text/_moz_htmlcontext") には HTML の断片。
CF_DIB / CF_MAX / RegisterClipboardFormat("DragImageBits") はビットマップっぽいデータ。
CF_HDROP は元データではなく、元データが BMP ファイルに変換されたもののパスが渡されてくるため、元データが欲しい場合にこれを優先的に処理してはいけない。
未変換の画像データが欲しい場合はやはり Chrome と同じように RegisterClipboardFormat("FileContents") と RegisterClipboardFormat("FileGroupDescriptorW") を使うのが望ましい。
ただし一つ注意点があって、Firefox では FORMATETC 構造体で TYMED_HGLOBAL を要求して GetData を呼んでも STGMEDIUM 構造体は TYMED_ISTREAM で返ってくる。そのため手抜きで戻ってきたものは全部 TYMED_HGLOBAL だと決め打ちして実装すると Firefox で上手く動かなくなると思われる。あと IStream::Clone は未実装らしい。

src に RFC 2397 Data URI scheme を使用した img タグの場合

最近だいぶ浸透しつつある data:image/png;base64,... みたいな奴。

Microsoft Internet Explorer 11.63.10586.0
以下のフォーマットが利用できる。

CF_TEXT
CF_DIB
CF_UNICODETEXT
RegisterClipboardFormat("HTML Format")
RegisterClipboardFormat("DragContext")
RegisterClipboardFormat("msSourceUrl")
RegisterClipboardFormat("DragImageBits")
RegisterClipboardFormat("UntrustedDragDrop")

URL を示す RegisterClipboardFormat("UniformResourceLocatorW") がない。
色々なソフトで URL として受け付けることはこの時点で諦めそうな気配がする。
ただし CF_TEXT / CF_UNICODETEXT には Data URI scheme 形式のテキストが入ってくるので、画像データを取得すること自体は普通に可能。
Microsoft Edge 25.10586.0.0 EdgeHTML 13.10586
以下のフォーマットが利用できる。

CF_TEXT
CF_DIB
CF_UNICODETEXT
RegisterClipboardFormat("HTML Format")
RegisterClipboardFormat("Preferred DropEffect")
RegisterClipboardFormat("msSourceUrl")
RegisterClipboardFormat("UntrustedDragDrop")
RegisterClipboardFormat("msSourceTopLevelWindow")

こちらも大体 IE と同じ。
Google Chrome 48.0.2564.103
以下のフォーマットが利用できる。

CF_TEXT
CF_UNICODETEXT
RegisterClipboardFormat("FileContents")
RegisterClipboardFormat("FileGroupDescriptorW")
RegisterClipboardFormat("HTML Format")
RegisterClipboardFormat("UniformResourceLocator")
RegisterClipboardFormat("DragContext")
RegisterClipboardFormat("UniformResourceLocatorW")
RegisterClipboardFormat("text/html")
RegisterClipboardFormat("text/x-moz-url")
RegisterClipboardFormat("DragImageBits")
RegisterClipboardFormat("chromium/x-renderer-taint")

Chrome は比較的普通のファイルと同じように扱えるよう配慮された挙動をする。
画像データは RegisterClipboardFormat("FileContents") で普通に取り出せるし、RegisterClipboardFormat("FileGroupDescriptorW") には AQK0eAs+oHYKAAAAAElFTkSuQmCC.png のように Base64 エンコードされている画像データの最後の方に .png をつけたファイル名で格納されている。
また、CF_TEXT / CF_UNICODETEXT / RegisterClipboardFormat("UniformResourceLocator") / RegisterClipboardFormat("UniformResourceLocatorW") / RegisterClipboardFormat("text/x-moz-url") などのように URL が格納されているものには Data URI scheme の画像データが格納されている。
Firefox 44.0.1
以下のフォーマットが利用できる。

CF_UNICODETEXT
RegisterClipboardFormat("FileContents")
RegisterClipboardFormat("FileGroupDescriptorW")
RegisterClipboardFormat("HTML Format")
RegisterClipboardFormat("DragContext")
RegisterClipboardFormat("UniformResourceLocatorW")
RegisterClipboardFormat("text/html")
RegisterClipboardFormat("text/x-moz-url")
RegisterClipboardFormat("text/x-moz-url-data")
RegisterClipboardFormat("text/x-moz-url-desc")
RegisterClipboardFormat("text/uri-list")
RegisterClipboardFormat("text/_moz_htmlcontext")
RegisterClipboardFormat("text/_moz_htmlinfo")
RegisterClipboardFormat("DragImageBits")

Firefox の RegisterClipboardFormat("FileContents") は画像ではなく、Data URI scheme へのインターネットショートカット（ファイル名は Untitled.URL）がデータ本体になっているため、これを抜き出してはいけない。
CF_UNICODETEXT や URL が格納されている形式に関しては普通に Data URI scheme でデータが格納されているため、このデータをデコードすることで画像データを取得するのがいいと思われる。

結局どのようにデータを取得すべきか

ドロップ元のプログラムが何なのかを知らずに処理できなければいけないので、概ね以下の順序で取得するプログラムを書くのが取りあえずいいかなと思う。
なお TYMED_HGLOBAL でデータを要求しても TYMED_ISTREAM で返ってくることが実際にあったので、戻ってくる値が TYMED_HGLOBAL であることを想定して実装してはいけない。

RegisterClipboardFormat("FileContents") があるなら読んでみて、GIF / JPEG / PNG / WEBP など対応可能な形式ならこれをデータとして受け付ける。形式の認識はファイルの先頭数バイトを見れば
GIF: GIF87a または GIF89a
JPEG: \xff\xd8\xff
PNG: \x89PNG\x0d\x0a\x1a\x0a
WEBP: RIFF????WEBP
などなど、ある程度は判断できるはず。
WebP は一般的な RIFF ヘッダなので ???? にはサイズ情報が入る。
もしファイル名も必要な場合は RegisterClipboardFormat("FileGroupDescriptorW") を参照してファイル名を取得する。
ブラウザ以外からもドロップを受け付けるつもりの場合は ANSI 版である RegisterClipboardFormat("FileGroupDescriptor") からのファイル名の取得も恐らく試みるべきだろう。
CF_HDROP があるなら読んでみて、対応可能な形式ならこれをデータとして受け付ける。
これに対応した時点で一般的な色々なソフトからのドロップにも対応できるようになる。
なお、例えば 7zip で圧縮済みデータを閲覧中にファイルをドロップしようとした時など、DragEnter で CF_HDROP を渡してくるのにも関わらず、ファイルがまだ実在しないというパターンもある（DragEnter ではなく Drop の時にはファイルはある）。
このような実装になっているのは大容量の圧縮ファイルのドラッグ時のレスポンスを良くするためだと思うが、実際お手本実装とも言える Windows 標準のエクスプローラはこの手のものでも正常に動作するので、対応する価値はあるように思う。
この手のソフトから受け付けることも考慮する場合は拡張子からのファイルタイプ判断が必要になる。
CF_UNICODETEXT または CF_TEXT があるなら読んでみて、内容が data: で始まる場合は Data URI scheme からのデータ抽出を試みる。Wikipedia にも少し書いてあるけど、仕様としては Base64 以外にパーセントエンコーディングが使用されている可能性がある。
ただ画像データをエンコードする際、データの肥大化を考えるとまともなプログラムなら Base64 以外選択肢は実質的にはないと思えるので、Base64 のみ対応でもあまり問題ないかも知れない。
これに対応すると副産物として当然ただのテキストの範囲選択ドロップでも Data URI scheme の形式なら画像として読み込めるようになる。

http://s.oov.ch/software/oledd_project1_20190512.7z

概ね上記の順番に従って実装したサンプルプログラム。
Lazarus 2.0.0 で作ってある。
(2019-05-12 追記: CF_HDROP の処理に関するバグを修正)

もう少しマイナーなエッジケースも存在するかもしれないが、知っている範囲では今のところ良好。

2015年の一人反省会

2015-12-31T21:50:00.001+09:00

今年もやったこととかやらなかったこととか色々あったと思うけど、手を出した中でも中途半端な状態で投げ出していて自分でも勿体ないなあと感じているのは、夏の少し前ぐらいに Sinsy を触って遊んでいた奴。

触って遊んでいたと言っても Web インターフェイスから音声を生成していたのわけではなくて、プログラムから叩いて遊んでみていた。

触り始めた発端は単純で、CeVIO のピアノロールでガイド表示を有効にしている時に 1/32 だと描画内容からは想像ができないレベルで重いので、バグレポートついでに「そんなに重くなるのか？」というのを自分で実装して試してみようということで始めた。
ただ C# はまともに触ったことがないし、取りあえず C++ で JUCE を使って作業を始めた。
JUCE も触ったことはなかったものの、API を眺めたことぐらいはあったので精神的な障壁が低めだった。

CeVIO で表示している相当の情報を Sinsy から貰ってきて描画するだけだから専門的な知識がなくても必要な関数をちょちょいと呼べばいけるだろうと高をくくっていたのだが、これが思いの外手間がかかった。

外部リソースを埋め込めるようにする

スクリーンショットでもわかるように、最初から Android もテスト環境として試していた。
クロスプラットフォームで動くプログラムを作る場合外部リソースの読み込みは結構環境ごとに差があってあまり触れたくない領域で、実際 JUCE でもソースコードに埋め込む手段が標準で用意されているのでそれを使いたかったのだが、ソースコードを少し読んでみると Sinsy::setLanguages とか Sinsy::loadVoices などのインターフェイスが引数にファイル名などを受け取る形しかなくリソースをソースコードに埋め込むことができなかった。

だからまず最初に std::istream からリソースを読み込めるようにオーバーロードを追加して、Sinsy を使う上で外部ファイルに全く依存せずに実行可能な環境を整えることから始めた。

「C ならともかく C++ なら抽象化されたストリームが使えるのに何故そんな構造に」とか「辞書として言語ごとに shift_jis/euc_jp/utf_8 とか文字コードを複数用意するつもりっぽいけど、言語と文字コードは本来別の問題だから『UTF-8 でよこせ』っていう仕様にした方が後々良くない？」とかいくつか疑問があったけど、多分色々事情もあるだろうしそれ自体もまた別の問題だから取りあえず見なかったことにした。
（特にストリームの話に関しては内部で使われている C の hts_engine API にまで話が及んでいてもう少し面倒臭い話になっている）

ともあれ変更によって全てのリソースの埋め込めるようになった。

なんかデバッグビルドが重くて辛い

試しに Wave ファイルを書き出して出力のテストをしてみていたのだが、デバッグビルドでは Wave 書き出し完了までやたら遅いし、リリースビルドでも CeVIO と比べると何となく遅いような感じがした。
なぜだろうかと思って少し調べてみたら、どうやら hts_engine API の HTS_alloc_matrix など複数の箇所でループ内で HTS_calloc を大量に呼ぶコードがあり、こういう箇所がかなり足を引っ張っているようだった。
デバッグビルドでは格段に重くなるのもリーク検出のためかと思うと合点がいく。

HTS_calloc の実装を見てみると #ifdef FESTIVAL でライブラリがあるなら多分これの safe_wcalloc を呼んで、ないなら素直に malloc を呼ぶというコードになっていた。そしてその #ifdef が終わった後には確保した領域を memset で 0 埋めしている。
このコードだと safe_wcalloc が呼ばれた場合には無駄に memset してしまうし、なぜライブラリがない場合に calloc じゃなくて malloc なんだろうかと、またいくつか疑問はあった。

でも取りあえず1番大きな問題は HTS_calloc の大量呼び出しで、必要なければ頻繁に行うべきではないのは自明なので必要な量のメモリをサイズ計算して一度で全部確保するように変更した。
こうすると当然開放側でも HTS_free を一度呼べば全て開放できるし。

何箇所かを似たようなアプローチで書き換えてデバッグビルドが耐えられる程度の速度になった。

表示周りを作るためには拍子から

今度は楽譜データを管理する内部構造と、それに伴う GUI 周りを JUCE と共に作り始めた。

最初に手を付けるべきなのは拍子を扱う機構だろうと思い、いわゆるコンダクタートラックを考え始めた。
というのも、当初の目的ではガイドの線がどの程度の負荷で描画できるのか、というのを試してみることだったので、まずは途中で拍子が変わることに対応できなければいけないと思ったから。

キーと拍子をまとめて扱うクラス（位置は小節単位での絶対位置として管理）を作って、std::deque に突っ込むだけで即席なコンダクタートラックは完成した。

厳密に楽譜を再現する場合にはキーを扱うのに位置情報が小節単位の精度では上手くいかないはずではあるのだが（小節の途中でキーが変わる楽譜もあるから）、キー情報自体ピアノロールに対してはかなり些末な情報と思えるので気にしないことにした。

ピアノロールの左側にある鍵盤表示

この時点でノート情報が存在しないピアノロールをレンダリングするには最低限必要なデータが揃ったので、JUCE で GUI を考え始めた。とはいえ特別オリジナリティのあるインターフェイスにはせず CeVIO に似たところを攻めるだけでいいので、Viewport と Slider を組み合わせたコンポーネントでピアノロールのメイン領域を準備しつつ、まずは左側にある鍵盤描画に着手し始めた。

ところで、ピアノロールの鍵盤描画は思っていたより様々なアプローチがあるようでとても面白い。
ここではピアノロールが回転していることを踏まえ鍵盤の縦の高さのことを「幅」と呼ぶことにする。

FLStudio や SONAR のインターフェイスでは白鍵の幅がバラバラになっている。
常に黒鍵の中央に白鍵の分かれ目があるものとして扱う場合、こういう鍵盤が生まれる。
VOCALOID やこっちの FLStudio では白鍵も黒鍵も完全に同じ幅として描画している。
鍵盤らしさはないが、ピアノロールのノート表示との相性を考えるとこれも一つの答えだと思う。
Domino や Singer Song Writer(ABILITY)、そして CeVIO では恐らく正確な幅で描画している。
Studio One も 3 からはこの形式になったようだ（以前は白鍵バラバラ方式）。
Cubase は個性的な方式を採用している。
鍵盤描画は正確な描画なのだが、ノートが置かれるエリアでは白鍵が連続するEF、BCの間に余白を挿入することで、白鍵だけを並べた時に等間隔になるようにしている。なおメリットは不明。

上記一覧で正確な描画としてまとめた中でも恐らく実際には更に方式は細分化されていて、Domino は本当に正確で、他はちょっとだけズルをしているんじゃないかと思う。
（実際には拡大率とか描画時の座標丸め込みとかの関係で判断難しいのかもしれないけど）

というのも、白鍵を1オクターブの中で配置すると7個で、黒鍵は12等分にしたエリアの 2, 4, 7, 9, 11 番目、ノート配置エリアも同じく12等分したエリアに配置されることになる。
すると、1オクターブを12等分したノート配置エリアと鍵盤の白鍵の線の位置が一致するのがBC間の一箇所だけになり、EF間の線はかなり惜しい位置にあるものの一致しない（1.0/12.0*5.0 = 0.41666666666666663, 1.0/7.0*3.0 = 0.42857142857142855）。

文章だとややこしいけど、要するにこういうことだ

正確に描画した結果ずれているように見えるのも面白い話ではあるのだが、この合いそうで合わないモヤモヤ感を解消するためには、1オクターブ内で白鍵の幅をCDE と EFGAB で別に扱う必要がある。

まず1オクターブの幅を12で割り、それをノート配置エリアと黒鍵の幅とする。
そして CDE の幅を黒鍵の幅*5/3、EFGAB の幅を黒鍵の幅*7/4 とすれば揃うようになる。
この幅の差は凄く小さいので見た目上ほとんど正確に見える。

そういう感じでピアノロールの左側にある目安程度の鍵盤の描画にはちょっとしたドラマがあると感じつつ、鍵盤の描画処理を完成させて次の段階へ進むのだった。

ノート配置エリアの描画に関しては特に面白い話はなくて、拍子の変更情報を読みつつ線を引くだけだった。

ノートの配置

まずトラックデータを格納する機構から。
基本的なアプローチはコンダクタートラックと似た感じになるが、位置情報を PPQN 単位での絶対位置で保持して（4分音符を例えば 480 などにする）、それを基底クラスとし、継承してノートイベントを作る。
また、コンダクタートラックにまだテンポ情報がないので、同じクラスを継承してテンポイベントも作る。
これらもやっぱり std::deque に突っ込むだけでそれぞれのトラックとしては基本的には完成。

ところで位置情報に関しては MIDI ファイルの構造を知っているとデルタタイムを参考に相対位置で管理したくなる部分でもあるのだが、絶対位置から相対位置を求める場合は自分のひとつ前との差を見れば済むのに対し、相対位置から絶対位置を求めるには自分より前の全てのイベントを足さないと結果が出せないので、効率を考えると絶対位置で保持するほうがいいだろうと思い、この構造にした。
絶対位置を符号付き 32bit 整数に格納しても PPQN が 480 の時 2147483647/1920 ≒ 1118481 小節までは進めるし、実際に使う上で困ることはほとんどない。

描画に関しては表示だけなら特に難しいことはなくて、画面外のものを描画しないとか基本的なところを抑えておけばパフォーマンスも問題ないようだった。

Sinsy からタイミング情報などを取得

ノート情報を Sinsy に叩き込んで CeVIO の TMG パネルで表示するようなデータを貰おうと思ったら、どうやらその辺のデータを外側に持ち出す機構がなさそうだったので、手を入れる必要があった。
同じようにやはりピッチやボリュームデータを取り出す仕組みも見当たらないし、取り出す機能がないという事は当然書き換えたデータを代わりに渡す機構もないし、必要になる機能が色々足りない。
元々ビブラート関係の仕組みはオープンソース版の Sinsy には多分入っていないんだろうとは思うのでその辺は良いとしても、このままではデータの入出力のストリーミングも出来ないし、Sinsy 側での内部処理を理解しなくてもいけるだろうというのは幻想でしかなかったのが浮き彫りになりつつあり、この頃から気分的に盛り下がってくる。

あと元のライブラリとの差分が増えてくるとバージョンアップを取り込む時のマージ作業も面倒くさくなっていくのであまりやりたくない作業でもあった。
とはいえ、Sinsy や hts_engine API は変更前にローカルの git リポジトリに最初にコミットして、そこから変更分をコミットするようにしているので全部手作業でやるよりはかなりマシなはずではある。

少し変更することでタイミング情報は取れたので、ピアノロール上へのオーバーレイ表示にも取り組み始める。
小節単位で表示しているピアノロールに実時間ベースで来るタイミングデータをオーバーレイ表示するのは地味に面倒な部分ではあるものの、テンポ情報を見ながら愚直に計算する以外の方法が見つからないのでそのように作った。

タイミング情報が描画できればピッチ情報も近からず遠からずみたいな感じなので同じように描画処理を作った。JUCE の Graphics::strokePath を使うとアンチエイリアシングもされて、線も滑らかに。

作業に一旦の区切り

ここまでの時点でノートの追加、範囲選択、移動、削除などはできるものの歌詞入力は未実装（日本語入力周りの関係で手間が掛かりそうだったから）、ピッチの書き換えや反映を未実装、ボリュームの取得や書き換えや反映を未実装、オーディオデータの再生も未実装。
この辺りでだいぶ興味が薄れてきてノート編集周りの挙動を気持ちよくなるようにしたりとかしながら、段々ソースコードを触らなくなっていった。

ここからは未着手なので推測だけども、ピアノロールで位置を指定して再生するためには波形の任意の位置からの再生ができなければいけない。
例えば10分ぐらいのシーケンスがあって、最初の5秒が欲しい場合は頭のほうだけを処理したいし、シーケンスの中央辺りを編集した時は頭の方を処理し直す必要がなさそうに思えるし、こういう部分で不要な処理を削り取りたい。
今回のプログラムはノートを変更した時など再生対象になるシーケンスが確定したタイミングで裏で別スレッドで生成を始めておいてシームレスに更新する仕組みにはしているけど、ラグ自体は解消しないからタイミング次第では改善しないし、VST とかでの連携を視野に入れると再生開始時に少し音が出ないとか微妙な挙動にもなりそうだし、この辺をもう少し上手く動くようにしたかった。

そのため Sinsy で任意の位置からのストリーミング再生をする方法を探っていたのだが、HtsEngine::synthesize の中で使われている HTS_Engine_get_generated_speech はその名の通り既に生成済みの波形データをコピーしてくるだけなので、これではシーケンス全体のサイズに関わらず一定に近い処理量で任意位置から再生することはできそうになかった。

どうやら肝になるのはその前に使われる HTS_Engine_synthesize_from_strings が呼ぶ HTS_Label_load_from_strings と HTS_Engine_synthesize で、負荷のバランスを見た限りでは HTS_Label_load_from_strings は軽くはないけど HTS_Engine_synthesize に比べれば所要時間は短い。
なので重要そうなのは HTS_Engine_synthesize で行われる3パスの波形生成処理で、ここを細かい単位で複数回に分けて実行できるように、更に可能であれば途中からの実行、無理でも前回からの変更差分のみを最低限の範囲で再処理できるようにしたかった。

そう思って少しずつソースコードを読んでみたりはしたものの、基本的に必要となる前提知識が足りないというか無いので各処理がどんな役割があり変わるとどうなるのかがわからず、たいへん手を出しにくい（実際出していない）。

そういうわけで今回は自分にとっては大きな課題を残したまま放置することになった。
基本的な部分の知識を持っていないが故に瑣末な問題が気になるんだろうとも思った。

そんな感じで色々な部分が大量に残っているおもちゃ以下のプログラムなのだが、それでも当初の目的だった「ガイド表示の線が増えると重いのか」というのに関してはやっぱりそんなに重くならないということで自分の中では落ち着きつつある。
ただ少なくとも JUCE のレンダラでは線を引く時に素直に引くとアンチエイリアシングの影響で地味に重くて、代わりに fillRect で細長い長方形を描くと速度が出ることがわかった。
CeVIO は点線で描画してるけどそれで重くなるのだろうか。その辺は調べていないので謎。

ちゃんと記録取ってなかったので正確なところはわからないものの、ここまでで作業開始から多分1～2ヶ月程度経っている。ライブラリの仕様がわからない状態から始めた割には良く出来たほうかな、とは思っている部分も少しあるが、MARI-ON を作った時は1ヶ月で完成まで辿り着いているので良く出来てないような気もする。色々な面で違っててあんまり比較にはならないけど。

JUCE は標準の状態では日本語が豆腐になるし Android 対応はこの時点では実験的な状態でもちろん日本語は入力できないし、問題は少なくなかったので実は結構その辺にもじわじわと時間を取られた。
しかも OpenGL ベースのレンダラを使わないと Android では描画速度も結構厳しくて、使うとそれはそれで他の問題も起こるし、楽譜に対する入力効率も含めやはりPCとスマホやタブレットで同じプログラムの流用は使い物にならなそうなのが実情かなぁというぼんやりとした印象だった。

あと Sinsy のオープンソース版は他のプログラムから呼んで使うためのものというよりはやっぱり技術デモという感じなのかな、というのがちょっと触ってみた感じでの印象だった。

少し前に JUCE は 4.x 系も出たし、年末に Sinsy と hts_engine API もバージョンアップしたみたいなので、また気が向いたら弄くり回してみようと思う。

2015年の一人反省会は大体こんな感じ。

Go 言語用 SQL クエリービルダーを作ってみた話

2015-12-06T23:54:00.000+09:00

これは Go Advent Calendar 2015 とは何の関係もない記事です。

Go 言語用の SQL クエリービルダーとしては https://github.com/elgris/golang-sql-builder-benchmark でベンチマークされているものが有名どころのようなのだが、SQLite に対応した純粋なクエリービルダーはなさそうだったのと、「自分で作ってみるのも勉強になるかな」と思い、自前の SQL クエリービルダーを作ってみることにした。
（あとこのベンチマークは dbr が 2.0 になる前のものっぽいので内容も少し古い）

https://github.com/oov/q
実際に作ったのはこちら。

パッケージ名に1文字はちょっと短すぎると自分でも思うけど、必要なら好きな名前を当てればいいし大きな問題ではないだろうと思ってそのまま進めることにした。
実際のコードでは q, args := builder.ToSQL() みたいなノリで q を使いたくなるだろうけど、SelectBuilder.ToSQL で出力してしまえばもうパッケージとしての q にアクセスする必要性は薄いし、また続きのコードでアクセスしたい場合は q という変数名はちょっと可読性が微妙だろうという気もするので問題ない。という言い訳も自分にした。

パッケージの話の前に作ろうと思うに至った話を少し。

元々作ろうと思った発端としては YAML に Go の構造体と SQL とのマッピング情報を書いて、Go のソースコードを自動生成するようなツールを試しに作ってみていた時の話になる。
この手のツールも似たようなものが結構あるのだが、Go の構造体にタグをゴリゴリ書いていくとか、使う前にコードでマッピング情報を追加するとか、使い方を覚える自信があまりなくて個人的には結構精神的な障壁が大きかった。
そういう感じで既存のは実際に使うところまでは気が乗ってこなくて、あと作ると勉強になりそうというのもあって自作してみることにしたのだった。
最初は github.com/jmoiron/sqlx を使っていたけど途中で必要ないかもと思って使うのやめたりとかソース生成用テンプレートがカオスになったりしつつなんとか基本的な動作はできたが、生成されたコード内で SQL は文字列で直書きされるようになっていて、ちょっとだけ条件を加えたクエリーを投げるような柔軟性が持たせられなかった。
「なるほど、これは後からの改変に耐えられるようにクエリービルダー的なものを経由しないとダメかな？」と思ったところで今回のパッケージを作るに至った。
クエリービルダーもこのジェネレータと同じパッケージに含めようか迷ったのだが、一緒にした時のメリットが使う時に import 文がまとまる以外特に思いつかず、本質的には別のパッケージなのでやめた。

あと、前回の記事で Docker コンテナを使うテストを書きやすくするためのパッケージを作ったんだけども、これもこの辺の話に関連していて MySQL、PostgreSQL、SQLite での動作を確認するためになるべく手間が減らせるように作ったのだった。
（しかし肝心のテストはかなり薄い）

今回のパッケージの話に戻す。

q を作る上でのテーマは、短く書くためだけにショートハンドメソッドなどをガツガツ増やしたりせず、なるべく素直な形に実装にしようというところ。とはいえやり過ぎると SQL を書くのにクッソ面倒くさくて結局使わなくなるだろうし、色々考えて良い落とし所を探ったつもりではある。
本当はあんまり reflect とか type switch とかも使いたくなかったけど、いくつかやむを得ず使った。でもあまり欲張らなかったので、import するのは fmt と reflect だけで済んだ。

使用例としては大体こんな感じ。

user := q.T("user")
sel := q.Select().From(
    user,
).Column(
    user.C("id"),
    user.C("name"),
).Where(
    q.Eq(user.C("age"), 18),
)
fmt.Println(sel) // SELECT "user"."id", "user"."name" FROM "user" WHERE "user"."age" = ? [18]

簡単に説明すると、

SELECT 文をつくるには q.Select
q.Select("SELECT SQL_NO_CACHE") みたいなことも一応できる
テーブルを作るには q.T
クエリービルダーにも同じ名前のメソッドがあり、サブクエリーを FROM に書きたい場合などに使える
カラムを作るには q.C か、Table.C か、Expression.C
q.C の場合は "column" table.C の場合は "table"."column" のような形になる
JOIN にも対応
テーブルにあるメソッドを呼ぶことで使用可能

といった感じで、他のクエリービルダーに比べて文字列で直接指定できる部分は結構少ないはず。
そのためテーブル名やカラム名に関してはキッチリエスケープされる。

ただしこれだけだとパッケージに準備されていない色々なことができないので、SQL の破片を直書きできる q.Unsafe もあり、概ね fmt.Print と同じ使い勝手で以下のように使うことができる。

user := q.T("user", "u")
age := user.C("age")
sel := q.Select().From(user).Column(
    q.C(q.Unsafe(`SUM(CASE WHEN (`, age, ` >= 13)AND(`, age, ` <= 19) THEN 1 ELSE 0 END)`), "teen"),
    q.C(q.Unsafe(`SUM(CASE WHEN `, age, ` >= 20 THEN 1 ELSE 0 END)`), "adult"),
)
fmt.Println(sel) // SELECT SUM(CASE WHEN ("u"."age" >= 13)AND("u"."age" <= 19) THEN 1 ELSE 0 END) AS "teen", SUM(CASE WHEN "u"."age" >= 20 THEN 1 ELSE 0 END) AS "adult" FROM "user" AS "u" []

※ただしこの例で出てくる CASE 文は本当は q.Unsafe を使わなくても組むこともできる。

このように文字列が直接 SQL として書き出されるため外部からの入力を直接埋め込むのは大変危険なのだが、その場合には q.V で外部からの入力を囲うことで、プレースホルダーに置換させることもできる。

このような構造にしておいたら外部ツールで解析して危なそうな箇所を見つけられるかな？　と妄想している。文字列リテラルでも Expression でもないものを渡してる箇所を検出するみたいな感じで。
簡単にやるなら grep で q.Unsafe を探すのでもいいけど。

あと godoc で目次がある程度読みやすくなるように考えて作ってみた。
Function タイプのように実質的に中身が一緒でも、敢えて別名にすることで一覧を整理したりとか。
英語は全然できないんだけど English > Broken English > Non-English Language という話を見かけて「確かにな」と思ったのでそういう方針で、あと Example を沢山用意することで言語を超えて意図を伝えようというのも試みている。
Go 言語の場合 Example を書くことで出力内容の検証もやってくれるようになるので一石二鳥だった。

小さいパッケージなので話としては大体こんな感じ。
今後も UPDATE, DELETE, INSERT 文辺りへの対応とか、あと日時周りの計算とかもプラットフォーム依存しないように使えるメソッド増やせるといいかもなあ。詳しくないけど。

まだ作ってみたという段階で、これから発端のプロジェクトで使うことでドッグフーディングしていく。そこで使った感触を元にまたドラスティックな変更をするかも知れないけど、ひとまず現状こんな感じ。

---- 2015-12-08 追記

全然まだテストしてないけど UPDATE と DELETE も一応組めるようになった。
あと type switch を減らせそうなところを減らした。
プライベートな型とかインターフェイスとかメソッドも結構 public にしてみたので、足りない関数とか諸機能を外部のパッケージで作って組み合わせて使うようなやり方もいけるかも知れない。

Go 言語で Docker を使うテストを書く時

2015-11-19T07:38:00.000+09:00

日記。
Docker コンテナ内で立ち上げたサーバーに繋ぐテストを書く時の話。
テスト開始時にコンテナを立ち上げて、テストして、終了時に落とすみたいな奴。

コマンドや API を叩いてコンテナの実行が始まった直後に繋ぎに行くと、まだコンテナ内で listen が始まっていないのが原因で失敗する、ということがしばしば起こる。
この時の対応策は色々あるだろうけども、１番安直な方法は恐らく「成功するまで sleep とリトライを繰り返す」という類のものだと思う。
（コンテナ自体が不安定な場合は起動失敗してないか調べるのも必要そう）

この sleep の部分を「netstat の出力で listen しているか調べる」という、これまた安直な方法で実現すれば、汎用的に使えるリトライ不要な手段になるのではないだろうか？　と思い、少し作ってみることにした。

https://github.com/oov/dockertest
コードの一部はこの記事を参考にさせてもらった。

パッケージを作る前に手作業で試してみた時点で「コンテナ内に netstat 自体が存在しない」という理由で上手くいかず/proc/net/tcp などを見に行くようにアプローチを変えざるを得なかったものの、Docker Hub にあるオフィシャルの MySQL, PostgreSQL, Redis, MongoDB と、dnsmasq(andyshinn/dnsmasq) に繋ぐのを試した限りでは概ね成功した。

概ね、というのは PostgreSQL は listen が始まった直後だと "the database system is starting up" と言われて接続に失敗することがあり、結局リトライする処理が必要になったため。
他のプログラムでも設定などによっては listen したあと更に準備時間が必要なケースもあるかも知れないので、結果的には思惑ほど全て上手くは行かなかったことになる。ちょっと残念。

環境変数 DOCKER_HOST の有無も考慮して動くようにしたおかげでテストに手を加えなくても Windows 環境でも Docker Quickstart Terminal とか boot2docker を経由してテストを実行できるし、パッケージとしては作ってよかったと思う。

ところで、普段 Go 言語を使って遊んでいるのは自宅サーバの Ubuntu で作曲とかに使うマシンは Windows なんだけど、このテストを両方の環境で実行したら思っていたより速度差が大きかった。

CPU: Intel Atom D510 1.66GHz / Memory: 4GB / OS: Ubuntu 14.04

=== RUN   Example_dnsmasq
--- PASS: Example_dnsmasq (2.98s)
=== RUN   Example_mongoDB
--- PASS: Example_mongoDB (4.61s)
=== RUN   Example_mySQL
--- PASS: Example_mySQL (55.38s)
=== RUN   Example_postgreSQL
--- PASS: Example_postgreSQL (17.30s)
=== RUN   Example_redis
--- PASS: Example_redis (2.46s)

CPU: Intel Core i7-4790K 4.00GHz / Memory: 32GB / OS: Windows 10

=== RUN   Example_dnsmasq
--- PASS: Example_dnsmasq (1.08s)
=== RUN   Example_mongoDB
--- PASS: Example_mongoDB (0.87s)
=== RUN   Example_mySQL
--- PASS: Example_mySQL (6.91s)
=== RUN   Example_postgreSQL
--- PASS: Example_postgreSQL (4.49s)
=== RUN   Example_redis
--- PASS: Example_redis (0.96s)

普段の環境で毎回1分近く掛かるのは結構辛いし、テスト開始時にコンテナを起動するか、名前をつけておいた起動済みコンテナを利用するのか自動で判断する仕組みが必要かもなぁ、と思ったのだった。

---- 追記 2015-11-20

起動済みのコンテナを再利用する仕組みを追加したところ、遅い環境でも1秒程度で終わるようになった。
名前しかチェックしていないのでイメージやパラメータが違う状態で起動しているのも利用できてしまったりするけど、厳密にやり過ぎても使いにくいかも知れないのでその辺りは緩めにしておくことにした。
同じパラメータで起動したい時は Container.RunArgs を利用するとコピペできて便利。

goji + goth で OAuth ログイン

2015-10-16T23:14:00.000+09:00

ただの日記。

何となく Go 言語で goji を使って OAuth クライアントとして外部サービスにログインして戻ってくる流れを作ってみようと思ったんだけど、実際書き始めてみると思っていたよりも迷ったので一応書き残しておく。

認証用ライブラリの選択

まず便利そうなパッケージをいくつかピックアップしてきた。

取りあえず自分がよく使う Twitter と Google+ アカウントでのログインを使いたいので、OAuth 1.x に対応していない gomniauth を除外。
次に gologin を見てみると、これは golang.org/x/net/context を活用したつくりになっていて結構良さそうに見える。ただ複数のサービスにログインできるようにするためには何気にコード量が多くなりそうなのが若干気になる。
最後に goth を見てみると、サンプルコードひとつで複数サービスへのログインを想定した作りになっていた。

今回はサンプルコードが何となく想像していた構造に近そうな goth にしてみることにした。
コードが短いのは結局のところ取り捨て選択に寄るもので細かい融通が利かないことも少なくないので、やりたいことや相性によって良くも悪くもなるので判断が難しい。

サンプルコードを元に goji 用に書き直す

これを単純に goji で置き換える形で書いてみたのがこちら。この段階ではまだ動いてない。

動かすと「you must select a provider」というメッセージが表示されるので、URL から「twitter」などのプロバイダ名が取得できていないことが容易に推測できる。
まあ書き直している時点で動かなくなることが想定済みだったけども。

じゃあそもそもプロバイダ名をどうやって取得しているのか？　というのをまず確認することにした。

https://github.com/markbates/goth/blob/master/gothic/gothic.go#L161
該当の処理はここで、*http.Request から URL のクエリ部分を抜き出し "provider" あるいは ":provider" という名前のパラメータを取得しようとしていた。
先頭にコロンがついたものは元々のコードで使われていた github.com/gorilla/pat が独自に追加しているパラメータで、"/auth/{provider}" のようなパターンでハンドラを登録しておくと追加されるらしい。

そのすぐ上にある GetProviderName を外部から差し替える事でこの振る舞いを変えることもできるようだ。
ところで goji では "/auth/:provider/callback" のようなパターンでハンドラ登録をしておくと web.C.URLParams から URL のパラメータを取得できる仕組みになっているのだが、GetProviderName には *http.Request しか渡されないためそのままでは取得できず、微妙に意思の疎通ができていない感じになっている。

この時点で比較的アクロバティックでない手段として考えついたのは以下の様なものだった。

GetProviderName を差し替えて、自力で URL のパスからプロバイダ名を抽出する
pat の仕様に準拠するように、独自にパラメータを追加する
URL を /auth?provider=twitter のような形に変更する

候補としては一番最後のが愚直ながらも収まりの良さそうな解決方法ではあるのだが、この場合コールバック先 URL にも同じように GET パラメータを付与させておく必要があり、ユーザーがログイン成功後こちらに戻ってくるためにはログイン先のサービス側で GET パラメータの連結をしてもらわないといけなくなる。
それに失敗してログインできないような大手サービスがあるとはあまり思えないものの、可能なら避けたい気もするので今回は選ばなかった。

次に、pat に合わせる形で済ませると簡単そうかと思ったのでこれを考えてみた。
というのも最初は「もしかして req.URL.Query().Get("provider") を Set に変えるだけで簡単に割り当ても出来るのでは？」と思ったのだが、どうやらこれは Query のタイミングで毎回 URL.RawQuery から生成されているようなので、直接 RawQuery を書き換えないといけないようだ。
そうなると "Raw" Query なのに実際には改ざん済みという状況を作らないといけなくて、個人的にこの仕様はあまり好きではないので除外した。
（もちろん、もし Set で割り当てができたとしても、結果としては RawQuery とは異なる状態を持つか RawQuery も伴って変更されるかどちらかだと思うので、どちらにしても受け入れがたいものではあった）

結局最後に残ったのは URL を自分で切り分けて検出するパターン。
しかしこれを自力でやるとせっかく goji がパースしてくれていたのに改めてパースし直さなければいけなくて全体的に見ると二度手間で、goji を使っている意味が薄れている感じがしてこれも気に入らないところではある。

ひとまずこれで動くようにはなった。

セッション周辺の挙動も気になる

環境変数に必要なデータを加えて PORT=3000 SESSION_SECRET=hoge TWITTER_KEY=fuga TWITTER_SECRET=moge go run main.go と実行させることで、取りあえず Twitter でのログインに成功するようになった。
しかしログイン後 Cookie を覗いてみると 500 バイトぐらいのデータが入りっぱなしだ。そのうち消えるとはいえ不始末感が拭えない。
また、セッションにはどうやら github.com/gorilla/sessions を使用していて、これを使っている場合は後始末が必要なのに元のサンプルコードでは特にやっていない。
「なんでやっていないんだろう」と一瞬考えたものの、確か github.com/gorilla/mux を使った時は自動でやってくれているはずなので、例で使われていた pat でも内部的にやっているんだろうと思った。

内部でセッションに何を使っているのかは説明などで触れられていないので pat 以外で使おうとした際に後始末が忘れられそうだし、先述のプロバイダ名取得も含めつくりが pat に合わせてありそうな部分が見受けられるので、pat に依存気味でサンプルコードとしてはあまり良くないような気がしてきた。

とはいえ気付いてしまえばこれは単純に context.ClearHandler を goji の Middleware として追加するだけでいけるのでいいのだが、クッキーにデータが残りっぱなしになるのはあまりエレガントな対策方法が思いつかない。
sessions にも丸ごと削除する機能はなく、試しに中身のデータを消してみてもクッキー自体は残っていた。
もちろん http.SetCookie で直接消しに行く手はあるものの、外部から無理矢理叩いてる感じはとても美しくない。
取りあえず丸ごと消すのは諦めて、後始末をやるようにだけしたのがこちら。

思っていたよりも綺麗に収まらなかった

pat を goji に変えた結果思っていたよりも修正項目が多かったのだが、これは恐らく goth での処理を更に単純化するために用意された gothic の柔軟性が今ひとつだった（≒実質的に pat を前提としたコードになっていた）ことに起因するものだろうと感じた。
セッションの後始末の話も単純にクッキーの読み書きとかなら必要なさそうだし、URL からのパラメータ抽出ももっと柔軟にできた方がいい。
例えば goji 以外でも github.com/julienschmidt/httprouter とか github.com/dimfeld/httptreemux とかのように、*http.Request 以外に URL からのデータ格納するケースは他にもあるわけだし。

その辺を踏まえて改めて仕切りなおしてみることにした。

自家製 gothic

ということで、もう少し柔軟に使えそうな gothic の代わりになるものを試しに作ってみた。
goth の構造が綺麗に整っていたので gothic の差し替えはとても綺麗にできた。

https://github.com/oov/gothic

主な変更点は以下のとおり。

GetProviderName を廃止し、プロバイダ名は直接渡す形に変更
セッションの代わりに github.com/gorilla/securecookie を使用し、後始末を不要に
使い終わったクッキーはその場で破棄
GetState を廃止し OAuth 2.0 の state パラメータを内部で検証

これによって自分が使おうとした際に気になった部分は一掃できた。
改めて goji と組み合わせて使った場合のサンプルはこちら。

わかりやすい変化としては引数が増えたことによって gothic.BeginAuthHandler が http.HandlerFunc ではなくなったので名前を gothic.BeginAuth に変更して、ついでに error を返すように変えたのでエラー処理が増えてサンプルコードではこの辺が少し冗長に見えるようになった。
ただ元々の gothic でも gothic.CompleteUserAuth に関しては戻り値を返していてハンドラにできていなかったし、個人的にはこの変更で両方の足並みが揃った感じがしていい。

gothic.BeginAuth で error を返すようにしたのはハンドラではなく普通の関数ならエラーは処理せず返すのが自然だと思ったからで、内部で勝手に処理されると自前のエラーページなども表示できないし、エラーが起きたこと自体に気付けない（無視できることと気付けないことには大きな隔たりがある）し、結構微妙な問題があると思っている。
この変更をせずとも gothic.GetAuthURL で取得した URL にリダイレクトするコードを各自で書けば同じようにエラー処理はできたけど、パッケージを使う人のほとんどはリダイレクト先 URL が取得できたらその後はリダイレクトしたいわけで、エラー処理が必要になっても gothic.BeginAuth の存在意義は十分にあるように思う。

ところで実は元々は web.C にガッツリ依存させて gojic って名前にする冗談で作り始めたんだけど、作業している途中でプロバイダ名を単に引数で渡すようにするだけで素晴らしい柔軟性があることに気付いて最終的にこのような形に落ち着いた。

その他

Twitter でのログイン時に authorize じゃなくて authenticate を使いたかったものの対応していなかったのだが、これは仕様を変えなくても追加だけでスムーズにいけそうだったので PR を投げてマージしてもらった。

あと、ついここ最近の流れで http.Request に golang.org/x/net/context.Context を持たせてはどうか、という話も持ち上がっているので、これの流れ次第でまたちょっとルータやライブラリに動きがあるかも知れない。

CeVIO が軽くなった話

2015-07-17T15:41:00.000+09:00

CeVIO Creative Studio S でソングトラック編集中重かった部分が v3.2 でかなり改善された話です。

少し前の出来事になりますが、私 oov はニコニコ超会議2015 の JOYSOUND ブースにて行われた「CeVIO 座談会」という、CeVIO について話し合う場に CeVIO のユーザー代表（？）として招待して頂きました。

CeVIO 座談会当日の様子。左から ITmedia 松尾さん、ブイシンク加藤さん、エクシング石原さん、自分、オワタPさん
自分以外はみんな人間力が高かったので、喋ってる間でさえ「出るんじゃなかった……」などと丸い背中で思っていた

ちなみに改めて oov って誰だよ、というのを簡単に説明すると、最近では主に JOYSOUND からリリースされている Color Voice Series という CeVIO のソング専用ボイスを使って遊んでいる人です。

この曲は Color Voice Series 黄咲愛里のソングボイスを使っているが、実は負荷テストにも使っていた

■ CeVIO が重い

座談会では色々な話をしたんですが、その中で要望のひとつとして「CeVIO が重いのを何とかしてほしい」というのを挙げさせてもらいました。
もちろん挙げた理由は単純に、自分が CeVIO を使う上でかなり気になっていた部分だったからです。
（DTM をそれなりにやってきた身としてはサンプラーよりも物理モデリング音源の方が計算負荷が高いことは経験上理解しているつもりではあるので、ある程度は我慢はできるものの、曲が長くなると操作が辛いと感じるレベルで UI でカクカクして重かった）

座談会の場においては簡単に「重い」とだけ表現していたのですが、後日改めてどのようなシーンで重く感じたのか、また状況の再現方法などを連絡させて頂き、この約2ヶ月半の間に多くが改善、軽減したので、主に負荷周りではどんな部分が変わったのかを動画で比較しつつまとめておきます。

なお、今回の話は全てソング機能におけるもので、所要時間の数字や動画はオリジナル曲「月の交点と彼女の海」のプロジェクトファイルを Intel Core-i7 4790K / メモリ 32GB の環境で CeVIO v3.1.14.1 と v3.2.15.0 で動かした時のものです。
トラック数や演奏時間、調整機能を多用しているかどうかなどで負荷の掛かり方は変わりますが、これは比較的重いシーンでの例になります。

アクティブトラックの切り替えが重かった: 以前の CeVIO ではアクティブトラックを切り替える度に 1.5 秒程度の処理待ちが発生していました。
v3.1.16 以降ではこの待ち時間は発生しなくなりました。; 左側では切り替えの度に時間が掛かっていますが、右側ではすぐ切り替わるのが確認できます。
再生停止後の最初の操作が重かった: 以前の CeVIO では、プレビュー再生の停止後に初めて再生カーソルを移動させた時などに数秒の待ち時間が発生していました。
v3.2 以降ではこの待ち時間は発生しなくなりました。; 左側ではクリックしてから再生カーソルが移動するまでに 2.23 秒掛かっていますが、右側では即座に移動するのが確認できます。
ノート編集後、ピッチやボリュームの調整画面に切り替えようとすると重かった: 以前の CeVIO ではノート編集後にピッチやボリュームの調整画面に切り替えようとした時、実際に表示が切り替わるまでには 1.5 秒程度の待ち時間が発生していました。
v3.2 以降では即座に表示が切り替わり、データの準備が間に合っていない場合は完了次第追って反映されるようになったため、体感的な待ち時間はほぼ発生しなくなりました。; 左側ではクリックしてから表示が切り替わるまでに 1.53 秒掛かっていますが、右側では即座に切り替わっているのが確認できます。
再生開始までの待ち時間が長かった: 以前の CeVIO ではプレビュー再生の開始地点が後ろに行けば行くほど実際に再生が始まるまでの待ち時間が長くなっていました。
v3.2 以降ではこの待ち時間がほぼ一定になり、例えば以前の CeVIO で12秒弱掛かっていたものが v3.2 以降では2秒強にまで短縮されました。; 左側ではクリックしてから再生が開始されるまでに 11.51 秒掛かっていますが、右側では 2.33 秒で再生開始されているのが確認できます。

自分が把握している範囲内で大きな改善点は以上の4つです。
どれもかなり頻繁に行う操作であるためにこの変化による影響はとても大きく、一度 v3.2 での操作に慣れてしまうと古いバージョンに戻るのは結構苦痛になると思います。
（ベータの時点で既に快適すぎたので実際に自分でもバグでたまにデータが崩壊するのにも関わらず負けずに v3.2 でデータ作りを続けてました）

パフォーマンス面に関しては他にも「トラックの固定」（DAWで言うところのフリーズ機能で、トラックを内部的に Wave 書き出し済みにしておくことによって負荷を減らす）機能が追加されていたり、クォンタイズ単位でのガイド表示（ピアノロール上での右クリックメニューにある「ガイド表示」→「クォンタイズ」）が重かったのが改善されたりなどもしています。

なお v3.2 ではパフォーマンス面以外にも大量の変更が含まれており、操作性の向上や誤操作の抑制など、多方面から使い勝手の向上が図られています。
変更点の一覧はユーザーズガイド内の最新情報ページに記載されています。

■歌ってない場所で呼吸してる？

パフォーマンスに関する話ではありませんが、もうひとつ重要な改善点があるのでこれにも触れておきます。

CeVIO はピアノロール上でノートを置いていない場所で自動でブレスが入ったりしますが、大きな余白であっても少しノイズが出ており、綺麗なデータにしたい場合は手動でそこを削ぎ落とす必要がありました。
v3.2 ではノートのない小節が続いた場合に間の部分を自動的にミュートしてくれるようになったため、間奏部分やコーラスパートなど、長い休みがある場所を手動で消す必要がなくなりました。

以下の画像は1小節目と9小節目に8分音符で「ドレミファソ」を配置したプロジェクトファイルを v3.1.14.1 と v3.2.15.0 で書き出し、その結果を Wavosaur で縦方向に拡大表示して比較したものです。

v3.2 で書きだした側は余白部分に存在していたノイズがなくなっているのがわかります。
また、これは音量調整画面にも反映されているため、以下のように CeVIO 上でも確認できます。

ノイズがカットされた結果、音量のラインが下に消えている

■おわりに

生放送で中継もされているようなそこそこパブリックな場所である座談会で関係者を目の前にして「重い」とか言っちゃうのはなかなかに辛く当たっているなぁと自分でも感じていたものの、その重かった印象が覆るようなドラスティックな変更を、たった2ヶ月程度の間に行って頂いていたことをパブリックベータテストの開始によって知ることとなりました。
発言の場を提供して頂いたこと、そして改善のために尽力して頂いたことについて、エクシング小松様、石原様、ブイシンク加藤様、川出様、その他関係者の皆様に感謝の意を表すとともに、心より厚く御礼申し上げます。

で、別に自分のためだけにやってくれたわけでないにしても、ここまでやってもらっておいてベータテストに参加しないのでは不義理にも程があるし、ブイシンク加藤さんには~~「愛をとりもどせ」~~「愛をください ~~wow wow~~」とも言われてもいたので、今回は逆にやり過ぎなぐらいベータテストに参加しようと思い、他のことが手に付かない程度にはとても積極的にテストやレポートすることで愛を表現させてもらいました。
こうしてブログにどのような変更があったのかを簡単に紹介しているのもその一環ではありますが、それはそれとして v3.2 がいかに素晴らしいリリースであるかを少しでも伝えられたら幸いです。

今回の変更の影響によるバグや以前からあったバグの報告、改善の要望など、2週間程の短いベータテスト期間ながらほぼ毎日のように、多分10通ぐらい毎回そこそこの長さのレポートを送ったりしてました（送信者控えがなく記録も残していないので正確な数字は不明）。
正直仕事をしていた頃よりもよっぽど仕事をしてる気分が味わえたような、そんな2週間でした。

■おまけ

8月末までのうたスキミュージックポストのオープニングキャンペーン、募集要項を守って投稿することで抽選ではなく先着100名に CeVIO の Color Voice Series の中から一つ貰えるんですが、間違っている人を見かけるのでここにもツイートを再掲しておきます。まあ間違っている人はここ見てないとは思いますが。

https://t.co/1Jr2SFVy6D ↑ このキャンペーン、プレゼント対象のキャラクターと投稿可能なキャラクターは違うので注意。間違ってる人がチラホラ居る。 pic.twitter.com/4Puu6t4cYK
— おおぶ (@oovch) 2015, 7月 10

Color Voice Series は純粋に音としての面白さで音声合成界隈を見ている人なら興味深い代物のはずなんだけど、人気（にんき）がないというか、人気（ひとけ）がないみたいな感じで僕ちゃん寂ちい。使って。

■おまけ2

oov っぽくて惜しいってずっと思ってた（マジでどうでもいい）

CeVIO で歌わせる時に考えていること

2015-05-25T23:23:00.000+09:00

↑この画像に使った CCS ファイルは→こちらからDLできます

自分が CeVIO で歌わせる時に考えている内容を書きます。
歌わせ方のコツからミックス時の話までひと通り。

まあ一年後には自分でも全然違う手法になっているかも知れないものの、少なくともここ2年程度の間に培ったノウハウ的なものは大体吐き出すつもりなので、使えそうな部分があれば適当につまみ食いでもしてください。

なお、画像の下の小さい説明文のところにはしばしば mp3 へのリンクがあり、画像で解説している内容が視聴できるところがいくつかあります。説明と合わせて聞いてもらえると、より理解が深まるかもしれません。

ミックス時の話
1. 存在感の希薄なリバーブ
2. どう攻めるか
3. 実際にエフェクトをかけてみる
CeVIO を使う時の基本姿勢
1. 音量、パンは変更しない
2. 書き出す時はトラック単位
3. 全てのビブラートをピッチで手入力する時は標準のビブラートを無効にする
4. ピッチを描く時は必ずズーム状態で描く
5. データを入力する時はノート→TMG→PIT/VOLの順
6. CeVIO で作ったデータを VOCALOID や UTAU に持ち込むなら
7. まとめ
調声の話
1. VOCALOID を使ったことがある人へ
2. 歌わせる時は「本人に任せる」のが楽
3. スタッカートとブレスについて
4. 「yes」などの発音をそれっぽくするための母音の脱落記号と「_0」の話
5. 母音が綺麗に繋がらない時
6. 発音が気に入らない時
7. ピッチを描く
終わりに

■ 1. ミックス時の話

CeVIO 上でのアレコレの話の前に、ミックスの話です。
ぶっちゃけ CeVIO の場合細かく弄らなくてもミックスが良ければかなり聴けるデータになると思います。
なのでこのサンプルデータを元にして、処理例などを連々と書いていきます。

1-1. 存在感の希薄なリバーブ

まず自分の中の大前提として、CeVIO は音声合成ソフトウェアであり、元になった人が歌いそうな感じの音を想像して出力してくれるソフトです。これは恐らく喉から声を出すところまでの音をシミュレートしてくれます。

しかし現実世界において我々の耳に最終的に入ってくるのは喉から出たダイレクトな音ではなく部屋の反響なども含めた音なので、CeVIO が出力した音を直接聴くと（伝わらないかもしれませんが）物理モデリング音源の出力音をリバーブなしで聴いた時に特有の、嘘っぽい音になります。

なので自分が CeVIO のボーカルトラックをミックスする時は、ボーカルっぽいぼわーっとしたリバーブの前に、部屋っぽい薄いリバーブを先にかけるようにしています。

エフェクト前後の音を試聴する（※両方とも同じだけ元より音量を上げています）

これはフリープラグイン Voxengo OldSkoolVerb をセンドではなくインサートで入れた時の設定例です。
個人的には普段は（探さなくても最初からあるから） Cubase 付属のものを使っているんですが、Windows / Mac に対応していて今後も長らく配布してくれそうなベンダー、というところでここでは Voxengo のリバーブを選んでみました。

デフォルトから変更したのは赤枠で囲んだ TIME / WIDTH / REVERB GAIN の3つのみで、それぞれ最低 / 最高 / -18db に変更しています。
ヘッドホンなど細かい音が聴こえる環境じゃないとあまり聴こえないような薄いものです。
また、WIDTH を変えていることからもわかる通りステレオチャンネル上での設定を想定しています。

1-2. どう攻めるか

普段イコライザーやコンプレッサーを入れる時はさっきのリバーブの前、リバーブとかディレイを入れる場合はさっきのリバーブの後ろ、という感じで追加していくんですが、「実際のところその辺のエフェクトはどのぐらいどんな感じでかけるの？」というのは、誰もが気になるところだと思います。

例えば petit milady 恋はみるくてぃトラック5 を例に挙げますが、これはエフェクト処理済みのボーカルトラックが収録されたもので、もし作りたい曲調に近ければとても参考になると思います。
ちなみに余談ですが、このトラックを実際に買って聴くともっと高音もハッキリ聴こえるしマイクがヘッドホンの音漏れか何かを拾ったのかセリフ部分でオケが少し残っていたりと、なかなか面白いのでオススメです。

試聴で聴ける範囲を細かく見ていくと、基本的にはリバーブ、セリフに入る直前のフレーズはディレイ、セリフ部分には歌部分のリバーブはなし、とか多分そんな感じで場所によりかなり細かく調整されています。

しかしながらそれ以上に特徴的なのはやはりコーラスパートの多さで、いまどきの曲はコーラスパートが多い傾向にあると思うので、音が薄いのを解決するのはエフェクトではなくコーラスパート追加も手段として重要なこともある、ということは肝に銘じておく必要があると思います。

ということで、エフェクトをゴテゴテと盛って誤魔化す前に、まずはその辺を疑ってみてください。

1-3. 実際にエフェクトをかけてみる

コーラスパートの追加が重要なのはさておき、エフェクトの例を作ってみました。
（※これは今回説明のために改めて作ったもので、実際の楽曲に使われているものとは異なります）

エフェクト前後と伴奏付きの音を試聴する

今回はやはり無料で使える Guitar Rig 5 PLAYER でエフェクトを設定してみました。実際に使っているのは Guitar Rig 5 PRO ですが、PLAYER でも再現できる範囲で設定しています。
なお、Guitar Rig は名前にギターと入っているもののギター専用ではなく、実際にはギター以外の用途にも使える便利なエフェクター集で、無料版でもそれなりの種類のエフェクターが収録されているので便利です。

ここでは上で Voxengo OldSkoolVerb を使って説明した分も STUDIO REVERB で代用してみています。
個々の説明をしていく前に上記の設定がどんな感じの順番で適用されるか確認して下さい。

1-3-1. Gate

この部分の説明は CeVIO 3.2.17.3 がリリースされるより前に書いたものです。
CeVIO 3.2.17.3 ではノートのない小節が続く場合自動的にミュートされるようになったため、以前より神経質に削る必要はなくなりました。

まず枠外の一番上にある「Gate」です。
これはツマミで指定した音量以下の音はミュートしてくれるという、ノイズが多いギターにおいて特に役に立つ機能なのですが、CeVIO においても大変役に立ちます。
CeVIO ではメロディデータが存在していない部分でも常に微量にノイズが出続けているという謎の挙動があるのですが、このノイズは Gate を使うことでほぼ自動で切り落とすことができます。

緑咲香澄に3小節目でC4で「ドー」と歌ってもらった場合の書き出し例

画像は今回ミックス例に使ったデータとは違うのですが、緑咲香澄が歌っているデータを Wavosaur という Windows 専用の波形編集ソフトで出力時のノイズ部分を縦方向に拡大表示した時のものです。
上下ズームの影響で画面からはみ出す勢いの2つの大きな山がありますが、ひとつめはブレス、ふたつめは「ドー」とC4の高さで歌った時のものです。

波形表示エリアの左側にある目盛りに注目すると、真ん中が無音、そこから上下に離れるごとに -78db -72db -69db と書いてあります。
ノイズがある部分はおおよそ -72db より下の範囲で収まっているので、この場合 Gate の設定を -72db 以上に設定するとノイズを削ぎ落とすことができることになります。
ただし、みてわかるようにブレスも結構小さい音なので、あまり適当に設定するとノイズと一緒にブレスを巻き添えでそぎ落としてしまうので設定値には注意が必要です。

Guitar Rig 5 では Gate は初期設定で有効で、しかも設定値は -71db なのでこの場合何もしなくても勝手に消えそうです。歌いだしの前など目立つブレスが消えないできちんと残っているかとか、変なところでノイズが漏れてこないかチェックしましょう。
もし上手くいかない場合は消えてしまうブレスの音量を CeVIO 側で上げておくとか、ノイズを CeVIO 側で下げておくとか、Gate を使わずに手動で削るとか、色々やってみてください。

1-3-2. PRO-FILTER

一番左のツマミを 150Hz、一番右のツマミを HPF にして、緩やかに低音を削っています。
HPF はハイパスフィルター、ハイをパスするフィルターで、逆に言えばローカットフィルターです。
今回のサンプルでは一番最初の歌い出しがかなり低い音なので影響が強めに出ます。

1-3-3. TUBE COMPRESSOR

まず子音が潰れないよう ATTACK を 3.00 にして少し遅めにしました。
あとはこのコンプのデフォルト設定はかなり強く潰しているようなので、それを柔らかくするために RATIO を 9 : 1 に、THRESHOLD を -36db にしました。

1-3-4. PARAMETRIC EQUALIZER

声をもう少しキラキラさせるために4kと8k周辺を持ち上げました。
Q の設定が標準だと見えていないので EQ の右上にある ▲ をクリックして詳細設定を開きます。
左からそれぞれ 4019Hz / +3.4db / 0.30 と 8074Hz / +5.4Hz / 0.34 に設定しました。

1-3-5. STUDIO REVERB

ほぼ聴こえないレベルの方です。
WET / ROOMSIZE / BRIGHT をそれぞれ 20.3% / 2.66 / 最大に設定しています。
Voxengo OldSkoolVerb で設定した時よりも更にドライな設定です。

1-3-6. STUDIO REVERB / DELAY MAN

残響成分ですが、Tools にある Split を用い、2つに分離してかけてみました。
リバーブとディレイがお互いに干渉しないので両方かけても多少スッキリしています。
リバーブ側は ROOMSIZE と BRIGHT を上げて、ディレイ側は TIME を 233msec にしました。
ディレイはもう少し控えめでも良かったかもしれません。

1-3-7. まとめ

以上のような感じで一部 CeVIO に特化した話もあったものの、ミックス周りは通常のボーカルのミックスと大きく変わりません。実際のミックスでは更に曲の展開に合わせてトラックの音量をオートメーションで変えて起伏を作ったりしています。

ミックスの細かい部分に関しては曲ごとに変わる部分も大きいのでここに書かれたものを鵜呑みにしても上手くいかないことも多いと思いますが、取りあえず無料の Guitar Rig 5 PLAYER があるだけでもわりといい感じにできる、という感じでどうでしょうか。

■ 2. CeVIO を使う時の基本姿勢

自分が使う時に心掛けている話で、これらは自分の中ではほぼマストです。

2-1. 音量、パンは変更しない

せっかく各トラックに付いている音量調節やパン機能ですが、これらはあまり積極的には触りません。
最終的には DAW 側で設定するし、個人的には編集と書き出しを繰り返す場合に途中で変えて DAW 側でコンプの掛かり方が変わったりと余計なトラブルを生まないために後述するトラック単位の書き出しを使っているため、ここでの設定内容は最終的には DAW 側には一切持ち込まれません。

また、ツールメニューからオプションを開いたところにある「トラック設定」タブのベースボリューム設定も一切変えません。一度これを変えてしまうとマウスでは初期値に戻すのが難しいし、何となく CCS ファイルを開く環境によって音量バランスがぶっ壊れるんじゃないのかという気がするので変えないようにしています。ベースボリューム設定は将来的には廃止されるようです。

ゼロに戻すには設定ファイルを直接書き換えるか、一度端にくっつけてから矢印キーを160回分押せばいい

数値入力できない上に細かい値を設定させるツマミは基本的に悲しみを生みます。
なお Guitar Rig 5 も数値入力できませんが、こちらは Shift キーを押していると細かく設定できますし、ダブルクリックすると初期値に戻せるようになっているので悲しみは少なめです。
なお、CeVIO 3.2.17.3 以降ではボリュームやパンを Ctrl + クリックすることで初期値に戻すことができるようになりました。

2-2. 書き出す時はトラック単位

CeVIO 上では各トラックに対してエフェクトをかけたりできず機能としては不十分で、他のソフトでエフェクトをかける場合は複数のトラックがミックスされている場合処理しづらくなるため、ミックスダウン書き出しを使う理由が基本的にありません。
そのため、書き出しは基本的にこのメニューから WAV 書き出しを選んで使用します。

トラックのタイムライン上で右クリックすると出てくるメニュー

トラック単位で書き出しておけば例えばコーラスを修正して書き出し直す時もコーラスだけを書き出せばいいので必要最低限の負荷で書き出せることになり、長い目で見ると作業効率が上がります。
また、トラック単位での書き出しはベースボリュームの設定やトラック毎のボリューム設定、パン設定が影響しない上モノラルオーディオファイルとして書き出されるので、悲しみも無駄も少なくて済みます。

2-3. 全てのビブラートをピッチで手入力する時は標準のビブラートを無効にする

無効にチェックを付けると無効状態が有効になるメニュー

メニュー上に無効化できる項目があるので、これにチェックを付けることで無効にする機能を有効にできます。

ビブラートをピッチで描くこと自体はよくあることですが、その場合「ビブラートの振幅」をゼロにしておかないと自分がピッチで描いたものと干渉してしまい、本来イメージしていた高さで出力されないという想像に難くない問題が起きるので、ピッチで描く場合は始めから無効化しておきます。

これに関しては神無月Pさんが Twitter で書かれていたような（その1、その2）、ピッチの画面でビブラートの振幅が加算された状態で見えるようになると状況も変わるかも知れません。
（が、多分個人的には全て手描きしたい時はビブラートに人間味のあるムラを求めてるシーンだと思うので結局あまり使わないような気はする）

2-4. ピッチを描く時は必ずズーム状態で描く

CeVIO のピッチツールは大変センシティブで、あまり考えずにパパっと描くといい感じになりません。
なぜセンシティブなのかというのは非常に簡単な理由です。

VOCALOID で PBS=2 の時の CeVIO での範囲

そのままの拡大率でピッチを描いてしまうと精細なラインが要求されるシーンを画面上のわずか数ピクセルの中で表現しないといけないことになり、難易度が上がるというか無理に近い状況に陥ることになります。

そのため、作業時にはかなり拡大しておかなければ綺麗なデータが作れません。自分の拡大率の目安は縦方向が1オクターブ程度で、いつも同程度に拡大すればビブラートを描く時に同じ大きさで描けば同じ振幅のビブラートになり作業しやすいです。

自分が作業時に実際に使っている拡大率

2-5. データを入力する時はノート→TMG→PIT/VOLの順

基本的にピッチやボリュームはノートと TMG の情報を元にしているので、自分でピッチやボリュームを書き換えた後に改めてノートや TMG を触り直すとピッチやボリュームの部分が乱れるため実際のところこの辺は結構やり直しになります。

これは構造上仕方がないことなので、せめてもの抵抗ということでメロディの入力と TMG の編集で大体納得できるレベルまで編集してから PIT と VOL の調整を始めるようにしています。
そうすると並行作業するよりも幾分作業効率が良くなります。

2-6. CeVIO で作ったデータを VOCALOID や UTAU に持ち込むなら

メロディを DAW で作ってから持ち込んでいる場合は MIDI を各種ソフトに持ち込む感じになるのでそれでもいいですが、CeVIO で作ったデータから歌詞付き MIDI ファイルを作るためのツールを先日作りました。

http://oov.github.io/mxl2mid/
（Safari 以外の最新のブラウザでアクセスして下さい）

「MusicXML の書き出し」で出力したファイルを MIDI に変換できます

CeVIO と VOCALOID や UTAU とデュエットさせたい時とか、作業量を減らせると思うのでもし良ければ使ってみてください。
ちなみに CeVIO の 2015-05-22 のアップデートにより CeVIO 自身でもインポートできるようになりました。

2-7. まとめ

結局のところ CeVIO が持つ機能のいくつかを使わないことによって作業効率を上げています。
ミックス周りの機能が DAW の操作性に追いついていないなど仕方がなさそうな部分もあるものの、音量ツマミが -24db までしか下げられないために外部オーディオトラックの音量調整が上手くできないなど機構上の粗も目立ちます（ベースボリューム併用でもっと下げられるが、なぜそんな二度手間が必要なのか）。
適材適所という言葉もあるので、使いたい部分を上手く組み合わせて使うのがいいと思います。

■ 3. 調声の話

この辺も人によってやり方や考え方は様々だと思うので一例という感じでお読み下さい。

3-1. VOCALOID を使ったことがある人へ

ボーカルパートを作るという目的の上では最終的に目指すピッチの動きなどが似ることは多々ありますが、ソフトの使い方のお作法という意味では VOCALOID での経験が使えない場面も多々あります。

VOCALOID での経験は一旦色々忘れると楽になります。
新しく覚える必要がある要素は決して多くはありません。

3-2. 歌わせる時は「本人に任せる」のが楽

基本的に CeVIO は元になった人の歌い方を再現しようとする性質があり、つまりキャラクターによって声だけではなく音の高さの変化の速さや発音のタイミング、ビブラート具合など歌い方自体が異なります。

ピッチ変化の違い。ONE はアップテンポな曲、金咲小春はスローテンポな曲が歌いやすい

これらの特性は細部を細かく沢山変えることによってある程度塗り替えることはできるものの、その上で滑らかに歌わせるのはやはりなかなか難しいです。
そのため、そのキャラクターが得意な感じの歌を本人任せで歌ってもらい、気になるところだけ注文を付ける感じで直していくのがクオリティも作業量もいい感じで進められると思います。

3-3. スタッカートとブレスについて

「かもめの水兵さん」の「かもめ」の部分をスタッカートでリズム良く歌わせてみましょう。

打ち込み比べてみたものを試聴する

CeVIO は音符がない場所にある程度の余裕があればそこでブレスを入れることがあります。
場合によりこのようなシーンでも細かくブレスが入ることがあり、そういう時は音符自体は繋げたままで歌詞として「っ」を入力することによって「cl」という無音部分を意図的に作ることができます。
（むしろ、ブレスが入って欲しくない場所は全て「っ」で入力したほうがいいと思う）

また逆に、意図的にブレスを入れることもできます。

右クリックメニューから開けるプロパティにブレスの項目がある

このようにすると、音符が繋がっていてもブレス「br」が入ります。

こちらのブレスは短い時間で一気に吸い込む動きが向いていることが多いようなので、個人的にはAメロとBメロの間のように時間に余裕がある場合は休符によるブレス、忙しいフレーズの途中での息継ぎにはプロパティからのブレスのような形で使い分けをしています。

3-4. 「yes」などの発音をそれっぽくするための母音の脱落記号と「_0」の話

「yes」を発音させる時は「いぇす」というよりは「いぇｓ」ぐらいで、「す」は子音から母音までキッチリ発音しないほうがそれっぽく聴こえます。
これを実現させるために CeVIO には「母音の脱落記号」というものがあり、以下のようにすると使えます。

比べてみたものを試聴

単純に全角のアポストロフィー「’」を後ろに付けるだけです。

なおこれは本当に「desu」を「des」にするように本当に母音を脱落させるだけで、VOCALOID で無声音のために「_0」を付与するものとは異なります。
寒い時に手を温めるために息をかける「はー」とか、熱いものを食べる時の「ふー」とかの喉の振動が伴わないものが無声音です。
テレビの寝起きドッキリで最初に言うようなヒソヒソ声での「おはようございます」とか、母音を含む言葉も無声音のままで発音できます。

3-5. 母音が綺麗に繋がらない時

「青い家」のような母音が連続する歌詞の時、歌い方がぎこちない感じになってしまうことがあります。
このような時は「スラー」を使うと改善する可能性があります。

比べてみたものを試聴

スラーは右クリックメニューから開ける音符のプロパティで設定することができます。
この場合だと「あ」でスラーの開始を、「え」でスラーの終了を指定します。
CeVIO 3.2.17.3 以降ではスラーにしたい範囲のノートを選択して「R」ボタンを押すことでもスラーを設定できます。

ただしこれは上手くいった場合で、キャラクターによってはスラーでは改善しないことがあります。
その場合はこの動画のように TMG を調整することで、滑らかに歌えるようになるかも知れません。

3-6. 発音が気に入らない時

歌ってもらう内容によってはなんかいい感じの発音にならない時もあります。
以下は黄咲愛里に「ミカヅキモ」と歌ってもらった例です。

そのままだと「も」が「もら」に聞こえるので直した例。比べてみたものを試聴

パッと見ではゴチャゴチャしていて取っ付きにくい TMG 画面ですが、実際に使うのは簡単で、下のアルファベットが書いてある部分の線を引っ張って母音や子音の位置を移動させたり、その上の線を引っ張って発音する上で気に入らない区間を縮めたりいいところを伸ばしたりして使います。

今回の例では「あ」に近い発音の目立つ区間を潰すことで歌い方を抑えこんでいます。
なお、このように TMG を変更すると場合によってはピッチがずれて音痴になったりもするので、改めて直してあげないといけないこともあります。

3-7. ピッチを描く

これは CeVIO に限った話ではないのでここであまり真面目に書く必要もなさそうですが、よくあるパターンを簡単にまとめてみることにします。
音量の変化も合わせて描くとより効果的なパターンなどもありますが、ここではピッチのみの変化で紹介します。

3-7-1. 上から入る

癖のある歌い方をさせたい時に。試聴

上からでも下からでもアクセント強めの印象にしやすいです。
例えばオコメライスで「タカハシもハマってるんだよ」のところは印象的にする目的で上に抜けるのと合わせて過剰に使っています。

3-7-2. 上に抜ける

ヒーカップ唱法的な奴。かわいい表現としても。試聴

B'z の稲葉さんの歌い方で頻繁に見られる形なので愛のままにわがままに僕は君だけを傷つけないをカバーした時には多用しました。
下に抜ける形は力を抜いていく感じの表現として使えます。

3-7-3. 前にずらす

多分バラードとかでは特に頻繁に出てくるパターン。試聴

よく使います。上手く歌ってる風になるか調子に乗ってる風になるか使い方次第で変わりそうです。

3-7-4. 後ろにずらす

これもバラードとかで頻繁に出てくるパターン。試聴

これも同じ感じです。

3-7-5. 優しく

スローテンポな曲とか、柔らかい歌い方をさせたい時。試聴

緩やかに目標のピッチに移行するイメージです。
これは例えば「レ」の頭を下から持ち上げていますが、「ド」の後ろを持ち上げる手もあります（上から下に向かう場合はそのほうが安定しやすいです）。
ただしこれはミスると音痴に感じやすいので注意も必要です。

3-7-6. 強く

ちょっと上に行きすぎる感じで力みを表現。試聴

アタック感強めな感じをピッチで演出しています。2013年にささら音頭を作った時、当時は CeVIO にピッチ編集機能が無かったので VocalShifter を使っているものの、同じ手法を用いて表現しています。

3-7-7. まとめ

ピッチ周りは本当に色々な表現があるし、実際に歌っているものを参考にすると得られるものがたくさんあるので色々な曲を聴いてみるのが一番いいと思います。
得られたバリエーションは音声合成に留まらず自分で歌う時でさえ活用でき、とても有用です。

■ 4. 終わりに

CeVIO 界隈はまだまだ発展途上にあり、例えば pixiv に投稿されるイラストなども決して多くはないのですが、2013年にりちかさんが投稿されている【動画作成にご利用ください】「CeVIO支援中」タグというものもありまして、イラストを投稿される際には差し支えなければこのタグを付けて頂けると、楽曲用の動画製作時に利用させて頂く選択肢が増えるので大変嬉しく思います。
（ところで piapro はここに CeVIO キャラの名前がなく投稿は厳密には NG のような気がしているので、CeVIO 関連は自分のアカウントからは登録しないようにしています）

また、Color Voice Series を使ってニコニコ動画に投稿する際は nc107951 を親作品に登録してくださいとの事で、登録するだけの簡単なお仕事なのでこちらも是非登録していくと良いと思います。

あと、

CeVIOプロジェクトではさとうささら.comに掲載させていただける作品を常に募集しております。掲載ＯＫな方は、ニコニコ動画やpixiv等で「ささら.com_掲載OK」のタグをつけて投稿して頂けると嬉しいですm(_ _)m
— CeVIOプロジェクトスタッフ公式 (@CeVIO_st) 2015, 5月 26

とのことですので、こちらも合わせてご利用下さい。
http://satosasara.com/ のコンテンツ欄に載ったりします。

CeVIO における音声やキャラクターの利用可能な範囲については無料版が出た当時色々言われていたものの現在はかなりオープンになっており、非商用でも商用でも使える範囲について細かく記載されているので、是非確認してみるのをオススメします（ONE や Color Voice Series など他社キャラクターのライセンスは各社の HP 上にあるのでそちらも確認して下さい）。
不明点がある場合も質問すればきちんと答えてくれると思いますので Twitter とかで「わからない…」とか呟くぐらいなら実際に聞いてみるといいと思います。

個人的にも CeVIO 界隈にはもっと盛り上がって欲しいと思っていて、そのために自分が持てる情報は積極的に公開していこうという考えのもと、最近は CCS ファイルの公開やこのブログの記事を書いたりなどしております。
自分だけがこういう情報を持っていても少し優越感に浸れるぐらいしか利点がなくて全然面白くないし、もっと他の人にも CeVIO を使ってもらい面白い何かを作って欲しいな、という心境です。

どんどんお願いします。どんどん。

2015-05-26 - 「ささら.com_掲載OK」に関する記述を追加
2015-05-28 - タイトルっぽい画像を追加
2015-05-28 - CeVIO 3.2.17.3 のリリースに伴って変わった部分について追記

Go で作ったプログラムを GopherJS を使ってブラウザで動かした話

2015-04-10T04:35:00.000+09:00

先日 CeVIO Creative Studio で出力した MusicXML を MIDI ファイルに変換するプログラムを作った。

これは Go 言語を使って作ったのだが、頻繁に使うわけでもないツールをダウンロードして使うのは面倒だし、バージョンアップなどを考えるとブラウザから使えたほうが手軽かもしれないと思ったので、プログラムを更に GopherJS でブラウザ単体で動くようにしてみた。
サーバサイドでは一切何もやらないため、GitHub Pages に置くこともできる。

GopherJS は C 言語に対する Emscripten のようなもので、Go 言語で書いたプログラムを JavaScript にコンパイルすることができる。
どの程度そのままで動くのかはここに対応表があり、例えばローカルファイルを触るような操作は node.js でのみ対応だったり、cgo や syscall のように Go 言語で書かれていない部分が関わるものは動かなかったりもする。
Goroutine にも対応しているらしいのだが、今回は使用しなかったため特に触れない。

今回のプログラムは元々はコマンドラインで引数としてファイルを渡すとそれを読み込み、ファイルを作成して終了するといった動作をするもの。
先述の通りローカルファイルへのアクセスはブラウザ上では難しいため、その部分は入出力共に ArrayBuffer で行うことにした。

以下、ここだけ掴んでおけばファイルを受け取ってファイルを吐くツール相当のものが作れるメモ。

1. Go 言語で書いた処理をJavaScript 側から呼び出すには

今回のイメージとしては、jQuery などと同じようにライブラリとして Go 言語で書いた処理を読み込んでおき、必要なところで JavaScript から呼び出すような使い方をしたい。

そのためにはこの辺を参考にするといい。

js.Global.Set を使って登録すると、JavaScript からその名前でアクセスできるようになる。
自分のプログラムではオブジェクトである必要すらなかったので、map ではなく直接関数を登録した。

2. JavaScript から Go 言語にバイナリデータを渡す

やり方は色々あるかも知れないが、先述の通り ArrayBuffer で行うことにしたので、JavaScript から以下のような感じでファイルを <input type="file" id="inputfile"> から読み込むような処理を書いた。

 var file = document.getElementById('inputfile').files[0];
 var r = new FileReader();
 r.onload=function(e){
  YourGoFunc(r.result);
 };
 r.readAsArrayBuffer(file);

これで Go 言語側に第一引数として ArrayBuffer が渡されてくる。
渡されてきたデータはこのコードで xhr.Get("response") を []byte に変換しているのと全く同じ方法で、[]byte に変換できる。

3. Go 言語から JavaScript にバイナリデータを渡す

Go 言語からは js.NewArrayBuffer を使えば []byte から簡単に ArrayBuffer に変換できる。
今回のツールではその ArrayBuffer を元に Blob を作成し、それを FileSaver.js で保存させるようにした。
Safari とかいうブラウザではちゃんとダウンロードできない問題があるらしい。

まとめ

ファイル関連の処理を差し替えた以外には何もしなくても動かすことができた。
Go 言語を使っている場合、データの入出力には io.Reader や io.Writer を使うのが定石のようなものなので、変にファイルに依存せずしっかりやっておけば大変持ち込みやすい。

実際の処理では Shift_JIS の XML を UTF-8 に変換しながら読み込み、MIDI ファイルの出力時には改めて Shift_JIS に変換して保存しているが、XML の読み込みは標準ライブラリがあり、文字コード変換には golang.org/x/text/encoding という準標準ライブラリもあり、いずれも大変完成度が高く Pure Go で書かれており外部ファイルにも依存していないため、何の問題もなく持ち込めたのが良かった。

charset.NewReaderLabel を使用すると XML 読み込み時に必要なことを全部やってくれて全く手間がかからないため今回はこれを利用したが、Big5 など今のところは必要ない文字コード変換周りの処理も読み込まれてしまうので、多少オーバーヘッドはありそうだ。

今回のプログラムは Windows 64bit 環境で go build すると 3.78MB になるが、gopherjs build -m すると js 2.39MB + js.map 68KB と大きさもなかなか健闘している感じになり、js ファイルを更に gzip 圧縮すると 463KB まで縮んだ。
ブラウザからアクセスした場合に転送される容量としては小さくはないが、利便性を考えると個人的には許容範囲内に感じた。

使いはじめるための準備も、Go 言語利用者なら誰でも知っている go get -u github.com/gopherjs/gopherjs だけで良く、簡単で素晴らしい。
今後も機会があれば積極的に利用していきたい。

Go言語で E-MU Proteus Pack for Kontakt 専用リネーマーを作った

2015-02-12T15:11:00.000+09:00

わりとただの日記。

以前 E-MU 1616M と Emulator X のバンドルを買ったことがあって、E-MU 1616M は半年前までは使っていたし Emulator X も古臭い音だけど個性的でわりと好きだった。
しかし E-MU 1616M 用のドライバ最終リリースが Windows7 用のベータ版で止まっていたり、64bit 対応した Emulator X3 は日本で出ていなかったり、ここ数年は色々な面で危険な匂いが漂っていた。

去年の後半、マシンを新調するついでにサウンドカードはこのグラフを見ながら懐事情と相談して Focusrite Saffire PRO 14 を FireWire-Thunderbolt 変換ケーブルを経由して Thunderbolt 接続で使うように変えた。
そのグラフを見る限り RME は異常だけど基本的には PCIe > FireWire > USB の構図で、FireWire より更に PCIe に近いであろう Thunderbolt 環境があると将来的にも安泰かもしれない、ということもあって Windows で Thunderbolt 接続することを前提に ThunderboltEX II が使えるマザーボードでマシンを組んだりした。
（だから経路としては現状 Saffire PRO 14 -> FireWire6pin↔9pin 変換 -> Apple Thunderbolt - FireWireアダプタ -> ThunderboltEX II -> マザボ、とアホみたいに遠い）

その結果 Saffire PRO 14 は大変好調で文句ない環境になったのだが、当然 Emulator X の代わりは手元にない。
Emulator X といえば Proteus サウンド、そこで代用品として Digital Sound Factory の E-MU Proteus Pack の Kontakt 版を買うことにした。Proteus 2000 の他に Virtuoso と Mo' Phatt と Planet Earth と Vintage Pro と Xtreme Lead-1 がついて $99 だった（時期によってはセールで$69とかになるらしい）。
実際のところはまあぶっちゃけ買わなくても良かった気もするんだけど。
今となっては小さい波形容量の PCM 音源の音って独特で好きなもので。

で、実際に手に入れてみるとファイル構造がこんな感じになっていて、実機上で表示されていたと思われる 'kb1' のようなカテゴリ名がなく、プリセットの順番もグチャグチャになっていた。

多分 Emulator X の時もこの辺適当だった気がするしこんなもんかな、とは思ったものの、このままだと実際に使う時音色を探すのに苦労する。
そのため実機の順番で並ぶようにファイル名を変えたいのだが、全部で3000個近いファイル数があり、手作業で変えていくのはちょっと面倒臭い。

というわけで、これをある程度少ない手数でリネームするために、専用のツールを作ろうと思った。
ここまでが前置き。

1. 本来のプリセットの順番やカテゴリ名をデータ化する

まずこれをデータにしないと始まらない。
ハード音源のマニュアルは後ろのほうにプリセット一覧があると思ったので少し探してみたところ、Proteus 2000 のマニュアルがアーカイブされていた。

この一覧は簡素なリストなので、PDF 版の該当部分をコピーするだけでかなり綺麗な形になった。

0. kb1:DynamicGrand
1. kb4:Yo My Dynos
2. orc:Orchestral
3. gtr:Grusty
4. bs1:A Ku Stq
5. kb3:Rock'in B
.
.
.

これを、プログラムから扱いやすいように CSV フォーマットに変換する。
以下の様な正規表現で変換した（本当はサクラエディタ上でやった）。

$ cat bank0.txt | sed -e "s/\([0-9]\+\)\. \(...\):\(.\+\)/\1,\2,\3/g" > bank0.csv

これだけでわりと上手くいったので、この調子で Proteus 2000 のバンク8個と、Mo' Phatt / Planet Earth / Vintage Pro / Xtreme Lead のバンク4個ずつ、合計 24*128=3072 個分をデータ化した。

ちなみに Xtreme Lead の Bank 2 に「4. bpm:"Carpe Diem"」というダブルクォートが入ったものがあったり、Planet Earth の Bank 2 に「60. pr1:BD,Tm,Sn Set」というカンマを含んだものがあったりして若干罠がある。

ともあれ、いくつかの修正を経て Virtuoso 以外のデータ化がサクッと完了した。
Virtuoso だけはファイル名と実機上のパッチ名が目視でわかるレベルで差が大きく、かつファイル名から音が大体想像つくネーミングになっているので今回の変換処理の対象からは除外することにした。

2. Kontakt 用 nki ファイルとパッチの対応付けをどうやるか考える

実機上のパッチ名と Kontakt 用ファイル名が 100% 一致しているなら非常に簡単に済むのだが、Proteus 2000 の Bank 0 の一番最初の「DynamicGrand」がそもそも「Dynamic Grand.nki」とスペースが入ったファイル名になっており、完全に一致していることは期待できそうにない。

とはいえ似た名前にはなっているようなので、今回はレーベンシュタイン距離が近いものを候補として挙げる方向で作業を進めることにした。

また、元々のパッチ名にはファイル名として使用できない事が多いダブルクォートやスラッシュなどを含んでいるものが存在しているので、レーベンシュタイン距離を求める前にパッチ側の記号はアンダースコアに置換しておくことにする。

3. リネームプログラムを作る

ここで説明した内容に合わせてプログラムを作ると、実機上パッチ名と実際のファイル名から拡張子を取り除いたもので完全一致しているファイルの数が出せる。
完全一致した数は2663件、つまり409件が完全一致しなかった。

エラー率としては13%程度なのでそんなに悪くないが、もう少し改善したい。
ここからは泥臭い戦いを繰り広げていく。

4. 検出率の改善

「DynamicGrand」の例のように完全に一致していないが正解しているパターン、Proteus 2000 の Bank 3 「84. str:Section」「125. brs:Section」のようにパッチ名が被っていて誤検出してしまうパターンなど、失敗のパターンはいくつかあるようだ。

まずは完全一致していないが正解しているパターンを成功として扱えるようにしていきたい。
名前が惜しいケースでは以下の様なものがあった。

単語の間にスペースが入っているもの
記号が「_」に変換ではなく取り除かれているもの
「Drms」が「Drums」になるなど短縮形が戻されているもの
実機のパッチ名の後ろの「 w」が省略されているもの（パンが左右に振られていたパッチ？）
実機のパッチ名の後ろの「 mono」が省略されているもの（同時発音数が1だったパッチ？）
実機のパッチ名の後ろの「 MW」が省略されているもの（モジュレーションホイールで特殊効果があったパッチ？）

上記のパターンの中で、最後の3つは簡単に機械的な対応できそうだ。

実機上のパッチ名が「Pizz&Sct MW」のように「 w」「 mono」「 MW」で終わる場合、それを外した名前で完全一致するものがある場合はそれを採用するように変えてみることにする。

この修正によって71件が成功として扱われるようになった。一部「w」や「MW」の前にスペースがないパッチもあり、現状これらは漏れているがひとまずスルーしておく。

短縮形が戻されているものについても対応したいが、これらはスペースの有無も関係しており、両方を同時に対応しないと作業量の割に成功率があまり上がらなそうだった。

そのためこれに対しては、実機上のパッチ名の短縮形の単語を長いものに展開を試みる処理を加え、更に nki ファイルの名前からスペースや記号を取り除いた名前で比較するようにし、これによって完全一致するようになったものを成功として扱うようにする。

この修正によって更に111件が成功として扱われるようになった。

細かい処理を変えることでここの件数もまだ少し増やすことができると思うが、ひとまず保留とする。

5. 最後の悪あがき

一定のルールに従って修正できそうなものはある程度丸め込むことができた。

まだ残っているものは法則性が薄いか、正しいかどうかがすぐに判断できないものが多い。

ここからはリネーム対象にならないまま残った nki ファイルのリストと対象ファイルが見つけられなかったパッチのリストを見比べ、手作業で対応付けを行っていくことにする。

そのため、対応するパッチが見つからないまま余ったファイル一覧を見ながら、目視で正しい変換をどうかを「認定」あるいは間違っている場合は手動で正しいものを「指定」することにする。

しかし作業を始めてみるとこれがなかなかつらい。

0-127 までの128種類あるはずなのにファイルが 127 個しかないディレクトリがあったり、他のバンクに探している音色用のファイルがあるように見えるものなど、どう対応していいのか微妙なものが少なくない。
何より、実機での音がわからないので本当に正しいのか確証が持てない。

結局100個程度手動で対応したが、80個以上の分類不能なままのファイルが残った。
最後に手作業で割り当てた分が全部正しいと仮定すればここまでで300個近くが成功になっていて、10% 近く改善できたので今回はこれで我慢しようと思う。

今回作ったプログラムはこちら。

http://github.com/oov/proteus-pack-renamer
多分使う人はほとんどいないと思う。

6. おまけ：全てのリバーブを外したい

なんかしばしばイマイチなリバーブが深めにデフォルトで入ったりしているので、全部切ってしまいたい。
全ての nki ファイルを書き換える必要があるので、これも nki ファイルの中身を解析して、リバーブをなしに差し替えるツールを……作るのは辛いので、ここは AutoIt でクリアすることにする。

Local $sPath = "T:\EMU_Proteus_Pack_Kontakt\Proteus 2000\Proteus 2000 Bank 0\"
Local $hWnd = WinWait("[TITLE:Kontakt 5; REGEXPCLASS:NINormalWindow.*]")

ReverbBypassDir($hWnd, $sPath & "*.nki")

Func ReverbBypassDir($hWnd, $pattern)
   Local $h = FileFindFirstFile($pattern)
   If $h = -1 Then
      Return False
   EndIf

   Local $s = "", $iResult = 0
   While 1
      $s = FileFindNextFile($h)
      If @error Then ExitLoop
   ReverbBypass($hWnd, $sPath & $s)
   WEnd
   FileClose($h)
EndFunc

Func ReverbBypass($hWnd, $sPath)
   WinActivate($hWnd)

   ; Open an instrument
   ControlClick($hWnd, "", "", "left", 1, 315, 23)
   ControlClick($hWnd, "", "", "left", 1, 315, 93)
   Local $hOPWnd = WinWait("[CLASS:#32770]")
   ControlSetText($hOPWnd, "", "[CLASS:Edit; INSTANCE:1]", $sPath)
   Send("!O")
   Sleep(1500)

   ; Select the tab "Proteus 2000"
   ControlClick($hWnd, "", "", "left", 1, 60, 303)
   Sleep(200)

   ; Select the FX Type <<Bypass>>
   ControlClick($hWnd, "", "", "left", 1, 376, 188)
   Sleep(200)
   ControlClick($hWnd, "", "", "left", 1, 376, 209)
   Sleep(200)

   ; Save and close
   ControlClick($hWnd, "", "", "left", 1, 632, 97)
   Sleep(200)
   Send("!Y")
EndFunc

処理内容はかなり簡単で、$sPath に指定されたディレクトリ内にある *.nki ファイルを起動済みの Kontakt 5 で開いて（Files メニューをクリック → Load... をクリック → 入力欄にファイルへのフルパスを指定 → Alt+O）、FX Type を選択しなおして閉じる。
閉じる時に保存するか聞かれるので、そこで「はい」と答えるだけの単純なスクリプト。
本当は Proteus 2000 タブを選択する処理も必要ないはずだったのだが、Proteus 2000 バンク 0 「L.V.'s Worm.nki」のように初期状態で開いているタブが異なっている音色が一部あったので、タブを選ぶ処理も加えた。
128個処理するのに大体400秒程度なので、そんなに時間も掛からずほぼ放置で全てのパッチの設定を変えることができた。
Proteus 2000 以外も画面上の配置は変わらないのでこのスクリプトはそのまま流用できた。

また、この処理中、他にも nki ファイル側で問題があるものが見つかった。

Proteus 2000 バンク 3「Huge Brass.nki」はサンプルファイルの参照先が間違った場所のままリリースされている
（ただし本来の場所にファイル自体はあるので修正すれば問題なく使える）
Virtuoso の Orchestral Winds, Brass, & Percussion の Timpani.nki は対応するサンプルファイルの一部が存在しない

ティンパニの問題は少し気になるけど、この音源パック自体何年も前からあるはずだし「まあいいか」レベルで誰かが見つけても放置されてるのかなあ…。

更におまけ: Go言語に似たパッチ名があった。リネームしたおかげで「bas」でベースだとわかる。

転送サービスを使って Gopher 君を買った話

2014-11-24T15:18:00.000+09:00

個人輸入・転送サービスのスピアネットというサービスを利用して、Canada/US の Google Merchandise Store から Gopher 君のピンクとパープルを買った話。

Go 言語のマスコットである Gopher 君は元々はブルーの一種類だったのだが、GopherCon の時にピンクとパープルが増えた。
以前ブルーの Gopher 君を購入した時は Squishable で注文し、このショップは日本への配送も可能なため転送サービスを利用しなくても手に入れることができたのだが、ピンクとパープルに関してはイベント類に全く参加せずに家で細々とGo言語と戯れているだけの自分が手に入れる方法がわからず指をくわえていた。

ところが先日 Canada/US 向けの Google Merchandise Store で販売が開始されているのを発見した。

ブルー / パープル / ピンク

日本へ直接配送は出来なかったので、初めて転送サービスを使って購入することにした。
購入から荷物の到着までは非常にスムースに進めて頂いたのだが、自分へのメモという意味も含めて全体的な流れとトータルで掛かった費用を簡単にまとめることにする。

なお、これは2014年11月時点での情報なので参考にする場合は注意されたし。

全体の流れ

まず、スピアネットでアカウントを新規作成。

↓

スピアネットの荷物配送先に向けて、Google Merchandise Store で商品を注文。
（ピンクx2 $35.40 + パープルx2 $35.40 + 送料 $6.50 = $77.3）
配送先住所には部屋番号のようにスピアネットのアカウント番号を含めることになるので、必ずスピアネットのアカウントを先に作成する必要がある。

↓

翌営業日辺りに Google から送られてくる発送通知メールに書かれている配送のトラッキングナンバーを使って、スピアネットの管理画面から「転送依頼作成」を行う。
購入先のサイト名「Google Merchandise Store」と送料以外の合計金額、そして商品名１つずつと、1個辺りの単価と個数を入力して依頼する。

よく見ればわかることだったのだが、この時自分は1個辺りの単価を入力するところで間違えて2個合わせた金額を入力してしまっていた。この入力時点では全く間違いに気付いておらず、後々スピアネットの方に荷物に関するメッセージとしてお知らせして頂いた時に初めて知り、お手を煩わせてしまうことになってしまった。すみませんでした。

↓

スピアネットの受取センターへ荷物が届くのを待つ。
最初は配達予定日が4日後ぐらいだったのだが、FedEx の追跡をこまめに見ていると少しずつ予定日が後ろにずらされ、最終的には1週間後に目的地に辿り着いた。
この辺は Google Merchandise Store での購入時の配送オプションによって変わるのかも。

↓

その後程なくして、スピアネットから到着のお知らせと上記の入力間違いに対する訂正を行った旨がメールで届いた。今回の注文では特に一緒に送ってほしい別の荷物などはなかったため、すぐに発送準備に移行された。

↓

6時間後ぐらいにスピアネットから配送準備が整った旨の連絡と、料金の連絡があった。
（送料 $25.00 + 転送手数料 $9.00 = $34.00）

PayPal 経由ですぐに料金を支払うと、翌日（決済完了後の翌営業日）にヤマト運輸で発送された。

↓

ここからは4日程掛かって手元まで届いた。
クロネコメンバーズ会員なら荷物が近くまでくると受け取り時間帯指定もできるようだった。
（※なおクロネコメンバーズ会員カードにはあの猫の絵が入っていてかわいい）

まとめ

費用
　(ピンクx2 $35.40 + パープルx2 $35.40 + 送料 $6.50) + (送料 $25.00 + 転送手数料 $9.00) = $111.3
　最近は円安なので日本円にすると少し高めになり、支払った合計金額は13301円

所要時間
　注文から受け取りまで13日

所感
　「転送サービス面倒そう」と思っていたが、管理画面は日本語だし説明は細かいし良かった。
　また今回は自分の入力ミス以外のトラブルは特になかったこともあって、進行はとてもスムースだった。

2011年にブルーを購入した時は送料手数料で $75 掛かった代わりに1週間でクリスマス直前という超忙しそうな時期に届いたけど、今回はそれに比べると少し安くなり、代わりに少し届くまで長くなった感じだった。
（ただしスピアネットが関わっているところは全てを迅速に進めてくれている）
（あと、ドルベースでは安くなっているけどレートの関係で支払った額は今回のほうが高い）

Gopher 君の完成度については見ての通りで、個体差がゆるふわな奴である。ういやつ。ういやつ。
注文したあとに知ったのだが、Gopher 君のメッセンジャーバッグも売られていて、それもちょっと欲しかった。

---

あと1週間ほどで runtime のほとんどが Go 言語実装に置き換わる Go 1.4 がリリースされ、Go 1.5 では runtime が完全移行、そしていよいよ C コンパイラが削除されるらしい（cgo は無関係）。
セルフホスティングに向けて速いペースで着実に作業が進んでるし、Android への対応や何度目かの darwin/arm 対応作業も行われているし、LLVM の Go バインディングがマージされたりなど個人的に面白いニュースには事欠かない感じで、活発な活動が続いているのがとても嬉しい。
これからも楽しみだ。

Go言語で画像縮小できるライブラリのベンチマーク

2014-08-14T09:02:00.000+09:00

Go言語で画像縮小できるライブラリのベンチマークなどを取ろうと思って少し書いてみた。
https://github.com/oov/resize-test

この辺りのライブラリは画像の縮小ができるので、どれも func(src image.Image, w int, h int) (image.Image, error) で呼べるよう整理して、それを元にしたベンチマークのジェネレータとかサンプル画像出力プログラムを作った。

テスト環境は Intel Atom D510 で、物理コア数2でハイパースレッディング対応。遅い。

使用したGo言語環境は go1.3.1 の linux/amd64 版。

これはベンチマーク結果を Google ドキュメントでグラフ化したもの。画像を別窓で開く

amd64 用に最適化されている rez はかなり速くて、速度と品質のバランスを見て unsafe なコードが使える環境の場合は rez の Bicubic や Lanczos が良さそうに思える。

unsafe が使えない場合は同じレベルの速度で動くのは品質が NearestNeighbor 相当のものしかなく、それを避けると nfnt/resize の Bilinear、そして nfnt/resize の他のアルゴリズムや gift / imaging の Box という感じで続いていく。

nfnt/resize は全体的にパフォーマンスがいいが、出力品質と GOMAXPROCS=1 の時のパフォーマンスなどを見ると gift や imaging の Box が今回のサンプル画像においてはかなり健闘していながら速度もなかなか速いので、個人的に使いたいのはこれかなぁという感じがした。

テスト環境の物理コア数と一致する GOMAXPROCS=2 の時は大体のライブラリで速度が2倍近くなり、GOMAXPROCS=4 ではそこまで伸びないのもあるがそこそこ速くなり納得できる結果に。

一方で moustachio/resize はおそらく元々 GAE 用のサンプルということもあって並列化されていないため GOMAXPROCS に関わらず速度は変わらず、graphics-go/graphics もまた変わらなかった。

これは余談だけど moustachio/resize のルーチンはGo言語にまだこれといった画像縮小ライブラリが無かった時代に重宝されていたように思うが、使いやすい場所にライブラリが配置されていなかったこともあり fork ではなくコピーされたファイルがいくつかのリポジトリにあり紛らわしいのが探すとき地味にだるい。

そのうち go.image/draw が追加されそうなので、これが追加されてコミットが落ち着いた頃にでもベンチマークに追加しようと思う。

個人的なまとめ

rez 良い
gift や imaging の Box がその次ぐらいに好み
nfnt/resize も良い
選べるぐらいに選択肢が増えて嬉しい
ImageMagick とか cgo 経由するようなのとかは面倒なので試してない

2014-08-16 追記

画像を別窓で開く

大変見づらくなってしまっているが、需要がありそうな ImageMagick(convert コマンド) もベンチマークに追加するために色々と変更した。

前回のプログラムでは

画像のデコード
画像の縮小
画像のエンコード

上記の3つのステップのうち、2の段階のみを純粋に計測していた。

ImageMagick が加わる場合これまでとは違い画像をデコード／エンコードする処理自体も使用されるコードが異なる上これらを切り離して計測するのは難しく需要も薄いと思われるので、公平な結果を簡単に出力できる

画像のデコード
画像の縮小
画像のエンコード

この3つのステップ全てをまとめたベンチマークを追加し、ベンチマークのメソッド名を

縮小処理のみを計測しているものを BenchmarkScaler*
一連の流れをまとめて計測したものを BenchmarkFlow*

という名前で統一した。

計測用のマシンに前回使用した Intel Atom D510 go1.3.1 linux/amd64 の環境を今回使うとベンチマーク完了まで20分強の時間を要してしまい辛くなってきたので、環境を変えて Intel Core i7 4790K go1.3.1 windows/amd64 で計測した。この CPU は物理コア数4でハイパースレッディング対応なので GOMAXPROCS=8 の結果も追加している。
また、今回使用した ImageMagick は chocolatey 経由でインストールしたもの。

早速 BenchmarkFlow* 辺りのスコアを見ていくと、前回速かったニアレストネイバー系や rez のパフォーマンスが BenchmarkScaler* に比べるとかなり落ち込んでいる。これはテストに使っている test.jpg が 4912x3264 で 4.68MB ぐらいある少し大きいファイルであることも原因の一端を担っていると思う（一端どころではない気もする）。

ともかく、この増えた分を差し引けば BenchmarkScaler* の方と関係性はほとんど変わらないので、後は ImageMagick との比較になる。今回 ImageMagick の縮小方法は -define ありとなしの2種類を定義していて、-define ありの方は JPEG 画像で縮小後のサイズが予め判明している場合に処理速度が速くなる。

フィルタ指定を特にしていない時 ImageMagick は Lanczos のようなので、それも踏まえて見てみると -define なしの方に関しては rez の Lanczos3 が結構いいところまで迫ってきている。
一方 -define ありの方はもうなんか他の追随を許さない勢いでとても速い。

まとめ2

今回選んだ画像がかなり大きいせいか、デコードに掛かる所要時間で勝負の大半がついてしまった感じがある。それでも -define なしの時と比べた限りではGo言語で書かれた JPEG デコーダや rez の縮小処理は決して遅くないので、今後同じようなアプローチで高速化されたGo言語版の JPEG デコーダなどが登場すると更に差が縮まりそうで楽しみになった。

Cocos2d-JS 触り始めた5

2014-07-23T07:04:00.000+09:00

前回の作業中ホーミングミッソーを試しにたくさん飛ばしてみると、一時的にフレームレートが低下し、それに伴いゲームの進行速度が遅くなることがあった。特にフレームスキップなどの実装をしていないしこれは想定通りの動作ではあるものの、update メソッドの第一引数に渡されてくる値は前回のフレームからの経過時間（秒）なので、これを適切に扱うようにすればフレーム落ちも加味して計算できる。

これによって少しぐらいのフレームレート低下なら何もしないよりはマシに振る舞うことができる可能性がある。ただゲームによってはフレームレート低下でゲームの進行速度が遅くなるのも許容できることもあるだろうし（例えばターン制のゲームなど時間に追われていない場合とか）、実装の面倒臭さも合わせて上手い落としを見つけるのがいい。

diff --git a/src/app.js b/src/app.js
index e0d3a27..03ccee6 100644
--- a/src/app.js
+++ b/src/app.js
@@ -119,8 +119,11 @@ var GameOverLayer = cc.Layer.extend({

 var MyShipLayer = cc.Layer.extend({
     sprite:null,
-    vy: 3,
+    vy: 140,
     barrier:false,
+    d:0,
+    origY: 0,
+    G: -280,
     ctor:function () {
         this._super();
         this.sprite = cc.Sprite.create(res.nc_png);
@@ -132,11 +135,12 @@ var MyShipLayer = cc.Layer.extend({
         return true;
     },
     update:function(dt) {
-        this.y += this.vy;
-        this.vy -= 0.1;
+      var d = this.d += dt;
+      this.y = 0.5*this.G*d*d + this.vy*d + this.origY;
     },
     jump:function() {
-      this.vy = 3;
+      this.d = 0;
+      this.origY = this.y;
     }
 });

@@ -157,8 +161,8 @@ var BlockLayer = cc.Layer.extend({
         return true;
     },
     update:function(dt) {
-        this.x += this.vx;
-        this.y += this.vy;
+        this.x += this.vx * dt;
+        this.y += this.vy * dt;
     }
 });

@@ -167,13 +171,17 @@ var HomingMissoLayer = cc.Layer.extend({
     particle:null,
     d:null,
     a:0,
+    acos:0,
+    asin:0,
     vx:0,
     vy:0,
-    speed:6,
+    speed:300,
+    trackInterval: 0.032,
     angle:0.3,
     ctor:function () {
       this._super();
       this.scheduleUpdate();
+      this.schedule(this.track, this.trackInterval);
       this.d = cc.DrawNode.create();
       this.d.drawRect(cc.p(-8, -2), cc.p(8, 2), cc.color(255,255,255,255));
       this.addChild(this.d, 0);
@@ -184,26 +192,29 @@ var HomingMissoLayer = cc.Layer.extend({
       this.addChild(this.particle);
       return true;
     },
-    update:function(dt) {
+    track:function(dt) {
       var bb = this.target.getBoundingBox();
       var dx = this.d.x, dy = this.d.y;
       var vx = this.vx, vy = this.vy;
       var tx = bb.x + bb.width*0.5 - dx, ty = bb.y + bb.height*0.5 - dy;
-      var tl = Math.sqrt(tx*tx+ty*ty), a = this.a;
-      if ((tx*vx+ty*vy)/(tl*Math.sqrt(vx*vx+vy*vy)) < 0) {
-        a += this.angle;
+      if ((tx*vx+ty*vy)/(vx*vx+vy*vy) < 0) {
+        this.a += this.angle;
       } else {
-        a += this.angle * (vx*ty - vy*tx)/tl/this.speed;
+        this.a += this.angle * (vx*ty - vy*tx)/Math.sqrt(tx*tx+ty*ty)/this.speed;
       }
-      this.a = a;
-      var cosa = Math.cos(a), sina = Math.sin(a), r = a*180/Math.PI;
-      this.vx = vx = this.speed * cosa;
-      this.vy = vy = this.speed * sina;
-      this.d.x = dx += vx;
-      this.d.y = dy += vy;
+      this.acos = Math.cos(this.a);
+      this.asin = Math.sin(this.a);
+      this.vx = this.speed * this.acos;
+      this.vy = this.speed * this.asin;
+      var r = this.a*180/Math.PI;
       this.d.rotation = -r;
-      this.particle.setSourcePosition(cc.p(dx + -6 * cosa, dy + -6 * sina));
       this.particle.angle = 180+r;
+    },
+    update:function(dt) {
+      var x = this.vx * dt + this.d.x, y = this.vy * dt + this.d.y;
+      this.d.x = x;
+      this.d.y = y;
+      this.particle.setSourcePosition(cc.p(x + -6 * this.acos, y + -6 * this.asin));
     }
 });

@@ -222,6 +233,7 @@ var HelloWorldScene = cc.Scene.extend({
           x: 40,
           y: size.height / 2
         });
+        this.myShip.jump();

         this.blocks = [];
         for (var i = 0, bl; i < 16; ++i) {
@@ -238,8 +250,8 @@ var HelloWorldScene = cc.Scene.extend({
           bl.attr({
             x: size.width+Math.random()*size.width,
             y: -bl.height+Math.random()*(size.height+bl.height),
-            vx: -0.5-Math.random()*3,
-            vy: -0.25+Math.random()*0.5
+            vx: -60-Math.random()*60,
+            vy: -2.5+Math.random()*5
           });
           this.addChild(bl);
           this.blocks.push(bl);
@@ -298,8 +310,8 @@ var HelloWorldScene = cc.Scene.extend({
           bl.attr({
             x: size.width,
             y: -bl.height+Math.random()*(size.height+bl.height),
-            vx: -0.5-Math.random()*3,
-            vy: -0.25+Math.random()*0.5
+            vx: -60-Math.random()*60,
+            vy: -2.5+Math.random()*5
           });
         }
       }

なお面倒だったので速度などは前と全く同じではなく適当に似た振る舞いになるように合わせているだけ。今までは例えばブロックは毎フレーム this.vx を足していたが変更後は this.vx*dt になっていて、dt は秒単位なので 0.0167 などの小さい値が入ってくる。前は60フレーム想定の速度で書いていたので、this.vx/0.0167 ぐらいの値を指定すれば大体同じくらいの速度で動くことにはなるとは思う。

まあでもこの手のものは今どきっぽい実装をするなら物理エンジンに丸投げしてしまえばそれで済むことも多いんだろうし予め最適化されたエンジンが使えるので、下手に自分で作るより頑張らないという選択肢も悪くなさそうだと思った。作るものの複雑さ次第かも。

Cocos Code IDE を使ってみる

つい先日 Cocos Code IDE というものがリリースされたらしい。

これは Eclipse 系列のよくある開発環境のようなのだが、どうやら Cocos2d-x の Windows 用コンパイル済みバイナリが付属していて手軽に実行して確認できる上、実行中にソースコードを書き換えるとすぐに反映して実行しなおしてくれた。

既存のプロジェクトを Cocos Code IDE で使える状態に移行するには新規プロジェクトを作って必要なファイルを突っ込めばいいようで、Cocos2d-x の新しいバージョンも出たっぽいし試しに使ってみることにした。作業中のリポジトリにはランタイムなども含んでいるのでこれによる変更ファイル数は相当多いものの基本的な振る舞いに変更はないのでここでの diff は省略する。

デバッグボタンを押すとほとんどラグなしですぐにウィンドウが出て動き始めるのでテストまでのストレスが少ない。Haxe で NME で開発していた時、Flash が動き出すのも丁度こんな感じだったので作業しやすい（とはいえ元々ブラウザをリロードするだけで試せていたので前もそんなには遅くなかった）。

今後はブラウザ上でのテストも Run In Browser ボタンでいける。

CocoStudio UI Editor を使ってスコア表示機能を作る

今度は CocoStudio に付属している UI Editor を使ってインターフェイスを作り、それを利用してスコア表示をしてみる。

単に画面にスコアを出すという目的だけを達成するなら最初から HelloWorldLayer に存在しているラベルを応用するなどでできるとは思うものの、デザインに関わる部分は長い目で見ればプログラマーとデザイナーで分業できる形になっていたほうがいい。分業相手は居ないけど。

ビットマップフォントを作る

スコアには点数しか出さないし、多種多様な実行環境に依存せず使えるように数字が格納されたビットマップフォントがあるといい。これには ShoeBox というツールが使えるらしいので、試しに M+ フォントで数字を書いただけの画像を適当に作ってみた。

これを ShoeBox に投げつけていくつか設定をするだけで余白を元に文字の切り分けポイントをは別して簡単にビットマップフォントは生成できたのだが、どうやら Cocos2d-x にはプロポーショナルフォントとして解釈されてしまうようだ（まあ描画したフォント自体もプロポーショナルフォントなので正しくはあるのだが……）。どんどんカウントアップされている点数が左右にガチャガチャ動くのは辛いので、モノスペースフォントになるように回避策を考える必要が出てきた。

自分の手で fnt ファイルを編集するとか生成用ツールを作るとかアプローチは色々ありそうではあるものの、Littera というツールでモノスペースフォントで吐けば綺麗に出ることがわかったので、手間も掛からないし今回はこの方法で行くことにした。

数字を書いて適当にポチポチやって保存すると zip ファイルで書き出される。

UI Editor でインターフェイスを組み立てる

スコア表示周りの素材を作り、その上に作成したビットマップフォントでスコアを表示させるような感じに素材を作った。UI Editor のインターフェイスは若干独特な部分があって操作性が微妙に良くない感じもあるけど、試行錯誤しているうちに目的の形に落ち着いた。

なお作った素材がダサいことについては重々承知しているのでこれ以上の追撃は必要ない。
作成したインターフェイスはエクスポートで res ディレクトリ内にサブディレクトリを作って配置した。

プログラム上でインターフェイスを読み込む

早速作った素材を読み込むレイヤーを追加し、そのレイヤーを HelloWorldScene に追加する。インターフェイス用の JSON ファイルは project.json の modules に "cocostudio" を追加すると、ccs.uiReader.widgetFromJsonFile というメソッドを通じて読み込むことができるようになるらしい。

diff --git a/project.json b/project.json
index f0c0298..b1cc345 100644
--- a/project.json
+++ b/project.json
@@ -8,7 +8,7 @@
     "renderMode" : 2,
     "engineDir":"frameworks/cocos2d-html5",
 
-    "modules" : ["menus", "cocos2d"],
+    "modules" : ["menus", "cocos2d", "cocostudio"],
 
     "jsList" : [
         "src/resource.js",
diff --git a/res/main/font.fnt b/res/main/font.fnt
new file mode 100644
index 0000000..e0b6c39
--- /dev/null
+++ b/res/main/font.fnt
@@ -0,0 +1,15 @@
+info face=font size=30 bold=1 italic=0 charset= unicode= stretchH=100 smooth=1 aa=1 padding=5,5,5,5 spacing=0,0 outline=0
+common lineHeight=45 base=32 scaleW=128 scaleH=64 pages=1 packed=0
+page id=0 file="font.png"
+chars count=10
+char id=48 x=5 y=5 width=13 height=23 xoffset=1 yoffset=0 xadvance=15 page=0 chnl=15
+char id=49 x=23 y=5 width=10 height=22 xoffset=2 yoffset=0 xadvance=15 page=0 chnl=15
+char id=50 x=38 y=5 width=12 height=23 xoffset=2 yoffset=0 xadvance=15 page=0 chnl=15
+char id=51 x=55 y=5 width=12 height=23 xoffset=2 yoffset=0 xadvance=15 page=0 chnl=15
+char id=52 x=72 y=5 width=14 height=22 xoffset=1 yoffset=0 xadvance=15 page=0 chnl=15
+char id=53 x=91 y=5 width=12 height=23 xoffset=2 yoffset=0 xadvance=15 page=0 chnl=15
+char id=54 x=72 y=32 width=13 height=23 xoffset=1 yoffset=0 xadvance=15 page=0 chnl=15
+char id=55 x=5 y=33 width=12 height=22 xoffset=2 yoffset=0 xadvance=15 page=0 chnl=15
+char id=56 x=22 y=33 width=14 height=23 xoffset=1 yoffset=0 xadvance=15 page=0 chnl=15
+char id=57 x=41 y=33 width=13 height=23 xoffset=1 yoffset=0 xadvance=15 page=0 chnl=15
+char id=32 x=0 y=0 width=0 height=0 xoffset=1 yoffset=0 xadvance=15 page=0 chnl=15
\ No newline at end of file
diff --git a/res/main/font.png b/res/main/font.png
new file mode 100644
index 0000000..a30c2e2
Binary files /dev/null and b/res/main/font.png differ
diff --git a/res/main/main.json b/res/main/main.json
new file mode 100644
index 0000000..e512a7e
--- /dev/null
+++ b/res/main/main.json
@@ -0,0 +1,183 @@
+{
+  "classname": null,
+  "name": null,
+  "animation": {
+    "classname": null,
+    "name": "AnimationManager",
+    "actionlist": []
+  },
+  "dataScale": 1,
+  "designHeight": 450,
+  "designWidth": 800,
+  "textures": [],
+  "texturesPng": [
+    "score.png"
+  ],
+  "version": "1.5.0.0",
+  "widgetTree": {
+    "classname": "Panel",
+    "name": null,
+    "children": [
+      {
+        "classname": "ImageView",
+        "name": null,
+        "children": [],
+        "options": {
+          "__type": "ImageViewSurrogate:#EditorCommon.JsonModel.Component.GUI",
+          "classname": "ImageView",
+          "name": "Image_6",
+          "ZOrder": 0,
+          "actiontag": 45502051,
+          "anchorPointX": 1,
+          "anchorPointY": 1,
+          "classType": "CocoStudio.EngineAdapterWrap.CSImageView",
+          "colorB": 255,
+          "colorG": 255,
+          "colorR": 255,
+          "customProperty": "",
+          "flipX": false,
+          "flipY": false,
+          "height": 34,
+          "ignoreSize": true,
+          "layoutParameter": null,
+          "opacity": 255,
+          "positionPercentX": 1.0025,
+          "positionPercentY": 1.00444448,
+          "positionType": 1,
+          "rotation": 0,
+          "scaleX": 1,
+          "scaleY": 1,
+          "sizePercentX": 0.31875,
+          "sizePercentY": 0.0755555555,
+          "sizeType": 0,
+          "tag": 10,
+          "touchAble": false,
+          "useMergedTexture": false,
+          "visible": true,
+          "width": 255,
+          "x": 802,
+          "y": 452,
+          "capInsetsHeight": 1,
+          "capInsetsWidth": 1,
+          "capInsetsX": 0,
+          "capInsetsY": 0,
+          "fileName": null,
+          "fileNameData": {
+            "path": "score.png",
+            "plistFile": "",
+            "resourceType": 0
+          },
+          "scale9Enable": false,
+          "scale9Height": 34,
+          "scale9Width": 255
+        }
+      },
+      {
+        "classname": "LabelBMFont",
+        "name": null,
+        "children": [],
+        "options": {
+          "__type": "LabelBMFontSurrogate:#EditorCommon.JsonModel.Component.GUI",
+          "classname": "LabelBMFont",
+          "name": "scoreValue",
+          "ZOrder": 0,
+          "actiontag": 52610097,
+          "anchorPointX": 1,
+          "anchorPointY": 1,
+          "classType": "CocoStudio.EngineAdapterWrap.CSLabelBMFont",
+          "colorB": 255,
+          "colorG": 255,
+          "colorR": 255,
+          "customProperty": "",
+          "flipX": false,
+          "flipY": false,
+          "height": 45,
+          "ignoreSize": true,
+          "layoutParameter": null,
+          "opacity": 255,
+          "positionPercentX": 0.99625,
+          "positionPercentY": 0.9911111,
+          "positionType": 0,
+          "rotation": 0,
+          "scaleX": 1,
+          "scaleY": 1,
+          "sizePercentX": 0.285,
+          "sizePercentY": 0.25111112,
+          "sizeType": 0,
+          "tag": 12,
+          "touchAble": false,
+          "useMergedTexture": false,
+          "visible": true,
+          "width": 90,
+          "x": 797,
+          "y": 446,
+          "fileNameData": {
+            "path": "font.fnt",
+            "plistFile": "",
+            "resourceType": 0
+          },
+          "text": "112266"
+        }
+      }
+    ],
+    "options": {
+      "__type": "PanelSurrogate:#EditorCommon.JsonModel.Component.GUI",
+      "classname": "Panel",
+      "name": "Panel_14",
+      "ZOrder": 0,
+      "actiontag": -1,
+      "anchorPointX": 0,
+      "anchorPointY": 0,
+      "classType": "CocoStudio.EngineAdapterWrap.CSPanel",
+      "colorB": 255,
+      "colorG": 255,
+      "colorR": 255,
+      "customProperty": "",
+      "flipX": false,
+      "flipY": false,
+      "height": 450,
+      "ignoreSize": false,
+      "layoutParameter": null,
+      "opacity": 255,
+      "positionPercentX": 0,
+      "positionPercentY": 0,
+      "positionType": 0,
+      "rotation": 0,
+      "scaleX": 1,
+      "scaleY": 1,
+      "sizePercentX": 1,
+      "sizePercentY": 1,
+      "sizeType": 0,
+      "tag": 3,
+      "touchAble": false,
+      "useMergedTexture": false,
+      "visible": true,
+      "width": 800,
+      "x": 0,
+      "y": 0,
+      "adaptScreen": false,
+      "backGroundImage": null,
+      "backGroundImageData": null,
+      "backGroundScale9Enable": false,
+      "bgColorB": 255,
+      "bgColorG": 200,
+      "bgColorOpacity": 0,
+      "bgColorR": 150,
+      "bgEndColorB": 255,
+      "bgEndColorG": 200,
+      "bgEndColorR": 150,
+      "bgStartColorB": 255,
+      "bgStartColorG": 255,
+      "bgStartColorR": 255,
+      "capInsetsHeight": 1,
+      "capInsetsWidth": 1,
+      "capInsetsX": 0,
+      "capInsetsY": 0,
+      "clipAble": false,
+      "colorType": 1,
+      "layoutType": 0,
+      "vectorX": 0,
+      "vectorY": -0.5
+    }
+  }
+}
\ No newline at end of file
diff --git a/res/main/score.png b/res/main/score.png
new file mode 100644
index 0000000..c51951a
Binary files /dev/null and b/res/main/score.png differ
diff --git a/src/app.js b/src/app.js
index f7454fe..468a0df 100644
--- a/src/app.js
+++ b/src/app.js
@@ -62,6 +62,26 @@ var HelloWorldLayer = cc.Layer.extend({
  }
 });
 
+var StatusLayer = cc.Layer.extend({
+ _score:0,
+ ui:null,
+ scoreValue:null,
+ getScore: function () {
+  return this._score;
+ },
+ setScore: function (newScore) {
+  this._score = newScore;
+  this.scoreValue.string = newScore;
+ },
+ ctor:function () {
+  this._super();
+  cc.defineGetterSetter(this, "score", this.getScore, this.setScore);
+  this.ui = ccs.uiReader.widgetFromJsonFile(res.main_json);
+  this.scoreValue = ccui.helper.seekWidgetByName(this.ui, "scoreValue");
+  this.addChild(this.ui);
+ }
+});
+
 var GameOverLayer = cc.Layer.extend({
  ctor:function () {
   this._super();
@@ -223,6 +243,8 @@ var HelloWorldScene = cc.Scene.extend({
  myShip:null,
  blocks:null,
  el:null,
+ status:null,
+ live:0,
  onEnter:function () {
   this._super();
   var size = cc.director.getWinSize();
@@ -271,6 +293,10 @@ var HelloWorldScene = cc.Scene.extend({
   ml.attr({target: this.blocks[3]});
   this.addChild(ml);
 
+  this.status = new StatusLayer();
+  this.addChild(this.status);
+  this.status.score = 0;
+
   this.el = cc.EventListener.create({
    event: cc.EventListener.TOUCH_ONE_BY_ONE,
    swallowTouches: true,
@@ -316,6 +342,9 @@ var HelloWorldScene = cc.Scene.extend({
     });
    }
   }
+  
+  this.live += dt;
+  this.status.score = Math.floor(this.live * 1000);
  },
  gameover:function() {
   this.unscheduleUpdate();
diff --git a/src/resource.js b/src/resource.js
index 756e58d..f392785 100644
--- a/src/resource.js
+++ b/src/resource.js
@@ -12,6 +12,10 @@ var res = {
  return_to_title_selected_png : "res/return_to_title_selected.png",
  FireParticle_plist : "res/FireParticle.plist",
  stripes_png : "res/stripes.png",
+ font_png : "res/main/font.png",
+ main_json : "res/main/main.json",
+ score_png : "res/main/score.png",
+ font_fnt : "res/main/font.fnt",
 };
 
 var g_resources = [
@@ -28,11 +32,14 @@ var g_resources = [
  res.return_to_title_normal_png,
  res.return_to_title_selected_png,
  res.stripes_png,
+ res.score_png,
+ res.font_png,
 
  // plist
  res.FireParticle_plist,
  
  // fnt
+ res.font_fnt,
 
  // tmx
  
@@ -40,4 +47,6 @@ var g_resources = [
  
  // effect
 
+ // json
+ res.main_json,
 ];

今回の StatusLayer クラスには、プロパティに setter/getter を定義できる cc.defineGetterSetter を使って score というプロパティを定義してみた。これによって setScore のようなメソッドを呼ばない単なる代入に対しても処理を介入させられるようになるので、間違えて setScore を呼ばずに score に代入してしまうといったケースを減らせる。

これでひとまず動くようになった。

はずだったのだが、コンパイル済みの Windows 版で出ている画像がブラウザ上だと出ない。この手の問題は自分が原因でないケースも考えられるので調べてみたらそれっぽい報告がある模様。
寝て待つとそのうち果報が来そうな予感がするしこの問題にはこれ以上対処しないことにする。

効果音をつける

オーディオ周りは多数の環境で動かすことを考えるとどのフォーマットで用意すればいいのか悩ましい。一応ここに簡単な表と、ブラウザの場合はこっちを見るとどの辺が使えるのかがわかる。ただここまで多種多様なものを覚えるのは結構きついので、本当は *.wav とか *.aiff 辺りで用意しておくと書き出し先の動作環境に合わせて適切にエンコードしてくれたりくれると嬉しいと個人的には思う。

今回は各ブラウザへの対応を考えて ogg と mp3、更にその元データになっている wav も用意した。また、チュートリアルを見る限りでは「And you don't need to list both in resource.js, please just list "mp3" format which has better compatibility with iOS and Mac when you run your game on devices.」とのことなので resource.js には mp3 だけを書くことにする。

あとはこれを cc.audioEngine.playEffect(res.jump_mp3) として再生すればいいだけなのだが、どうもブラウザでは5回以降音がでない状態に陥る。挙動的に再生完了を自動的に検知せず再生数上限か何かに引っかかっているんだろうと思いちょっと見てみると _maxAudioInstance: 5 というのがあったので、どうやらこれっぽい。再生前に前回再生時のオーディオIDを停止させるようにすることで問題なく動くようになった。

diff --git a/res/jump.mp3 b/res/jump.mp3
new file mode 100644
index 0000000..a2d3a5e
Binary files /dev/null and b/res/jump.mp3 differ
diff --git a/res/jump.ogg b/res/jump.ogg
new file mode 100644
index 0000000..d15fc28
Binary files /dev/null and b/res/jump.ogg differ
diff --git a/res/jump.wav b/res/jump.wav
new file mode 100644
index 0000000..fd5c63a
Binary files /dev/null and b/res/jump.wav differ
diff --git a/src/app.js b/src/app.js
index 468a0df..202de44 100644
--- a/src/app.js
+++ b/src/app.js
@@ -244,6 +244,7 @@ var HelloWorldScene = cc.Scene.extend({
  blocks:null,
  el:null,
  status:null,
+ jumpAudioId:null,
  live:0,
  onEnter:function () {
   this._super();
@@ -297,16 +298,21 @@ var HelloWorldScene = cc.Scene.extend({
   this.addChild(this.status);
   this.status.score = 0;
 
+  var that = this;
   this.el = cc.EventListener.create({
    event: cc.EventListener.TOUCH_ONE_BY_ONE,
    swallowTouches: true,
-   onTouchBegan: this.onTap,
+   onTouchBegan: function(touch, event){ return that.onTap(touch, event); },
   });
   cc.eventManager.addListener(this.el, this);
   this.scheduleUpdateWithPriority(10);
  },
  onTap:function(touch, event) {
-  event.getCurrentTarget().myShip.jump();
+  this.myShip.jump();
+  if (this.jumpAudioId !== null) {
+   cc.audioEngine.stopEffect(this.jumpAudioId);
+  }
+  this.jumpAudioId = cc.audioEngine.playEffect(res.jump_mp3);
   return true;
  },
  update:function(dt) {
diff --git a/src/resource.js b/src/resource.js
index f392785..1bcb3f0 100644
--- a/src/resource.js
+++ b/src/resource.js
@@ -16,6 +16,7 @@ var res = {
  main_json : "res/main/main.json",
  score_png : "res/main/score.png",
  font_fnt : "res/main/font.fnt",
+ jump_mp3 : "res/jump.mp3",
 };
 
 var g_resources = [
@@ -46,6 +47,7 @@ var g_resources = [
  // bgm
  
  // effect
+ res.jump_mp3,
 
  // json
  res.main_json,

同じ流れで BGM も流すようにしてみる。

diff --git a/res/bgm.mp3 b/res/bgm.mp3
new file mode 100644
index 0000000..218012a
Binary files /dev/null and b/res/bgm.mp3 differ
diff --git a/res/bgm.ogg b/res/bgm.ogg
new file mode 100644
index 0000000..6eb0b1b
Binary files /dev/null and b/res/bgm.ogg differ
diff --git a/src/app.js b/src/app.js
index 202de44..8174010 100644
--- a/src/app.js
+++ b/src/app.js
@@ -298,6 +298,7 @@ var HelloWorldScene = cc.Scene.extend({
   this.addChild(this.status);
   this.status.score = 0;
 
+  cc.audioEngine.playMusic(res.bgm_mp3, true);
   var that = this;
   this.el = cc.EventListener.create({
    event: cc.EventListener.TOUCH_ONE_BY_ONE,
@@ -353,6 +354,10 @@ var HelloWorldScene = cc.Scene.extend({
   this.status.score = Math.floor(this.live * 1000);
  },
  gameover:function() {
+  if (this.jumpAudioId !== null) {
+   cc.audioEngine.stopEffect(this.jumpAudioId);
+  }
+  cc.audioEngine.stopMusic(true);
   this.unscheduleUpdate();
   cc.eventManager.removeListener(this.el);
 
diff --git a/src/resource.js b/src/resource.js
index 1bcb3f0..0edd300 100644
--- a/src/resource.js
+++ b/src/resource.js
@@ -17,6 +17,7 @@ var res = {
  score_png : "res/main/score.png",
  font_fnt : "res/main/font.fnt",
  jump_mp3 : "res/jump.mp3",
+ bgm_mp3 : "res/bgm.mp3",
 };
 
 var g_resources = [
@@ -45,6 +46,7 @@ var g_resources = [
  // tmx
  
  // bgm
+ res.bgm_mp3,
  
  // effect
  res.jump_mp3,

Windows / Android / Web どの環境でもそれなりに鳴るけど、Windows はループ再生してもギャップレスにはならずループ時にノイズが混じり、Android は曲の終端が切れ、Web(Chrome) は一番理想には近いもののギャップレスにはならなかった。

もし実際にゲームを作る時に BGM を入れる場合は1ループは長めに確保し、曲の頭には少しの無音を入れ、かつ曲の終わりはフェードアウトか無音部分を入れて終わらせる感じだろうか。

ゲームと言っても日常の生活の中で開いた時間にちょっとずつプレイするようなスタイルだと重厚な臨場感溢れる BGM とかそもそもあまりお呼びではない気もするし、取りあえずそこそこに音が出せれば十分であまり洗練されていないのかもしれないと思った。

加速度センサーの値に応じて挙動を変える

端末を傾けるとブロックの速度と得点の上がり方が変わるようにしてみる。これによってゲームプレイ方法に幅が広がる。

加速度センサーからの情報を得るには cc.inputManager.setAccelerometerEnabled で有効化した上で cc.eventManager.addListener でイベントリスナーを登録しておけばいいようだ。

diff --git a/src/app.js b/src/app.js
index 8174010..d4ff88c 100644
--- a/src/app.js
+++ b/src/app.js
@@ -169,6 +169,7 @@ var BlockLayer = cc.Layer.extend({
  d:null,
  vx: 0,
  vy: 0,
+ accel:null,
  ctor:function (width, height, fillcolor) {
   this._super();
   this.d = cc.DrawNode.create();
@@ -182,7 +183,7 @@ var BlockLayer = cc.Layer.extend({
   return true;
  },
  update:function(dt) {
-  this.x += this.vx * dt;
+  this.x += this.vx * dt * (1-Math.min(0.5, Math.max(-0.5, this.accel.x)));
   this.y += this.vy * dt;
  }
 });
@@ -243,14 +244,19 @@ var HelloWorldScene = cc.Scene.extend({
  myShip:null,
  blocks:null,
  el:null,
+ ela:null,
  status:null,
  jumpAudioId:null,
+ accel:null,
  live:0,
  onEnter:function () {
   this._super();
   var size = cc.director.getWinSize();
   var layer = new HelloWorldLayer();
   this.addChild(layer);
+  
+  this.accel={x:0, y:0, z:0};
+
   this.myShip = new MyShipLayer();
   this.addChild(this.myShip);
   this.myShip.attr({
@@ -275,7 +281,8 @@ var HelloWorldScene = cc.Scene.extend({
     x: size.width+Math.random()*size.width,
     y: -bl.height+Math.random()*(size.height+bl.height),
     vx: -60-Math.random()*60,
-    vy: -2.5+Math.random()*5
+    vy: -2.5+Math.random()*5,
+    accel: this.accel,
    });
    this.addChild(bl);
    this.blocks.push(bl);
@@ -306,6 +313,13 @@ var HelloWorldScene = cc.Scene.extend({
    onTouchBegan: function(touch, event){ return that.onTap(touch, event); },
   });
   cc.eventManager.addListener(this.el, this);
+
+  cc.inputManager.setAccelerometerEnabled(true);  
+  this.ela = cc.EventListener.create({
+   event: cc.EventListener.ACCELERATION,
+   callback: function(accel, event){ return that.onAccel(accel, event); },
+  });
+  cc.eventManager.addListener(this.ela, this);
   this.scheduleUpdateWithPriority(10);
  },
  onTap:function(touch, event) {
@@ -316,6 +330,12 @@ var HelloWorldScene = cc.Scene.extend({
   this.jumpAudioId = cc.audioEngine.playEffect(res.jump_mp3);
   return true;
  },
+ onAccel:function(accel, event) {
+  this.accel.x = accel.x;
+  this.accel.y = accel.y;
+  this.accel.z = accel.z;
+  return true;
+ },
  update:function(dt) {
   var myShipBB = this.myShip.getBoundingBox();
   var barrierBB = cc.rect(myShipBB.x-40,myShipBB.y-40,myShipBB.width+80,myShipBB.height+80);
@@ -350,7 +370,7 @@ var HelloWorldScene = cc.Scene.extend({
    }
   }
   
-  this.live += dt;
+  this.live += dt * (1-Math.min(0.5, Math.max(-0.5, this.accel.x)));
   this.status.score = Math.floor(this.live * 1000);
  },
  gameover:function() {
@@ -360,6 +380,7 @@ var HelloWorldScene = cc.Scene.extend({
   cc.audioEngine.stopMusic(true);
   this.unscheduleUpdate();
   cc.eventManager.removeListener(this.el);
+  cc.eventManager.removeListener(this.ela);
 
   var layer = new GameOverLayer();
   this.addChild(layer);

簡単に動くようにはなったのだが、端末の持ち方を上下逆さまにした時ゲーム画面はそれに合わせて回転するもののセンサーの反応はそのままなので、結果的に傾きに対するリアクションが正反対になってしまう。orientation 的なものを取得できれば挙動も反転させられそうだけどどこから取得すればいいのかわからない。

その他

Cocos Code IDE で新規プロジェクトを作成した時、画面サイズのデフォルト値が 960x640 になっていたので、スクリーンサイズをそれに変更した。これによって画面サイズが広くなったが、自機やブロックのサイズは変わらないままなので画面に余裕ができてかなり間延びした状態になった。

また、インターフェイスでビットマップフォントのラベルはインターフェイス用背景画像とは別の階層に居たが、これはインターフェイス用背景画像の子としてビットマップフォンのトラベルを配置したほうが正しいと思ったのでそうなるように変更した。変更したところ、数字だけは見えていたブラウザ上でのインターフェイス表示は数字も含めて見えなくなった。

今回までの成果物はこちら。また、今回はインターフェイスの追加が Web から確認できないので Android 用の apk ファイルも公開する。作業に使っているリポジトリはこちら。

Cocos2d-JS 触り始めた4

2014-07-19T07:15:00.000+09:00

だいぶやりたいことが見つからない感じになってきたので、cc.ParticleSystem を使って適当に何かを散らしてみようかと思った（やったほうがいいことはもちろんまだたくさんあるが面倒くさい）。

今回作ったものはこちら。ホーミングミサイル的なものが出るけど、ミサイルとの当たり判定は特に作ってないのでヒットせずにぐるぐる回り続ける。

作業環境である Windows 8.1 で使えるエディタを適当に検索し見つけたこの Particle Editor を使って plist ファイルを書き出し、それを読み込み、適当に作ったホーミングミッソーの後ろに向けて噴出する感じで動くようにしてみた。

diff --git a/res/FireParticle.plist b/res/FireParticle.plist
new file mode 100644
index 0000000..bab965a
--- /dev/null
+++ b/res/FireParticle.plist
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+<key>angle</key>
+<real>0</real>
+<key>angleVariance</key>
+<real>0</real>
+<key>blendFuncDestination</key>
+<integer>1</integer>
+<key>blendFuncSource</key>
+<integer>1</integer>
+<key>duration</key>
+<real>-1</real>
+<key>emitterType</key>
+<real>0</real>
+<key>finishColorAlpha</key>
+<real>0</real>
+<key>finishColorBlue</key>
+<real>0</real>
+<key>finishColorGreen</key>
+<real>0</real>
+<key>finishColorRed</key>
+<real>0</real>
+<key>finishColorVarianceAlpha</key>
+<real>0</real>
+<key>finishColorVarianceBlue</key>
+<real>0</real>
+<key>finishColorVarianceGreen</key>
+<real>0</real>
+<key>finishColorVarianceRed</key>
+<real>0</real>
+<key>finishParticleSize</key>
+<real>20</real>
+<key>finishParticleSizeVariance</key>
+<real>12</real>
+<key>gravityx</key>
+<real>0</real>
+<key>gravityy</key>
+<real>0</real>
+<key>maxParticles</key>
+<real>20</real>
+<key>maxRadius</key>
+<real>0</real>
+<key>maxRadiusVariance</key>
+<real>0</real>
+<key>minRadius</key>
+<real>0</real>
+<key>particleLifespan</key>
+<real>0.3</real>
+<key>particleLifespanVariance</key>
+<real>0.1</real>
+<key>radialAccelVariance</key>
+<real>0</real>
+<key>radialAcceleration</key>
+<real>0</real>
+<key>rotatePerSecond</key>
+<real>0</real>
+<key>rotatePerSecondVariance</key>
+<real>0</real>
+<key>sourcePositionVariancex</key>
+<real>0</real>
+<key>sourcePositionVariancey</key>
+<real>0</real>
+<key>sourcePositionx</key>
+<real>0</real>
+<key>sourcePositiony</key>
+<real>0</real>
+<key>speed</key>
+<real>80.0</real>
+<key>speedVariance</key>
+<real>20.0</real>
+<key>startColorAlpha</key>
+<real>1</real>
+<key>startColorBlue</key>
+<real>1</real>
+<key>startColorGreen</key>
+<real>1</real>
+<key>startColorRed</key>
+<real>1</real>
+<key>startColorVarianceAlpha</key>
+<real>1</real>
+<key>startColorVarianceBlue</key>
+<real>1</real>
+<key>startColorVarianceGreen</key>
+<real>0</real>
+<key>startColorVarianceRed</key>
+<real>0</real>
+<key>startParticleSize</key>
+<real>0</real>
+<key>startParticleSizeVariance</key>
+<real>0</real>
+<key>tangentialAccelVariance</key>
+<real>0</real>
+<key>tangentialAcceleration</key>
+<real>0</real>
+<key>textureFileName</key>
+<string>stripes.png</string>
+<key>textureImageData</key>
+<string></string>
+</dict>
+</plist>
diff --git a/res/stripes.png b/res/stripes.png
new file mode 100644
index 0000000..f67ac0b
Binary files /dev/null and b/res/stripes.png differ
diff --git a/src/app.js b/src/app.js
index e625506..e0d3a27 100644
--- a/src/app.js
+++ b/src/app.js
@@ -162,6 +162,51 @@ var BlockLayer = cc.Layer.extend({
     }
 });

+var HomingMissoLayer = cc.Layer.extend({
+    target:null,
+    particle:null,
+    d:null,
+    a:0,
+    vx:0,
+    vy:0,
+    speed:6,
+    angle:0.3,
+    ctor:function () {
+      this._super();
+      this.scheduleUpdate();
+      this.d = cc.DrawNode.create();
+      this.d.drawRect(cc.p(-8, -2), cc.p(8, 2), cc.color(255,255,255,255));
+      this.addChild(this.d, 0);
+      var bbox = cc.size(16, 16);
+      this.d.setPosition(bbox.width * 0.5, bbox.height * 0.5);
+      this.setContentSize(bbox);
+      this.particle = cc.ParticleSystem.create(res.FireParticle_plist);
+      this.addChild(this.particle);
+      return true;
+    },
+    update:function(dt) {
+      var bb = this.target.getBoundingBox();
+      var dx = this.d.x, dy = this.d.y;
+      var vx = this.vx, vy = this.vy;
+      var tx = bb.x + bb.width*0.5 - dx, ty = bb.y + bb.height*0.5 - dy;
+      var tl = Math.sqrt(tx*tx+ty*ty), a = this.a;
+      if ((tx*vx+ty*vy)/(tl*Math.sqrt(vx*vx+vy*vy)) < 0) {
+        a += this.angle;
+      } else {
+        a += this.angle * (vx*ty - vy*tx)/tl/this.speed;
+      }
+      this.a = a;
+      var cosa = Math.cos(a), sina = Math.sin(a), r = a*180/Math.PI;
+      this.vx = vx = this.speed * cosa;
+      this.vy = vy = this.speed * sina;
+      this.d.x = dx += vx;
+      this.d.y = dy += vy;
+      this.d.rotation = -r;
+      this.particle.setSourcePosition(cc.p(dx + -6 * cosa, dy + -6 * sina));
+      this.particle.angle = 180+r;
+    }
+});
+
 var HelloWorldScene = cc.Scene.extend({
     myShip:null,
     blocks:null,
@@ -200,6 +245,19 @@ var HelloWorldScene = cc.Scene.extend({
           this.blocks.push(bl);
         }

+        var ml = new HomingMissoLayer();
+        ml.attr({target: this.blocks[0]});
+        this.addChild(ml);
+        var ml = new HomingMissoLayer();
+        ml.attr({target: this.blocks[1]});
+        this.addChild(ml);
+        var ml = new HomingMissoLayer();
+        ml.attr({target: this.blocks[2]});
+        this.addChild(ml);
+        var ml = new HomingMissoLayer();
+        ml.attr({target: this.blocks[3]});
+        this.addChild(ml);
+
         this.el = cc.EventListener.create({
             event: cc.EventListener.TOUCH_ONE_BY_ONE,
             swallowTouches: true,
diff --git a/src/resource.js b/src/resource.js
index 574ab3e..24c26df 100644
--- a/src/resource.js
+++ b/src/resource.js
@@ -9,7 +9,9 @@ var res = {
     restart_normal_png : "res/restart_normal.png",
     restart_selected_png : "res/restart_selected.png",
     return_to_title_normal_png : "res/return_to_title_normal.png",
-    return_to_title_selected_png : "res/return_to_title_selected.png"
+    return_to_title_selected_png : "res/return_to_title_selected.png",
+    FireParticle_plist : "res/FireParticle.plist",
+    stripes_png : "res/stripes.png",
 };

 var g_resources = [
@@ -24,9 +26,11 @@ var g_resources = [
     res.restart_normal_png,
     res.restart_selected_png,
     res.return_to_title_normal_png,
-    res.return_to_title_selected_png
+    res.return_to_title_selected_png,
+    res.stripes_png,

     //plist
+    res.FireParticle_plist,

     //fnt

気をつける必要があるのは cc.ParticleSystem を addChild した親のレイヤーなどを移動すると全体が動いてしまい、出力されているパーティクルに本来存在しない動きが加わってしまい予め設定していた振る舞いと若干異なる挙動になってしまう（もちろんわかった上でやる分には問題ない）。

なので、今回のミッソーのように噴出口自体は動くものの噴出したパーティクルは出力時の動きを維持したいようなケースの場合、setSourcePosition や angle を使って正しい位置に合わせる必要があるようだった。

その辺りを把握していれば動かす上で障壁になるようなものはあまりない気がするので、非常に効率よく映えるエフェクトを追加できて便利なので積極的に使っていきたい仕組みだった。

plist ファイルに仕組みを追い出しておくことによってプログラマーとデザイナーで作業もある程度分担しやすくなるだろうしとても良い。

Cocos2d-JS 触り始めた3

2014-07-18T07:25:00.002+09:00

前回までの作業で操作することでブロックを避けられるようになり、少しゲームっぽくなってきた。
もう少し弄ってみる。

画面外に出たらゲームオーバーにする

まだ上下にはみ出した時にゲームオーバーにならないので、これがゲームオーバーになるようにする。

diff --git a/src/app.js b/src/app.js
index 28cd4bc..db28f83 100644
--- a/src/app.js
+++ b/src/app.js
@@ -156,12 +156,14 @@ var HelloWorldScene = cc.Scene.extend({
     update:function(dt) {
       var myShipBB = this.myShip.getBoundingBox();
       var size = cc.director.getWinSize();
+      if (myShipBB.y+myShipBB.height < 0 || myShipBB.y > size.height) {
+        this.gameover();
+        return;
+      }
       for(var i = this.blocks.length - 1, bl; i >= 0; --i) {
         bl = this.blocks[i];
         if (cc.rectIntersectsRect(myShipBB, bl.getBoundingBox())) {
-          this.unscheduleUpdate();
-          cc.eventManager.removeListener(this);
-          cc.director.runScene(cc.TransitionFade.create(0.5, new HelloWorldScene()));
+          this.gameover();
           return;
         }
         if (bl.x+bl.width < 0) {
@@ -172,4 +174,9 @@ var HelloWorldScene = cc.Scene.extend({
         }
       }
     },
+    gameover:function() {
+      this.unscheduleUpdate();
+      cc.eventManager.removeListener(this);
+      cc.director.runScene(cc.TransitionFade.create(0.5, new HelloWorldScene()));
+    }
 });

自機が完全に画面の外に出たら終わり。

飽きたのでちょっと遊ぶ

動作テストのためにブロックを避け続けていたので、たまにはブロック側から自機を避けてもいい気がしてきた。試しに自機に近づいたブロックが勝手に吹っ飛んでいく処理を書いてストレス解消しようと思う。

判定として「自機に半径rピクセル以上近づいたら」とやりたいところではあるものの円と矩形の衝突判定は複雑で重いので、今回は色々な面から妥協して自機を囲う大きな矩形と接触したら弾くことにする。

diff --git a/src/app.js b/src/app.js
index db28f83..04473b9 100644
--- a/src/app.js
+++ b/src/app.js
@@ -155,14 +155,25 @@ var HelloWorldScene = cc.Scene.extend({
     },
     update:function(dt) {
       var myShipBB = this.myShip.getBoundingBox();
+      var barrierBB = cc.rect(myShipBB.x-40,myShipBB.y-40,myShipBB.width+80,myShipBB.height+80);
       var size = cc.director.getWinSize();
       if (myShipBB.y+myShipBB.height < 0 || myShipBB.y > size.height) {
         this.gameover();
         return;
       }
-      for(var i = this.blocks.length - 1, bl; i >= 0; --i) {
+      for(var i = this.blocks.length - 1, bl, bb; i >= 0; --i) {
         bl = this.blocks[i];
-        if (cc.rectIntersectsRect(myShipBB, bl.getBoundingBox())) {
+        bb = bl.getBoundingBox();
+        if (cc.rectIntersectsRect(barrierBB, bb)) {
+          var vx = (bb.x+bb.width*0.5) - (barrierBB.x+barrierBB.width*0.5);
+          var vy = (bb.y+bb.height*0.5) - (barrierBB.y+barrierBB.height*0.5);
+          var l = 1/Math.sqrt(vx*vx+vy*vy)*4;
+          bl.attr({
+            vx: vx * l,
+            vy: vy * l,
+          });
+        }
+        if (cc.rectIntersectsRect(myShipBB, bb)) {
           this.gameover();
           return;
         }

自機より40ピクセル大きい矩形で判定して、ヒットした場合は自機と反対側の方向へ吹き飛ばすようにした。

これによってブロックは左端からスクリーンアウトする以外の理由で退場するケースが出てくるようになったので、画面外に出た判定処理をもう少しまともに作り直す。

diff --git a/src/app.js b/src/app.js
index 04473b9..ecb688c 100644
--- a/src/app.js
+++ b/src/app.js
@@ -177,10 +177,12 @@ var HelloWorldScene = cc.Scene.extend({
           this.gameover();
           return;
         }
-        if (bl.x+bl.width < 0) {
+        if (bl.x+bl.width < 0 || bl.x > size.width || bl.y+bl.height < 0 || bl.y > size.height) {
           bl.attr({
             x: size.width,
-            y: -bl.height+Math.random()*(size.height+bl.height)
+            y: -bl.height+Math.random()*(size.height+bl.height),
+            vx: -0.5-Math.random()*3,
+            vy: -0.25+Math.random()*0.5
           });
         }
       }

ブロックが表示領域外に出たら各パラメータをセットし直す感じになった。

この挙動を修正すると、今度はブロックの初期位置が横に2画面分あると仮定して見えない位置に配置していたのが、ゲーム開始直後に画面外判定を食らっていきなり同じ位置に集結してしまうようになった。

この問題を解決する方法は色々あるものの、致命的な問題ではないのでひとまず保留にする。一番短絡的な解決方法はブロックの画面外判定を右側だけもう1画面先にすることだと思う。

他にも高い位置から落下をすると結構な速度が出るのでそのタイミングでブロックを弾き飛ばしても接触できてしまうとかの問題もある。

これらの問題は後で考えるとして、取りあえず遊びで作ったこのバリアー機能は自機にバリアーフラグが立っている時だけ有効にするようにしよう。

diff --git a/src/app.js b/src/app.js
index ecb688c..976cd6f 100644
--- a/src/app.js
+++ b/src/app.js
@@ -64,6 +64,7 @@ var HelloWorldLayer = cc.Layer.extend({
 var MyShipLayer = cc.Layer.extend({
     sprite:null,
     vy: 3,
+    barrier:false,
     ctor:function () {
         this._super();
         this.sprite = cc.Sprite.create(res.nc_png);
@@ -164,7 +165,7 @@ var HelloWorldScene = cc.Scene.extend({
       for(var i = this.blocks.length - 1, bl, bb; i >= 0; --i) {
         bl = this.blocks[i];
         bb = bl.getBoundingBox();
-        if (cc.rectIntersectsRect(barrierBB, bb)) {
+        if (this.myShip.barrier && cc.rectIntersectsRect(barrierBB, bb)) {
           var vx = (bb.x+bb.width*0.5) - (barrierBB.x+barrierBB.width*0.5);
           var vy = (bb.y+bb.height*0.5) - (barrierBB.y+barrierBB.height*0.5);
           var l = 1/Math.sqrt(vx*vx+vy*vy)*4;

このバリアーフラグを立てる処理自体はまたの機会、ということで。

タイトル画面をつける

重い腰を上げ、ついにタイトル画面をつけることにする。重かった理由は目新しい要素がないことと、リソースを追加するのが面倒だったから。

diff --git a/main.js b/main.js
index 8569b66..34eecb3 100644
--- a/main.js
+++ b/main.js
@@ -3,7 +3,7 @@ cc.game.onStart = function(){
        cc.view.resizeWithBrowserSize(true);
     //load resources
     cc.LoaderScene.preload(g_resources, function () {
-        cc.director.runScene(new HelloWorldScene());
+        cc.director.runScene(new TitleScene());
     }, this);
 };
 cc.game.run();
diff --git a/res/game_start_normal.png b/res/game_start_normal.png
new file mode 100644
index 0000000..b4212fd
Binary files /dev/null and b/res/game_start_normal.png differ
diff --git a/res/game_start_selected.png b/res/game_start_selected.png
new file mode 100644
index 0000000..4e4c43a
Binary files /dev/null and b/res/game_start_selected.png differ
diff --git a/res/title.jpg b/res/title.jpg
new file mode 100644
index 0000000..d1d1285
Binary files /dev/null and b/res/title.jpg differ
diff --git a/src/app.js b/src/app.js
index 976cd6f..e58c103 100644
--- a/src/app.js
+++ b/src/app.js
@@ -194,3 +194,43 @@ var HelloWorldScene = cc.Scene.extend({
       cc.director.runScene(cc.TransitionFade.create(0.5, new HelloWorldScene()));
     }
 });
+
+var TitleLayer = cc.Layer.extend({
+    ctor:function () {
+        this._super();
+        var size = cc.director.getWinSize();
+        var sprite = cc.Sprite.create(res.title_jpg);
+        sprite.attr({
+            x: size.width * 0.5,
+            y: size.height * 0.5
+        });
+        this.addChild(sprite, 0);
+
+        var gameStartItem = cc.MenuItemImage.create(
+            res.game_start_normal_png,
+            res.game_start_selected_png,
+            function () {
+                cc.director.runScene(cc.TransitionFade.create(0.5, new HelloWorldScene()));
+            }, this);
+        gameStartItem.attr({
+            x: size.width * 0.5,
+            y: 80,
+            anchorX: 0.5,
+            anchorY: 0.5
+        });
+
+        var menu = cc.Menu.create(gameStartItem);
+        menu.x = 0;
+        menu.y = 0;
+        this.addChild(menu, 1);
+        return true;
+    }
+});
+
+var TitleScene = cc.Scene.extend({
+    onEnter:function () {
+        this._super();
+        var layer = new TitleLayer();
+        this.addChild(layer);
+    }
+});
diff --git a/src/resource.js b/src/resource.js
index 00cd775..2f3b84c 100644
--- a/src/resource.js
+++ b/src/resource.js
@@ -2,7 +2,10 @@ var res = {
     HelloWorld_png : "res/HelloWorld.png",
     CloseNormal_png : "res/CloseNormal.png",
     CloseSelected_png : "res/CloseSelected.png",
-    nc_png : "res/nc.png"
+    nc_png : "res/nc.png",
+    title_jpg : "res/title.jpg",
+    game_start_normal_png : "res/game_start_normal.png",
+    game_start_selected_png : "res/game_start_selected.png"
 };

 var g_resources = [
@@ -10,7 +13,10 @@ var g_resources = [
     res.HelloWorld_png,
     res.CloseNormal_png,
     res.CloseSelected_png,
-    res.nc_png
+    res.nc_png,
+    res.title_jpg,
+    res.game_start_normal_png,
+    res.game_start_selected_png

     //plist

リソースとしてタイトル画像、スタートボタンの通常時とタップ中の画像を追加し、それらを使った TitleLayer を作り、それを配置するだけの単純な TitleScene を作った。

ほとんど初期状態の HelloWorldScene と変わらない構成になっている。ボタン画像はこのサイトで適当に作った。

真面目に映える感じのタイトルにするならもう少し動かしたりとかタイトルっぽく振る舞う必要がありそう。

ゲームオーバーの処理も入れる

タイトル画面を作ったついでに、ゲームオーバーの処理も入れてしまうことにする。

この画面はリスタートとタイトル画面に戻ることができるようにする。

diff --git a/res/restart_normal.png b/res/restart_normal.png
new file mode 100644
index 0000000..a1105f7
Binary files /dev/null and b/res/restart_normal.png differ
diff --git a/res/restart_selected.png b/res/restart_selected.png
new file mode 100644
index 0000000..d953a99
Binary files /dev/null and b/res/restart_selected.png differ
diff --git a/res/return_to_title_normal.png b/res/return_to_title_normal.png
new file mode 100644
index 0000000..de11728
Binary files /dev/null and b/res/return_to_title_normal.png differ
diff --git a/res/return_to_title_selected.png b/res/return_to_title_selected.png
new file mode 100644
index 0000000..af5b3c2
Binary files /dev/null and b/res/return_to_title_selected.png differ
diff --git a/src/app.js b/src/app.js
index e58c103..0c185f2 100644
--- a/src/app.js
+++ b/src/app.js
@@ -61,6 +61,62 @@ var HelloWorldLayer = cc.Layer.extend({
     }
 });

+var GameOverLayer = cc.Layer.extend({
+    ctor:function () {
+        this._super();
+        var size = cc.director.getWinSize();
+        var sprite = cc.Sprite.create(res.title_jpg);
+        sprite.attr({
+            x: size.width * 0.5,
+            y: size.height * 0.5,
+            opacity: 0
+        });
+        this.addChild(sprite, 0);
+
+        var restartItem = cc.MenuItemImage.create(
+            res.restart_normal_png,
+            res.restart_selected_png,
+            function () {
+                cc.director.runScene(cc.TransitionFade.create(0.5, new HelloWorldScene()));
+            }, this);
+        restartItem.attr({
+            x: size.width * 0.5,
+            y: 160,
+            anchorX: 0.5,
+            anchorY: 0.5
+        });
+        var returnToTitleItem = cc.MenuItemImage.create(
+            res.return_to_title_normal_png,
+            res.return_to_title_selected_png,
+            function () {
+                cc.director.runScene(cc.TransitionFade.create(0.5, new TitleScene()));
+            }, this);
+        returnToTitleItem.attr({
+            x: size.width * 0.5,
+            y: 80,
+            anchorX: 0.5,
+            anchorY: 0.5
+        });
+
+        var menu = cc.Menu.create([restartItem, returnToTitleItem]);
+        menu.attr({
+          x: 0,
+          y: 0,
+          opacity: 0,
+          enabled: false,
+        });
+        this.addChild(menu, 1);
+        sprite.runAction(cc.FadeIn.create(0.5));
+        menu.runAction(cc.Sequence.create(
+          cc.DelayTime.create(0.5),
+          cc.FadeIn.create(0.5),
+          cc.CallFunc.create(function(){ this.enabled = true; }, menu)
+        ));
+
+        return true;
+    }
+});
+
 var MyShipLayer = cc.Layer.extend({
     sprite:null,
     vy: 3,
@@ -191,7 +247,9 @@ var HelloWorldScene = cc.Scene.extend({
     gameover:function() {
       this.unscheduleUpdate();
       cc.eventManager.removeListener(this);
-      cc.director.runScene(cc.TransitionFade.create(0.5, new HelloWorldScene()));
+
+      var layer = new GameOverLayer();
+      this.addChild(layer);
     }
 });

diff --git a/src/resource.js b/src/resource.js
index 2f3b84c..574ab3e 100644
--- a/src/resource.js
+++ b/src/resource.js
@@ -5,7 +5,11 @@ var res = {
     nc_png : "res/nc.png",
     title_jpg : "res/title.jpg",
     game_start_normal_png : "res/game_start_normal.png",
-    game_start_selected_png : "res/game_start_selected.png"
+    game_start_selected_png : "res/game_start_selected.png",
+    restart_normal_png : "res/restart_normal.png",
+    restart_selected_png : "res/restart_selected.png",
+    return_to_title_normal_png : "res/return_to_title_normal.png",
+    return_to_title_selected_png : "res/return_to_title_selected.png"
 };

 var g_resources = [
@@ -16,7 +20,11 @@ var g_resources = [
     res.nc_png,
     res.title_jpg,
     res.game_start_normal_png,
-    res.game_start_selected_png
+    res.game_start_selected_png,
+    res.restart_normal_png,
+    res.restart_selected_png,
+    res.return_to_title_normal_png,
+    res.return_to_title_selected_png

     //plist

タイトル画面とほとんど一緒。本当はゲームオーバーっぽい画面を出すところだけどリソースを使いまわしてタイトルと同じ画像を出している。

ちょっと違うのは、ボタンが2つあるところと、フェードインエフェクトが付いているところ。そしてフェードインの処理は画像のあとボタンがフェードインするようになっていて、完全に表示されるまでの間は enabled を false にしておくことで、間違って押すのを防止している。

ゲームオーバー画面はゲームプレイ中にボタンが現れる感じになるので、ゲームオーバーになったことに気付かないまま間違えてボタンを押してしまう可能性がありそうだったのでボタンが有効になるまでの時間を少し遅くした。とはいえ1秒でも足りない気もするので、ちゃんと死亡エフェクトを見せるのが正しい気もする。

あと、この追加によって勘違いによるバグがあったのを見つけたので修正した。

diff --git a/src/app.js b/src/app.js
index 0c185f2..c2fa56f 100644
--- a/src/app.js
+++ b/src/app.js
@@ -165,6 +165,7 @@ var BlockLayer = cc.Layer.extend({
 var HelloWorldScene = cc.Scene.extend({
     myShip:null,
     blocks:null,
+    el:null,
     onEnter:function () {
         this._super();
         var size = cc.director.getWinSize();
@@ -199,11 +200,12 @@ var HelloWorldScene = cc.Scene.extend({
           this.blocks.push(bl);
         }

-        cc.eventManager.addListener({
+        this.el = cc.EventListener.create({
             event: cc.EventListener.TOUCH_ONE_BY_ONE,
             swallowTouches: true,
             onTouchBegan: this.onTap,
-        }, this)
+        });
+        cc.eventManager.addListener(this.el, this);
         this.scheduleUpdateWithPriority(10);
     },
     onTap:function(touch, event) {
@@ -246,7 +248,7 @@ var HelloWorldScene = cc.Scene.extend({
     },
     gameover:function() {
       this.unscheduleUpdate();
-      cc.eventManager.removeListener(this);
+      cc.eventManager.removeListener(this.el);

       var layer = new GameOverLayer();
       this.addChild(layer);

イベントリスナーの削除は cc.eventManager.removeListener を呼んだ時点では失敗していて、シーン自体が入れ替わった時に合わせて削除されていたために成功と勘違いしていた。正しく削除するためには cc.EventListener.create で作成したインスタンスを渡さないといけなかったようだ。

そして Android 版で動かそうとしたところ "Invalid Native Object" というエラーで失敗したため以下の修正を行った。

diff --git a/src/app.js b/src/app.js
index c2fa56f..e625506 100644
--- a/src/app.js
+++ b/src/app.js
@@ -98,7 +98,7 @@ var GameOverLayer = cc.Layer.extend({
             anchorY: 0.5
         });

-        var menu = cc.Menu.create([restartItem, returnToTitleItem]);
+        var menu = cc.Menu.create(restartItem, returnToTitleItem);
         menu.attr({
           x: 0,
           y: 0,

配列のネイティブオブジェクトの処理に失敗したのかもしれないと思い、実装を確認してみたところ可変長引数でも受け取れるような構造になっていたのでそのまま渡すことで動くようになった。

また、致命的な問題ではないもののどうやらメニューのフェードインも上手く動いていないようだ。Cocos2dx との挙動の違いがあるんだろうか。

今回はあまり目新しい変化はなくブロック登場時のバグを注入しただけに見える気もするが、今回までの進捗はこちら。

Cocos2d-JS 触り始めた2

2014-07-17T02:50:00.000+09:00

前回の記事ではデモプロジェクトを少し触って大体の雰囲気を掴んだ。

今回はもう少し使い込んでみるために、以前作った簡単なゲームを Cocos2d-JS 上で動くよう移植してみることにする。

このゲームはスペースキーを押すとジャンプするだけのいわゆるところのワンキーゲームで、邪魔なブロックの登場パターンはランダムながら毎回同じシード値で生成しているので、練習するとその分だけスコアが伸びる感じのゲームになっている。

死んだらページをリロードするしかなくなったり、BGM を YouTube の動画で再生しているけどループしなかったりとか、読み込み完了前にゲームを開始すると動画再生が上手く始まらなかったりとか、つくりは色々投げやりであるものの、まあ枝葉の問題なので放置している。この記事で当時作っていた頃の変更履歴的なものを追える。

移植と言っても完全な再現とかではなく、似たような動きをする程度のものにしようと思う。

現在までの成果物はこんな感じ。
クリックやタップするとジャンプでき、ブロックを避けることができる。

プロジェクトを準備する

前回までの変更は一旦全て忘れて、改めて cocos new -l js NyanCat として新規にプロジェクトを作成した。
今回のゲームは横画面の方が向いているので、前回行ったような画面の向きの変更などは行わない。

また、本格的にものを作るに当たり、今回からデータは git で管理することにする。
そのため、まず新規にプロジェクトを作成した直後の状態でコミットし、その後 Android 版のビルドを行い、生成されたファイルのうちコミットに含める必要がなさそうなファイルを .gitignore で除外した上で作業を始める。

ゲームのメイン画面を作る

前回適当にいじくり回したことで、シーン切り替えの方法は概ね分かった。
タイトル画面を作ることに対しては特に難しい課題もないため、いきなりゲームのメイン画面を作っていくことにする。

自機を作る

猫のキャラを表示させるため NyanCat/res/nc.png にファイルを配置し、NyanCat/src/resource.js を以下のように改変した。

diff --git a/res/nc.png b/res/nc.png
new file mode 100644
index 0000000..10e8307
Binary files /dev/null and b/res/nc.png differ
diff --git a/src/resource.js b/src/resource.js
index 508554a..00cd775 100644
--- a/src/resource.js
+++ b/src/resource.js
@@ -1,14 +1,16 @@
 var res = {
     HelloWorld_png : "res/HelloWorld.png",
     CloseNormal_png : "res/CloseNormal.png",
-    CloseSelected_png : "res/CloseSelected.png"
+    CloseSelected_png : "res/CloseSelected.png",
+    nc_png : "res/nc.png"
 };

 var g_resources = [
     //image
     res.HelloWorld_png,
     res.CloseNormal_png,
-    res.CloseSelected_png
+    res.CloseSelected_png,
+    res.nc_png

     //plist

そして追加した画像を HelloWorldScene に自機用のレイヤーとして追加したい。
なので、NyanCat/src/app.js に MyShipLayer を追加し、HelloWorldScene に MyShipLayer を追加するためのコードを追加。

diff --git a/src/app.js b/src/app.js
index 1f2857e..3a4c7e4 100644
--- a/src/app.js
+++ b/src/app.js
@@ -61,11 +61,22 @@ var HelloWorldLayer = cc.Layer.extend({
     }
 });

+var MyShipLayer = cc.Layer.extend({
+    sprite:null,
+    ctor:function () {
+        this._super();
+        this.sprite = cc.Sprite.create(res.nc_png);
+        this.addChild(this.sprite, 0);
+        return true;
+    }
+});
+
 var HelloWorldScene = cc.Scene.extend({
     onEnter:function () {
         this._super();
         var layer = new HelloWorldLayer();
         this.addChild(layer);
+        var myShip = new MyShipLayer();
+        this.addChild(myShip);
     }
 });

この時点で画面の左下に自機が少し見えるようになった。

まだ静止状態なので動かしたいが、この自機はユーザーの入力に反応して動かす必要があるので、サンプルで動いていたアニメーションのように未来の動きを予め登録しておくようなことはできない。

そのためこの辺のチュートリアルでも使われている update メソッドを追加して、毎フレームの処理として動きを記述する。更にコンストラクタで this.scheduleUpdate を呼んで、毎フレーム update が呼ばれるようにする。

diff --git a/src/app.js b/src/app.js
index 3a4c7e4..23a3322 100644
--- a/src/app.js
+++ b/src/app.js
@@ -67,7 +67,12 @@ var MyShipLayer = cc.Layer.extend({
         this._super();
         this.sprite = cc.Sprite.create(res.nc_png);
         this.addChild(this.sprite, 0);
+        this.scheduleUpdate();
         return true;
+    },
+    update:function(dt) {
+        this.x += 1;
+        this.y += 1;
     }
 });

移動処理は取りあえず適当に直線移動。実行すると、左下から右上に向かって毎フレーム 1px ずつ動くようになる。

毎フレームの処理によってアニメーションが一応できたし、後はユーザーの入力によって反応して動くようにすれば、基本的な自機の振る舞いは完成する。

これもチュートリアルを参考にして Scene のタップに反応できるようにする。

diff --git a/src/app.js b/src/app.js
index 23a3322..2e324b7 100644
--- a/src/app.js
+++ b/src/app.js
@@ -83,5 +83,15 @@ var HelloWorldScene = cc.Scene.extend({
         this.addChild(layer);
         var myShip = new MyShipLayer();
         this.addChild(myShip);
-    }
+        cc.eventManager.addListener({
+            event: cc.EventListener.TOUCH_ONE_BY_ONE,
+            swallowTouches: true,
+            onTouchBegan: this.onTap,
+        }, this)
+    },
+    onTap:function(touch, event) {
+        var pos = touch.getLocation();
+        cc.log(pos);
+        return true;
+    },
 });

ひとまず、タップされたら座標をログに吐くようにしてみた。
実行してみると、タップ位置が左下を 0, 0 とした値で取得できているのが確認できる。

動きの流れのイメージとしてはシーンをタップしたらシーンが MyShipLayer にジャンプしろと伝達する感じなので、そうなるようにコードを修正していく。

MyShipLayer に jump メソッドを新しく追加し、タップされた時にそのメソッドを呼び出すようにする。

diff --git a/src/app.js b/src/app.js
index 2e324b7..dddb3d2 100644
--- a/src/app.js
+++ b/src/app.js
@@ -73,16 +73,20 @@ var MyShipLayer = cc.Layer.extend({
     update:function(dt) {
         this.x += 1;
         this.y += 1;
+    },
+    jump:function() {
+      this.y += 10;
     }
 });

 var HelloWorldScene = cc.Scene.extend({
+    myShip:null,
     onEnter:function () {
         this._super();
         var layer = new HelloWorldLayer();
         this.addChild(layer);
-        var myShip = new MyShipLayer();
-        this.addChild(myShip);
+        this.myShip = new MyShipLayer();
+        this.addChild(this.myShip);
         cc.eventManager.addListener({
             event: cc.EventListener.TOUCH_ONE_BY_ONE,
             swallowTouches: true,
@@ -90,8 +94,7 @@ var HelloWorldScene = cc.Scene.extend({
         }, this)
     },
     onTap:function(touch, event) {
-        var pos = touch.getLocation();
-        cc.log(pos);
+        event.getCurrentTarget().myShip.jump();
         return true;
     },
 });

これで実行すると、右上に動き続けている自機がちょっと大きめに上に動くようになった。

期待していた流れが完成したので、あとは自機の動きの振る舞いを変えていく。

まずは自機の初期位置を左中央に変更する。

diff --git a/src/app.js b/src/app.js
index dddb3d2..69e9ee8 100644
--- a/src/app.js
+++ b/src/app.js
@@ -87,6 +87,10 @@ var HelloWorldScene = cc.Scene.extend({
         this.addChild(layer);
         this.myShip = new MyShipLayer();
         this.addChild(this.myShip);
+        this.myShip.attr({
+          x: 40,
+          y: cc.director.getWinSize().height / 2
+        });
         cc.eventManager.addListener({
             event: cc.EventListener.TOUCH_ONE_BY_ONE,
             swallowTouches: true,

次に動きを自由落下っぽく変更する。

diff --git a/src/app.js b/src/app.js
index 69e9ee8..0d34a6d 100644
--- a/src/app.js
+++ b/src/app.js
@@ -63,6 +63,7 @@ var HelloWorldLayer = cc.Layer.extend({

 var MyShipLayer = cc.Layer.extend({
     sprite:null,
+    vy: 0,
     ctor:function () {
         this._super();
         this.sprite = cc.Sprite.create(res.nc_png);
@@ -71,8 +72,8 @@ var MyShipLayer = cc.Layer.extend({
         return true;
     },
     update:function(dt) {
-        this.x += 1;
-        this.y += 1;
+        this.y += this.vy;
+        this.vy -= 0.09;
     },
     jump:function() {
       this.y += 10;

y を加算すると上方向に移動することになるので、値が下がっていけば落下の動きが表現できる。

このコードでは vy が 0.09 ずつ値が小さくなっていくので、結果的に落ちれば落ちるほど落下速度が上がっていく。0.09 という値は適当。

あとはジャンプと、そのついでにゲーム開始直後にいきなり落ち始める代わりに最初だけはちょっとジャンプっぽく見せるように変更する。

diff --git a/src/app.js b/src/app.js
index 0d34a6d..a7817fd 100644
--- a/src/app.js
+++ b/src/app.js
@@ -63,7 +63,7 @@ var HelloWorldLayer = cc.Layer.extend({

 var MyShipLayer = cc.Layer.extend({
     sprite:null,
-    vy: 0,
+    vy: 3,
     ctor:function () {
         this._super();
         this.sprite = cc.Sprite.create(res.nc_png);
@@ -76,7 +76,7 @@ var MyShipLayer = cc.Layer.extend({
         this.vy -= 0.09;
     },
     jump:function() {
-      this.y += 10;
+      this.vy = 3;
     }
 });

どちらも単純に vy を 3 にするだけ。vy は毎フレーム -0.09 されていくので、少し経てばまたすぐ落下傾向の動きになる。

まだ衝突周りの判定はできていないが、自機としては概ねそれっぽい動きが完成した。

邪魔なブロックを作る

邪魔なブロックは、可変サイズの長方形プリミティブオブジェクト的な何かである。
ゲームの実行中に大きさを動的に決め、そのサイズでオブジェクトを作る必要がある。

このようなオブジェクトは cc.DrawNode を使って実現できるようだ。

まずは BlockLayer を作って HelloWorldScene に追加してみることにする。

diff --git a/src/app.js b/src/app.js
index a7817fd..8059657 100644
--- a/src/app.js
+++ b/src/app.js
@@ -80,6 +80,16 @@ var MyShipLayer = cc.Layer.extend({
     }
 });

+var BlockLayer = cc.Layer.extend({
+    d:null,
+    ctor:function () {
+        this._super();
+        this.d = cc.DrawNode.create();
+        this.addChild(this.d, 0);
+        return true;
+    }
+});
+
 var HelloWorldScene = cc.Scene.extend({
     myShip:null,
     onEnter:function () {
@@ -92,6 +102,8 @@ var HelloWorldScene = cc.Scene.extend({
           x: 40,
           y: cc.director.getWinSize().height / 2
         });
+        var block = new BlockLayer();
+        this.addChild(block);
         cc.eventManager.addListener({
             event: cc.EventListener.TOUCH_ONE_BY_ONE,
             swallowTouches: true,

最終的な登場個数は1個ではないが、取りあえず実験として1つだけ追加した。

次に長方形を描くのだが、大きさや色は BlockLayer の外から渡せるようにしたい。また、一度作られたもののサイズや色が変わる予定はないので、今回はコンストラクタで渡せるような形にする。

diff --git a/src/app.js b/src/app.js
index 8059657..5c6d1a0 100644
--- a/src/app.js
+++ b/src/app.js
@@ -82,9 +82,11 @@ var MyShipLayer = cc.Layer.extend({

 var BlockLayer = cc.Layer.extend({
     d:null,
-    ctor:function () {
+    ctor:function (width, height, fillcolor) {
         this._super();
         this.d = cc.DrawNode.create();
+        var hw = width * 0.5, hh = height * 0.5;
+        this.d.drawRect(cc.p(-hw, -hh), cc.p(hw, hh), fillcolor);
         this.addChild(this.d, 0);
         return true;
     }
@@ -102,7 +104,7 @@ var HelloWorldScene = cc.Scene.extend({
           x: 40,
           y: cc.director.getWinSize().height / 2
         });
-        var block = new BlockLayer();
+        var block = new BlockLayer(100, 100, cc.color(128,128,128,255));
         this.addChild(block);
         cc.eventManager.addListener({
             event: cc.EventListener.TOUCH_ONE_BY_ONE,

長方形の中央が 0, 0 になるように描画するようにした。

この長方形が描画されたノードを持つ BlockLayer の位置も今のところ 0, 0 なので、この状態で実行すると画面の左下に 50x50 程度の大きさの正方形が現れる。

これを適当な大きさと色で複数生成して動くようにすればいいのだが、今の表示位置は丁度自機と衝突する場所でもあるので、動かす前に当たり判定に関する処理を作り、自機との衝突を検出できるようにしてみる。

衝突の判定は取りあえずインスタンス化した MyShipLayer と BlockLayer が視野にある HelloWorldScene で行ってみることにする。

diff --git a/src/app.js b/src/app.js
index 5c6d1a0..36f3a69 100644
--- a/src/app.js
+++ b/src/app.js
@@ -111,9 +111,12 @@ var HelloWorldScene = cc.Scene.extend({
             swallowTouches: true,
             onTouchBegan: this.onTap,
         }, this)
+        this.scheduleUpdateWithPriority(10);
     },
     onTap:function(touch, event) {
         event.getCurrentTarget().myShip.jump();
         return true;
     },
+    update:function(dt) {
+    },
 });

まずはまた update メソッドを足し、毎フレーム呼ばれるようにする。

ただし今回は自機の時とは違い scheduleUpdate ではなく cheduleUpdateWithPriority を使う。scheduleUpdate は cheduleUpdateWithPriority を 0 で呼び出しているだけなのであまり大きな違いはないが、こうして優先順位を指定すると update が呼び出される順番をコントロールできる。

この点は地味ながらも非常に重要で、移動と衝突判定の順番がおかしいと表示される位置と実際に衝突する位置が噛み合わなくなってしまう。これは低速移動するオブジェクト同士ならあまり目立たないかもしれないが、高速なオブジェクトほど誤差が大きくなる。

実際に衝突判定をするにあたり注意すべき点は他にもあって、ゲームにおける当たり判定は必ずしもスプライトの表示領域とイコールである必要はなくて、少しめり込むぐらいが適しているシーンが多い。

なので、ここでは衝突判定用の領域は別に設け、そこを基準に判定していくことにする。

まずはレイヤーに setContentSize で当たり判定になるボックスのサイズを指定する。

diff --git a/src/app.js b/src/app.js
index 36f3a69..3a4628d 100644
--- a/src/app.js
+++ b/src/app.js
@@ -68,6 +68,9 @@ var MyShipLayer = cc.Layer.extend({
         this._super();
         this.sprite = cc.Sprite.create(res.nc_png);
         this.addChild(this.sprite, 0);
+        var bbox = cc.size(18, 12);
+        this.sprite.setPosition(bbox.width * 0.5, bbox.height * 0.5);
+        this.setContentSize(bbox);
         this.scheduleUpdate();
         return true;
     },
@@ -88,6 +91,9 @@ var BlockLayer = cc.Layer.extend({
         var hw = width * 0.5, hh = height * 0.5;
         this.d.drawRect(cc.p(-hw, -hh), cc.p(hw, hh), fillcolor);
         this.addChild(this.d, 0);
+        var bbox = cc.size(width, height);
+        this.d.setPosition(bbox.width * 0.5, bbox.height * 0.5);
+        this.setContentSize(bbox);
         return true;
     }
 });

MyShipLayer では自機画像より少し小さいサイズ、BlockLayer ではそのままのサイズとした。

レイヤーは setContentSize をしなかった場合デフォルトではスクリーンと同じサイズになっているのだが、具体的に指定するとそのサイズとして振る舞うようになるようだ。

これで当たり判定に使えるボックスが出来上がったので、実際に cc.rectIntersectsRect で判定を行ってみる。

diff --git a/src/app.js b/src/app.js
index 3a4628d..e8f4e8d 100644
--- a/src/app.js
+++ b/src/app.js
@@ -100,6 +100,7 @@ var BlockLayer = cc.Layer.extend({

 var HelloWorldScene = cc.Scene.extend({
     myShip:null,
+    block:null,
     onEnter:function () {
         this._super();
         var layer = new HelloWorldLayer();
@@ -110,8 +111,8 @@ var HelloWorldScene = cc.Scene.extend({
           x: 40,
           y: cc.director.getWinSize().height / 2
         });
-        var block = new BlockLayer(100, 100, cc.color(128,128,128,255));
-        this.addChild(block);
+        this.block = new BlockLayer(100, 100, cc.color(128,128,128,255));
+        this.addChild(this.block);
         cc.eventManager.addListener({
             event: cc.EventListener.TOUCH_ONE_BY_ONE,
             swallowTouches: true,
@@ -124,5 +125,8 @@ var HelloWorldScene = cc.Scene.extend({
         return true;
     },
     update:function(dt) {
+      if (cc.rectIntersectsRect(this.myShip.getBoundingBox(), this.block.getBoundingBox())) {
+        cc.log('hit');
+      }
     },
 });

当たっている間だけ、毎フレーム hit というログが出続けるようになった。

当たった時にどう振る舞うのか、という実際のところについてはひとまず後回しにして、先にブロックがたくさん出てくる処理を書いていく。

この動きに関してはユーザーの入力に関わらず同じ振る舞いをさせられるので、その側面から見た場合 update で自分で位置を管理する必要はないが、フレーム落ちした時などに自機は落ちた分だけ遅くなるのにブロックは同じ速度で進行してくると不公平な感じがするので、その辺りの理由からこのブロックも update で位置を更新していく形にしてみる。

まずはブロックを100個に増やしてみる。

diff --git a/src/app.js b/src/app.js
index e8f4e8d..5c133bd 100644
--- a/src/app.js
+++ b/src/app.js
@@ -100,7 +100,7 @@ var BlockLayer = cc.Layer.extend({

 var HelloWorldScene = cc.Scene.extend({
     myShip:null,
-    block:null,
+    blocks:[],
     onEnter:function () {
         this._super();
         var layer = new HelloWorldLayer();
@@ -111,8 +111,22 @@ var HelloWorldScene = cc.Scene.extend({
           x: 40,
           y: cc.director.getWinSize().height / 2
         });
-        this.block = new BlockLayer(100, 100, cc.color(128,128,128,255));
-        this.addChild(this.block);
+
+        for (var i = 0, bl; i < 100; ++i) {
+          bl = new BlockLayer(
+            40+Math.random()*60,
+            40+Math.random()*60,
+            cc.color(
+              128+Math.random()*64,
+              128+Math.random()*64,
+              128+Math.random()*64,
+              255
+            )
+          );
+          this.addChild(bl);
+          this.blocks.push(bl);
+        }
+
         cc.eventManager.addListener({
             event: cc.EventListener.TOUCH_ONE_BY_ONE,
             swallowTouches: true,
@@ -125,8 +139,11 @@ var HelloWorldScene = cc.Scene.extend({
         return true;
     },
     update:function(dt) {
-      if (cc.rectIntersectsRect(this.myShip.getBoundingBox(), this.block.getBoundingBox())) {
+      var myShipBB = this.myShip.getBoundingBox();
+      for(var i = this.blocks.length - 1; i >= 0; --i) {
+        if (cc.rectIntersectsRect(myShipBB, this.blocks[i].getBoundingBox())) {
           cc.log('hit');
         }
+      }
     },
 });

ランダムな大きさ、ランダムな色で100個のブロックを生成するようにした。まだ初期位置の指定や移動の処理が入っていないので、この段階では左下に大量のブロックが貯まるだけ。

ここから更に、ブロックに移動機能をつけてみる。

diff --git a/src/app.js b/src/app.js
index 5c133bd..21c2666 100644
--- a/src/app.js
+++ b/src/app.js
@@ -85,6 +85,8 @@ var MyShipLayer = cc.Layer.extend({

 var BlockLayer = cc.Layer.extend({
     d:null,
+    vx: 0,
+    vy: 0,
     ctor:function (width, height, fillcolor) {
         this._super();
         this.d = cc.DrawNode.create();
@@ -94,7 +96,12 @@ var BlockLayer = cc.Layer.extend({
         var bbox = cc.size(width, height);
         this.d.setPosition(bbox.width * 0.5, bbox.height * 0.5);
         this.setContentSize(bbox);
+        this.scheduleUpdate();
         return true;
+    },
+    update:function(dt) {
+        this.x += this.vx;
+        this.y += this.vy;
     }
 });

これは既に説明する必要がないほど既に通ったパターンなので省く。

移動機能が付いたが vx と vy は 0 のままなので、初期化時に指定するようにする。

diff --git a/src/app.js b/src/app.js
index 21c2666..eb3d3ea 100644
--- a/src/app.js
+++ b/src/app.js
@@ -110,13 +110,14 @@ var HelloWorldScene = cc.Scene.extend({
     blocks:[],
     onEnter:function () {
         this._super();
+        var size = cc.director.getWinSize();
         var layer = new HelloWorldLayer();
         this.addChild(layer);
         this.myShip = new MyShipLayer();
         this.addChild(this.myShip);
         this.myShip.attr({
           x: 40,
-          y: cc.director.getWinSize().height / 2
+          y: size.height / 2
         });

         for (var i = 0, bl; i < 100; ++i) {
@@ -130,6 +131,12 @@ var HelloWorldScene = cc.Scene.extend({
               255
             )
           );
+          bl.attr({
+            x: size.width+Math.random()*size.width,
+            y: -bl.height+Math.random()*(size.height+bl.height),
+            vx: -1-Math.random()*3,
+            vy: -0.5+Math.random()
+          });
           this.addChild(bl);
           this.blocks.push(bl);
         }

x 座標は同じ大きさの画面が横に2画面続いてるイメージで、見えてないエリアにだけランダムで配置している。y 座標は画面の範囲内のどこか。vx と vy は適当な値を指定した。

これで実行すると、わりと濃い密度のブロックの大群が押し寄せてきて、大体避けられそうにない感じになる。

ただ、このままでは通り過ぎた後はもう二度と再登場することはないのであまりゲームにならない。

なので、画面の左端を抜けたブロックは右端のランダムな上下位置へワープさせて再登場させることにする。

diff --git a/src/app.js b/src/app.js
index eb3d3ea..2119bc1 100644
--- a/src/app.js
+++ b/src/app.js
@@ -154,10 +154,18 @@ var HelloWorldScene = cc.Scene.extend({
     },
     update:function(dt) {
       var myShipBB = this.myShip.getBoundingBox();
-      for(var i = this.blocks.length - 1; i >= 0; --i) {
-        if (cc.rectIntersectsRect(myShipBB, this.blocks[i].getBoundingBox())) {
+      var size = cc.director.getWinSize();
+      for(var i = this.blocks.length - 1, bl; i >= 0; --i) {
+        bl = this.blocks[i];
+        if (cc.rectIntersectsRect(myShipBB, bl.getBoundingBox())) {
           cc.log('hit');
         }
+        if (bl.x+bl.width < 0) {
+          bl.attr({
+            x: size.width,
+            y: -bl.height+Math.random()*(size.height+bl.height)
+          });
+        }
       }
     },
 });

どこで実装するのか若干迷ったが、ブロックレイヤーが表示領域のサイズを見て移動する処理を行うのは何となく気持ち悪い気がしたのでひとまずシーン側の update で行うようにした。

これで地獄絵図みたいな状態が延々と続くようになった。少しブロック数を減らしたりして、ゲームバランスをマシにしてみる。

diff --git a/src/app.js b/src/app.js
index 2119bc1..a00e2c4 100644
--- a/src/app.js
+++ b/src/app.js
@@ -76,7 +76,7 @@ var MyShipLayer = cc.Layer.extend({
     },
     update:function(dt) {
         this.y += this.vy;
-        this.vy -= 0.09;
+        this.vy -= 0.1;
     },
     jump:function() {
       this.vy = 3;
@@ -120,9 +120,9 @@ var HelloWorldScene = cc.Scene.extend({
           y: size.height / 2
         });

-        for (var i = 0, bl; i < 100; ++i) {
+        for (var i = 0, bl; i < 16; ++i) {
           bl = new BlockLayer(
-            40+Math.random()*60,
+            30+Math.random()*60,
             40+Math.random()*60,
             cc.color(
               128+Math.random()*64,
@@ -134,8 +134,8 @@ var HelloWorldScene = cc.Scene.extend({
           bl.attr({
             x: size.width+Math.random()*size.width,
             y: -bl.height+Math.random()*(size.height+bl.height),
-            vx: -1-Math.random()*3,
-            vy: -0.5+Math.random()
+            vx: -0.5-Math.random()*3,
+            vy: -0.25+Math.random()*0.5
           });
           this.addChild(bl);
           this.blocks.push(bl);

少しマシになってきた。

ダメージ感がないので、ブロックに接触した時にログにメッセージを出力しているのをやめて、同じシーンをもう一度読み込むようにしてゲームオーバー画面の代わりとしてみる。

その作業をしている時にひとつバグを見つけたので修正した。

diff --git a/src/app.js b/src/app.js
index a00e2c4..bbed316 100644
--- a/src/app.js
+++ b/src/app.js
@@ -107,7 +107,7 @@ var BlockLayer = cc.Layer.extend({

 var HelloWorldScene = cc.Scene.extend({
     myShip:null,
-    blocks:[],
+    blocks:null,
     onEnter:function () {
         this._super();
         var size = cc.director.getWinSize();
@@ -120,6 +120,7 @@ var HelloWorldScene = cc.Scene.extend({
           y: size.height / 2
         });

+        this.blocks = [];
         for (var i = 0, bl; i < 16; ++i) {
           bl = new BlockLayer(
             30+Math.random()*60,

onEnter のタイミングで blocks を初期化せず、インスタンス化前に作った配列のインスタンスに push してしまっていたので、全ての HelloWorldScene でこの配列が共有されてしまうバグがあった。

シーンを切り替えても挙動がおかしいのが原因でこのバグに気付いた。

で、実際のシーン切り替えのコード。

diff --git a/src/app.js b/src/app.js
index bbed316..28cd4bc 100644
--- a/src/app.js
+++ b/src/app.js
@@ -159,7 +159,10 @@ var HelloWorldScene = cc.Scene.extend({
       for(var i = this.blocks.length - 1, bl; i >= 0; --i) {
         bl = this.blocks[i];
         if (cc.rectIntersectsRect(myShipBB, bl.getBoundingBox())) {
-          cc.log('hit');
+          this.unscheduleUpdate();
+          cc.eventManager.removeListener(this);
+          cc.director.runScene(cc.TransitionFade.create(0.5, new HelloWorldScene()));
+          return;
         }
         if (bl.x+bl.width < 0) {
           bl.attr({

まず unscheduleUpdate でこれ以上 update が呼ばれないようにする。これをやらないと自機がブロックに衝突後そのままめり込んでいき何度も死亡判定されてしまう。

次に cc.eventManager.removeListener でイベントリスナーを削除する。これをやらないと使わなくなっているのにずっと Listen したままになってしまう。

シーン切り替えのコードは前回試したコードと全く同じで、これ以上ループを処理必要がないのが明白なので最後はそのまま return で抜けている。

この辺はもっと本格的にゲームオーバー画面とか、死亡時のエフェクトとか、何らかのリアクションを作り込む時に見なおしたほうが良さそうだ。

記事の最初の方でもリンクを置いているが、ここまでの成果物はこちら。
クリックやタップするとジャンプでき、ブロックを避けることができる。ブロックに衝突した場合は強制的にリセットされて最初からやり直しになる。

まだ最初から入っている HelloWorld の動きを一切消さずに書いてるので背景がカオスに華やか。

Cocos2d-JS 触り始めた

2014-07-15T04:47:00.000+09:00

以前 NME でゲームを作ってみたりしたことなどもあったが、巷で話題なのは Unity とか Cocos2dx 辺りで、この辺は有名だしもっと色々便利なんだろうなあと思っていた。最近会社を辞めて少し時間ができたので、そんなに情報が多くなくて面白そうな Cocos2d-JS を触ってみようかと思ったので、合わせて日誌的にブログを書いてみることにする。

何も知らない状態から探り探りやっているので、書いている内容が正確ではない可能性があります。
俺っていつもそう。

インストール

ひとまず「ブラウザで動くものが出来上がればいいかな」と思っていたものの、Android デバイスを持っているのでせっかくだし目標としては Web 版と Android 版を書き出す方向で進めてみたい。

作業環境は Windows8.1 64bit 版。まず Cocos2d-JS v3.0rc0 と、Android SDK、Android NDK、Apache Ant、Python 辺りを導入。NME の時はこの辺はインストーラがほとんど自動で全てをやってくれたので、それに比べるとわりと面倒くさい。

それぞれをインストールしたらこちらのページを参考に setup.py を実行し、環境変数の設定について聞かれるので適宜設定し、手順の通り MyGame を作って

cocos run -p web

してみると確かにブラウザが開き簡単なサンプルが動いているのを確認できた。
ブラウザを閉じ今度は Android 端末を USB デバッグを有効にした状態で接続し、

cocos run -p android

すると C++ ソースファイルのコンパイルが始まり、そのまま3年の月日が流れた。それは嘘だが、しばらく待つと端末にアプリが転送され難なく起動した。これ以降はコンパイル済みのライブラリをリンクするだけで済むようになるので、実行までの所要時間もだいぶ減るようだ。

生成されたコードを眺めてみる

生成されたファイル群を見てみると、JavaScript ソースファイルは MyGame/main.js MyGame/src/resource.js MyGame/src/app.js の3つのファイルがあるようだ。

MyGame/main.js

cc.game.onStart = function(){
    cc.view.setDesignResolutionSize(800, 450, cc.ResolutionPolicy.SHOW_ALL);
 cc.view.resizeWithBrowserSize(true);
    //load resources
    cc.LoaderScene.preload(g_resources, function () {
        cc.director.runScene(new HelloWorldScene());
    }, this);
};
cc.game.run();

このファイルはゲームメイン処理実行において一番最初に呼ばれるであろう cc.game オブジェクトが持つ onStart イベントのイベントハンドラを設定し、ゲームのメイン処理が開始されるよう cc.game.run を呼んでいるように見える。
設定したイベントハンドラ内では、画面の大きさを設定し、ブラウザの大きさに合わせて表示領域を拡大縮小するように設定し、更に g_resources を読み込み、恐らくその読み込み完了時に呼ばれるコールバック関数で HelloWorldScene シーンを作り、そのシーンの実行を開始していると思われる。

それを検証するため試しに cc.view.setDesignResolutionSize に渡している数字を逆にすると縦長の画面になったり、cc.view.resizeWithBrowserSize を false で呼ぶとブラウザの表示領域が狭くても縮小表示されないことを確認できた。
ただし縦長の画面にするだけでは Android のアプリケーションとしては横向き（landscape）から縦向き（portrait）に切り替わるわけではないようだ。また、画面周りの設定は厳密にはここだけに存在するわけではないようなのでもう少し掘り下げて探してみて、一応 MyGame/index.html の canvas タグの幅と高さと、MyGame/frameworks/runtime-src/proj.android/AndroidManifest.xml 内の android:screenOrientation="landscape" を android:screenOrientation="portrait" に変更してみたところ、Android アプリ上で縦画面として動くようになった。

canvas タグの大きさはブラウザで cc.game.onStart が呼ばれる前のタイミングでどの程度の大きさで出すのかという話だと思う（ここを変更しなくても JavaScript ファイルの変更だけで縦長にはなっていたから）のであまり重要ではないと思う。
ただこの HTML ファイル内にも <meta name="screen-orientation" content="portrait"/> の記述があったので、この辺も必要に応じて変えたほうがいいのかも知れない（最初から portrait だったけど…）。

MyGame/src/resource.js

var res = {
    HelloWorld_png : "res/HelloWorld.png",
    CloseNormal_png : "res/CloseNormal.png",
    CloseSelected_png : "res/CloseSelected.png"
};

var g_resources = [
    //image
    res.HelloWorld_png,
    res.CloseNormal_png,
    res.CloseSelected_png

    //plist

    //fnt

    //tmx

    //bgm

    //effect
];

これは MyGame/main.js で cc.LoaderScene.preload に渡していた g_resources を定義しているファイルのようだ。
リソースの追加時はここに追記したりすれば良さそうだが、表示頻度の少ないシーン用のリソース（エンディング周りとか？）などはここに定義せずシーンを読み込む際に個別に読み込んだりした方が起動時のローディング時間を減らせるのかも知れない。

MyGame/src/app.js

var HelloWorldLayer = cc.Layer.extend({
    sprite:null,
    ctor:function () {
        //////////////////////////////
        // 1. super init first
        this._super();

        /////////////////////////////
        // 2. add a menu item with "X" image, which is clicked to quit the program
        //    you may modify it.
        // ask director the window size
        var size = cc.director.getWinSize();

        // add a "close" icon to exit the progress. it's an autorelease object
        var closeItem = cc.MenuItemImage.create(
            res.CloseNormal_png,
            res.CloseSelected_png,
            function () {
                cc.log("Menu is clicked!");
            }, this);
        closeItem.attr({
            x: size.width - 20,
            y: 20,
            anchorX: 0.5,
            anchorY: 0.5
        });

        var menu = cc.Menu.create(closeItem);
        menu.x = 0;
        menu.y = 0;
        this.addChild(menu, 1);

        /////////////////////////////
        // 3. add your codes below...
        // add a label shows "Hello World"
        // create and initialize a label
        var helloLabel = cc.LabelTTF.create("Hello World", "Arial", 38);
        // position the label on the center of the screen
        helloLabel.x = size.width / 2;
        helloLabel.y = 0;
        // add the label as a child to this layer
        this.addChild(helloLabel, 5);

        // add "HelloWorld" splash screen"
        this.sprite = cc.Sprite.create(res.HelloWorld_png);
        this.sprite.attr({
            x: size.width / 2,
            y: size.height / 2,
            scale: 0.5,
            rotation: 180
        });
        this.addChild(this.sprite, 0);

        var rotateToA = cc.RotateTo.create(2, 0);
        var scaleToA = cc.ScaleTo.create(2, 1, 1);

        this.sprite.runAction(cc.Sequence.create(rotateToA, scaleToA));
        helloLabel.runAction(cc.Spawn.create(cc.MoveBy.create(2.5, cc.p(0, size.height - 40)),cc.TintTo.create(2.5,255,125,0)));
        return true;
    }
});

var HelloWorldScene = cc.Scene.extend({
    onEnter:function () {
        this._super();
        var layer = new HelloWorldLayer();
        this.addChild(layer);
    }
});

これはゲームのメイン処理を行っているらしいファイルで、少し長い。全体としては cc.Layer を継承した HelloWorldLayer と cc.Scene を継承した HelloWorldScene を定義している。少し見てみた限りでは cc.Layer も cc.Scene も cc.Node を継承しているようだ。

HelloWorldScene では onEnter イベントの発生時に HelloWorldLayer を作成し、自身の子として追加している。MyGame/main.js では HelloWorldScene を作成しているコードがあったので、実行順序としては

cc.game の onStart イベントが発生
HelloWorldScene のインスタンスを作成
cc.director.runScene に作成したインスタンスを渡してシーン実行開始
HelloWorldScene の onEnter イベントが発生
HelloWorldLayer のインスタンスを作成
HelloWorldLayer のコンストラクタで定義したアニメーションが順次実行されていく

という感じになっていると思われる。
この辺、行番号付いてた頃の BASIC 辺りとか、HSP とか、DX ライブラリとかのようにメインループを自分で回すのではなく、知らんところで勝手にメインループ的なものは動いているので何かが起きた時に対応するコードだけを書く感じで進めていくようなイメージが基本になるので、こういうイベントドリブン型に慣れる必要があるように思う（まあブラウザで JavaScript を使ったことがあるならば自ずと触ることになったとは思うけど）。
なので HelloWorldLayer のコンストラクタで定義したアニメーションは自分で実行するんじゃなく、あくまでアニメーションの実行計画を渡しておくと、それを元にうまい具合に実行してくれる、というイメージ。

HelloWorldLayer では右下に表示されている電源ボタン、中央で回転する画像、下から上に移動していくテキストをそれぞれ作成し、自身の子として追加している。また、アニメーションの実行計画を作成し、それぞれのオブジェクトの runAction で実行開始しているようだ。
スプライトに対しては cc.Sequence.create で回転と拡大のアニメーションを連続実行するようにして登録し、テキストに対しては cc.Spawn.create でテキスト移動と色変化のアニメーションを並列実行しているようだ。

電源ボタンである closeItem を作っているところのコードでは関数を渡しているが、内容から察するにボタンがタップされた時にログメッセージを出力する処理を行っている。
確かにブラウザのデバッグコンソールを表示したり、Android ではコマンドプロンプトで adb logcat をした状態で端末でタップするとログメッセージが表示されるのを確認できた。
ちょっとした変数の内容確認などはここでも行えるようだ。

自動で生成されたプロジェクトの全体像が少し見えたような気がする。

ちょっと書き換えてみる

ひとまず cc.Scene や cc.Layer などのクラスがあることがわかった。シーンというのは恐らくタイトル画面とかプレイヤーセレクト画面などの大きな単位で、レイヤーはその画面内に登場するパーツを表現している気がする。

例えばアクションゲームを作ったとして、起動した瞬間にいきなり動き出すのではなくタイトル画面でゲームスタートボタン的なものを押してからゲームを始めるような流れを作るなら、タイトル画面のシーンとゲーム本編のシーンの2つを作り、それらを切り替えることで実現できそうに思える。

いきなりシーンを2つ作るのはちょっと面倒臭いので、既にある HelloWorldScene から HelloWorldScene に切り替えるのをやってみることにする。また、 closeItem というボタンがあるので、役割は違うものの、これをそのまま流用してログメッセージを吐く代わりにシーン切り替えを行わせてみることにする。

シーンを実行させる処理は MyGame/main.js で cc.director.runScene(new HelloWorldScene()); というコードを見かけているので、これをこのまま持ち込めば同じシーンに画面切り替えすると思われる。

        var closeItem = cc.MenuItemImage.create(
            res.CloseNormal_png,
            res.CloseSelected_png,
            function () {
                cc.log("Menu is clicked!");
                cc.director.runScene(new HelloWorldScene());
            }, this);

要するに、こんな感じでそのまま持ち込んでみる。

これを試しに実行してみると、確かにボタンを押されたタイミングでまた回転アニメーションなどが最初から始まり、シーンが1から実行されなおしている感じになった。

ただし、このままだと本当に単純に切り替わるだけで物足りない。完成度の高いゲームはほとんど全ての動作で細かい動きなどを入れていたりするし、画面切り替えにはやっぱりエフェクトが欲しい。

適当に見て回っているとこの辺で cc.TransitionFade というそれっぽいものを見つけた。このコードは Cocos2d-JS の v2.x 系のものなので少し実装が違うようなのだが、v3.0 系でも存在しているようなので、これを使ってみることにする。
cc.TransitionFade は cc.TransitionScene を継承していて、それは cc.Scene を継承しているので、画面切り替え用のシーンをシーンとシーンの間に挟み込むことで切り替えエフェクトを実現するんだろうか。取りあえずシーンだということはまたcc.director.runScene に渡せばいいということだと思った。

cc.TransitionScene のコンストラクタは第1引数に切り替え所要時間を秒で、第2引数に切り替え先シーンを指定すればいいようなので、少しコードを変えて以下のようにした。

        var closeItem = cc.MenuItemImage.create(
            res.CloseNormal_png,
            res.CloseSelected_png,
            function () {
                cc.log("Menu is clicked!");
                cc.director.runScene(cc.TransitionFade.create(0.5, new HelloWorldScene()));
            }, this);

これで、0.5秒でフェードアウト、フェードインしてシーンが切り替わるようになった。

今後

この辺にわりと丁寧なチュートリアルっぽいのがあるようなので、そっちも目を通してみたい。

Amazon Route 53 用 Dynamic DNS 更新ツールを Go で作った話

2014-05-01T18:35:00.000+09:00

なんか記事にするほどのことでもないんだけど。じゃあ記事のするほどのことって何だよ、俺にあるのかよ、って思ったので、深く考えずに書く。

oov.ch で使うネームサーバーとして今までは VALUE-DOMAIN のものを利用してて、特に不満もなかったものの Route 53 の使い方を把握しておいた方が今後のためにもなると思ったので、試しに移行してみることにした。

レコード情報はそんなに量もないし手作業でチマチマ入力して、dig コマンドで適宜応答も確認しながらやったのでこれといったトラブルもなく比較的スムースに移行は完了した。っぽい。

ただ、遊び用の自宅サーバーには Dynamic DNS 的な奴が必要で、これは編集画面でチマチマ触ってるだけじゃ無理そうなのでちょっと調べた。すると Amazon Route 53 Authentication Tool for Curl と AWS Route 53 Dynamic DNS Updater Script を使うと比較的簡単にできるという情報がゴロゴロ転がってきた。

それらをそのまま使えば多分解決するものの、そんなに難しいことをするわけじゃないだろうし自作してみてもいいかな、と思ってGo言語で作ってみることにした。できた。

https://github.com/oov/r53ddns

AWS へのアクセスには github.com/crowdmob/goamz/aws を使った。
Route 53 周りも一応実装はあったものの、ChangeResourceRecordSet でバッチ処理が出来なかったりとか若干イケてない気配がしたので、この辺に関しては自前で用意した。

自分が触るサーバは間違いなく Go が使える状態になっているので go get すればすぐ使えて便利だし、あと、あれだ、あの、なんでもない。

--ip オプションのデフォルト値は http://checkip.dyndns.org/ になってるけど、はるか昔に自分で自分のために用意した GAE 上で動く同じようなものがあるので、自分の環境ではこっちを使うようにした。

アルファチャンネル付き PNG の減色

2014-04-22T16:45:00.000+09:00

最近公開した楽曲用ページを作る際に、簡単なパララックス風の効果を作るためにアルファチャンネル情報を持った画像ファイルを複数扱う必要があるケースに出くわした。

以前ゲームを作った時は画像のデコード処理自体を外部デコーダに頼らなくてもできる状況だったので画像ファイルを WebP 形式にして、PNG 形式で 3.60MB ぐらいあった画像が 207KB まで容量削減できた（※この時使った WebP 形式はロスレスではない）のだが、ブラウザで WebP 形式を使うのは時期尚早……というかまともに使える日は来るんだろうか。
JavaScript によるデコーダがあることも知ってはいるもののわりとどうでもいい理由でボイコットされても困るし、それは冗談としても、とにかく WebP 形式は今回の選択肢にはなかった。

そうなると PNG の最適化の路線が残るわけで、まずは有名どころの PNGGauntlet を試してみた。圧縮アルゴリズムの最適化だけではそう大きくは縮まないだろうとは思ってはいたものの、ほぼ容量が変わらなかったので、別のアプローチの併用も必要そうだと思った。

とはいえここまで来ると減色ぐらいしか選択肢がない気がしてきた。
昔、今よりもインターネットが好きだった頃は OPTPiX webDesigner v2.x を買って使ったりもしていたこともあったものの、今となっては開発終了してしまっていて v2.x 系では少なくともアルファチャンネル付き PNG は扱えない。WebFree 版は制限厳しそうで面倒そうだし、Padie 系列のソフト類も現状は消息がよくわからんことになってるし、COLGA も試してみたものの容易く視認できるぐらいに劣化してしまった。

などと困っていたところで PNG Color Reducer Pro を見つけた。
試しに減色してみたら見た目がほとんど変化しないまま減色後の画像が生成された。
減色後のファイルサイズが表示されなかったのでどのぐらい縮んだのかわからず若干不安ではあったものの、楓 software の人は以前からアルファチャンネル対応動画形式の実装日記なんかも書いてて半透明を含む圧縮という分野での遭遇は初めてじゃないし、少なくとも出力結果から視認できるレベルの劣化は見当たらなかったのですぐ購入して実際にファイルを書き出してみた。

左が元のファイル、右が減色後のファイル

全体で 10MB 近かったファイルが、3.12MB まで縮めることができた。この縮んだあとのファイルを改めて PNGGauntlet にかけると最終的には 2.88MB 程度まで縮んだ。全てのファイルを WebP 形式に変換した場合は非可逆圧縮によってエッジが丸くなりつつも 1.78MB ぐらいにはなったので、PNG で 2.88MB は結構頑張ってる感じがする（根拠なし）。

思わぬところで良いツールに出会えてよかった。

欲を言えば自分の用途ではブラウザがある場所で使うことが多いので、NativeClient で動く Chrome アプリ版とかがあるとどこでも簡単に使えて嬉しいなあと思った。