cocos2dでParticleSystemを使うときのメモ

懲りずにcocos2dで遊んでます。今回はParticleSystemを触ったときに気づいたことなどをメモしてみます。


■ParticleSystemが放出するParticleを回転させたい
http://www.cocos2d-iphone.org/api-ref/latest-stable/interface_particle_system.html
こちらの公式リファレンスには2009/10/02現在記載されていませんが、startSpin, startSpinVar, endSpin, endSpinVarというプロパティが用意されており、こちらの値を調整することで放出される個々のParticleに回転を与えることが出来ます。

        // angle of particles
        startSpin = 90;
        startSpinVar = 0;
        endSpin = 1800;
        endSpinVar = 3600;

注意点として、PointParticleSystemを継承したParticleSystemでは、spin系のプロパティは利用できないみたいです。パフォーマンスで劣るそうですが、QuadParticleSystemを継承するようにしましょう。

結果はこんな感じ。青いミミズみたいなのがParticleSystemから放出しているParticleです。
回転の中心軸の位置がおかしいのかな？


■Particleの大きさを変化させたくない
endSizeにkParticleStartSizeEqualToEndSizeを指定すると、放出されたParticleの大きさが変化しなくなります。

        // size, in pixels
        startSize = 90.0f;
        startSizeVar = 30.0f;
        endSize = kParticleStartSizeEqualToEndSize;
        endSizeVar = 30.0f;

■応用：Particleの回転を変化させたくない
現在のcocos2dではまだサポートされていませんので、適当にParticleSystem.mのコードを書き換えます。具体的には180行目のあたりを以下のようにします。

 // angle
 float startA = startSpin + startSpinVar * CCRANDOM_MINUS1_1();
 particle->angle = startA;
    if (endSpin == kParticleStartSpinEqualToEndSpin ) 
        particle->deltaAngle = 0;
    else {
        float endA = endSpin + endSpinVar * CCRANDOM_MINUS1_1();
        particle->deltaAngle = (endA - startA) / particle->life;
    }

これで放出されたParticleがくるくる回転するのを防げます。でもこのマジックナンバーを使った実装、正直イマイチです。

 // angle
 float startA = startSpin + startSpinVar * CCRANDOM_MINUS1_1();
 particle->angle = startA;
    if (spinFixed) 
        particle->deltaAngle = 0;
    else {
        float endA = endSpin + endSpinVar * CCRANDOM_MINUS1_1();
        particle->deltaAngle = (endA - startA) / particle->life;
    }

個人的にはこの方に実装するほうが好きです。パフォーマンスは悪いかも。

各種WebサービスのAPI認証方法を調べてみた

自分でWeb サービスを作る際に、APIの認証ってどうやって作ればよいのだろうと思い立ち、各種Web サービスのAPIの認証方法を調べてみました。


■Google
参考にしたページはこちら。
http://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI

認証方法

ユーザーIDおよびパスワードを元に、Cookieを生成

認証時のAPI通信

HTTPS POST

認証URL

https://www.google.com/accounts/ClientLogin

認証後のAPI通信

HTTP GET/POST, HTTPS GET/POST

トークン送出方法

HTTPリクエストヘッダのCookie属性に「SID」を含める

Cookieを使う方法ですので、Webブラウザを用いるWebアプリケーションに対する認証の場合は非常に簡単ですが、クライアントアプリケーションの場合は、認証URLのレスポンスを元にSIDを保存し、HTTPリクエストヘッダのCookie属性にSIDを追加する処理を自分で行う必要があるため、ちょっとだけ面倒です。それでもシンプルで分かりやすい方法だと思います。


■Remember the Milk(RTM)
参考にしたページはこちら。
http://www.rememberthemilk.com/services/api/authentication.rtm
http://www.rememberthemilk.com/services/api/methods/rtm.auth.getFrob.rtm

認証方法

APIキー、開発者とサーバー間の共通鍵、使い捨てセッションの３つを元に、セッションIDを生成

認証時のAPI通信

HTTP GET

認証URL1（使い捨てセッションの取得）

http://api.rememberthemilk.com/services/rest/?method=rtm.auth.getFrob&api_key=abc123

認証URL2（本認証）

http://www.rememberthemilk.com/services/auth/?api_key=abc123&perms=delete&frob=123456&api_sig=zxy987

認証URL2（認証済みセッションIDの取得）

http://api.rememberthemilk.com/services/rest/?method=rtm.auth.getToken&api_key=abc123&frob=123456

認証後のAPI通信

HTTP GET

トークン送出方法

HTTPパラメータに「auth_token」を含める

Webアプリケーションだけではなくクライアントアプリケーションへの対応を行っているためか、先ほどのGoogleのAPIと比べて格段に難しくなります。その代わり、HTTPS POSTを用いなくても、HTTP GETのみで認証を行うことが出来ます。こういうのをRESTって言うんでしょうか？正直良く分からず。
以下、クライアントアプリケーションでの認証手順。

