0

私のゲームのパワーアップの1つは、メインスプライトのサイズを小さくすることです。そのため、メモリのために、各フレームでsprite.scaleをループする代わりに、元のスプライトよりも小さいパーセンテージサイズでスプライトを再保存し、それを置き換えたいと考えています。その後、「死」が発生するか、タイマーが切れると、元のスプライトが戻ります。

だから、私はそれを小さくするためにこのコードを使用しています:

[player setTexture:[[CCTextureCache sharedTextureCache] addImage:@"player-small.png"]];

そして、通常にリセットするためのこのコード:

[player setTexture:[[CCTextureCache sharedTextureCache] addImage:@"player-orig.png"]];

ただし、元の画像(初期化時とリセット時の両方)は正常に見えます。しかし、それを新しいスプライト(元の寸法の正確に75%の寸法)に変更すると、変更されますが、新しいスプライトの象限のみが表示されますが、元の寸法になります。

スプライトを再テクスチャリングする前にsprite.contentsizeを変更しようとしましたが、サイズを変更するだけで、画像が混乱する問題には影響しませんでした。

視覚的な例を次に示します。

オリジナル:

オリジナル


contentSizeを変更して再テクスチャ化された画像:

contentSizeを変更して再テクスチャ化された画像


contentSizeが正しくリセットされていない元の画像に再テクスチャ化された画像(おっと、これはまったく問題ではありません-サイズコードを読み取るのを忘れただけです):

contentSizeが正しくリセットされていない元の画像に再テキスト化された画像(おっと、これはまったく問題ではありません-サイズコードを読み取るのを忘れただけです):

PS-私はすべてのスプライトの「-hd.png」バージョンを持っているので、誰かが知りたい場合に備えてそれを追加したかっただけです(これまでの画像とテストは「nonretina」シミュレーターでのみ行われました)。

ありがとう!


編集:問題は網膜シミュレーターでのテスト中にも発生します。

4

1 に答える 1

2

あなたの主な関心事はメモリに関するものなので、単にテクスチャアトラスを使用することをお勧めします。

元の画像を画像編集プログラムにコピーして、その寸法を確認しました。画像のサイズは73x71ピクセルです。つまり、テクスチャには2次元の累乗があるため、128x128のサイズのテクスチャとしてメモリに保存されます。これにより、テクスチャは64 KBのメモリを消費します(32ビットの色深度を想定)。テクスチャアトラスを使用すると、テクスチャをより緊密にパックでき、CCSpritesetDisplayFrameメソッドを使用して表示されるフレームをより簡単に変更できます。

さらに、テクスチャキャッシュを使用しています。

[CCTextureCache sharedTextureCache] addImage:@"player-small.png"]
[CCTextureCache sharedTextureCache] addImage:@"player-orig.png"]

そのテクスチャのメモリを明示的に解放しない限り、どちらのテクスチャもメモリに残ります。現在使用していないテクスチャのメモリを解放し、これらのテクスチャを頻繁に交換すると、画像が比較的小さい場合でも、ゲームはメモリの解放とデバイスのフラッシュメモリからの画像の再読み込みに多くの時間を費やします。

また、いずれかのテクスチャを使用するスプライトが複数ある場合、2つ以上のスプライトがいずれかのテクスチャを使用することがあるため、テクスチャをアンロード/リロードしようとしても意味がありません。

最後に、最大で64KBのメモリについて話します。メモリ使用量とパフォーマンスが心配な場合は、代わりにPVRテクスチャをロードする必要があります。これは、メモリとディスクの両方のPNGファイルのサイズの何分の1かです(ただし、色の鮮やかさは失われます)。

テクスチャアトラスとPVR画像を作成するためのTexturePackerをご覧ください。

于 2011-11-24T11:04:37.187 に答える