2013年12月21日

SONY XPERIA SO-02F 入手しました

SONY XPERIA SO-02F(pink) を購入してしまいました。

本体そのものについては、以前の機種(F-05D)に比べ若干物理的に重い(124g→140g)以外の不満はありませんが、やはりドコモショップで機種交換手続きをする前に、SDカードとフィルムを量販店などで安く購入してから行くべきでした。今回は時間の無い中で行かざるを得なかったので、SDカードもフィルムもドコモショップで購入してしまいましたが、非常に反省しています。また、充電器卓上ホルダも「F-05D用のものがそのまま使える」とのことだったのですが、やはり(?)型式が違うようで、本日あらためて購入してくる予定です。

posted by cbbandtqb at 06:58| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2013年12月17日

Apportable - The Configuration File

Objective-C で書かれたコードをそのまま Android に移植できるという SDK のドキュメントを直訳してみました。 オリジナルは、こちらになります。

The Configuration File

Quick Overview

configuration.json は、あなたがあなたのプロジェクト上で apportable を初めて実行するときに作られる生成ファイルです。デフォルトでそれは、ターゲットとなる Xcode プロジェクトのような同じディレクトリの中の .approj ディレクトリの中に配置されるでしょう。あなたがあなたのプロジェクトを apportable でビルドする最初の時、 CLI はいくつかの質問をしますが、それらは configuration.json にいくつかの基本的な機能を付け加えます。ファイルはそれ自身、それをどう使えばよいかについての膨大なドキュメントを含まれています。

Manifest Options

configuration.json ファイルの中の "Features" という見出しの下に含まれる多くのオプションは、 Android ドキュメントの中のオプションに直接相当します。これらのオプションは、 Google Play がアプリをダウンロードすることをどのデバイスに許すかを制御する "Features" と、アプリケーションがどの API にアクセスするかを制御する "Permissions" に分けられます。

我々はこれらのオプションをリファレンスのために "Features" と "Permissions" に分けていますが、それらの全てが configuration.json ファイルの中の "Features" 以下にあるそれらを追加することで、プロジェクトにの中に含められます。

Features

touchscreen - Android documentation

Google Play に、装備されているハードウェアタッチスクリーンをあなたのアプリが要求することを通知します。 Google Play は、デバイスにこのことなしにあなたのアプリをダウンロードさせません。

multitouch - Android documentation

Google Play に、装備されているハードウェアマルチタッチタッチスクリーンをあなたのアプリが要求することを通知します。 Google Play は、デバイスにこのことなしにあなたのアプリをダウンロードさせません。

multitouch_distinct - Android documentation

Google Play に、装備されていて、多方向に動かすタッチを認識する能力を持ち、ただしジェスチャは認識しないハードウェアマルチタッチタッチスクリーンをあなたのアプリが要求することを通知します。 Google Play は、デバイスにこのことなしにあなたのアプリをダウンロードさせません。

multitouch_jazzhand - Android documentation

Google Play に、装備されていて、10本あるいはそれ以上の同時に発生するタッチイベントをハンドルできるハードウェアマルチタッチタッチスクリーンをあなたのアプリが要求することを通知します。 Google Play は、デバイスにこのことなしにあなたのアプリをダウンロードさせません。

accelerometer - Android documentation

アプリケーションに加速度計にアクセスさせます。

live_wallpaper - Android documentation

アプリケーションがライブウォールペーパーを有することを知らせます。

Permissions:

notifications - Android documentation

アプリケーションに、端末がリブートされるときに表示される通知をキューイングさせます。

write_external_storage - Android documentation

アプリケーションに、SDカードに書き込ませます。

vibrate - Android documentation

アプリケーションに、バイブレーションオプションにアクセスさせます。

access_network_state - Android documentation

アプリケーションに、ネットワーク状態にアクセスさせます。

write_settings - Android documentation

アプリケーションに、 Android 設定に書き込ませます。

wake_lock - Android documentation