１．APIキー申請をすると、以下の2つの値がもらえる
api_key・・・開発者がサーバーからもらえる公開鍵。公開鍵なので外に漏れても良い。
shared secret・・・開発者とサーバーが持つ共通鍵。絶対に外に漏れてはならない。

２．api_keyを元に、使い捨てセッションを生成する
frob・・・使い捨てセッション。以降、認証手続きの間のみ利用する。
frobの意味についてはhttp://en.wikipedia.org/wiki/Frobを参照。

３．shared secretと認証URLのリクエストパラメータを元に、api_sigを生成する。
認証URLには以下の3つのリクエストパラメータがつきます。

api_key=abc123&perms=delete&frob=123456

これを記号を抜いて結合して、

api_keyabc123permsdeletefrob123456

先頭にshared secretをつけて、

BANANASapi_keyabc123permsdeletefrob123456

md5 hash値を計算します。計算結果がapi_sigになります。

md5('BANANASapi_keyabc123permsdeletefrob123456')

４．api_key, frob, api_sigの値を元に、ユーザー認証画面を開いてIDとパスワードを入力してもらう
ここで認証URL2をユーザーにブラウザで開いてもらって、IDとパスワードを入力してもらえば認証が完了します。

５．認証が完了したセッションIDを取得する
auth_token・・・セッションID。次以降のリクエストには、全てこのauth_tokenをHTTPリクエストパラメータとして含める。


■Evernote
参考にしたページはこちら。
http://www.evernote.com/about/developer/api/evernote-api.htm#_Toc200272584

認証方法

メールアドレス、パスワード、consumerKey, consumerSecretを元に、セッションIDを生成

認証時のAPI通信

Thrift TBinaryProtocol wrapping a THttpClient transport

認証URL

https://www.evernote.com/edam/user

認証後のAPI通信

Thrift

トークン送出方法

UserStore Authentication Token？を付与する

Thriftというフレームワークが使われているようです。Thriftの実装がC, Java, PHP, Python, Perl, Rubyなどで用意されていて、クライアントはこれらの実装を用いて認証すればよいらしいです。詳細は良く分かりませんが、こちらもAPI Keyと共通鍵を利用しているため、比較的RTMの認証に近いことをしているように見えます。
ちなみに上記はクライアントアプリケーション用の認証で、Webアプリケーション用の認証にはOAuthを使用しています。OAuthについてはまた別の機会に調べます。


■Twitter
参考にしたページはこちら。
http://usy.jp/twitter/index.php?Twitter%20API
http://twitter.pbworks.com/API%20Docs#Authorization
http://watcher.moe-nifty.com/memo/2007/04/twitter_api.html

認証方法1

ユーザーID、パスワードを利用したBasic認証

認証時のAPI通信

なし

認証URL

なし

認証後のAPI通信

HTTP GET

トークン送出方法

http://username:password@twitter.com/のようにしてユーザーIDとパスワードを送出する

認証方法2

ユーザーIDおよびパスワードを元に、Cookieを生成

認証時のAPI通信

HTTP POST（HTTPSは無い？）

認証URL

http://twitter.com/login

認証後のAPI通信

HTTP GET

トークン送出方法

HTTPリクエストヘッダのCookie属性に「_twitter_session」を含める

認証方法3

OAuth
詳細については不明

以下、http://watcher.moe-nifty.com/memo/2007/04/twitter_api.htmlから転載。

public_timeline の取得等一部の API を除くほとんどの API で、認証を使用する。応答に protected なユーザに関する情報が含まれる可能性のある API は認証が必須となっている。
現在、OAuth認証とBASIC認証が使用可能。

トークンベースの認証 OAuth は、今のところベータ版であるが、将来、OAuth 認証を標準的な認証方法にする予定。
BASIC認証で使用するユーザ名はメールアドレスまたはスクリーン名のどちらでも構わない。

Webブラウザ等を経由して Twitter にログインしたときに発行される cookie を使うことで BASIC 認証の代わりにすることもできるが、公式には cookie を使っての API 実行はサポートしない。
(訳者による注記: API によっては cookie 使用時も BASIC 認証が要求されるものもある。また、BASIC認証での API 実行と cookie を利用しての API 実行では、異なる結果が返る API もある。特に、protected なユーザに関する挙動に違いが見られる。
OAuth 認証時も API の応答に cookie が含まれるが、次回 API 実行時にこの cookie をサーバーへ送り返す必要はない)。

もうこれを見るだけでばっちりでした。

スティーブ・ジョブズが目の前なう

2009/09/25: 帰宅したらきちんとした写真アップします。
2009/09/28: 写真アップしました。

■これまでのあらすじ
アメリカ旅行１日目
アメリカ旅行２日目〜３日目


