Hatena::ブログ(Diary)

黒白猫の開発日記 このページをアンテナに追加 Twitter

2014-01-12

cocos2d-x 3.0 betaの描画関連ソースを読んだ感想

cocos2d-x 3.x系はバージョンごとに大きな変更が入り、互換性保証が無理無理な状態になってますが、
betaで、ものすごく大きなジャンプが入ったようです。

これまでのcocos2d-xの描画は、
)茱侫譟璽燹DisplayLinkDirectorのmainLoop呼び出し

現在のシーンのdrawScene呼び出し

Nodeツリーをvisitメソッドトラバースしていく(=木構造をたどっていくという意味です)。トラバースしながらdrawメソッドを呼んで各ノードを描画。

という形でした。
http://www.cocos2d-x.org/news/172
こちらに、auto batchingというキーワードがありますね。

これどういう意味かわからなかったのですが、
ソースを読む限り、VBO(VertexBufferObject)を利用して描画するノードの矩形情報を、複数ノード分をまとめて
GPUに送ることで高速化をしているようです。

つまり、複数ノード分の描画をまとめて処理している(auto batching)なわけです。
どうやっているかというと、の処理が分割され、mainLoop内でい僚萢が呼ばれるようになりました。

Nodeツリーをvisitメソッドトラバースしていく。各ノードのdrawでは、描画コマンドを作成してキューに蓄積する。

Rendererクラスがキューの中の描画コマンドを順番に処理する。その際、いくつかの描画コマンドをVBOにまとめて、まとめて処理する。

VBOを使うというのはOpenGLの高速化手法の一つなので、どの程度かはわかりませんが高速化されたものと思います。


ただ、このbetaの変更で、cocos2d-x外部ツールのいくつかが非対応になったものと思われます。
僕が一番気になるのがSuperAnimationConverterですね。
まあもともと3系向けの対応は入ってませんでしたが、alpha0までは動いていることは確認していました。
しかし、全てのノードが描画コマンドを発行するbetaでは、もはやvisit内で描画をしているSuperAnimNodeV2.cpp
では非対応となります。

まあ、betaはまだまだ不安定バージョンなので様子を見ましょう。
やはり3系は本格的に採用を検討するのは3.1くらいになってからが妥当のようです。

2013-11-22

cocos2d-x 3.xでの、Eclipse(ADT)ブレークポイントデバッグ方法

cocos2d-x3.0Alpha0でのブレークポイントデバッグに成功したのでやり方をメモします。
2.x系のブレークポイントデバッグ方法については、この記事の一番下にあげる本に紹介されてるので読んでください。

\郷紊気鵑痢Cocos2d-xによるiPhone/Androidアプリプログラミングガイド」の通りにワークスペースを作成する。(通常通りAndroid Applicationとして実行できる状態になれば多分大丈夫だと思います)

アプリのプロジェクト設定のC/C++ Buildで、「bash ${ProjDirPath}/build_native.sh」→「bash ${ProjDirPath}/build_native.sh NDK_DEBUG=1」にする。

Android.mkで、$(call import-moule,cocos2dx)の行の前に以下を挿入する。
$(call import-add-path,$(LOCAL_PATH)/../../../..)
$(call import-add-path,$(LOCAL_PATH)/../../../../cocos2dx/platform/third_party/android/prebuilt)

アプリのプロジェクトが通常通りprojectsフォルダ直下にあることを想定しています。ともあれ$(LOCAL_PATH)/../../../..の部分をcocos2dxルートのフォルダパスになってれば大丈夫だと思います。)

アプリを「Debug As→Android Native Application」で実行。

3.x系はNativeActivityを採用し、ADT自身も最近のバージョンでAndroid Native Applicationでのデバッグ実行(つまりNDKアプリとしての実行)をサポートしたので、2.x系よりブレークポイントデバッグが簡単になっています。

手順の抜けがあったらご指摘ください。

----------------------
2013-12-10追記
すみません、もう一点必須の手順がありました。
Eclipseワークスペースで、環境設定→Android→NDKで、NDKのパスを指定してください。
これをしないと、NDKのパスが認識されず
[2012-10-04 12:09:12 - ndk_android] Unknown Application ABI:
[2012-10-04 12:09:12 - ndk_android]
[2012-10-04 12:09:12 - ndk_android] Unable to detect application ABI's

のようなログをCosoleで見ることになります。
この設定、Android Applicationとして実行するだけならいらないんですけどね。
面倒ですね。

2013-10-11

パーティクルの設定をプログラムで動的に変える

※こちらは、細かい使用方法の調査は同僚に行っていただきました。ありがとうございます!

パーティクルの色や放出量や半径といったプロパティをCCAction系の使用感覚で変えたいことがあると思います。

実は、任意のプロパティの値をTween的に変更する方法が用意されています。
CCActionTweenとCCActionTweenDelegateです。

CCActionTweenの使い方は他のCCAction系のクラスとほぼ同じで、違うのが、以下の2点です。
プロパティ名を引数に与える
・アニメーションさせたいクラスにCCActionDelegateを継承させ、updateメソッドを定義して、その中でプロパティの変更の計算を実装する必要がある。

勝手に、プロパティの値を均一に補完してくれる訳ではないんですよね。
これだと、自分でscheduleUpdate()とかで1フレームごとのプロパティ値設定を実装するのと大して変わらないと思われるかもしれません。

ただ、CCActionIntervalの派生クラスなので、他の派生クラスとのCCSequenceやCCSpawnによる組み合わせが期待できるのが大きいです。
やはり生にupdateメソッドを書くより扱いやすく読みやすいコードになります。

具体的にパーティクルに対して適用するときは、CCPartilceSystemQuadとCCActionTweenDelegateを多重継承したクラスを作って、それをCCPartilceSystemQuadの代わりに使うのが楽でしょう。

プログラムから好きなように動的に設定値を変えられると、パーティクルの表現の幅が広がります。
パフォーマンスにはご注意を。

パーティクルを移動した時に残像を出さなくする

パーティクルでCCParticleSystemQuadを使っていて、CCMoveToなどでノードごと移動すると、残像現象が起こります。
どういうことかというと、一度放出された粒子は、ノードのsetPositionに追随せず、
発生点からの計算された軌道にしたがって動くわけです。

こちら、なんとかする方法がないかと調べてましたが、CCParticleSystem.hを見たら普通に設定するenumがありました。

setPositionType(kCCPositionTypeRelative);
を使えばOKです。

ちなみにデフォルト値はkCCPositionTypeFreeで、放出後の粒子はノードの動きに影響されません。

ちなみにこちら、ParticleDesigner1.x系、2.x系の両方で、設定するメニューがありません。
あくまでソースコードで設定してください。

普段からAPI Referenceやヘッダファイルを見ておくといろいろ便利な機能があることに気づかされます。

2013-08-03

CCMoveTo, CCMoveByなどのCCAction系の競合対策

CCMoveToなどのアクションでは、到達時間と目標値(By系は変更量)を指定します。

これらは、あるアクションをやっている途中にもうひとつ別のアクションを重ねると、思わぬ動作をすることがあります。
一つ例を挙げます。
あるCCSpriteオブジェクトが(0,0)にあるとします。
CCMoveToで座標(100,100)に1秒で移動するようにしたとします。
1秒が終わる前に、もうひとつ同じ内容のCCMoveToを実行したら、最終的には(100,100)には着きません。
もっと先に進んでます。
どこ辺りにつくかは、2番目のCCMoveToを起動したタイミング次第です。

これがなぜ起こるか説明します。
CCMoveToなどのCCAction系は、runActionで起動すると、毎フレームどれだけ移動すればいいか計算し、
対象のCCNode系オブジェクトの毎フレームのループで、変更量を積み重ねます。
CCMoveToで言えば、setPositionによってCCNodeの位置を毎フレーム変更します。
2つのCCMoveToが同時に走ると、positionプロパティに、毎フレーム、別の値がプラスされることになります。
当然、目的の場所には着きません。

このような、ひとつのリソース変数(ここで言えばposotionプロパティ)に2つのものから書き込みがされることを、情報系の用語では「競合」と言います。

今回は、僕が競合による期待しない動作を回避するために対策した方法をいくつか紹介します。



ゞス腓起こるようなアクションを同時に2つ 走らせない
そもそも競合を起こさない、という話です。
大体、CCRotationとCCMoveToのような別種のものを2つ重ねるケースはあるでしょうが、同種のものを重ねなければならないケースなど滅多にないでしょう。
最初から競合が絶対に発生しないようなソースを書くのが一番です。

それができない場合は、1つ目が終わってから2つ目のものを起動するか、2つ目のものを起動する直前に1つ目のものを停止させればOKです。

前者はCCCallFuncなどのコールバックで実現出来ますね。
後者のための一番簡単なメソッドはstopAllActions()です。
全て止めるのが無理なら、一つ目のアクションにsetTag(int タグ値)でタグをセットしておいて、stopActionByTag(タグ値)で止めてやりましょう。


ccConfig.hのCC_ENABLE_STACKABLE_ACTIONSマクロを0に
実は、CCMoveToなどのpositionを変えるアクションが2つ重なった時に、ちゃんと目的地で止めるか、それとも2つ分の変更値を合算するようにするか、というのは、コンフィグマクロで指定出来ます。
それがccConfig.hのCC_ENABLE_STACKABLE_ACTIONSです。
バージョン2.1以降は2つ分の変更値が合算されるようになっているらしいです。
実際は合算させねばならないようなケースはあまりないでしょう。
基本的に0にして使って問題ないと思います。