アプリケーションが走っている間(バックグラウンドであっても)、デバイスはスクリーンを暗くしない、あるいはスリープモードに入りません。

access_wifi_state - Android documentation

アプリケーションに、wifi の状態にアクセスさせます。これは access_network_state によって包含されます。

read_phone_state - Android documentation

アプリケーションに、電話と SMS の着信と、電話と SMS の発信を読み取らせます。

bluetooth - Android documentation

アプリケーションに、 bluetooth 機能にアクセスさせます。

bluetooth_admin - Android documentation

アプリケーションに、 bluetooth 管理者機能にアクセスさせます。

no_internet - Android documentation

アプリケーションに、インターネット機能から遮蔽させます。

NFC - Android documentation

アプリケーションに、 NFC にアクセスさせます。

Apportable Features

以下のオプションは、 Apportable プラットフォームがあなたのプロジェクトをコンパイルするのを支援します。 "portrait" と "opengles2" は、 CLI サーベイの後で自動的に生成されますが、後で configuration.json ファイルの中で変更できます。これらは、 configuration.json の "add_params" セクションの中で "FEATURES" 下の文字列として含まれる必要があります。

check_license

アプリケーションは Google IAB から全てのレシートを検証します。

billing

アプリケーションに、 Google Play ビリング API にアクセスさせます。

c2dm_receive

アプリケーションに、プッシュ通知を受け取らせます。

urbanairship

もしアプリケーションが Urban Airship を使っていたら必須の機能です。

prefer_external_storage

もし利用可能であれば SD カード上にデフォルトインストールするための 外部ストレージロケーションを変更します。

expansion_files

apportable プラットフォームの内部機能です。ユーザが拡張ファイルビルドを要求した時に自動的に使われます。

hd, hd-large-hdpi, hd-large, normal-large-screens-only, normal-screens-only

これらの機能は、特定の画面の解像度やサイズを強化します。 Google Play は、指定された画面サイズかつ/あるいは解像度なく、デバイスにあなたのアプリをダウンロードさせません。

portrait

アプリケーションローダにアプリケーションが縦方向で表現するかもしれないことをヒントとして与えます。

opengles2

Apportable プラットフォームに、アプリケーションが openGL ES 2 を使うことを通知します。

xperia

アプリケーションを xperia デバイスに表示するときにアプリケーションランチャーに異なるアイコンを提供します。

no_depth_buffer

深さバッファを使えなくします。

no_stencil_buffer

ステンシルバッファを使えなくします。

true_color

RGBa8888 を有する GL サーフェイスを選ぼうと試みます。

deeplink

アプリケーションに、 G+ ディープリンクを実行させます。

install_referrer

アプリケーションに、どのベンディングインストールリファラがアプリケーションをしたのか調べさせます。

3rd Party Frameworks

もしあなたが Indie Apportable SDK もしくはそれ以上を使っているのであれば、あなたはより多くのサードパーティフレームワークへのアクセスを有することになります。これらは、 configuration.json の "add_params" セクションの中の "deps" 以下の文字列として含まれる必要があります。

Chartboost

Chartboost インテグレーションを許可します。

FlurryAPI

Flurry インテグレーションを許可します。

AdColony

AdColony インテグレーションを許可します。

The Facebook SDK

Facebook iOS SDK は以下の git リポジトリとして利用可能です。

https://github.com/facebook/facebook-ios-sdk

どのバージョンも repo の中にタグを有しています。例えば、バージョン 3.5.3 は、 git repo 内部から以下を実行することでチェックアウト可能です。

git checkout sdk-version-3.5.3

Apportable SDK はFacebook の iOS SDK をバージョン 3.5.3 までならコンパイルできます。3.6.0 以降からのより新しい Facebook SDK のバージョンは、 Xcode にインテグレートされていないビルドスクリプトを使いますが、 Apportable SDK は当該スクリプトの振る舞いをまだ複製できていません。

Facebook SDK で書かれた Objective C コードは、個々のヘッダをインポートするよりむしろ、以下のように書くことによって SDK をしばしばインポートします。

