AIR for Android ADVゲームを作ってみる(Starling編)

前回の続きです。
いざ、Starlingを使って進めて行こうと決めるもいろいろと問題が発生することがわかりました。
今回は、それについて書いていきます。
 

Starlingの使い方は、他のサイトでも散々解説されているので割愛。
 
まず、単純にStarlingを組み込んでみました。
Starlingのメリットは、AS3クラスと同じような使い方が出来るので、そのままの感じで
使う事ができる事です。Sprite、Eventと言った感じでクラス名も同一です。
 
しかし。。。
 
まずここでつまずきました。
今回は既存のプログラムの一部を Starling で置き換えるということで、同一名のクラスが
混在してしまう問題が発生しました。
Startling 側のSpriteクラスのイベントリスナーに Event.ADDED_TO_STAGE を登録した場合で例えてみると、

上記コードにおける “Event” は、starling.events.Eventクラスです。
flash.events.Eventクラスとは別物です。
よって、AS3側のEvent処理を行う事ができません。
プログラム全体を Starling で組む場合は特に気にする必要がありませんが、混在する場合は、
気をつけなければなりません。
この問題を解決するためにこんなクラスを作ってみました。

これでAS3側とStarling側のクラスを橋渡ししてあげます。
このクラスを使うことでの副産物として、イベントを一括管理出来るのでイベントの消し忘れが減りました。
  
 
イベント処理がどうにか上手くいきそうなので、次は実際に画像を表示していくことにしました。
今回 Starling を使う上で参考にしたのが、こちらのIntroducingStarlingを翻訳したPDF
これによると、
 
「Stage3d でテクスチャとして使う画像は、2のべき乗で正方形である必要がある」
「Stage3d でテクスチャとして使う画像の最大サイズは 2048 まで」
 
ということのようです。
 
Staling は読み込んだ画像のサイズを調べ自動的に元々の画像サイズに一番近い2のべき乗の
正方形テクスチャを作成してくれるます。
ただ、今回は少しでも処理を軽くしたかったので、事前に2のべき乗で正方形化した立ち絵画像
を新たに作りそれを素材としました。これで1つ目の条件はクリア。
 
で、問題は2つ目の条件。
今回使っているゲーム素材には、たまたま 2048 を超えるサイズのものがありませんでしたが、
昨今のゲームは高解像度化が進んでいるので、2048 を超える物が出てくるかもしれません。
今回はやりませんでしたは、いずれは分割表示の仕組みも必要になってくるでしょう。
 
とりあえず、2つの条件はクリアしているのでいざ表示してみると、
 
立ち絵の位置が合ってない。。。
 
新しく作った立ち絵の画像は下の様な形になります。
2のべき乗で正方形化した立ち絵画像
まず、Starling で画像を表示するには Textureクラス で画像を読み込み
その読み込んだ Textureクラス を引数として Imageクラス を作成する必要があります。
AS3クラスで言うと、BitmapDataクラスと Bitmapクラスの関係です。
最終的に、作成した Imageクラスは starling.display.Spriteクラスに addChild して表示します。
 
どうして表示位置がずれたかというと、まず上の画像の座標Pと座標qに注目しましょう。
Imageクラスには “pivotX” “pivotY” というプロパティが存在します。
これは、Imageクラスの基点プロパティです。
基点とは、移動 回転 スケール の中心となる座標です。
ゲームスクリプト内での座標指定は、座標qを基点として書かれています。
しかし、実際のImageクラスの基点は座標pです。
その差によって、表示された立ち絵の位置がずれたわけです。
じゃあ、基点のX座標を立ち絵画像の横幅の中心にし、Y座標を立ち絵画像の底辺Y座標にするということで、

が思いつきましたが、元々の立ち絵の縦横は画像によってバラバラなのでなのでこのままでは使えません。
  
そこで、下の画像のようにして配置を修正しリサイズしてみました。
位置を修正した立ち絵
こうすることで、常にX座標を立ち絵の幅の中心、Y座標を立ち絵の底辺に設定することが出来ました。
 
これらの処理によって、無事ADVゲームらしく表示することが出来ました。
GPUの恩恵もあり、立ち絵の移動速度も格段にアップしました。
 
が、ここでまた問題。
画像の切り替わりが遅い。。。
 
これは Starling を使う前から気がついていた問題なので、描画以外の問題であることがこれでわかりました。
通常は、パック化されたファイルから指定画像のデータを読み取って表示ってのがセオリーですが、
今回の移植版では、画像ファイルは1つずつ読み込む形を取っています。
1024x1024 の立ち絵画像の容量は大体、300~500KB
どうやらそこが引っかかっているようです。
 
どうにかこの容量を小さくするべく、次回は 画像フォーマットについて書いていこうと思います。

ActionScript AIR Flash Posted by Tomoya Kanehira @ 17:26

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です