H岾以圈ccTouchMoveメソッド内でアクションを起動する処理を書かない
あまり気を使わずにゲームを作っていると、ccTouchMoveメソッド内でCCMoveTo系のアクションを起動するコードを書いちゃうこともあるかと思います。
ただ、ccTouch系のタッチデリゲートメソッドは、現在のゲームのループに割り込んで呼ばれます。
cocos2d-xは、毎フレーム、update系のループメソッドを実行することで動いているわけですが、ccTouch系のメソッド呼び出しは、それに対して割り込んできます。
ccTouchMoveメソッドの中でCCMoveToを起動していたりしたら、当然競合が発生します。


ていうか、1フレームの間に何度も呼ばれるメソッドでそんな処理するのはCPU負荷的に無駄です。
(2013-11-14追記:人に聞いた情報ですが、上記は誤りのようです。ccTouchMovedの頻度は、そんなに高くないらしいです。頻度はデバイスに依存し、測定した方によるとiOSで4~5回/秒、Androidで頻度が高い端末だと12回/秒くらいだったそうです。cocos2d-x界隈で有名な方に聞いた情報ですが、製品開発のときは必要であれば調査するのをおすすめします。)

ゲームの開発では、ユーザからの入力もフレーム単位でしか扱わないのが通常だと思います。
cocos2d-xでそれに従うなら次のようにするといいとおもいます。

1,TouchContainerクラスを用意する

class TouchContainer {
public:
CCTouch* touchBegan;
CCTouch* touchMove;
CCTouch* touchEnd;
CCTouch* touchCanceled;
};

2,ccTouch系のメソッドでは上記のクラスに引数のCCTouchの値をコピーするだけにする。

3,updateメソッドなどのフレーム処理で、上記の値を使って、タッチに対する処理を行うようにする。

これで、通常のゲーム開発と同じやり方でユーザ入力が扱えると思います。


今回の記事は以上です。

2013-07-19

cocos2d-xでCocosDenshionのデバッグログを出力する方法

CocosDenshionのデバッグ出力マクロCDLOGは、デフォルトの条件付きコンパイルでは何も出力しません。
SimpleAudioEngineは、エラーになってもCDLOGでログを吐いて終了するだけで、他に何もエラー通知をしないメソッドを含んでいる(loadなど)ので、CDLOGを有効にした方がいいでしょう。

やり方は簡単。CDConfig.hで
#define CD_DEBUG 1
コメントアウトを外すだけです。

短いけどこれでこの記事は終わり!

2013-07-09

cocos2d-xでメモリリークを防ぐ開発習慣

cocos2d-xはC++で開発するため、メモリ管理が自由にできてパフォーマンス最適化がしやすい反面、人為的ミスでメモリリークや解放処理ミスを起こしやすい環境だと言えます。

メモリリークや解放処理ミスは再現や修正が非常に難しいバグであり、開発工程終盤になればなるほど難易度が増します。
発生させたらすぐに発見できるような開発習慣をつけておくことが大切です。

この記事では、僕が良い習慣だと考えているものをあげます。
随時追記し説明を詳細化していく予定です。


,い蹐鵑淵織ぅ潺鵐阿妊掘璽鵑魍放してみる
Cocos2dxでシーンの解放は非常に簡単です。
今、GameSceneというシーンの中でのメモリリークを検知したいとしましょう。
適当なテスト用のシーンを用意しておき(GameOverScene)、GameScene内の任意の場所に以下を記載します。
CCDirector::sharedDirector()->replaceScene(GameOverScene::create());

これにより、GameSceneを開放した上でGameOverSceneに移行します。
シーン内で確保したメモリが全て解放されていればメモリリーク無しといえます。
解放処理に重大なミスがあると、EXC_BAD_ACCESSなどの例外で停止します。

常にメモリ使用量を表示しておくのも有効です。
GameScene起動前と解放後のメモリ使用量が異なっている場合はメモリリークが起きている可能性があります。

デストラクタは、いつ呼ばれようとも確保したメモリは全て解放できるように書くのがベストです。
いろいろな場所に上記のシーン移動処理を入れてみて、メモリリークが発生しないことを確認するといいでしょう。

メモリ使用量表示方法はsyuhariさんが紹介しておられます。
http://blog.syuhari.jp/archives/2352
こちらでは、CCDirectorを修正する方法をとっていますが、Cocos2d内部のファイルには手を入れたくない方が多いと思います。
そのため、専用のCCLabelTTF派生クラスを作成しました。
このブログの最後に記載しますのでお使いください。





メモリリーク箇所探索の手助けにInstrumentsのLeaksツールを使う
http://tks2.net/memo/?p=122
清水さんが使い方を簡単に紹介しておられました。
僕はまだC++でInstrumentsをつかったことがないので、使ってみてまたこの記事で共有します。





■メモリ使用量(残りメモリ量)表示クラスMemoryUsedMetor

(2013-07-17追記:CCLabelTTFを毎フレーム描画更新しているので描画処理負荷が大きいという指摘をいただいています。)

・使い方
貼り付けたいLayerに対して以下でaddChildします。
MemoryUsedMetor* memoryMetor = MemoryUsedMetor::create();
memoryMetor->setAnchorPoint(ccp(1, 0));
memoryMetor->setPosition(ccp(CCDirector::sharedDirector()->getWinSize().width, 0));
layer->addChild(memoryMetor);


・MemoryUsedMetor.h

#ifndef __MemoryUsedMetor__
#define __MemoryUsedMetor__

#include <iostream>
#include "cocos2d.h"
USING_NS_CC;

class MemoryUsedMetor : public CCLabelTTF {
private:
bool init();
void update(float delta);
double getAvailableBytes();
double getAvailableKiloBytes();
double getAvailableMegaBytes();
public:
CREATE_FUNC(MemoryUsedMetor);
~MemoryUsedMetor();
};

#endif /* defined(__MemoryUsedMetor__) */



・MemoryUsedMetor.cpp
#include "MemoryUsedMetor.h"
#include <sys/sysctl.h>
#import <mach/mach.h>
#import <mach/mach_host.h>

bool MemoryUsedMetor::init() {
if (!CCLabelTTF::initWithString("000.0", "Arial", 48)) {
return false;
}

scheduleUpdate();
return true;
}

MemoryUsedMetor::~MemoryUsedMetor() {
unscheduleUpdate();
}

void MemoryUsedMetor::update(float delta) {
char megaBytes[12];
sprintf(megaBytes, "%.1f MB", getAvailableMegaBytes());
setString(megaBytes);
}

double MemoryUsedMetor::getAvailableBytes() {
vm_statistics_data_t vmStats;
mach_msg_type_number_t infoCount = HOST_VM_INFO_COUNT;
kern_return_t kernReturn = host_statistics(mach_host_self(), HOST_VM_INFO, (host_info_t)&vmStats, &infoCount);
if (kernReturn != KERN_SUCCESS) {
return 0.0f;
}

return (vm_page_size * vmStats.free_count);
}

double MemoryUsedMetor::getAvailableKiloBytes() {
return getAvailableBytes() / 1024.0f;

}

double MemoryUsedMetor::getAvailableMegaBytes() {
return getAvailableKiloBytes() / 1024.0f;
}

2013-07-08

SuperAnimationConverterの使い方メモ

最近cocos2d-xでSuperAnimationConverterを使っています。

SuperAnimationConverterとは、簡単に言うと、FlashProffesionalで作ったSWFをcocos2dシリーズで再生させるためのツールとライブラリです。
SWFスプライトシート化するツールは多くありますが、キャラクタの体をパーツに分けてモーションさせるタイプのSWFを、パーツごとの画像に分割して再生できるのは、これとspineくらいでしょう。
spineは独自オーサリングツールですが、SuperAnimationConverterはFlashProffesionalでSWFを作って、それを変換するやり方なので、Flasherが慣れたツールを使えるという点でメリットがあるかと思います。

この記事ではツール側の細かな紹介は行いません。
githubからzipダウンロードすると、中に説明書きのpdfが入っていますのでそれを読めばわかります。
https://github.com/raymondlu/super-animation-samples


基本的な使い方はsyuhariさんが紹介されています。
http://blog.syuhari.jp/archives/2428

ツール側はpdfを読めばわかるのですが、ソースコード側は全くリファレンスがありません。
ソースコードとサンプルを読めというスタンスですね。
なので、ソースを読んで調べたことをメモとしてまとめることにしました。


スプライトシートの使い方
吐き出された画像をTexturePackerでスプライトシートにまとめて使うことができます。
ダウンロードしたzip内にあるpdfに使い方と注意点が書かれてますね。
スプライトシートを使わない場合は、Resourcesフォルダには、samファイルとバラバラ画像を置くことになりますが、
スプライトシートを使う場合はsamファイルと同名のplistファイルとスプライトシート画像ファイルを置けばよいです。
スプライトシートがある場合は、CCSpriteFrameCacheに登録され、そちらが使われるようになっています。

・アニメーションをループさせる方法
OnAnimSectionEndを使ってループ、、、させる必要はありません。
PlaySectionメソッドの第二引数にtrueを指定してください。デフォルトではfalse扱いになってます。

・終了時以外にもコールバック呼びたい!
タイムイベントを登録できます。
void registerTimeEvent(const std::string &theLabel, float theTimeFactor, int theEventId);
void removeTimeEvent(const std::string &theLabel, int theEventId);