#import <FacebookSDK/FacebookSDK.h>

Facebook SDK ビルドスクリプトは、そのヘッダのレイアウトを再配置し、そのため、 Apportable SDK にそれらヘッダを見つけることを許可するためにもうひとつ追加ステップが必要とされます。

あなたのプロジェクトの .xcodeproj の隣に、 FacebookSDK と名付られたディレクトリを作って下さい。ディレクトリの内部で、 src/FacebookSDK.h に配置されている FacebookSDK.h ヘッダへのシンボリックリンクを作って下さい。

src/FacebookSDK.h

もしあなたのプロジェクトが以下のようにレイアウトされているとします:

MyProject

|-- MyProject.xcodeproj

|-- MyProject.approj

|-- facebook-ios-sdk

|-- |-- src

|-- |-- |-- FacebookSDK.h

|-- FacebookSDK

そうだとすれば、あなたは、 FacebookSDK ディレクトリに移り、以下を実行することによってシンボリックリンクを作成することができます。

ln -sv ../facebook-ios-sdk/src/FacebookSDK.h

最後に、 FacebookSDK ディレクトリをあなたのヘッダサーチパスに追加する必要があり、それはヘッダを含む他の場所に対してあなたの望むようにできます。


目次へ戻る

FruitsFields - 寄付代わりに購入いただけると嬉しいです。
Icon-72.png as_available_appstore_icon_20091006.png

サポートページはこちら。
http://cbbandtqb.toypark.in/FruitsFields/index_jpn.html

posted by cbbandtqb at 23:41| Comment(0) | TrackBack(0) | 備忘録 | このブログの読者になる | 更新情報をチェックする

2013年12月12日

cocos2d-iphone v3 プレビュー

cocos2d や KoboldTouch で有名な Steffen Itterheim 氏による cocos2d-iphone v3 プレビュー記事を直訳してみました。 オリジナルはこちらです。 なお掲載にあたっては、Steffen Itterheim 氏の許諾をいただいております。

cocos2d-iphone v3 のプレビュー版の早出しプレビュー

On November 18, 2013, in cocos2d, by Steffen Itterheim

cocos2d-iphone v3 のプレビュー版がここ数日でリリースされました。私が思ったのは、私はより近くで見るであろうということと、何がなされたのか、何がなされているところで何がなされていないか、何が新しくて何が古いものの改良されているかを要約するということでした。

Installation

インストーラスクリプトは改良されました。別の名前 (install.sh)になり、別のパラメータ (-fの代わりに–force)を持つようになりました。

私が気づいたうちで最初のこととしては、インストーラが Chipmunk2D をダウンロードするようになりました。なぜなのか不思議に思わされたので、私は確認するために2回☒チェックしました: Chipmunk はアーカイブに含まれていません。これはオフラインでのインストールができないことを意味します。

後で、なぜ Chipmunk が含まれないのか説明するつもりです。

Project & File Templates

プレビューには、一つだけプロジェクトテンプレートがあります。それは物理的な機能は何もデモしませんが、ボタンのついた典型的な “Hello World” のサンプルになります。

テンプレートには問題があるようで、それをカスタムロケーションに保存しようとすると、 Xcode をクラッシュさせてしまうようです。実際毎回 “Save File” シートが出てきて、 “Create” をすぐに押さずにいましたが、 Xcode はクラッシュしようとしました。ひとつにはこのようなことによりまだまだプレビューなのです。

CCNode File Template は現時点で言及する価値はなく、それは空の Objective-C クラスを生成し、現時点では通常の Objective-C クラステンプレートとほとんど変わりがありません。

Hello World v3

Hello World テンプレートをよく見ると、最終的にいくつか洗練されてきたことがわかります。

不愉快さが消え去るかもしれないのは、インポートとインプリメンテーションを含めて、ほとんど全ての行で以前のテンプレートのコメントを恩着せがましくしていないような場合です。 onEnter と onExit メソッドは super で呼び出すためにコメントと共に既に存在していますが、それはとてつもなく多くの cocos2d デベロッパによって作り込まれてしまった非自明な因果関係による共通した誤りでした。

