[Xcode] No architectures to compile for (ONLY_ACTIVE_ARCH=YES, active arch=arm64, VALID_ARCHS=armv7s armv7).のエラー

どうも、俺です。

Xcodeでビルドさせたときに、タイトルのようなエラーが出る人へ。

方法は2つ考えられます。

１）Build Settings内にある「Build Active Architecture Only」の値をNoにする。
２）転送先端末（またはシミュレータ）にマッチしたアーキテクチャを「Valid Architectures」に記述する。

これでエラーが出なくなるかもしれません。


１）の「Build Active Architecture Only」ですが、
これは"Yes"にすると現在選択された（転送先）端末に適した
アーキテクチャのみでビルドする、
という設定になるため、そのアーキテクチャが「Valid Architectures」にない場合は上記のエラーとなるようです。

以上でぇぇぇす。

[cocos2d-x] 謎の'string' file not foundエラー

どうも、俺＠眠いです。

ある日突然、cocos2d-xでビルドを実行したときに
Lexical or Preprocessor Issue
'string' file not found

というエラーに出くわしました。

環境はMac OSX 10.9.5  +  Xcode v6.0.1 + cocos2d-x v2.1.5です。


ファイルに何も変更を加えておらず、
Clean → Buildを行った際に発生したので何がなんだかです。

エラーが発生しているファイルは、
CCDataVisitor.h
で、

#include <string>

の箇所でエラーが出ました。

ググると同じようなエラーに遭遇した人がたくさんいるようですが、
僕の場合は、

ビルド時にCCDatavisitor.hの#include で'string' file not foundというエラーが突然出るようになってハマった

この方と同じ症状で、
Blockクラスを作成していました。

なぜだか理由は分かりませんが、
上記ブログと同じようにBlockクラスを削除して、別のクラス名にするとエラーがなくなりました。



以上でぇぇぇぇぇす。

Androidアプリ Lintエラーの対応

どうも、俺です。
しばらくなかったブログ更新を埋めるかのように連日投稿しています。

今日はAndroidアプリをeclipseでビルドするときに出るLinのエラー対応についてです。

■エラーその１
"xxxxx" is not translated "......"

→解決方法
　無視しましょう。

プロジェクト名＞Properties＞Android Lint Preferences
を選択、
MissingTranslationを選択してそのSeverityを"Warning"にしましょう。

これは、外部のライブラリ等を組み込んだ時に、

そのライブラリで設定されているローカライズ情報が、

開発中アプリまたはその他ライブラリに影響するために出るエラー、だそうです。。

要約すると、「言語リソースが足りねぇよ」というエラーです。

■エラーその２

"xxxx" is translated here but not found in default locale

→解決方法

google-play-servicesプロジェクト内にある

res＞values-en-rIN＞auth_strings.xmlをコピーして、

同じくgoogle-play-servicesプロジェクトの

res＞valuesフォルダにペースト。

google-play-servicesを導入してから出るようになったエラーなので、

おそらくそれが原因っぽい。。

以上でぇぇぇぇぇぇす。

Xcode6(v6.0.1)でアーキテクチャarmv7sがはずされてしまう。

どうも、俺です。
しばらくぶりのブログです。忙しかったです。


さて、iOS8もリリースされXcodeも新たに6系が出てきました。
が、これまで通りの設定のままXcode6でビルドすると、armv7sでビルドができません。

これは、TARGETS＞Build Settings＞Architectures＞Architecturesのデフォルトの設定にある
Standard Architectures (armv7, arm64)
が原因です。

これでは、いくらValid Architecturesにarmv7sを書いても
そのバイナリは生成されません。


対応するには、
先ほどのArchitecturesを選択し、
Other...
から「armv7s」を追加しましょう。

あとは、Valid Architecturesにarmv7sを記入しておけばOKです。


以上でぇぇぇぇぇぇす。

cocos2d-x CCSprite(テクスチャ)の軽量化

どうも、俺＠仕事中です。

今日はcocos2d-xで頻繁利用するCCSprite(またはテクスチャ)の軽量化についてめも。
軽量化というのは、ファイルサイズ的な意味ではなくパフォーマンス面での軽量化という意味です。
ファイルサイズ的な意味での軽量化については最後に記します。