使い方は、引数を見ればだいたいわかるかと思いますが、ダウンロードしたzipについてくるサンプルにサンプルコードが含まれています。
ラベルがタイムラインのラベル、イベントIDはタイムイベントごとに独自につけるID、タイムファクターは、タイムライン開始地点が0.0f、終了地点が1.0fです。

登録すると、指定した時間が経つとInit()でリスナーとして登録したクラスの以下のコールバックが呼び出されるので、実装しておきましょう。
void OnTimeEvent(int theId, std::string theLabelName, int theEventId);

現状、OnAnimSectionEndとOnTimeEvent以外にコールバックはありません。

・他のActionとの競合について
SuperAnimationConverterはcocos2d-xのActionは使っていません。
CCNodeのupdateとdrawをオーバーライドして処理を行なっています。
ですので、Actionとの競合は発生しません。つまり、stopAllActionsメソッドなどには反応しません。
中断したい場合は、Pause、Resumeなどのメソッドがあるのでそちらを使ってください。

2013-07-05

SuperAnimationConverterのcppファイルのcocos2d-x2.1.4への対応

SuperAnimationConverterという、FlashProffesionalで作ったswfアニメをcocos2dシリーズで再生制御するためのライブラリがあります。

ccoos2d-x2.1β3までは対応しているようですが、2.1.4に組み込んだらビルドエラーが出たので、解消方法をメモします。

エラーが出たのはSuperAnimNodeV2.cppファイル内の1箇所です。

SuperAnimNodeV2.cpp:750:123: No member named 'fullPathFromRelativePath' in 'cocos2d::CCFileUtils'; did you mean 'fullPathFromRelativeFile'?
というエラーメッセージが出ます。

fullPathFromRelativePathというメソッドは2.1.4ではもうなくなっています。
fullPathForFilenameメソッドに置き換えてください。

2013-06-30

cocos2d-xを学習する方法:和書の書評

cocos2d-x関連の和書で、発刊が周知されていた3冊が出揃いました。
この記事では、それらを紹介し、個人のレベルに合わせてどれを読んでいけばいいかお勧めを書きたいと思います。

より初心者向けのものから書いていきます。

cocos2d-x入門

cocos2d-x入門

cocos2d-x.jp代表やってる清水さんの書いた初心者向けの本。
C++文法についても簡単に触れています。
cocos2d-xとは、というところから書いています。
全くcocos2dシリーズを知らないならこれで始めるといいでしょう。
プログラミング初心者もこれが一番。

やはり清水さんの本。
上の本に比べて、基本的概念の解説が少し簡略化されて密度が濃くなってますが、そこまで難しさは変わりません。
他の2dスプライトフレームワークFlashとか)を触ったことがある人なら、これで始めて全く問題ないと思います。
GlyphDesigner、CocosBuilder、PhysicsEditorを使ったゲームサンプルが1つずつが載っています。


上の2つの本は写経用であり、サンプルソースを全て写経すればcocos2dをリファレンス見ながら書けるレベルまで到れるでしょう。
写経しながら、周辺ツールの使い方も覚えられると思います。

こちらは、逆引きリファレンスといったものです。
業務や趣味で既にcocos2d-xを使っている人、cocos2d-iphoneを使っていて
、cocos2d-xとの違いを知りたいだけの人はこの一冊で十分です。
逆引きリファレンスといえどノウハウのかたまりなので、全て読み通しておくと、何か困ったときに、「あの辺りに書いてあったかな」と辞書をひくように読み直せると思います。
cocos2d-xはまだ日本語の情報が少なく、リファレンスDoxygenも記述が少ないので、英語の公式サイトやTestCppやcocs2d-xのソースを読めば十分!という人もこれは買っておくと良いと思います。

この本は最高ですが、欲を言えば、TiledやCocosBuilderなど周辺ツールの記載が簡略です。
値段を高くしていいから、もっと量が充実していると嬉しかった。

この本に書いてないTipsについて、今後このブログでも共有して行きたいと思います。



cocos2dで作る iPhone&iPadゲームプログラミング

cocos2dで作る iPhone&iPadゲームプログラミング

この本は、Cocos2d-iphoneの本であり、しかも、バージョン0.9に基づいた本です。(現在のバージョンは2.1)
翻訳書であり、原書の方はバージョン2に対応したものが出ています。
Cocos2d-iphoneは新規機能開発が行われないことはほぼ確定しているようなものであり(iOS7の2Dフレームワークのせい ゲフンゲフン)、Cocos2d-iphone使用者が減ることを考えると、和書が改訂されることはないでしょう。

それでも僕は入門にはこの本を一番におすすめできます。
理由を順不同に挙げます。
・量と質の差。周辺ツールおよび機能をくまなく取り上げている。上の本はタイルやパララックスのことを詳しく取り上げていない。
・ゲーム開発の基本的考え方や、良いゲームプログラミング、とは、といったところまで踏み込む。上で紹介した本が、あくまでcocos2dを使いこなせるようになるための本であるとするなら、この本は、cocos2dを道具としてゲーム開発そのものを学べる本だと思う。
・cocos2d-xのAPIはcocos2d-iphoneAPIとほぼ同じ。cocos2d-iphoneができる人はcocos2d-xもできる。
・原書のバージョン2向けのサンプルソースを読みながら、この本の0.9向けのソース解説を読むことは十分に可能(僕がそうやって学んだので)。このブログ内でも、関連する記事を書いていますので読んでみてください。


今更cocos2d-xのためにcocos2d-iphoneの本を使って学びたい、という人はいないでしょうが、この本が読者をひきあげてくれるレベルが他よりも高いので、やはりこの本が初心者向けにはベストと言わざるを得ません。

以上です。

2013-06-19

cocos2dの派生クラスで気をつけること2つ

また釣りっぽいタイトルになってしまった。。。
短いキーワードでタイトルを作ると自ずとそうなるのだろうか。


さて、cocos2d-xの書籍として「cocos2d-x 開発のレシピ」というのが発売されてまして、先日ひと通り読みました。
その上で、CCObjectを継承したクラスを作るときに、気をつけなければいけないと思った点が2点ありましたので紹介します。
つまり自分で調査した訳ではなく単なる抜粋です。すみません。




コンストラクタに例外が発生するような処理を書かない

軽量化のために、コンストラクタでは例外は扱わないようにしているらしいです。
ソースについては未調査です。
調査したら追記します。

基本的に、初期処理はinitXxx()メソッドを作ってそちらに書きましょう。
CCObject派生クラスにはinitXxx()メソッドは必ず用意するのがcocos2d-xの慣習(というか、cocos2d-iphoneから来たiOSの慣習だと思う)だと思うので用意するべきです。
あ、initXxx()は戻り値をboolにしてください。


create系メソッドを作ったらretain&autorelease

クラスを作ろときは (new Hogehoge())->init(); していらなくなったらretain、でもいいのですが、便利のためにコンビニエンスコンストラクタを作るのもいいですね。
cocos2d-xの命名規則ではcreate()やcreateWithXxx(Xxx xxx)が慣例のようです。

中では以下のようにします。
Hoge* ret = new Hoge();
if (ret != NULL && ret->init()) {
ret->autorelease();
return ret;
}

CC_SAFE_DELETE(ret);
return NULL;


CCSpriteとかのcreate()もこうなってるので見てみてください。

 

2013-06-15

cocos2d-xでxcodeプロジェクトを作成した時に最初にすべきこと

意図せず釣りっぽいタイトルになってしまった。。。

ここではinstall_template.shで導入したテンプレートを使ってxcodeプロジェクトを作成した時に最初にすべきことを書きます。

一言で言うと、それはResourcesグループとClassesグループのPathを設定することです。

XCodeのプロジェクトは、ファイルを入れるフォルダのことをグループと呼んでいて、このグループの木構造はプロジェクト不フォルダの実際のなフォルダ構造そのままとは限りません。
グループの場所が、プロジェクトフォルダ外の全く別の場所に結びついていても構わないわけです。

XCodeのウィンドウの左側(NavgatorのProjectNavigator)でフォルダのアイコンマウスでフォーカスすると、ウィンドウの右側(Utilitiesのinspector)のIdentityというところに情報が出ます。
この中のPathが、ResourcesフォルダとClassesフォルダではNoneになっています。
つまり設定されていません。

このままの状態だと、[Add Files To...]でグループにファイルを作成すると、プロジェクトフォルダ直下に入ってしまい、実際のResourcesフォルダ内に作成されません。


対処方法は簡単で、Noneと書かれている部分の右にあるアイコンをクリックして、Resourcesフォルダの場所を教えてあげてください。
(Relative to Groupを選択した状態で行なってください)
そうすると、Resourcesグループに最初から入っていたファイルたちが、ProjectNavigatorで赤文字になると思います。
これは、格納されていたグループのPathの値が変わったことで一時的にファイルのPathがわからなくなっているのです。
それらに対しても、ProjectNavigatorですべてフォーカス選択した状態で、inspectorでNoneの右のアイコンをクリックし、Resourcesフォルダの場所を教えてあげると、赤文字状態は解消されます。


この問題は、project_creator.pyでは発生しません。
install-template.shが悪いんだから修正してPullRequestしろよ、という話なのですが、僕が面倒くさがってるだけです。
誰かやってくれると嬉しいな〜

2013-06-12

cocos2d-xで等角タイルマップを扱うときのはまりどころ