初心者に対してウェルフォームドなコードを最終的に誇示するという私の cocos2d の対する情熱は、 self が nil かチェックされない init スタイルによって曇らされただけです。それはフィックスされるべきです。

もしあなたがビルドし実行するなら、あなたはいくつかのデベロッパ用のノートとワーニングを見ることになり、アプリは開発にあたってプレビューを使うためというわけでもないワーニング立て続けに表示します。アドバイスをよく聞いて下さい。全般的に v3 は、プロダクションユースの準備が整ったとはとても言えません。私からのアドバイスは、元に戻り、来春のバージョンを見てみることです - もしあなたがアーリーアダプタでデバッグの方法を知っているなら、バグにまみれて苦労して作業してレポートして下さい。

例えば、 iOS 6 シミュレータを使ってテンプレートを実行すると、パフォーマンスは最悪です。全て iOS 7 上ではとてもスムースですが、 iOS 6 ではそうではありません。これは明らかにさらなるテストが必要です。

Display Some Sprites

テンプレートのプロジェクトは、ラベルとボタンを表示するだけです。私がやろうと思ったのは、共通的に使われているコードがどう変わったかを調べるために、2つのオブジェクトにいくつかのスプライトを追加するというものでした。あなたは違いが分かりますか?

CCTexture* texture = [CCTexture textureWithFile:@"Icon.png"];
CCSpriteBatchNode* batchNode = [CCSpriteBatchNode batchNodeWithTexture:texture];
[self addChild:batchNode];

for (NSUInteger i = 0; i < 800; i++)
{
CCSprite* sprite = [CCSprite spriteWithTexture:texture];
[batchNode addChild:sprite];

sprite.position = CGPointMake(CCRANDOM_0_1()*360+60, CCRANDOM_0_1()*200+60);
sprite.rotation = CCRANDOM_0_1() * 360.0;
sprite.color = ccc3(CCRANDOM_0_1()*255, CCRANDOM_0_1()*255, CCRANDOM_0_1()*255);
sprite.opacity = CCRANDOM_0_1() * 255.0;

id rotate = [CCActionRotateBy actionWithDuration:CCRANDOM_0_1()*10 angle:360];
id forever = [CCActionRepeatForever actionWithAction:rotate];
[sprite runAction:forever];
}

2つの変更点に注目です: CCTexture2D は今 CCTexture で、アクションクラスは、常に “CCAction” プレフィックスを使うことによって今は区別することができます。他の全ては期待通りに動作します。

CCTextureCache を使う代わりに - cocos2d.h ヘッダファイルによってもはやインポートされることはありませんが - CCTexture の textureWithFile: initializer が今は使われます。

好むと好まざるとに関わらず、 API は多く変更されました。また少なくとも未定です。これは cocos2d ユーザにとっては良いニュースですが、 Sprite Kit から cocos2d-iphone v3 へ"アップグレード"しようとしているデベロッパには悪いニュースであり、なぜなら相違点は API レベルでの類似性にまだまだ比重を高めに置いているからです。

基本的な API は、モノマネ Sprite Kit に合うようにサポートされています。もしそれがそうするつもりがなかったとしても、これはアドオンとして容易に実行可能であり、単純に API コールを cocos2d-iphone 相当にマッピングすることで可能になります。これらの変更のほとんどは “Sprite Kit コンパチビリティ”カテゴリで間に合わせることができるので、私が確信しているのは、そのまま使うことができるようには定めていない v3 を誰かが喜んで人々にそのようなアドオンとして提供するということです(訳注:?)。

Cocos2D UI Controls

今のところ cocos2d-ui と名付けられた歓迎すべきエクストラプロジェクトがあり、これはいくかのユーザインタフェースコントロールを含んでいます。驚くようなことはなく、もしあなたが cocos2d-iphone プロジェクト使っているなら、あなたを驚かすようなことはないでしょう。