■まずはGoogleへ
今日はCaltrainに乗ってシリコンバレーへ向かいます。お目当てはGoogleとAppleの本社！
↓
Caltrainのサンフランシスコ駅へ到着。日本の駅と作りが全然違ったり、標準軌道（広軌？）だったり、全2階建ての客車をディーゼルの機関車が引っ張る構成だったり、そんな機関車がずらりと横一列に並んでいる姿が拝めたりと、鉄道マニアにはたまりませんよ。あ、私は鉄道マニアなんかじゃないんだからねっ？＞＜
↓
一路San Antonio駅へ。ここからVTAのバス40番に乗り換えて一路Googleへ移動。
駅で降りてまず感じたのが、空が広い！明るい！緑が鮮やかで綺麗！暖かい！家並みが美しい！まるで絵に描いた楽園のような風景です。なるほど、これはすごい。みんなシリコンバレーで起業したがるわけです。
↓
Google到着。めっちゃめっちゃ広い！！＞＜
雰囲気としては途中Palo Alto駅すぐそばにあるスタンフォード大学のキャンパスとそっくりで、全然「会社」って感じがしません。緑がたくさんあって、へんちくりんな形の建物がどーんと。大学のキャンパスかカフェか何かみたいです。
↓
さんざん周りをうろついて写真を撮りまくったあげく、何かの間違いで中に入れてもらえないかとVisitor用のロビーに向かったら、受付のおねーさんに「ここはClosed Campusです、知り合いが面会者がいない奴は立ち入り禁止です。でてけ」とやんわり怒られ、外に出たらセキュリティのお兄さんにまたやんわり怒られ、あえなく撤退。入れないのはわかっていたもののやはりショック。
↓
"There are no public visitor center or a shop"だそうです。嘘つき！俺は知ってるよ！某氏がGoogle社内見学したとき、お土産にバッグ買って帰ってきたのを！
↓
あ、そうか、だから"public"って断りを入れたのね。というわけで、技術にはオープンですが、本社警備には大変クローズドなGoogleでした＞＜


■続いてAppleへ
ふたたびCaltrainに乗って、こんどはSunnyvale駅へ。
↓
駅からVTAバス55番で南下するとAppleの本社に到着。外見はGoogleと違ってテクノロジー企業らしい企業ビルって感じです。あたりの交差点にたくさんリンゴマークの住所書きがあります。
↓
先ほどのGoogleでの失態を教訓に、まずはすぐに施設に近づかずInfinity Loopの公道からゆっくり観察することに。あ、6 Infinity Loopに山積みのMac Proがある。一つお土産に欲しい。
↓
Infinity Loopを左回りに進むと、6, 5, 4, 3, ....という風に施設が並んでいます。一番最後が1 Infinity Loop, 本社ビルです。
↓
本社ビル前に到着。お土産屋さん発見。観光バスと観光客らしき人も発見。どうやら思ったより観光客に対してオープンになっているみたいです。
↓
しかし当たり前ながら本社ビルの中には入れないようで、入り口の前で立ち往生。


■あんびりーばぶる！
で、中にも入れないし写真も撮ったしそろそろ帰るかと思っていたら。

http://twitter.com/akisutesama/status/4354424273
http://twitter.com/akisutesama/status/4354453168
http://twitter.com/akisutesama/status/4354498099

まさかのジョブズ降臨！！

目の前3メートルの位置にジョブズが！声をかけたけど無視されてすたすた行ってしまわれた。
↓
いや待て、本物がこんなド真ん前を堂々と歩くわけがない、偽物か影武者だと思って売店のおねーさんに聞いてみたら、"then it might have been"（ならたぶん本物だったのよ）とのお返事が。あと"He usually doesn't answer because he's so busy"らしいので、どうやら本物っぽいです。ああ、来て良かった！
↓
最後に記念撮影してたら建物の中が写るからそこで撮るなとセキュリティのイケメン兄ちゃんにやんわり怒られました。またか！＞＜


■じゃあ帰りましょ
Sunnyvaleの駅前で食ったsushiはなかなかおいしかった。カリフォルニアロール、言うほど不味くないですよ。私の舌がゲテモノ食いなのかもしれませんけど。ただし握りはいまいち、しゃりがなんだか変。食えないことはないけど、近所のスーパーのパック寿司のほうがおいしいと思う。これで4ドルは日本だとぼったくり。
↓
帰りのPalo Alto駅で乗ってきたスタンフォードの学生が目の前でMacBook広げてプログラミングを始めたので興味本位でのぞいてみた。ソースはよく見られなかったけど、たぶんAdobe AirかFlash。集中力が凄くって、乗ってからサンフランシスコの駅についてドアが開いてもまだMacとにらめっこしていた。きっと朝から夜遅く（19時）まで授業があっただろうにと思うと、さすがスタンフォードの学生だと感心するとともに、自分も負けていられないと思うのでした。