Live2D + Electron でデスクトップマスコット作って同人誌即売会で頒布してきました
標題の通りです。まずはこちらをご覧ください。
10/30 の 京都秘封で頒布予定の、宇佐見蓮子さんデスクトップアプリのモデルを動かしてみました。 pic.twitter.com/Y1F0ykMDXG
— さい@京都秘封 倶04 (@saigyojiyu) 2016年10月2日
宇佐見蓮子さんのデスクトップマスコットアプリできた。クリックでランダムに5種類の反応してくれる。Mac/Windows 両対応。10/30 の京都秘封オンリーで頒布予定。 pic.twitter.com/5E1ZUJqrTT
— さい@京都秘封 倶04 (@saigyojiyu) 2016年10月9日
東方Project という同人ゲームに登場する「宇佐見蓮子」さんの
デスクトップマスコットアプリを作りました。デスクトップ上で動きます。
クリックすると、何かしらの色々な反応をしてくれます。
2016/10/30 の科学世紀のカフェテラスという同人誌即売会で頒布してきました。
Live2D
Live2D WebGLとNW.jsでデスクトップマスコット
Live2D については上記の記事を参考に実装させていただきました。
公式サイトで WebGL 用 SDK が提供されているのでそれを使用しました。
Live2D Cubism SDK 2
Live2D WebGL SDK の解説については下記のスライドがわかりやすいと思います。
Electron
デスクトップマスコット用に、ウィンドウ表示を無くし、
背景を透過して、常に最前面に表示する方法ですが、
mainWindow = new BrowserWindow({ "transparent": true, // ウィンドウの背景を透過 "frame": false, // 枠の無いウィンドウ "resizable": false, // ウィンドウのリサイズを禁止 "hasShadow": false, // 残像が残らないようにする(Mac only option) "alwaysOnTop": true, // 常に最前面 });
BrowserWindow 作成時に、上記のオプションを設定することで、
簡単に実現することができます。
なお、hasShadow
オプションですが、Mac ではデフォルトで、
ウィンドウに影が付くようになっており、このオプションがオンのままだと、
Live2D モデルのモーションに残像のようなものが残ってしまいます。
オフにしましょう。
上記 Qiita の記事では、NW.js を使ってデスクトップアプリ化しているため、
XMLHttpRequest でなく、fs を使ってモデルファイルをロードしていますが、
Electron においては XMLHttpRequest でロードできます。
このため、Electron のメインプロセスのAPIを使用する必要がなく、
レンダラプロセスのみで完結するため、開発中はブラウザ上でマスコットを表示し、
完成後に Electron で build して完成としました。
ライセンス
Live2D のライセンスは結構ややこしいです。下記の内容は 2016/10/30 時点のものです。
最新の内容は、公式サイトをご確認ください。
本デスクトップマスコットアプリは、同人サークルとして頒布したものです。
直近売上高が1000万未満の同人サークルであるため、「一般ユーザー」として
使用することになります。
一般ユーザーであれば「iOS, Android, Flash, DirectX, Unity, Cocos2d-x, WebGL」のSDKを、
商用/非商用問わず利用することができます。
インディークリエーター向けにLive2D Cubismを無償提供。商用利用も可能
DLカード
同人誌即売会での頒布は、DLカード(ダウンロードカード)を
作成して頒布する方法を取りました。
対面電書という Webサービスにて、
ファイルのアップロード及びシリアルコードの発行を無料で行うことができます。
こうして発行したシリアルコードを、バリアブル印刷対応の印刷所(印刷のウェーブ様等)にてカードの印刷を発注しました。
ポストカード(オンデマンド、両面フルカラー)+バリアブルテキスト印字オプションで、
200部だいたい8000円くらいのお値段です。
メール便に対応しているので、注文から手元に届くまで
だいたい4営業日くらいというスピード感です。
きゃーい。DLカードも届いたぞー!(これはおまけでもらったシリアルコードがついてないやつ) pic.twitter.com/EC18qC7J7S
— さい@京都秘封 倶04 (@saigyojiyu) 2016年10月29日
感想
Mac を会場に持ち込んで、実際に動いてる様を展示していたのですが、
「すごい」「こんなことができるんだ」といった反応をたくさん頂けました。
(エンジニア冥利につきます)
Live2D を使った作品を作る上での課題は、
やはり元のイラストをどう用意するか、
そしてそのイラストをどうやってモデル化するかだと思います。
今回はそのどちらもを他の人にお願いしてしまったので、
私はモデルとモーションを組み合わせただけなのですが、
逆に言うと、モデルさえ用意してしまえば、このような
デスクトップマスコットアプリを作ることは結構サックリとできます。
JavaScript 製ファミコンエミュレータを公開しました
公開しました(過去系)
Demo
Screenshot
作ろうと思ったきっかけ
コンピュータの仕組みについて知りたいなら NES エミュ作るのが手っ取り早いと、 優秀な人が強い事を言ってて、僕もコンピュータの仕組みについて知りたかったので、 実装しようと思いました。
まず読んだ本
コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方
CPUやメモリの仕組みを大まかに知ることができる
OSの仕組みやアセンブラの基本がわかる
自作エミュレータで学ぶx86アーキテクチャ コンピュータが動く仕組みを徹底理解!
こちらもアセンブラに慣れるために読んだ
バイナリに慣れるために読んだ
コンピュータの仕組みについて何も知識がなかったので、上記の本を読んで勉強しました
参考にしたサイト
NES on FPGA +そんなベタなファミコンはイヤだ!+
実装してみての感想
OS自作系の知識を応用して、CPUの実装までは容易にできる。その後 PPU APU等の 描画や音楽周りになってくると、ドキュメントを読んでも理解できないことが多かった。
ドキュメントを読んでも実装のイメージがまったく湧かなかったので、 とにかく他人が既に実装したコードを読み漁った。 人によって実装内容が異なり、また実装によって動くROM動かないROMが異なるので、 何を正にすればいいのか戸惑った。
スライド
JavaScript の勉強会で発表した内容です。
www.slideshare.net
他の人のJavaScript系NESの実装
英語を使えるようになってみようと思う
こんにちは、さいです。標題の件をやっていこうと思います。
なぜ?
ソフトウェアエンジニアとしてやっていく上で、 やはり日本語だけでなく、英語の情報にもアクセスし、 またアウトプットできたほうが有利だなと思ったから。
またそれとは別に、日本人というのは割りと皆考えることが 似ているように思うのだが、他の国の人が何を考えて、 何を指向して生きているのか知りたい。
学習方法
個人的なパーソナリティとして、 コンピュータとオタクカルチャー以外の情報と接触するのが難しいクチなので、 それらを通して、読み・書き・喋り・聞き、ができないか試してみる。
特に、海外のOtaku Fandom に私は強い興味があり、海外の Otaku と 英語でコミュニケーションすることについては、英語を学ぶ強い動機付けになりそう。
読み
英語の技術書を読む。
Otaku コミュニティの投稿を読む(4chanとか)
書き
技術翻訳(今もやってるけど Electron とか Node の docs)
喋り
DMM英会話
オンライン英会話のラングリッチ
聞き
coucera とか udacity とか
それでは
どこから手を付けていこう。英語の技術書読んだり、あるいは技術翻訳は 今でも必要に応じてやっているので、Otaku コミュニティの方に手を広げて行こうか
今自分は思考する際、日本語で思考を組み立てているが、これを英語で 組み立てられるようになるとアツい。
Mac で xv6 を gdb でデバッグする
前回、Mac 上で xv6 を動かしたので、今回は gdb 使ってデバッグしてみます。
gdb のインストール
brew install --with-all-targets gdb
i386 形式のシンボルとか読むために、全ターゲットの gdb をインストールします。
qemu で実行
cd xv6 make qemu-nox-gdb
gdb モードで実行
gdb でアタッチ
cd xv6 gdb
.gdbinit があるので、xv6 ディレクトリで gdb 起動するだけで 良しなにアタッチしてくれます
TUI モード
TUI (Text UI)モードにするには Ctrl+x + Ctrl+a。
TUI モードにすると、コマンド追いながらソースコードを終えてめちゃ便利。
関数にブレークポイント
(gdb) break main
break で関数名にブレークポイントを打ちます。
(gdb) break 24
行数指定で、指定行にブレークポイントをウチます。
continue
(gdb) cont
停止しているプログラムを続行する。
next
(gdb) next
停止しているプログラムの次の1行を実行する。 関数の中まではステップしていかない。
step
(gdb) step
停止しているプログラムの次の1行を実行する。 関数の中までステップしていく
ブレークポイントの削除
(gdb) delete
ブレークポイントを全て削除
変数の中身の表示
(gdb) print 変数
関数の終端まで実行
(gdb) finish
ループを抜ける
(gdb) until
引数の変更があった時に止まる
(gdb) watch 変数
関数の呼び出し元をトレース
(gdb) backtrace
変数の型を知りたい
(gdb) whatis 変数
構造体の定義を参照する
ptype struct 構造体
変数が構造体だった場合、その構造体の定義まで表示される
ptype 変数
ソースコードを表示
(gdb) la src
la は layout の略
アセンブラ表示
(gdb) la asm
レジスタ表示
(gdb) la regs
その他
十字キー上下左右で、ソースコードやアセンブラ表示を移動できる
Ctrl+P, Ctrl+N でコマンド履歴を追うことができる
画面が乱れたら Ctrl+L で直す
Mac で xv6 を動かす
導入
xv6 は UNIX V6 を元に MIT の人が作ったOSで、UNIX V6 と同じく、1万行程度のコードでOSを実現している。 ANSI Cかつ x86 プロセッサ上で動く。 MIT の教材にもなっていて、講義で使われているテキストもダウンロードできる。
情報系の大学に通わないで、オペレーティング・システムの仕組みについて学ぶことは結構敷居が高いように思える。 昔は「30日でできる! OS自作入門」みたいな分厚い本を読むしかなくて、 最近だと「はじめてのOSコードリーディング」みたいな本で学ぶことはできるようになった。
ただ、「はじめてのOSコードリーディング」はUNIX V6 のコードを読む本で、 UNIX V6 は古いC構文かつPDP-11上でしか動かないのでまだ敷居が高い。
xv6 は x86 アーキテクチャ上で動き、ANSI C で書かれているので 現在の我々にも読みやすい。
クロスコンパイラの準備
Mac は x86_64 アーキテクチャなので、 x86 の xv6 をソースから コンパイルするにはクロスコンパイラが必要。
よって i386-jos-elf toolchain を準備する。
まず GMP/MPFR/MPC の3つをインストールする。 ソースからコンパイルしてもいいが、Mac なら brew install で楽にインストールできる。
$ brew install gmp $ brew install mpfr $ brew install mpc
binutils を用意する
$ wget http://ftp.gnu.org/gnu/binutils/binutils-2.25.tar.gz $ tar xvf binutils-2.25.tar.gz $ mkdir build-binutil $ cd build-binutil $ ../binutils-2.25/configure --disable-nls --target=i386-jos-elf --disable-werror --prefix=/usr/local/ $ make all $ make install
$ wget http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-4.9.2/gcc-4.9.2.tar.gz $ tar xvf gcc-4.9.2.tar.gz $ mkdir build-gcc $ cd build-gcc $ ../gcc-4.9.2/configure --with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib --with-mpfr-include=/usr/local/include --with-mpfr-lib=/usr/local/lib --target=i386-jos-elf --disable-werror --enable-languages=c --without-headers --prefix=/usr/local/bin/ --disable-nls $ make all-gcc $ make install-gcc
qemu のインストール
qemu は CPU エミュレータ。x86_64 上で x86 をレミュレートしないといけないので必要
$ brew install qemu
xv6 のダウンロード
git clone git@github.com:mit-pdos/xv6-public.git
-# TOOLPREFIX = i386-jos-elf +TOOLPREFIX = i386-jos-elf- -# QEMU = qemu-system-i386 +QEMU = qemu-system-i386
xv6 をビルドして実行
$ cd xv6 $ make $ make qemu-nox
qemu は Ctrl+a x で終了できる。
最後に
ここまであれこれソースビルドしておいてアレだけど、 実はだいたい全部 homebrew で揃えられる。
32bit 版 xv6 を Yosemite で動かす
http://attonblog.blogspot.jp/2015/04/32bit-xv6-yosemite.html
brew install homebrew/versions/gcc49 brew install qemu brew tap altkatz/gcc_cross_compilers brew install i386-elf-gcc i386-elf-binutils
Yukkuri Talker を公開しました
Yukkuri Talkerという Webサービスを公開しました。(※ 2019/03/29 に閉鎖しました) Web 上で AquesTalk2 による合成音声(俗にいうゆっくりボイス)を再生/保存することができます。
技術スタック
Sails.js
Node.js のサーバーサイドフレームワークです。その名前の通り、 Ruby on Rails に強い影響を受けたフレームワークです。
mithril
クライアントサイドの JavaScript フレームワークです。 地味に HowTo や About へのページ遷移を SPA にしています。 ボイスの再生も、サーバーから音声バイナリを m.request で 受け取って、Web Audio API で再生しています。
gulp
browserify + msx でクライアントサイドの開発をよさ気に。 Sails.js が Grunt に依存しているので、Gulp と Grunt 両方混在してしまうのが難点。
AquesTalk2
合成音声ライブラリです。ライブラリなので、 C プログラムを書いて、 node.js からそのプログラムを叩くようにしました。 http://www.a-quest.com/products/aquestalk.html
bootstrap
Honoka の fork テーマ「Frandle」を使用しました。 http://sairoutine.github.io/Frandre/
努力と才能について所感
努力と才能
こんにちは。さいです。「努力」と「才能」よく対比される概念ですね。こちらの記事を読んで、努力と才能の話について思い出しました。
先日、二人の競技プログラマが入社した。二人とも、TopCoderのAlgorithmのレーティングも僕より高い、格上の競技プログラマである。社長としては嬉しくはあるが、選手として見れば中々難しいところである。社内レーティングランキングが4位にまで転落してしまった。
まぁ、そんなことはどうでもいい。問題はここからだ。
彼ら二人の会話を見ていて思ってしまった。
「僕にはたどり着けるわけがなかった」と。
理由は極めて簡単。彼らのしていること。彼らの日常会話。それの、ほぼ全てが、「競技プログラミング」に繋がっているように見えたからだ。とにかく、数学的な、パズル的な、そんな思考を繰り返している。仕事中でも、仕事が終わっても。
持論の話なのですが、人が天才を見て、どうして天才と感じるのかといいますと、別にその人の結果がスゴイだけでは天才とは恐らく感じないと思います。人はなにかしら目標に向けて時間を費やしており、その延長線上にスゴイ結果にたどり着く未来が思い浮かべられれば、天才とは感じません。
天才とは、その人の行動や習性が明らかに異質で、かつ圧倒的な結果を出していると、人は「この人には勝てない」と感じます。明らかに自分とは異なる行動で、自分より先に目標にたどり着いている人間を見ると、今の自分の努力方法ではその成果に辿りつけないと考えます。
努力と才能というのは人によって定義が曖昧で、定義によって、論じる内容も異なってしまうので、一旦今回の記事における努力と才能の定義について整理しておきましょう。
努力と才能についての定義では、こちらの動画の内容が僕はすごくしっくりきています。
努力とは目的のための有意識的行動であり、才能とは無意識行動によって得られたもの
努力によって得られたものを成果、才能に至る言葉を習慣と名付ける
努力は過程で才能は結果
表にするとこういうことです。
過程 | 意識 | 結果 |
---|---|---|
努力 | 有意識 | 成果 |
習慣 | 無意識 | 才能 |
努力とは過程であり、対として語るならば、同じ過程である習慣を語るべきであり、 努力は意識を持って行う行動、習慣は無意識に行う行動です。
努力による結果を成果と呼び、習慣による結果を才能と呼びます。
ここで習慣という言葉が出てきます。才能がある人間は、 頑張っている/努力しているという意識すらなく、 無意識に行う行動によって才能を積み重ねているということです。
無意識に習慣によって行う利点は、圧倒的に長い時間をかけられるということです。 才能も成果も、時間を費やした結果であって、努力 or 習慣のどちらかによって得たかの過程によって 結果をカテゴライズしたに過ぎないのですが、努力に比べて習慣の方が圧倒的に長い時間をかけられる分、 才能の方が成果より大きくなることが多いです。
つまり天才とは、頑張っているという意識すらなく、無意識による行動で才能を積み上げて評価される人あり、努力家とは、やる気ドリブンで成果を積み上げて、積み重ねて評価される人です。
「やる気が出ないから研究できない」と仰る皆さん pic.twitter.com/y6ksjsZgea
— (あんちべ! 俺がS式だ) (@AntiBayesian) 2013年12月14日
上記画像は、主題とはちょっとズレる画像ではあるのですが、やる気というのは出たり出なかったりする運要素であることを述べています。有意識であるがゆえに継続し続けることに非常にエネルギーを費やします。
僕は、競技プログラミングをやっていた、といっても、業務で触れていただけだ。日常ではない。だが、彼らにとってはそれが日常だった。
僕は「競技プログラミングの選手」ではあったかもしれない。だが、彼らのような「競技プログラミング星人」ではなかった。それがこの差なんだなぁ、と、ここ数か月で非常に感じた。
少し前の僕は「才能が違うのかな」と思っていた。そんなんじゃない。才能だったら自分だってある程度はある。致命的に違うのは、生き様だ。
なるほど。これは勝てるわけがない。
高橋直大さんが述べているように、これが努力と習慣の違いです。ここで述べられている日常/生き様が 私の述べる習慣のことだと考えています。日常/生き様レベルで目標に向けた行動ができる人は、 努力に比べて圧倒的に長い時間を費やせるので、結果も圧倒的に大きくなります。
どうすればいいのか
さて、努力と才能の話にて「才能とは、習慣による圧倒的長い時間を費やして生み出されたものである」という話をさせていただきました。 それを踏まえて、僕達はどうすればいいのでしょうか?
1つは、同じように習慣によって圧倒的時間を費やすことです。今努力して行っていることを習慣化してしまいます。 日常の行動は全て自分が目指している目標のために費やし、それ以外の行動は全て捨ててしまいます。
また自分の周囲の環境も変える必要があると思います。自身が当然としている行動基準が、 他の人からすれば異常じみてることを知れば、無意識に行動基準を下げてしまうのが、社会性のある人間の習性です。
天才とは自分が普通であると疑わない愚か者でなくてはならない
先ほどの動画でも述べられています。
X分野における天才に、X分野で真っ向からぶつかっていく方法もあります。一方、 X分野のうちの x1 にフォーカスしてぶつかっていく方法もあります。 高橋直大さんもそういう方向で勝負していくようですね。
他にも X分野だけでなく、Y分野も身につけて、X+Yで勝負していく方法もあります。この辺、X分野の天才とどう戦っていくかは人それぞれだと思います。
私は愚かなので、もう少しX分野に真っ向からぶつかっていこうと思います、今有意識的に行っている行動を無意識に行えるようにすることで。
終わり
今回のお話では努力について、「方法について考えながら努力すること」を、努力と呼びました。「何も考えず愚直に練習を重ねることを努力と呼び、そうした努力をするべきでない」と唱える人もいますが、今回の話ではそちらの努力の話はしませんでした。