■必須設定
http://www.cocos2d-x.org/boards/6/topics/25129
に設定を記載してくださった方がおり、この記事はその紹介です。

cocos2d-xバージョン2.1.3rc0(5/1リリース版)で等角タイルマップを扱うための必須設定は以下となります。
AppDelegate.cppに以下を加えます。

CCDirector *pDirector = CCDirector::sharedDirector();
pDirector->setDepthTest(true);
pDirector->setProjection(kCCDirectorProjection2D);

前者はCCNode::setVertexZ()を用いて、Z座標を操作する場合にのみ必要です。
前者はcocos2d-iphoneでは不要でした。

後者はcocos2dを2D投影モードなるものに設定するらしいのですが、どういうものかは未調査です。
わかったら追記しようと思います。

Tiledエディタレイヤープロパティにcc_vertexzを設定する必要がありますので、それについては以下を参照してください。
http://www.cocos2d-x.org/projects/cocos2d-x/wiki/TileMap

■tmxファイル(Tiledエディタで作成したファイル)に対する制限
・タイルセット画像は一個しか扱えません。複数使っているとエラーになります。エラーメッセージが吐かれます。
  複数のタイルセット画像を使いたい場合はTexturePackerなどで1ファイルにまとめましょう。

・各レイヤーに必ず一つはタイルが必要です。
  全く無いレイヤーがあるとエラーになります。エラーメッセージが吐かれます。

cocos2d-xの場合はまだ情報が少ないこともあってはまりやすいので、エラーメッセージを見ることがデバッグのポイントになのかもしれませんね。

■おまけ
http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:tiled_maps
cc_alpha_funcの意味がよくわからない。。。
  

2013-05-20

createJSでクロスドメインの画像ファイルを使った時のマウスイベントエラーへの対処

createjsでは、クロスドメインの問題で悩まされるときがあります。

その中の一つに、
JSファイルを実行しているのと別のドメイン(画像を置いてるサーバなど)から画像をロードしたBitmap/BitmapAnimationだとマウスイベントが拾えない」
という問題があります。

ドメインの画像で作ったボタンなどをクリックするとChromeでは以下のJavascriptエラーが出ます。

Unable to get image data from canvas because the canvas has been tainted by cross-origin data.
Uncaught An error has occurred. This is most likely due to security restrictions on reading canvas pixel data with local or cross-domain images.

1行目はブラウザにより報告されているエラーです。
2行目はCreateJSにより報告されているエラーです。

createjsのソースを見ると、これは、DisplayObject.jsの_testHit()メソッドで生じていることがわかります。(easeljsバージョン0.6.0時点)

p._testHit = function(ctx) {
try {
var hit = ctx.getImageData(0, 0, 1, 1).data[3] > 1;
} catch (e) {
if (!DisplayObject.suppressCrossDomainErrors) {
throw "An error has occurred. This is most likely due to security restrictions on reading canvas pixel data with local or cross-domain images.";
}
}
return hit;
}

1行目はcanvasAPIであるgetImageData()で出ていて、2行目はthrowしているエラーメッセージです。
エラーを投げているのでここで処理が止まってしまいます。

getImageData()でエラーが発生しているのですから、suppressCrossDomainErrorsプロパティをtrueに設定しても解決しません。


蛇足ですが、この関数が何をやってるか説明すると、マウスポインタがある座標のピクセルのαが1(完全不透明が255です)より大きければヒットテストに合格した、と判定しています。
Easeljsは透過している部分をマウスイベントの対象から除外するんですよね。
>0でなく>1で判定している理由は不明です。



■対処方法
衝突判定のために衝突判定専用の表示オブジェクトを用意する、という定番の方法を利用します。
簡単なのは、ボタンと同じサイズのShapeを用意することですね。

サンプルソース

var button = new createjs.Bitmap('別ドメイン/button.png');
button.addEventListener("mousedown", buttonMouseDownHandler);
var hitObject = new createjs.Shape();
hitObject .graphics.beginFill("#000000").drawRect(0, 0, button.image.width, button.image.height);
button.hitArea = hitObject;

parentObject.addChild(button);



以下がポイントです。
hitObjectの位置は、buttonの相対座標としてマウスイベント時に計算されます。なので、buttonと同じ位置に設定したければx=0、y=0でOK。
マウスイベントリスナーはbuttonにつけてOKです。hitAreaに設定しているオブジェクトがあると、そちらに対して_hitTest()関数で判定されます。
hitObjectは表示リストに加える必要がありません。なので、ステージ上には表示されません。αが不透明でありさえすれば何色であっても問題ありません。


特に、表示リストに加える必要がない!というのがhitAreaプロパティを使う利点かな、と思います。
表示リストに衝突判定専用のオブジェクトを加えるなら不透明が強制されるのは不便ですからね。

2013-01-19

cocos2d-iphone 2.0でのARC対応(2013-02-17追記)

※はじめに書いておくと、この記事は以下の記事に書いてあることを紹介しているだけです。最初から以下の記事を読んでもらえばこの記事は読む必要ないです。大して英語力は必要ないです。
http://www.learn-cocos2d.com/2012/04/enable-arc-cocos2d-project-video-tutorial/

結論から書きます。
cocos2dで自分が書くソースでARC使いたいなら、以下の2つの方法が簡単です。
‐綉チュートリアルを真似して、cocos2dライブラリと自分のソースを分離し、自分のソースだけARC化
learn-cocos2d.comで公開されているhttps://github.com/LearnCocos2D/cocos2d-iphone-arc-templates をダウンロードしてプロジェクトの雛形として使う。


cocos2d-iphone 2.0は、ARCと共存可能(compatible)ですが、cocos2dのライブラリ自体はARCに対応していません。

すなわち、自分が書くソースはARC使えるけど、cocos2dのライブラリはARCに基づいて書かれてないってことです。
最新のXCodeにはソースをARC対応させる機能があります。
[Edit]→[Refactor]→[Convert to Objective-C ARC...] です。

cocos2dライブラリはARC化してないので、この機能をプロジェクトに使うと大量の警告が出ます。
自力で対応させるのは現実的ではありません。
というか、自力で対応させたら是非cocos2dのgithubにPullRequest送ってあげてください。


cocos2d 2.0でXcodeインストールしたテンプレートは、ライブラリ部分以外(ライブラリを使う側、アプリ部分、main.mとか)もARCに対応していません。
なので、main.mでautorelease poolが指定されており、CCArrayやNSMutableArrayといった配列を定義して要素を格納しても、次のフレームには格納した要素が解放されているということが生じます。

そこは、autoreleaseを意識したソース書けば解決ですが、せっかくARCという便利な機能があるのだから使っちゃいましょう!

という訳で、既にcocos2dのテンプレートで作成済みのプロジェクトをARC化したいなら,鬚笋辰討ださい。
慣れればすぐできます。

最初からARC対応したプロジェクトを作りたいなら△鮖箸Δ里簡単でしょう。
△蓮↓,既に行われた雛形、というだけのものだと思います。


ちなみに、最新のcocos2d本(和訳はまだ出版されてません)のソースコードzipファイルには最初から△入ってます。
http://www.learn-cocos2d.com/store/book-learn-cocos2d/
学習の出発点としてはこの本のソースはとてもいいと思います。
記事内の「Cocos2D Source Code (ARC) (Cocos2D v2.0; includes 12 Cocos2D ARC templates)」からダウンロードできます。

(2013-02-17追記)
以上の方法をとった場合、シミュレータだと実行出来ますが、iOS Deviceだとリンクエラーが起こります。
ld: library not found for -lcocos2d-library
というメッセージです。
以下のページのコメントのやりとりに解決策がありました。
http://www.learn-cocos2d.com/2012/04/enabling-arc-cocos2d-project-howto-stepbystep-tutorialguide/
自分のアプリとcocos2dライブラリの両方のBuild Settingで、Build Active Architecture OnlyをNoにしてください。
cocos2dライブラリを作ったときはデフォルトでYesになっています。

2013-01-03

cocos2d-iphone 2.0でのHD画像を用意しない簡単なRetina対応

(ここではiPhone4SまでのRetina対応に関する知見を書きます。
アスペクト比の変わるiPhone5でどうすべきかは未調査です。)

cocos2d-iphone 2.0でのRetina対応ですが、
Retina向けの高精細画像では以下のようにファイル名を変更するだけです。

Retina用:xxx.png
Retina用:xxx-hd.png

iPadの場合はxxx-ipad.png、iPadRetina用にはxxx-ipadhd.pngです。
ソースコード内ではxxx.pngというファイル名で扱っていても、デバイスによってcocos2d側で勝手にファイル名を変換して読み込んでくれます。

と、ここまでのことはAppDelegate.mのapplicationメソッド内のコメントに書いてあり、このサフィックスについてもそこのソースを編集すれば変えられます。

さて、わざわざ高精細画像を用意しない場合、つまりResourceフォルダ内にxxx-hd.pngなどを置かないと、Retinaディスプレイであってもcocos2dはxxx.pngを使います。
これはフォールバックと呼ばれているようです。

しかし、そのまま使うと、画面全体のサイズに対して、画像が半分のサイズで表示されてしまいます。
縦横のピクセル数をそのまま反映すると考えれば自然なことです。

画像の精細度が半分になってもいいから、Retinaでも同じように表示したい、という場合はapplicationメソッド内で以下をコメントアウトすればOKです。

if( ! [director_ enableRetinaDisplay:YES] )
CCLOG(@"Retina Display Not supported");