ここに現時点でエクステンションが存在する UI クラスのリストがあります:

  • CCButton
  • CCSlider
  • CCTextField
  • CCScrollView
  • CCTableView

これらの多くは、 cocos2d-iphone-extensions から以前に存在していたクラスの移植または合わせ込みのように思われます。

All ARC Now

言及するに値することがあります: cocos2d-iphone のコードベースが ARC を使うように移植されました。もう retain 、 release 、 autorelease も必要ありません。

私がこの件をもっともエキサイティングだと思うのは、 cocos2d デベロッパが現在の MRC テンプレートに基づいたプロジェクトを開始し、決して ARC に再考を与えないというだけの理由で、 stackoverflow.com 上で何百万回と MRC 関連の問題に私が答えるのにうんざりしているからです。あるいは最初の件は、おそらく非常に多くの人が気にしていないし、 ARC について知りません。まさしく使っているべき人であり、私は心配しています。

Cocos2D Internals

コードはより構造化され、いくつかのクラスはより良い名前に再定義されるか、これまで通りのままかです。例えば CCTouchDispatcher は今のところ2つのクラスの集合であり、 CCResponder と CCResponderManager からなっています。

今のところ CCLayout と CCLayoutBox クラスは、子ノードをグリッド上にレイアウトするためにあります。それを言うなら CCLayoutGrid と名付られるべきですが、ともかく、 私もまた、Box2D は誤って命名された何らかのものであり、なぜならボックスは 3D プリミティブであり、その 2D 表現が矩形であるからといったことを主張している人間です。命名するなら、Rect2D でしょう、命名するなら

CCLayout(Box) と CCButton によって、あなたはアイテムを伴った CCMenu を作成することができますが、そのことによって、 CCMenu それ自身と関連するクラスはもはや存在しません。ようやく、というところです。

TMX のサポートは現在のところ実用になりません。TMX をダウンロードすると認識されないセレクタを伴って非常に早い段階で(TMX ファイルそれ自身には関係なく)クラッシュするだけではありません。私は描画コードへのいかなるコードを見つけることさえできませんでした。それはもぬけの殻です。このことが良いニュースであるというのは、それはあちこちでオーバーホールが冗談抜きで必要とされているからです(訳注:?)。

もし TMX のサポートが復活しないのであれば、あるいは時間がかかるようであれば、 OpenGW によって提供されるタイルマップレンダラがいつでもあります - OpenGW が cocos2d-iphone v3 はサポートする時点、すなわちデベロッパが実際に v3 を使い始める時点で我々はサポートするつもりですが、それはおそらく2014年より前にはなりません - あなたが尋ねてくる場合に備えて。

コーディングスタイル:これは常に主観の問題ではありますが - 私はあまりその点に関わりたくありません。私が注記しておきたいのは2点だけです: -(BOOL)isPhysicsNode {return NO;} といったフォームの読み辛い一行コードが多く存在します。こういったものは私をビビらせます。

また、 Objective-C のメッセージングオーバヘッドを回避するためにスタティックインライン C 関数を Objective-C メソッドから呼び出すのを頻繁に目にするでしょう。多くの場合、これは早計な最適化のように思われます。

非常に歓迎すべき変更は、ハッシュテーブルのような C ライブラリの除去です。代わりに Core Foundation が使われています。

私は提案されている新しいレンダラを見つけようとしましたが、何も見つけることができませんでした。おそらく、多くの進捗がレンダラ上で既になされているはずですが、私の見たところで問題がなかったものは、ひとつも見つけられませんでした。レンダリングのコードはまだ v2.1 のようにほぼ見えます。私のスプライトテストでも確認したのは、まだ適切な位置に自動的にバッチすることがなく、あなたはまだ CCSpriteBatchNode を手動で作成及び使用しなければならないということです。私の推測では新しいレンダリングコードは、まだラップされたままで、現在のプレビューバージョンには含まれていません。

Audio Engine: ObjectAL

