c#のジェネリック(Dictionary, List etc)は安易にキャストする前に必ず注意すること
この前ハマったコード
例えばobjectクラスからDictionary<string, object>へはキャストできるけど、
Dictionary<string, Dictionary<string, object>>へはキャストできなかったりする。
直感的に、これでいけそうに見えませんか？
そもそもジェネリックとは
これが簡単でわかりやすい。テンプレートと呼ばれるものらしい。
プログラミングにおけるテンプレートは、静的型付けのC++でデータ型にとらわれずにコードを書くことを可能にする機能であり、
ひとつのソースコードを使って、型をパラメータ指定にすることで複数の型で同じロジックを流用できる、という機能のようだ。
挙動が中途半端
とかなら挙動としてわかりやすいが
ジェネリックのキャストについては、いけるケースといけないケース
があってよくわからない・・・
- Dictionary<string, object>は、いける
- Dictionary<string, Dictionary<string, object>>は、いけない
- List<object>は、いける
- List<uint>は、いけない
悲しみを感じながら今後は・・
確実に非ジェネリック(System.Collectionsの方のIList, IDictionary)にキャストしていくのが
間違いない。c#のキャスト機能(()演算子、as演算子)は、ジェネリックを考慮しきれてない
ということだろう。
まとめ
動画にBGMを使うならTSUTAYAに行かずiTunes Storeを利用すること！
「悪いんだけど、余興のムービー作ってくれない？」
と、そう妹に言われて、妹の友人の結婚式用のムービーを
最近作ってました。
スケッチブックリレーというものを作りました。
こんなかんじのやつです。
自分の結婚式のときにAdobe Premiere Proを使って3つほどムービーを作ったぼくは、
もはや得意げでした。
意気揚々と作り、苦労はあったものの何事もなく完成したと、
そのときはおもってました。
作ったDVDを渡した後、しばらくしたある日
結婚式の前の週に、ウェディングプランナーに確認してもらったようで
「音割れがひどいって言われたんだけど・・」
といわれ、「うそーん(´・ω・｀)ｼｮﾎﾞｰﾝ」となり再度確認。
確認しても、通常の音量なら、問題なく視聴できました。
おれ「あれ、そんな音割れてなくね？」
妹 「音でかくしてみると、なんか変な音する」
おれ「そんなこと言われてもこっちではそんな音しないからどうしようもないんだけど・・・」
妹 「えーーー、、、」
うんぬんと話していて、
妹 「youtubeとかでBGMとってきたんじゃないか、って言われたんだけど」
おれ「いやいや、わざわざTSUTAYAでCD借りて取り込んだし」
妹 「そうだよねー」
・・一応試してみるか。
ということで、iTunes Storeを使って同じ曲買ってみたら、
もしや…音源が音割れしてた？！
「借りてiTunesに取り込んだデータよりiTunes Storeで買ったやつの方がめっちゃ音イイんだけど！w」
もはや笑えるレベルでした。
Mac Book Proを使って最大音量で確認すると、差が歴然とでます。
一方は全体的にノイズや音割れがし、他方は美しい音が維持されたまま流れるという。
なぜTSUTAYAで借りたCDを取り込んだやつが音割れしたのか
TSUTAYAはたぶん悪くありません。
単純に、インポート設定が適切じゃなかった、というのはあると思います。
ちなみに、自分のPCの設定は以下のようになっていました。
インポートの時間を高速にするためか、少なくとも最も高音質、という設定とかではないようです。
ビットレートとかサンプルレートってなんやねん、と思う方もいると思いますが、
それはまた別の記事で書いてみたいと思います。
とにかくいいたいことは、
「むずかしすぎるわ！」
ということです。
当然、ビットレートとかサンプルレートとかエンコーダとか
詳しければ、もっと自分でコントロールできるようになるのですが、
経験と経験がないと難しいです。
まとめ
- 曲を動画に使うときは、できるだけ大音量で聞いて、きれいに聞こえるか確認する
- CDをインポートするのではなく、iTunes Storeで買ったデータをそのまま使うことで、高音質を担保する
ではでは〜。
画像を光らせたい、暗くしたいときに使う、画像の加工(ブレンド)方法「加算」とか「乗算」とか
画像を光らせて点滅させてください
今日、「画像を光らせて点滅させてほしい」と言われて実装していたら、
デザイナーとチャット越しで
デザイナ：ベースの画像の上に光の画像をのっけてください
ぼく ：はーい
デザイナ：加算でおねがいできます？
ぼく ：ん？乗っけてますよ？
デザイナ：・・・
ぼく ：(あれ、加算ってなんかそういう用語？)
ぼく ：(隣のパイセンに) 加算ってどういう意味ですか？
パイセン：Photoshopとかで、２つのレイヤーを合成するときの合成(ブレンド)方式だよ
ぼく ：！！！
てなやりとりがあって勉強になったのでまとめます。
加算ってなに？
単純に2つの色を足してるだけ。カラーコードでいえば
#FF0000 + #00FF00 = #FFFF00
これだけ。画像で下記例を見るとわかりやすいです。
加工前
単純に上からかぶせた場合 (不透明度100%)
加算の場合
画像の引用元：Adobe Photoshop * 描画モード
加算だと、かなり明るくなりましたね！
「明るくしたいときは加算」とざっくり覚えておきましょう。
Unityでの実装例
ぼくはNGUIを使っていたので、ベース画像はそのままUISpriteで配置して、
光らせ用画像を、UITextureで参照しつつShaderでAdditiveなものを使うだけでよいです。
「Particles/Additive」とか、「Particles/Additive (Soft)」とか、デフォルトでShaderがあるようです。
SpriteRendererの例はこちらを見るとよさそうです。
ポイントは、「"Particles/Additive"などの、AdditiveなShaderを使う」ですね。
他にもあるの？
ぼく ：「他にもそういうやつあるんですかね？似たようなやつ。」
パイセン：「乗算とか、スクリーンとか、うんぬん」
ぼく ： ほほぉ・・・！
ということで、他のものも簡単にまとめます
乗算ってなに？
色をかけ算するだけ。また、カラーコードで考えると、
#CC0000 × #CC0000 = RGB(204/255, 0/255, 0/255)^2 ≒ #A30000
と、少し暗くなります。
同様に、Photoshopページの例でも暗くなっています。
加工前
乗算
画像の引用元：Adobe Photoshop * 描画モード
Unityでの乗算の実装は・・・
残念ながら、デフォルトのShaderはなさそうです。少なくとも私には見つかりませんでした。
自力でシェーダーを書く必要があります。
※ 申し訳ありませんが、筆者は2015年4月4日現在シェーダーを書いたことがありません。
じゃあスクリーンって何？
乗算で暗くなるのを、逆に明るくするロジックです。
計算方法は少し難しくなります。
RGB(1,1,1) - (RGB(1,1,1) - RBG(r,g,b)) * (RGB(1,1,1) - RBG(r',g',b'))
こんなかんじなのですが、なんとなくわかりつつよくわかりませんねw
見た目は、以下のようになります。
加工前
スクリーン
画像の引用元：Adobe Photoshop * 描画モード
加算と比べると、少しまろやかになります。
最初は、「加算よりも、少し明るさがまろやかになる」とだけ覚えておけばいいと思います。
スクリーンもデフォルトでShaderなし
自力で実装(ry
書いたらアップします。
まとめ
- 画像を明るくしたいときは加算かスクリーン、暗くしたいときは乗算を思い出そう
- Unityでデフォルトで使えるシェーダーは加算のみ (自分の環境はUnity4.6でした)
developブランチはオワコンじゃないよ
develop ブランチなんてオワコン - Togetterまとめ
developブランチめっちゃ使ってますよ！
- masterではなくdevelopが普段使うブランチにしてる
- 検証終わるまではdevelopを育てる
- 終わったらmasterにmerge
これでmasterブランチの品質を担保します。
こうやって構造的に担保する、というところが大事だと思う。
ちなみに、リリースブランチは使ったことないけど、タグ打つのとどっちが便利なのかな。
そもそもgit-flowてなに？て方はこちら。
XCodeでビルドログをみたい
iOS - Xcode のビルドログの詳細を確認する方法 - Qiita
これを見て解決。
command + 8 でいけます。
こんなかんじの画面でみれます。
でも、もっとテキストベースのやつみたいなー。
良い方法ないかな。
iOSでビルドしたら、dllがでかすぎてXcodeでエラー
ドキュメントのしたの方にあった。。
Xcode throws compilation error: "ld : unable to insert branch island. No insertion point available. for architecture armv7", "clang: error: linker command failed with exit code 1 (use -v to see invocation)"
このエラーは通常、ひとつのモジュールにコードが多すぎることを意味します。典型的には多くのスクリプトコードがあること、または大きな .NET アセンブリがビルドに含まれることに起因します。そしてスクリプト デバッギング を有効化することで状況はさらに悪化するかもしれず、いくつかの追加指示を各々の関数に加えるため、より多くに制限にヒットするようになります。
この問題の解決にはマネージド コード ストリッピングを有効化することで役立つ場合があり、特に おおきな.NET アセンブリがカラム場合です。しかし、もしこの問題が継続的に発生する場合、もっとも良い解決策はユーザのスクリプトのコードを複数のアセンブリに分割することです。その最も簡単な方法はコードを Plugins フォルダに移動することです。この場所にあるコードは別のアセンブリに含まれます。さらにこれらのスクリプト コンパイル ガイドラインもチェックして下さい：
これが結構大変だった。。
ちゃんと依存関係を意識して、最初から分割すべきだった。気をつけよ。
NGUIのUILabelをいじってたらBBCodeなるものに出会う
BBCodeなるものがあるというのを初めて知った。
テキストを少しリッチにできるらしい。
例えば、
あいうえお
みたいな。
おれの場合は、一部の文字の色を変えたかった。
[#ff0000]hello[-]world
こんなかんじで色変えられる。
でも、全然変わらなくて焦った。
原因は、これ。
この中の"BBCode"にチェックが入ってなかったせい。
気づかなかったよ、、(´･_･`)
色々タグがあるらしい。以下のページがわかりやすそ。