cocos2d 2.0のテンプレートでは上記の処理が含まれています。
cocos2dの古いバージョンでは、上記はコメントアウトされていたようですね。少なくとも0.99.5では。
(どのバージョンからコメントが外されたかは未調査です。)


applicationメソッドの中では各種初期設定を行なっているので、理解するとためになると思います。

cocos2d-iphone 2.0で縦画面と横画面を切り替える方法

先の記事
http://d.hatena.ne.jp/DiegoTristan/20130102/1357135643
で、縦画面表示になってしまう理由が不明だと書きました。
その解答が見つかりました。
バージョンはcocos2d-iphone 2.0.0です。

結論から言うと、Info.plistのSupported Interface OrientationでPortraitにしてれば縦画面で表示されるし、Landscapeにしてれば横画面に表示されます。
(BOOL)shouldAutorotateToInterfaceOrientationメソッドは何も影響しません。
このメソッドは、起動時にも端末の回転時にも呼ばれないことをデバッガで確認しました。
調べていませんが、他の用途のためにあるのでしょう。


ここまでだと、何でわざわざこのような簡単なことではまり、わざわざ記事を書いたのかと疑問に思われるでしょうが、
答えは簡単で、
参考にした下記の書籍のサンプルソースで回転が有効になっていなかったからです。

Learn cocos2d 2: Game Development for iOS

Learn cocos2d 2: Game Development for iOS



おそらくcocos2d 2.0のベータバージョンか何かを元にしているのでしょうか、
AppDelegate.mのdidFinishLaunchingWithOptionメソッド内で
[window_ addSubView:navController_.view]としています。
これだと、必ず縦画面になってしまい、info.plistを編集しても変わりません。
(原因は未調査です。)

現在は、cocos2d 2.0のテンプレートでプロジェクトを作ると、
[window_ setRootViewController:navController_];
となっていますが、これでしたらOKです。

まあ、おそらくは単に、古いバージョンのソースを参考にしていてはまってしまったというだけですね。

2013-01-02

cocos2dのtmxファイルの1レイヤー1タイルセット制限

AIRで作っていたブロック崩しシューティングゲームを放っておいて、
最近はcocos2d-iphoneやTiledMapEditorを触っていました。

今回、TiledMapEditorを使っていてはまったことの一つがタイトルの件でした。
1つのレイヤーに複数のタイルセット画像を用いていたのですが、そうすると実行時に
TMX: Only 1 tilset per layer is supported'
というエラーメッセージが吐かれます。
で、タイルの読み込みあるいは表示のどちらが失敗してるか調べてませんがともかく表示に失敗します。
これはおそらくCocos2dの仕様なのですが、ドキュメントは確認していません。
cocos2d-iphoneのバージョンは2.0.0です。


これの対処方法はまさにそのまんまというか、1レイヤーにつかうタイルセットを1枚にするしかありません。
使う画像は一枚の画像ファイルにまとめておけ、ということですね。
逆に、一枚のタイルセットを複数のレイヤーで使用する分には問題ありません。


僕は、同じタイル画像を複数持って、それらに別々のタイルプロパティの値を持たせる、ということがやりたかったので、1レイヤーに同じタイルセット画像を名前を変えて複数使おうとして上記のエラーにはまりました。
なぜ一枚のタイルセット画像に同じタイル画像を複数含めなかったのかというと、タイルセット画像の作成に用いているTexturePackerがそれを許さなかったからです。
TexturePackerは、たとえファイル名が違っていても、データ上全く同じ画像だと、複数並べてくれません。
バージョンは現在最新の3.0.4です。
ここら辺は、どなたか解決策をご存知でしたら教えて下さい。