私は長く ObjectAL をプロモートしてきており、そのため私は、 ObjectAL が CocosDenshion を cocos2d-iphone ディストリビューションにおいて置き換えたことを見て、本当に嬉しく思います。

CocosDenshion と比べると ObjectAL はより使いやすくなっており、それはあまりにも"シンプルなオーディオ"インタフェースを有していますが、より複雑な要素がより当然となるでしょう。それは CocosDenshion に比べて多くの機能を持ち、問題は少ないです(私の経験では)。そのアクションサポートは、オーディオエフェクトを徐々に容易にしていきます。

過去において ObjectAL のもっと大きな難点は、 OS X をサポートしていなかったということです。しかし OS X は今から数ヶ月でサポートされてきました。内部的に ObjectAL は OpenAL と AVAudioPlayer を使っており、目の前の課題に依存しており、そのためその内部は CocosDenshion に実に似ています。

Physics Engines

現在のところ、 Box2D がディストリビューションに含まれていますが、現時点では Box2D に対するテンプレートプロジェクトはありません。 Hello World テンプレートは Chipmunk2D ファイルを含んでいますが、それらを使っていません。

Objective-Chipmunk を含んでいることは歓迎すべきですが、現在のプレビューでは、ヘッダファイルの集合とプリコンパイルされたスタティックライブラリとしてクローズドなソースのままです。従ってそういうわけで、 Chipmunk はインストールスクリプトによって、ダウンロードされコンパイルされるのです。しかしながら Objective-Chipmunk は、将来のリリースでオープンソースとして全体がリリースされるでしょう。

CCPhysicsNode と CCPhysicsBody が Objective-Chipmunk を内部的に使っています。全ての CCPhysics* クラスは、素の C の Chipmunk2D でもくなく Box2D でもなくサポートを伴って修正されるような兆候は見えてきません。

事実、 Box2D は、 cocos2d-iphoneへの関連がないダウンロードにおいて “as is” を基本としたソースコードとしてほぼ提供されています。ざっくり言うと、私が思うには、 Box2D がもしこのままであるなら、すべて一緒にディストリビューションから削除されるべきでしょう。なぜ Box2D を使いたいかが分かっているデベロッパは、彼ら自身によって Box2D を追加するのに十分な能力があって然るべきでしょう。

いずれにせよ、 CCNode は今のところ Sprite Kit に相当するものがある physicsBody プロパティを有しており、実装は以前の CCPhysicsSprite “hack” よりさらに複雑で柔軟です。

CCBReader included

新しい CocosBuilder は今実際には SpriteBuilder と呼ばれてますが、おそらく混乱を避けるために、 CB は cocos2d-iphone v3 はサポートせずに cocos2d-x だけをサポートし、一方で SpriteBuilder は cocos2d-iphone v3 をサポートし、おそらく cocos2d-x はサポートしません。

CCBReader と名付けられた必要とされるローダ用コードは、今のところ cocos2d-iphone v3 に含まれています。それが常識でしょう。

私の意見において何が常識でないかと言えば、 CCBReader.m のコードそのものです。もし、あなたが CocosBuilder もしくは SpriteBuilder を使おうと考えているデベロッパなら、私は敢えてあなたにそのファイルを見るように薦めたいと思います。もし、あなたが CB/SB で CCBReader.m を編集してもコードの中で何かがうまく動作しないという問題をデバッグする必要があるとしたら、私は次の言葉を引用します:"これを理解することに幸運あれ"。

私はここでがなりたて始めてしまいましたが、止めることができませんので、そのまま続けます:XML はいいでしょう!でももし SB が本当に cocos2d-iphone v3 のためだけに作られているなら、 NSCoding でしょう。あるいは、あなたも知っているように、 zlib のようなオープンソースライブラリとして利用できる他の既にあるファイルアーカイブソリューションがあるでしょうに。うー、落ち着け Steffen ...

I, for one, welcome our new Cocos2D Overlords!

私はもちろん Copyright (c) 2013 Apportable Inc. を参照しています。

