Objective-Cとcocos2D自体が好きでした。 粘土のように柔らかい。 C ++で何年も書いた後、少し簡単になりました。 悲しいかな、iOSのみ。 もちろん、あらゆる種類のApportableが登場しましたが、何らかの理由でそのように見たくありませんでした。 さらに、すべての電子レンジでプレイされたという事実にもかかわらず、同じプラットフォームで疲れを感じ、プロジェクトを望んでいました。 Unityは良いように見えますが、それは閉じられていますが、それが内部からどのように機能するかを知ることは非常に重要です。 さらに、私は今すぐ何かを始めたかったです。 そして、私はiPhoneのココナッツモデルに非常に精通していたので、 cocos2D-Xを見てみることにしました 。 C ++の1つ。
同じこと。 C ++でのみ。 同じリリース/保持（最新の3.xバージョンでは、いくつかのポイントが既に変更されています）、ノードからの同じモデル。 テストベンチを運転しました（常に、エンジンの例を常に参照してください）-すべてがスマートに動作します。 しかし、私は1つのことを思い出しました-その多くの画面解像度を持つAndroidについて。
iPhone用のゲームを作成したとき、すべてが簡単でした。 Retinaサポートが必要な場合は、フラグを1つだけ設定するだけで十分です。
[director enableRetinaDisplay: YES]
HDグラフィックセットを追加します。 iPadの場合、すべてが少し異なりました。座標の再計算が必要でした。 5台目のiPhoneの登場により、事態はもう少し複雑になりましたが、少しは複雑になりました。 ただし、Androidを使用していて、画面の数に制限がない場合は、脳を少しオンにする必要があります。 これが私たちがやったことです。
構成を追加しました。 プロジェクトのすべての魔法は、Coconutスクリプトによって生成されたAppDelegateクラスで発生し始めます。 その方法の1つでは、シーンが起動され、アクティブ化されます。
bool AppDelegate::applicationDidFinishLaunching() { Director *director = Director::getInstance(); EGLView *eglView = EGLView::getInstance(); director->setOpenGLView(eglView); ... Scene *scene = GameScene::scene(); director->runWithScene(scene); return true; }
シーンでは、スプライト/他のノードをロードし、何らかの方法でそれらを配置し、必要に応じてねじります。 たとえば、スプライトを作成するメカニズムは、 FileUtilsクラスと密接に関連しています 。 次のようなことをするときはいつでも：
Sprite *object = Sprite::create("object.png")
Spriteクラスの内部メソッド（コードを手元に置いておくと便利です ）は、 FileUtilsにインストール済みの検索パスのリストを実行して、そのようなファイルがあるかどうかを確認します。 検索パス？ はい、それは簡単です。 次のようなスプライトを作成できます。
Sprite *enemy = Sprite::create("enemies/enemy0.png")
しかし、ファイルを検索するためのディレクトリまたはリストがあることをココナッツに伝えることができます。 これにより、それぞれ落書きが減り、エラーの数が減り、柔軟性が得られます。 別の方法でファイルをグループ化したかったのです。コードでは、すべての「敵/」を「オブジェクト/」などに変更する必要はありません。 本当に便利で簡単：
FileUtils::getInstance()->addSearchPath("fonts"); FileUtils::getInstance()->addSearchPath("objects"); FileUtils::getInstance()->addSearchPath("backgrounds"); ... Sprite *back = Sprite::create("back0.png"); LabelBMFont *label = LabelBMFont::create("an incredible label", "font0.fnt");
私はあらゆる種類の画面解像度について話しているようです。 Cocos2D-Xにはもう何もありません
[director enableRetinaDisplay: YES]
代わりに、いくつかの新しいものが登場しました。 物理的な画面サイズを知りたいですか？ これを行う：
Size frameSize = Director::getInstance()->getOpenGLView()->getFrameSize();
また、構成についても言いました。 これは単純なjsonファイル（rapidson parsim ）で、リソースパスセットを記述しています（ああ、この対格の場合）。 各セットは次のようになります。
{ "width": 960, "height": 640, "designWidth": 480, "designHeight": 320, "paths": [ "Res/960x640/fonts/", "Res/960x640/ui/", "Res/960x640/maps/" ... ] }
ここで、 幅と高さは、このリソースのセットが適している物理的寸法を表します。 すでに私が得ているものをキャッチしますか？ AppDelegate :: applicationDidFinishLaunchingでアプリケーションを起動するとき、設定を読み込み、すべてのパスセットを実行し、 Director :: getInstance（）-> getOpenGLView（）-> getFrameSize（）から取得した物理サイズをそれらの幅と高さと比較し、必要なサイズをロードします写真。 ただし、これでは十分ではありません。
より深く理解するために、ここに行きます：
www.cocos2d-x.org/wiki/Multi_resolution_support
実際に使用するには、次のことを知るだけで十分です。 Director :: getInstance（）-> getOpenGLView（）-> setDesignResolutionSize（）があります。これは相対サイズを設定します。 たとえば、iPhoneのサイズは960x640であり、画面の中心は座標{480、320}で表すことができます。 ただし、{ 96、64 }をsetDesignResolutionSizeに渡すと、{ 48、32 }を使用して中心を設定できます。 相対座標は非常に重要であり、 構成からの2つのパラメーターdesignWidthとdesignHeightがそれらを設定します。 したがって、構成を実行し、サイズを確認し、必要なリソースをロードして、正しい相対座標を設定します。 もうすぐゴールに近づきます。
巨大な画面解像度を備えたデバイスでゲームを実行しているが、 ピクセルの性能を直接ピクセル化するリソースのセットがないと想像してください。 大丈夫-ココナッツに絵を伸ばすように言うだけです。 このために、 Director :: getInstance（）-> setContentScaleFactor（）があります。 （ポートレートゲームの場合） 幅をconfigからdesignWidthに分割するだけで 、すべてのプラットフォームで満足できます。
もう1つのパラメーターがあり、最後のパラメーターはResolutionPolicyです。 正直に言うと、 ResolutionPolicy :: FIXED_WIDTHとResolutionPolicy :: FIXED_HEIGHTという 2つの有用なものがあります。 縦向きで再生する場合-ResolutionPolicy :: FIXED_WIDTHを設定します。 同時に、例えばMe Meのゲームのように、画像の幅が引き伸ばされます。
このアプローチでは、追加の垂直方向のスペースが表示される場合があります。 上記の例では、画面全体がタイル状になり、インターフェイス要素がその端に対して相対的に配置されるように、背景を引き伸ばしました。 ただし、これは常に機能するとは限りません。 したがって、横向きの別のreTalesゲーム（ ResolutionPolicy :: FIXED_HEIGHTを使用）では、画面の端に2つのスプライトを描画しました。
構成を実行し、パスのセットを読み取り、物理的寸法と比較し、必要なリソースをロードし、正しいポリシーを適用してストレッチします。 しかし、私はもう少し進んだ-私はローカライズに夢中になりました。 エンジンレベル。 FileUtils :: getInstance（）-> addSearchPath（）の特性は、インストールされたパスに沿って厳密に同じ順序でリソースが検索されることです。 私は「fonts /」でそれを見つけませんでした、それは「ui /」に行きます、私はそれを見つけませんでした-それは「maps /」に行きます、そしてそれは失敗の場合にルートで見えます。 素晴らしい。 Application :: getInstance（）-> getCurrentLanguage（）を使用して現在の言語を取得し、パスを追加するときに、まず特定の言語に固有のパスを追加し、次にこのパス自体を追加します。 一度見た方がいい。 このようなことが起こります：
FileUtils::getInstance()->addSearchPath("fonts/en"); FileUtils::getInstance()->addSearchPath("fonts"); FileUtils::getInstance()->addSearchPath("objects/en"); FileUtils::getInstance()->addSearchPath("objects"); FileUtils::getInstance()->addSearchPath("backgrounds/en"); FileUtils::getInstance()->addSearchPath("backgrounds");
その結果、スプライトを作成しようとすると、ココナッツは最初にローカライズされたフォルダーを探し、次に共有フォルダーを探します。 デフォルトの言語に応じてフォントをロードしますか？ フォルダーを作成するだけです。 プレイヤーの言語に合わせて特定のスプライト（兵士のパッチの旗）を読み込む必要がありますか？ フォルダーを作成し、必要なファイルをそこにドロップします。 テキスト自体は、設定と同じjsonファイル内にあります。 代わりに
Label::create("This is label", "font.fnt")
ただ使う
Label::create(Localized::getString("mainMenuCaptionLabel"), "font.fnt")
ローカライズされたクラスなど、以下のリンクからダウンロードできます。 私は気にしません:)
私と一緒にいてくれてありがとう、読者。 あなたの猫を養うことを忘れないでください-彼は本当にあなたを必要としています。
動作する構成の例-pastebin.com/5idCpjYh
行を含むサンプルファイル-pastebin.com/LfBxs6dA
Localized.h-pastebin.com/LwNaKrFK
Localized.cpp-pastebin.com/GHVmPvCc
パスのダウンロード-pastebin.com/CX8Xma25
AppDelegateでこの全体を実行する方法-pastebin.com/dMVtY2Rb