後、現在はまっているのが、作成したcocos2dアプリがなぜか横画面表示できないという問題です。
info.plistのSupported Interface OrientationをPortraitにしても、
AppDelegate.mのshouldAutorotateToInterfaceOrientationを

  • (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation

{
return UIInterfaceOrientationIsLandscape(interfaceOrientation);
}

にしても全く聞きません。
というかデバッグで追いましたが、shouldAutorotateToInterfaceOrientationがそもそも全く呼ばれないので上記の意味がありません。
cocos2d-iphone 2.0.0のテンプレートそのまんまのHelloWorldアプリは、横画面表示でHelloWorldLayerが出てきて、そこから大きく変えていないのに、なぜ必ず縦画面で表示されるのか不思議でなりません。

ちなみに、以下書籍のサンプル(和書じゃないですよ!洋書の最新版のサンプルです)でも同じ問題が発生しますんで、自分のソースのせいではないと思います。
何かご存知の方がいたら教えて下さい。

Learn cocos2d 2: Game Development for iOS

Learn cocos2d 2: Game Development for iOS

2012-12-15

Eclipseでgithubリポジトリをチェックアウトするメモ

自プロジェクトをアップロードする記事はあっても
他者のプロジェクトをチェックアウトする方法が書いてある記事がなかなか見つからなかったのですが、以下がよかったです。

http://rough-and-ready-co-jp.blogspot.jp/2012/02/giteclipsegithub.html

プロジェクトをインポート、Import as General Project が肝ですね。

自分の環境だと、例えばLWFのインポートには相当な時間がかかりました。
2時間くらいかかった記憶が。。
単に特定リビジョンをダウンロードするのと違い、これまでの全リビジョンの情報をとってくるからだと思います。

FlashBuilderもEclipseベースなので同様の方法です。


最近頻繁にxcode触ってますが、xcodeはどうするんでしょうね。

2012-11-04

自分のキャリアに用いる開発環境を定める

ITエンジニア(ゲーム開発エンジニアを含む意味で)は職務経歴書
自分の得意な分野、開発環境、言語を書くわけですが、
自分もweb系を始めて1年半。DBサーバに、一部クライアントにと他の同僚と違い広く浅く経験してきましたが、やはり方向性を絞らねばなりせん。

自分が組み込み系エンジニアだったときはCかC++一択だったし、サーバという概念はありませんでした。

ゲームのクライアントエンジニアならばやはりC++一択ですね(一部C#もあるようですが)。下手すると組み込みより低レイヤーです。

組み込みとゲームは似てるところが多いと思ってます。
一つはwebのコンテンツ会社と違って扱うのがより低レイヤーなことです。
webは何かにつけオープンでapachetomcatみたいなミドルウェアにオープンなDBが普及してますが、組み込みやゲームは何かにつけプロプライエタリで、ミドルにあたる部分は他社から買ってくるか自社で作っているのが当たり前です。
その分、使う環境というのが特定の環境に捕らわれたりします。

webはというと、あまりに環境が乱立しています。
クライアントHTML5Flash、Obj-C、etc、etc、、、サーバもですけどまだクライアントほどではない。

自分はクライアントスキル中心に生きたいし、サーバは1年以上やってみて、「必要だからしょうがなくやる」、以上のやる気と興味が出ませんでした。
これはもう向き不向きであり性格だと思います。30年生きていて自分の好き嫌いは大体把握しているので、1年半やらなくてもとっくにわかっていたことではありました。


本当にいろいろやってきた自分ですが、とりあえずしばらくは以下にフォーカスしたいと思います。

クライアントJSHTMLHTML5中心、CocosとUnityJSも動向監視はしていく)
サーバも他の人がやってくれなかったらやる:JS
・グラフィック用オーサリング:Blendar、FlashCS(フリーでいいものが出たら代替)、GIMPInkscapeも必要があれば
クライアント用ミドル部分に手を出していく:C++
・簡単なツールやアプリをささっと作る:AdobeAIR

正直、クライアントサーバも、C++とかの低水準な言語でがりがり書きたいですが、時代の流れと、他の同僚に使ってもらうことを考えるとJSを選びました。必要な部分にはC++を使っていけばいい。
Obj-Cには非常に興味がありましたが、仕事でやる機会が無さそうなのでこだわっていてもしょうがない。
仕事でやらず趣味に限定されてしまうと極度に成長が遅れます。

AIRは今後そこまで発展するとも業界で支配的地位を得るとも思いませんが、一回書けばwebでもスマホでもデスクトップでもOSを問わずどこでも互換性問題なく安定して動き、環境が乱立しておらず、かつ言語として学びやすくコンパクトでコンパイル言語なのは最高です。
プロプライエタリなのはマイナスですが、他にここまで扱いやすい環境を知りません。
ゲームのモックも作りやすい。
JSは当分そこまでには至らないと思います。


逆に言うと、これ以外の技術やツールになるべく時間を取られずにすむように仕事とキャリアを整理していかねばなりません。
今は特定の言語と環境にかなり人生の時間を割いていますが、その言語には本質的に興味が無いので少しずつ減らしていきたい。
必要は必要ですが、自分は状況を改善するために自分のやりたいことを犠牲にして何にでも手を出してしまい破綻しがちなので、必要性以上に時間を割かないように意識して注意していきたいと思います。

2012-10-28

AdobeAIRでのマルチスクリーンサイズ対応

これまでiOS用のアプリしか作ってきませんでしたが、ちょっとしたきっかけでAndroid用の簡単なアプリを作ることになりました。

手馴れているのでAIRで作ることにしましたが
Androidといえば、やはり様々なスクリーンサイズ対応が問題になってきます。
ちなみにマルチスクリーンに対応して画面パーツのレイアウトが変わるようなものをリキッドレイアウトと呼ぶらしいです。
今回は簡単なリキッドレイアウトがやりたいわけですね。

Flexは画面サイズが違っていてもiPhoneのようにアスペクト比が違うだけなら(今はiPhone5もありますが)基本的に勝手にフィットさせてくれます。
フットサルボードはFlexで作りました。
iPhoneであれば解像度が違っていても無問題です。
ですが、アスペクト比が違うiPadだと想定どおりにうまくリキッドレイアウトしてくれなくて困った記憶があります。

ですので、今回は最初からFlexを使わないことにしました。
FlexFlexのSWCを含めると12MB程度ネイティブよりサイズ上乗せだというのもあります(最近は3G回線でも50MBまでのアプリならダウンロードできるようになりあまり気にならなくなってきましたが)。
AIRだけだと8MB程度です。


さて、リキッドレイアウトをやるためには、デバイスの画面サイズを取得できなければなりません。
それができれば後は適当な位置を計算してパーツを配置するだけです。
そこで結構はまりました。
この記事はそのはまりで得た知見のメモです。

結論から言ってしまうと、以下の情報源が非常に参考になります。
http://www.adobe.com/devnet/air/articles/multiple-screen-sizes.html

最終的には、resizeイベントのイベントハンドラーの中でstage.full
ScreenWidth,fullScreenHeightを取得しました。
起動して数フレームはstageのwidthとheight(fullScreenWidthとfullScreenHeightにも)には正しい値が入ってないというのは本当で、知らなければはまるポイントだと思います。
起動して数フレームで必ずresizeイベントが発行され、そのときには正しい値が入るそのとき値を取得します。
ていうか、これバグに近いですね。回避策もバッドノウハウです。

他にはCapabilities.screenResolutionX,screenResolutionYでも値がとれます。
こちらはresizeイベントを待つ必要はないようです。
ただしこちら、PC上のシミュレータで実行すると、PCの画面のサイズがとれますwww なんでやねん
まあデバイスではちゃんと動くのでしょうが、開発がやりにくいので使うのをやめました。

今回のソースは後ほどgithubで公開します。


FlexもFlashProも使わないと、ちょっとしたコンポーネントさえ無いので、使いどころが限られてきますが、アプリサイズが小さくなるという恩恵を受けます。
フットサルボードではFlexに頼りっぱなしだったのでいい勉強になりました。

個人的にはFlexを使う必要性に迫られなければFlexは使う必要ないと思います。


後、今回、スプラッシュ画面を適用したいのですが、iPhoneならFlexだとスプラッシュ用のattributeがあるし、
Flex使わなくてもDefault.pngを使えばOK。
しかし、Androidはどうもデフォルトスプラッシュというものが存在しないらしいのです。
情報を探すと以下のように強引にやってる人もいますが、もっと簡単にやりたいですね。
http://swfhead.com/blog/?p=817
http://forums.adobe.com/thread/764981
http://forums.adobe.com/message/3691229
いい情報があったら皆さん教えてください。

2012-10-22

githubでフォークして作ったリポジトリをeclipseにプロジェクトとしてインポートした作業メモ

長いタイトルになってしまいました。

最近JSのゲームやアニメーションのソースを触っている関係で、
LWFとCreateJSのソースをいじりたくなりました。
どちらも、SWFHTML5をつなぐJSライブラリとして有名です。


この記事は、
githubでフォークして作ったリポジトリeclipseにプロジェクトとしてインポート
した際の備忘録です。
いろいろ試みて失敗しているので、次に同じ手間をかけないために
仕組みはわからない(調べるのに時間かける気がない)けど、とりあえずこうやったらできたよ、というメモですね。
ちゃんとgitの仕組みやgithubのことを調べて書いたものではないので、ベストの方法であるかどうかはわかりません。


準備:EGitプラグインインストールなど
以下が参考になります。
http://d.hatena.ne.jp/ishibashits/20110627/1309193856

1、githubで見たいソースをフォーク
  解説しません。
2、Eclipseで[ファイル]→[インポート]
3、Gitを選択
4、URIを選択
5、URIのテキストエリアに、githubからとってきたgit@xxx/yyy.git というURIを貼り付ける。そうすると、他の入力項目が勝手に入ります。

どんどん[次へ]で進むと、gitレポジトリがそもそもEclipseプロジェクトではないために、[既存プロジェクトのインポート]では失敗する場面が出ます。
そのときは、

6、ひとつ戻って、[新規に一般プロジェクトを作成]という選択肢があるのでそちらで作成。

そうすればとりあえずひとつのプロジェクトとしてソースを落としてこれます。

まだコミットやプッシュがうまくできてないのでできたらまた加筆します。

2012-10-18

swfからスプライトシートを吐き出す方法のメモ

前の記事の続きです。

以下の記事を大いに参考にさせていただきました。
http://d.hatena.ne.jp/DiegoTristan/20121004/1349371840?_ts=1350580477

仕事上、過去資産swfファイルをスプライトシートに吐き出して
JSで同じモーションをさせる必要が生じました。

FlashCS6のライセンスを持っていれば、それを使ってスプライトシートを生成できた、むしろCreateJSでJSコードに落とせたと思うのですが、CS6持ってないし、そもそも古いバージョンのブラウザもサポートする必要があったのでCanvasベースのライブラリだと困ります。

その話はさておき、以下のツールを試しました。この記事はその備忘録です。
・TexturePacker
・Zoe(CreateJS開発チーム作)
・SwfAnimationConverter(マルチデバイスLab様作)
・SWFSheets(KiethPeterさん作)

下の3つはAIRアプリで、SWFからスプライトシートを出力する機能に特化しています。
TexturePackerはSWFからスプライトシートを出力もできますが、複数画像を一枚のスプライトシートにまとめるのが元々の機能です。
すべてMacにもインストールできます(AIRアプリは当然ですが)。

TexturePackerはひとつ前の記事に書いたとおり、2000円くらいで有償版を買わないと実用になりません。
でも実績あるソフトですし実用性は十分なので買って損は無いと思います。


さて、最終的に私はSWFSheetを使って複数のswfにそれぞれスプライトシートを出力し、それをTexturePackerでさらにまとめてひとつのスプライトシートにしました。

それはなぜかというと、上3つのアプリケーションSWFのルートのタイムラインを読み取る仕組みになっていた(動作からの想像です)からです。
SWFにおいてルートのタイムラインが24フレームのムービーであれば、24枚の画像で出力されました。
(ルートに結びついたタイムラインの入れ子構造まで読み取れるのかは謎です。僕はタイムライン構造を見れていないので。)

これが自分にとっては厄介で、
たまたま自分の持っていたswfのルートが1フレーム扱いになっていたのか、
上の3つのアプリケーションは最初の1フレーム分しか画像を生成してくれませんでした。

それに対し、SWFSheetはタイムライン構造など見ておらず、ムービーを再生して、その途中で設定された枚数のスナップショットを撮影するような仕組みになっているようです。
タイムライン構造気にせずに、ムービーとして再生できさえすればスプライトシートを出力できるし、タイムラインが何フレーム分か気にしなくていいです。
SWFSheetは個人で作られてるからか使い勝手に難がありますが、
ある意味、タイムライン構造を読み取るような高価な機能が無いために使いやすくなっています。


ただSWFSheetはあくまで1swfファイルに1スプライトシートを生成するので、複数のムービーを1スプライトシートにまとめるのはTexturePackerの出番です。
TexturePackerは使い勝手のよいソフトなので触っていれば慣れてすぐに使いこなせるようになるとは思います。
現行のバージョンでひとつ気になったのは、デフォルトの設定であるターゲットが「cocos2d」だと、上の作業がうまくいきませんでした。
というのは、正常にpngファイルを生成しませんでした。

そこでターゲットを「starling/sparrow」(だったかな)にしたところ、理由は不明ですが期待通りのpngを生成できました。


他にもツールはあるでしょうし、Adobeのツールを何でも使える環境ならそれらでやる方法はあると思います。
ここで書いたのは、アマ開発者がお金をかけずにやれる方法だと思っていただければ。

2012-10-04

TexturePackerでswfを読み込む

Starling向けのMovieClipを作るときはTextureAtlas用に
スプライトシートとxmlファイルが必要ですが、
その解説チュートリアルです。
TexturePackerのページにリンクがありました。
英語ですが、映像をまねして触ればすぐ使いこなせるくらい簡単です。

一定動作がループしているようなタイムラインでもうまく一周分だけのスプライトシートに落としこんでくれますし、タイムライン構造がパーツごとに多段になっていても問題ありません。

http://www.youtube.com/watch?v=Qhq4COk_QyU

TexturePackerは、無償版だと着色された画像が必ず含まれてしまうので
使い物になりません。
1000円くらいなのでProを買いましょう。
何らかのフレームワーク開発者や、ブロガーは、それを説明すれば
無料でライセンスがもらえるようです。

swf読み込みもしてくれて超便利!
僕は、自作ゲームの爆発エフェクトを、同僚にswfで作ってもらって
TexturePackerでスプライトシートにしてStarlingに読み込みました。

ちまただと爆発エフェクトのスプライトシートを提供しているサイトは
あっても、TextureAtlas用のxmlは自作せねばならなくなるので、
swfさえ手に入るならTexturePackerを使うのがらくだと思います。


FlashProCS6にはStarling用のスプライトシート書き出し機能があるので、FlashProCS6を持っていればTexturePackerは不要です。


※現在、安定版はMac MountainLionには対応してないようなので、3.0β版インストールが推奨されています。

swf読み込みはかなり重いようで、僕のメモリ2GBしかないMoutainLionのMacでは、読み込もうとすると頻繁にTexturePackerが落ちました。何回か試したらたまたま成功したのでよかったですが。

2012-09-17

CSSSpriteとJSによる極簡単なアニメ

ちょっと仕事上、Flashをつかうほどでもない局面で、
JSで簡単なアニメーションが要求される場面が出ました。

なんで、勉強のためにちょっとアニメーションを作ってみました。
http://futsaltacticsboard.appspot.com/JSExperiment/skelton_anime.html
ソースはブラウザで見れます。

いろいろ調べましたが、canvasなど最近のHTML5の機能や
enchant.jsのような最近のライブラリは、IE9移行でしか使えないことが
わかったので、IE8でも動くDHTMLの技術を使うことにしました。

つまりは、CSSのbackground-imageを使うCSSSpriteと、
JSのsetInterval、setTimeout関数を使ったアニメーションです。
これだけでもファミコンドラクエレベルの表現であれば、可能なようです。


個人的感想ですが、やっぱりJSのようなライトな言語より、自分はC/C++のような低水準言語の方が好きですね。
JavaGCでさえ余計なものに思うくらいなので。。
バイナリアンを自称できるくらいになりたいものです。

iOSゲームアプリの一部をブラウザで遊べるようにしました

まだ製作途中ですが、iOSゲームブロック崩しシューティングをWeb上に上げました。
是非プレーして感想および指摘をいただければとおもいます。

http://futsaltacticsboard.appspot.com/blockShootingFlash/BlockShootingWeb.html

環境はFlashおよびStarlingです。
最新のFlashPlayerが必要です。

iOS、RetinaDisplay用に作られたものなので、PC上では画面サイズ、パフォーマンスやジャギーなどの
アラが見えるものと思います。

2012-09-15

FlashBuilderでワンソースでモバイルプロジェクトとAS3プロジェクトを両方作るテクニック

大したテクニックでもないですが自分用のメモとして。

Flashの利点の一つは、幅広い環境に移植の労が少なく移植できるtことだと思います。

スマホアプリの宣伝のため、機能を制限してWeb上で体験してもらうなんてことが可能なのが素敵です。

ただ、FlashBuilderのプロジェクトはモバイル向けとWeb向けは分かれているので面倒くさい。

僕の場合はスマホ向けのプロジェクトが先にできていて、それをWeb向けにパブリッシュした形ですが、こうしました。

1、AS3プロジェクト作る。(FlexならFlexプロジェクト)
2、ソースパスでスマホプロジェクトのソースとってくる

コンパイラ向けのシンボリックリンクという感じですね!
ただ、素材を入れているフォルダをこの方法でリンクしても
[Embed(source="assets/img.png")]
コンパイルエラーが出ます。(トランスコードができませんとかなんとか)

理由は不明ですが、コンパイル向けのリンクと普通のフォルダのリンクは違うのでしょう。

そういうときは以下で解決。
3、プロジェクト右クリックで[新規]→[フォルダ]
4、[拡張]を選択。[代替場所をリンク]にチェック入れる
5、フォルダ追加。
これで、普通のフォルダのリンクが追加されてEmbedのコンパイルが通ります。

2012-09-02

iOSゲームアプリ、ソース公開しました(ブロック崩しシューティング)

だらだらと作っていたiOS向けゲームのソースを公開しました。

https://github.com/monguri/BlockShooting

f:id:DiegoTristan:20120902185412p:image:w360

まだまだモックレベルなので、バグ報告、アドバイス歓迎いたします。
あまり参考にしたソースが無く自分で考えた部分が多いので、ソースにひどいところはあると思います。
ソースへの指摘は大歓迎です。

OSiOSフレームワークにAdobeAIRおよびStarlingを採用しています。
FlashBuilderでシミュレータ起動できますが、Starlingのソースを含めてないので、含めてビルドしてください。
後日、GoogleAppEngineにFlash形式で公開して誰でも触れるようにしたいと思います。


とりあえず何か簡単なゲームを作ってみたくて、ブロック崩しを選択したのですが、それだけじゃつまらないのでシューティングの要素とボス戦を持たせました。

最も注力したのは、いかに拡張性の高いつくりにするか、という点です。
つまり、今後ステージを増やしたり見た目を派手にしたり敵やアイテムを増やしたりするときになるべく簡単になるようにということです。

そのため、現時点ではモックに過ぎない地味なゲームとなってますが、自分が気分よく拡張できるつくりにしたつもりです。
今回、最初一度作って、拡張性が気に食わなかったので一から作り直してます。


絵や音楽といったアセット面をそろえるのに一番苦労しているので、協力してくれる方がいたらご連絡ください。大歓迎です。



今後の課題メモ
・ステージ数の増大
・ボスの種類を増やす
・敵、ブロックの種類を増やす
・パワーアップアイテム、パワーアップ効果を増やす
・パフォーマンスチューニング
・楽しませるエフェクト、わかりやすいUI
・音楽

アメリカ人の書いたキャリア関連の本の感想

最近、キャリアや仕事のやり方、会社の中での身の振り方について考えたくなったので、IT業界のキャリア関連の本を2冊読みました。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方



オーム社は最近立て続けにいい訳本出してますよね。
ハズレがない感じがします。

それはともかく、この2冊を読んで一番強く印象に残ったことは

アメリカも日本もIT系エンジニアの実態はほとんど変わりない。

ということです。

アメリカというと、シリコンバレーの企業に対する印象が強いもので、
華々しい起業OSSで有名に、大手の高額報酬、レイオフアメリカ人らしい大雑把さやオープンさ
などのイメージがあったのですが、
この2冊で書かれているエンジニアの生き方は何も日本と変わりないものでした。
大学なり何かなりで情報科学について学び、就職活動をし、会社組織の中で人間関係に苦労し、上司に成果をアピールし、転職し、OSS勉強会に参加し、オタクとして生きる。。。

大手の高額報酬、レイオフ、という部分には差異がありますが、その他の点は本当に何も変わりません。
もしかしたら、自分がいるweb業界という業界が、特に日本的な部分が少ない業界だから、という要素があるのかもしれませんが、
やはり、処世術、人との関係の持ち方、成功への道、という社会的人間的な部分がアメリカと日本で何も違わない。

アメリカ人の思考って日本人とあんまり変わらないんだなあ〜というのが驚きでした。


と、第一印象についてばかり書きましたが、事細かにキャリアや仕事のやり方についてセキララに書かれていて、そういうことを経験から学ぶのが苦手な自分には非常に役立ちました。
何度も読み返そうと思います。

2012-07-01

FlashBuilderでipaファイルのビルド中にNotAfter...と出たら

証明書期限切れです。

すごく丁寧な対処法の解説があったのでリンク貼っておきます。

http://mushikago.com/i/?p=705

2012-06-10

フットサルボードアプリをリリースしました。

審査にかけていたアプリが何事も無く審査通過しました。
ちょっと拍子抜けしましたが、こんなもんかもしれませんね。

http://d.hatena.ne.jp/DiegoTristan/20120603/1338752911

iTunesのページは以下です。
http://itunes.apple.com/us/app/futsaltacticeboardfree/id454047745?l=ja&ls=1&mt=8
http://itunes.apple.com/us/app/futsaltacticsboard/id533003750?l=ja&ls=1&mt=8

無償版は更新、有償版は新規リリースです。
とりあえず無償版をDLして触ってみてください。
前回リリースからかなり機能を追加し、アプリとしては実用的なものに仕上がっていると思います。

本格的に使い始めると、有償版でないとしょうしょうしんどいと思います。
1$ですし、次回のアップデートサーバ連携機能をつけるつもりですのでよかったらご購入ください。




さて、今回は、自分のアプリ開発の練習という意味合いを超えて、アプリとして機能が一通り完備なものをリリースしたつもり。
ただリリースしただけだとDL数は伸びないだろうから、どこかで宣伝しようと思う。
どうすればいいんだろう。詳しい人、教えていただけると助かります。


2012-06-12
リリースしたアプリですが、タッチ精度に難があり、操作しにくい点があることが判明しています。いつできるかわからないのですが、次のリリースにて改善しようと思います。

2012-06-03

FlashBuilderで作ったiOSアプリをAppStoreリリースする際のメモ

以前フットサルボードをリリースした際は、FlashProCS5.5を使いました。
今回は初のFlashBuilderによるアプリ、そして有料版も審査にかけた、ということで、いろいろとつまづいた分ノウハウも貯まりましたので、ここにメモを残そうと思います。
基本的なリリース手順は前回経験しているので、今回時間がかかった部分だけ書きます。


〕料版に向けて、銀行口座と税金の手続き

難しいのかなと思ってましたが、思ったより簡単でつまづくところがありませんでした。
参考にしたページを貼っておきます。
http://iphone.o-84.com/pub-apps/itunes-connect/paid-app-regist/
http://blog.livedoor.jp/tattyamm/archives/1177705.html
僕は既存の口座を何の考えも無く設定しましたが、外国から振り込まれる際に手数料がかかるのかとかをちゃんと考慮したほうが本当はいいと思います。

アプリアップロード

ApplicationLoaderを使います。ネットで検索すると、ちらほらと旧バージョンの不具合の問題が書いてあるので、iTunesConnectから最新版(現時点で2.5.1)をDLしましょう。iTunesConnectのManageYourApplicationのページ内に小さくDLリンクがあります。

スクリーンショット

iTunesConnectへのアプリ情報の登録の際に、512×512画像、960×640画像を求められました。
後者は撮影したスクリーンショットで、前者は、その画像を加工して作りました。
Macだと加工用ソフトでプリインストールソフトが無いのでとりえあずFlashProCS6を使いました。

アイコン

これが一番面倒だったwww
アプリiPhone&iPodTouchに対応させるか、iPadに対応させるか、で必要なアイコン画像の種類が違ってきます。
僕は最初、全デバイス対応の設定にしてて、72×72の画像が無いぞ、とApplicationLoaderに怒られました。
実際は、Flexがサイズの差を自動的に吸収してくれるのはアスペクト比が等しいときだけで、フットサルボードはiPad対応はできてないのでiPad向けにリリースする必要はありませんでした。
というわけでiPad対応を落としました。

iPad対応を落とす一番簡単な方法は、FlashBuilderでプロジェクトを作るときに、ターゲットデバイスのチェックをはずすことですが、app.xmlを修正することでも対応できます。
以下のAdobeヘルプに詳しいです。
http://help.adobe.com/ja_JP/air/build/WSfffb011ac560372f7e64a7f12cd2dd1867-8000.html
つまり、iPad対応を落とすなら、<string>1</string>だけにしておけばいいということです。

アプリのサイズをなるべく小さくするためにも、アイコン画像ファイルは必要最低限に抑えましょう。
以下を見ると必要なものがわかります。
http://help.adobe.com/ja_JP/air/build/WS901d38e593cd1bac1e63e3d129907d2886-8000.html
ひらたく言うと、iPhone&iPod touchでipaファイルに入れておく必要があるアイコンは、29×29、48×48、57×57です。
入ってないとApplicationLoaderに怒られてアップロードできないと思います。

AIR for IOSバグ

AIR for iOSを使うと(つまり、FlashBuilderでiPhoneアプリ作ると)、iTunesに表示されるアプリ対応言語がものすごく多くなってしまうバグはまだ解消されてないようです。

フットサルボード(Flexアプリ)をApple審査にかけました

最近人に教えられて初めて知ったのですが、iOSの5.1へのバージョンアップ時に、3G回線のアプリサイズ制限が20MBから50MBに緩和されたとのこと。

http://www.appbank.net/2012/03/08/iphone-news/380678.php

僕がフットサルボードをFlexに移植した後に、機能追加するばかりで一向にリリースしないのはFlexを使うとHelloWorldレベルのアプリでも平気で19MB程度になることでした。

今回の制限解除で、23MBある我がアプリも無事にリリースできると言うわけです。
Flexは、ユーティリティアプリを作るのには本当に作りやすい環境なので非常に助かります。

具体的にFlexで作ったモバイルアプリのメリットデメリットをまとめてみます。

■メリット
AIR環境、AS3環境で作れる。AIRは、ゲームを作るにも適した環境であり、同じツール、同じ言語で、適用範囲が広いのは大きいと思います。
プラットフォーム非依存性が高いです。AndroidiOSの差異の吸収、画面サイズの差異の吸収をフレームワーク側である程度受け持ってくれます。
Flexに慣れてれば作りやすいです。そして高級な環境なので慣れるのは易しいです。

■デメリット
・これが一番の懸念点。FlexはもともとOSSでしたが、ついにAdobeの手を離れてしまいました。Adobe経営判断としてFlexにはリソースを以前ほど割かないと思われ、今後は開発が積極的に行われない可能性が高いです。
アプリサイズの肥大化。Flexだと16MB程度の上乗せは覚悟すべきですかね。
Flexの機能を積極的に使ってしまうとやはり遅い感じがします。iPhone3GSのような前世代端末で顕著。
・これはメリットでもありますが、UIFlexのものになります。
・もちろん、一部、ネイティブで使える機能が使えません。

2012-04-29

フットサルボードサーバ側をgithubに公開しました

フットサルボードサーバ側ですが、基本的な機能実装が一段落したので、githubにあげることにしました。

こちらです。
https://github.com/monguri/futsalTacticsBoard-GAE-J

Eclipsegit-hub向け環境構築は以前書きました。
http://d.hatena.ne.jp/DiegoTristan/20111017/1318874997

Slim3のようなフレームワークは使わずに、生のサーブレット&JSPで書いています。
サーバ側を作るにあたって、以下の本のソースを参考にしました。

クラウド活用のためのANDROID業務アプリ開発入門

クラウド活用のためのANDROID業務アプリ開発入門



スマホアプリ開発の本は多数あれど、サーバ側のことを書いている本はこれ以外知りません。
それも当たり前で、スマホアプリだろうがWebアプリだろうが、WebAPIを設けるのならサーバ側に何の違いも生じないからです。

とはいえ、この本は非常に参考になりました。お勧めできます。
ただ、GAEを使う場合は普通はSlim3Strutsなどのフレームワークを使うのでしょうけど、この本はサーブレット&JSPで書いてあります。


雑談ですが、GAEは最近そんなに人気ないみたいですね。
特に企業においては、GAEは自由度低すぎですからね。
何より環境が特殊すぎる。

企業においては圧倒的にAmazonEC2が使われているようです。
ただ、個人で簡単にWebサービスを作りたい場合は、相変わらず良い選択肢だと思います。


自分、努力して習得しましたが、会社では「GAEうちでは使わないしね」で一蹴です。当然ですが。
かといって、レンタルサーバ借りて、ミドルウェアフレームワークインストールして、っていうのにそこまで興味ないんですよ。
今の仕事上有益なのはわかってるんですけどね。
まあ興味と仕事の方向性が一致できてないということだと思います。


さて、機能的にはフットサルボードはリリースに十分な状態とは言えますが、うーん、まだまだですね。
アプリ未リリース、サーバ側はGAE上で動いてるけど一般ユーザに公開してません。
というのは、ダウンロードアップロード関係の機能ができているだけで、UIの部分がろくにできてないのです。
htmlとかCSSとか業務レベルのものは書いたことないし、かなり開発に時間かかりそう。


サービスにするとなると、やっぱりそういうところも作りこまねばならない。
しかもスマホですからね。スマホブラウザに表示を最適化しないと。
できれば、PCブラウザスマホブラウザの両方で操作できるようにしたいし。
スマホブラウザ向けのwebページフレームワークみたいなものが必要かなーと。
何か有名なのあったっけ。
良いものがあれば皆さん紹介お願いします。

2012-03-31

AIR3.2でStage3DをiPhoneで動かす

今年はフットサルボードのサーバ側(GAE/J)ばかりやってます。

さてAIRのバージョン3.2が発表されています。
自分にとって重要な変更は、stage3DがスマートフォンGPUに対応したこと。

先ほど、以前FlashPlayer11向けに作成したStage3D+Away3DのサンプルをiPhone3GSで動作させるのに成功しました。(ちょっとおかしい動きはしてますが)
http://futsaltacticsboard.appspot.com/stage3dSample/GettingStartedWithAway3D.html

単純に言ってしまうと、AIR3.2SDKをダウンロードしてきて、Flex4.6SDKに上書きコピーして、それを使ってビルドすればOKです。
ですが、僕はMacでそれをやってはまったので、備忘録のためにやり方を残しておきます。

1、AIR3.2SDKをダウンロード
http://www.adobe.com/devnet/air/air-sdk-download.html
tbz2ファイルがダウンロードされる。

2、FlashBuilder4.6がインストールされてるフォルダにsdksフォルダがある。
その中に4.6.0フォルダがあると思うので、コピペでもう1個作っておく。適当に名前を4.6.0withAIR3.2とでもしておく。

3、tbz2ファイルを4.6.0withAIR3.2に入れて、tar jxvf で展開。
ここが重要。
普通にtbz2ファイルを展開して、それをFinderでフォルダに上書きコピーするのはダメ。
FinderWindowsエクスプローラとは異なり、上書きコピーすると、同名のフォルダがあった場合にフォルダの中の元ファイルを消してしまいます。
元からあったファイルが消えるので、FlexSDKのファイルが消えてしまいます。
tar以外にもcpとか使う方法あると思うけど、とにかくFinderはダメ。

4、プロジェクトActionScriptコンパイラーの設定でFlexSDKを切り替えます。また、コンパイルオプションとして-swf-version=15を加えるように。理由は知りません。

5、後は、app.xmlの設定が不十分な場合はコンパイル中にコンパイラが教えてくれるので、適宜設定してください。

これで終わり。後はいつもどおり。

2012-02-23

stage3Dのスマホ対応予定は2012年6月ごろ?

上條さんのブログAdobeのロードマップ発表が紹介されてました。
http://cuaoar.jp/2012/02/flash-player-2012.html

という訳で他者のブログ内容を転用するだけというチェーンメール的な記事なのですが、
stage3DスマホGPU対応がFlashPlayer11.2で出る予定(正確には、スマホではFPは動かないのでAIR3.2)と聞いて大興奮。

これで、当初予定していたフットサルボードの3D再生が搭載できる!
前の記事で技術調査した結果を生かし、Away3Dで作るつもりです。
素材はUnityのMarketから適当なのを拾ってきてフォーマットをAway3D向けに変更しようと思います。

また、上記対応により、AIRアプリによって作ったゲームアプリが十分許せる速度のスピードで動くことが期待できると思います。

フットサルボードの次はゲームアプリを何か作ってみることを考えているので今から楽しみです。

Flash\(^o^)/ハジマタ