あなたはこれを主に CCBReader と関連ファイルで見つけるでしょう。結局は、そしておそらくはあなたは次のことが分からなかったのです: CocosBuilder と今の Sprite Builder は Zynga でしばらく使われた後、 Apportable で動作しています。

これに関して他の事項を知らない場合に備えて念のため記します: Apportable は cocos2d-iphone v3 の開発をスポンサーしています。そのため cocos2d-iphone v3 は財務的な後ろ盾を有しますが、より重要なのは、オープンソース Objective-C レンダリングエンジンのサポートにおいて配当される利子を受け取る会社です。

それでどこに Zynga の関与は残されているのでしょうか?それは100%以上 cocos2d-x においてです。全ての Zynga デベロッパは、 cocos2d-x で開発していて、 cocos2d-iphone への全ての関与は停止しており、少なくとも私の言える範囲ではそのような状況です。このことが、なぜ SpriteBuilder が CocosBuilder から分離したかを説明しているでしょう。

少なくとも、 SpriteBuilder が Sprite Kit を将来サポートするかもしれないという望みはあるでしょう。ただ確実に膨大なリエンジニアリングが必要になるはずで、なぜなら SB は cocos2d-iphone にかなり強く結び付けられているからです。

Come back next spring!

もしあなたが私にいつ cocos2d-iphone v3 を使うことを考えるべきか質問するなら、私のアドバイスがあります。開発が現在のペースで続くと考えれば、あなたの要求とアーリーアダプタになりたいというあなたの意思次第でしょう。もしベータテストできるものが欲しいなら、夏かそれ以降になるでしょう。

ほとんどの部分に対して cocos2d-iphone と似たままのようでいて、その API とコードの両方共がですが、全てについて再検証が必要な全体に渡るコードベースの実質的な変更があります:iOS のバージョンや様々なデバイス、デバイスの解像度やファイルサフィックス、 ARC コンバージョンのためにあり得るバグ、全てのツールとデータフォーマットはこのまま正しくサポートされるかどうか、などなどです。提案されている新しいレンダラに言及はありません。

私が願うのは、 cocos2d-iphone v3 に対して、Xmas前に全ての提案されている機能が用意されることを願わないようにすることです。私が何事につけ"3年"と言ったとき、それは冗談ではありません(単一のデベロッパに対して、現在は取り組んでいる多くの人々がいます)。現時点では、機能リストから実装された機能は - 私の言える限り - ARC 、統合化物理エンジン、いくつかの UI コンポーネント、わずかな Sprite Kit API 適応です。一方で、プレビューは見たところ進行中の作業の全てを含んでいるわけではないので、 v3 の実際の状態は評価され得ません。

基本的に v3 のプレビューが示しているものは、事実上 v2.2 のアップデートのようなものです。本当の v3 のアップデートはいつかリリースされます。

事実、 cocos2d-iphone v3 は、"バックワードコンパチビリティ"の目的のため生き続ける古い機能に分割されるでしょうし、しかし一方で新しい機能が物事を処理する古い方法に対する代替物として追加されるでしょう。私は本当にこのことが嫌いで、なぜならそれは新しいユーザとアップグレードしてきた人達(そして彼らを助ける人達)をより混乱させるためです。個人的には、私はまっさらな状況とフレッシュなスタートを望みます。

あなたには完璧に正直であるために言います:私は混乱しています。私は来年もう一度 v3 を見直してみようと思います。

PS: 気に留めておいて欲しいのは、これは開発ビルドのすぐに速く変化する主題のスナップショットであり、何事につけ粗塩で揉んでます。この記事を書いてから多くの本当に多くの時間が過ぎました。


FruitsFields - 寄付代わりに購入いただけると嬉しいです。
Icon-72.png as_available_appstore_icon_20091006.png

サポートページはこちら。
http://cbbandtqb.toypark.in/FruitsFields/index_jpn.html

posted by cbbandtqb at 00:24| Comment(0) | TrackBack(0) | 備忘録 | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。