CCSpriteで画像生成するとけっこうなメモリを消費します。
けっこうなメモリとはどのくらいかと言うと、一般的なpng画像(24bitフルカラー)の場合、
1pxあたり4byte(赤8bit + 緑8bit + 青8bit + アルファ8bit)になります。
例えば200x200(px)のpng画像の場合、
200 x 200 x 4byte = 160000byte = 156.25KB
必要です。

なのですが、iPhoneや(ほとんどの？)Android端末で画像を処理する場合、
(2014.5.22修正 iPhoneやAndroidで実際にどのようにメモリ確保されるか不明)
利用するハードウェアによって、
画像(テクスチャ)のメモリは、2の累乗のサイズで確保されます。
どういうことかと言うと、
上の200x200サイズ画像の場合、256x256サイズとしてメモリ確保されるため、
消費メモリは
256 x 256 x 4byte = 262144byte = 256KB
になります。
なんと、これだけで約100KB無駄なメモリ領域が発生してしまいます。

500x600サイズ画像の場合は、
512 x 1024 x 4byte = 2097152byte = 2048KB
になります。
約900KB無駄なメモリ領域が。

画像を大量に使用するゲームアプリなどだと、かなり無駄なメモリが消費されてしまうことになります。


そこでこの問題の解決方法(1)として、スプライトシートを使いましょう。

スプライトシートは複数の画像をまとめて一つの画像として扱うため、
上記で述べたような無駄なメモリ領域というのを極力縮めてくれます。

次に解決方法(2)ですが、pngを出力する際に
・透過を使わない → png24で出力
・画像が荒くても構わない → png8で出力
という方法もあります。
png24は、24bitフルカラーで透過利用不可になります。
png8はGIFと同じ256色になります。

または、cocos2d-x側で、

    // 透過使わない
    CCTexture2D::setDefaultAlphaPixelFormat(kCCTexture2DPixelFormat_RGB565);
    // 減色させる(赤4bit + 緑4bit + 青4bit + アルファ4bit)
    CCTexture2D::setDefaultAlphaPixelFormat(kCCTexture2DPixelFormat_RGBA4444);

を呼び出しておく、という方法もあります。

このpng8で出力、またはkCCTexture2DPixelFormat_RGBA4444の設定は非常に効果的なのですが、画質が目に見えて荒くなるのが分かるのが残念です。
特にグラデーションは目も当てられません。

そこで、TexturePacker(基本有償)というツールを使いましょう。

有償なだけにとても高機能で、
TexturePacker上で画質を上述したRGBA4444に減色出来ます。
またすごいのが、画質が落ちた画像ファイルをディザリングという機能でキレイに加工してくれます。

例えば下の画像はRGBA8888の綺麗なままのpng画像。
※見やすいように拡大表示しています。

これをRGBA4444に画質を落とすと、

のようにグラデーション部分に荒い線が浮き出てしまいます。

これにディザリングをかけると、

のようになります。

荒いポツポツが目立ちますが、

拡大表示していることが原因で、実物サイズにすると

ほらキレイ。

目を細めてみると ほぼ元画像との違いなんて分かりません。

ちなみに、RGBA4444画質の元サイズはこちら。

うーん、、、

画像が小さいからあまり違い分からないですが、

やっぱりグラデーションが汚いです。そう思って下さい。

というわけでTexturePackerを使えば、

スプライトシートを生成できるだけでなく、画質の調整もできちゃうのでオススメです。

冒頭に書いた「ファイルサイズ的」な軽量化についてですが、

MacだとImageOptimがオススメです。

いろんなアルゴリズムを駆使して画像ファイルを圧縮し、ファイルサイズを小さくしてくれます。

ものによっては60%以上ファイルサイズが軽量化することもあります。

配布するアプリサイズが小さくなるので良いですね。

メモリへのロードも早くなるのかな？

あとは、CCSpriteBatchNodeを利用して、描画も軽量化させると見違えるほどアプリが軽くなります。

以上でぇぇぇぇぇす。