Bitmap の回転

 この何日か、スプライトの制御コマンドを作っているよ。
 で、その流れで、回転コマンドを作ってみることにした。

 Android での画像の回転は、Bitmap にかけるものらしい。
 BitmapDrawable には、回転に相当するものが見当たらない。
 これにはちょっと面食らっちゃったよ。
 スプライトは半透明を使うことを想定して、BitmapDrawable を描画するようにしてたから。

 仕方ないので、回転角を変更するたびに、Bitmap からBitmapDrawable を生成しなおすことにしてみたよ。
 処理落ちが気になるところだけど、やってみないことにはわからないね。

Matrix

 Bitmap の回転には、Matrix クラスを使う。
「Matrix に回転設定をして、Bitmap に適用する」みたいな感じ。
 Matrix クラスは回転の他にも、サイズ変更なんかもあって、色々と多彩なことができるみたい。

 で。回転は、postRotate method を使って、角度を設定する。
 ↓こんなテストmethod を作ってみた。

	protected Bitmap bitmap = null;
	protected pos_X = 0;
	protected pos_Y = 0;
	protected width = 0;
	protected height = 0;
	protected BitmapDrawable img = null;
	//--

	protected float roll = 0.0f;
	protected void rotate(){
		Matrix matrix = new Matrix();
		roll += 5.0f;
		matrix.postRotate( roll );  // 角度設定
		
		Bitmap _bitmap = Bitmap.createBitmap( bitmap, 0, 0, bitmap.getWidth(), bitmap.getHeight(), matrix, true);
		img = new BitmapDrawable( _bitmap );	// Drawable変換
		
		int w = _bitmap.getWidth();
		int h = _bitmap.getHeight();
		
		pos_X = pos_X +( ( width - w ) /2 );
		pos_Y = pos_Y +( ( height - h ) /2 );
		
		width = w;
		height = h;	
	}
	//--

 このmethod は、実行するたびに、bitmapを5度ずつ右回転させて、BitmapDrawable を作り出している。
 bitmap とimg は、別method であらかじめ読み込んでいて、表示位置やサイズ等もその時に設定している。
 実描画も別method で行っている。
 ちなみに、実描画でBitmap を描画するなら、BitmapDrawable にする必要はないね。

 実行すると、こんな感じ。

 実行速度は、まぁ、こんなモンかな…って感じ。
 エミュレータ上なのでハッキリいえないけど、サイズを考慮すると遅いのは仕方ないやね。

by the way…

 18行目からの処理は、表示位置と幅の更新。

 位置更新をしないと、Bitmap のセンターで回転されず、宇宙遊泳してるみたいになってしまう。
 ソレはソレでおもしろかったけどね。(^_^;

 幅の更新は、描画をDrawable で行っているため。
 更新しないと、↓な感じに変形してしまう。(^_^;

 なぜDrawable で描画しているのかというと、半透明表示を行いたいから。
 いまわかっている時点では、半透明表示には、Drawable を使うしかないみたいなんだ。
 Bitmap のpaint にalpha マスクをかければいいような気もするけど…まだ試してない。
 拡縮もDrawable 上でやってたんで、作り直しだよ…。(-_-;

Posted in Bitmap, Matrix. Tags: , , , . Bitmap の回転 はコメントを受け付けていません »

スプライト表示コマンド

 スプライト表示のコマンドを追加して、画像表示が可能になったよ。
 ノベル・アプリとしては、これで必要最低限の状態。
 音関係を作ってプレ配布…といきたいトコだけど。
 VirrualBoxだと音が出ないんで、音関係に手が出せない…。
 そろそろ、実端末が欲しいなぁ…。

20110218

Posted in 雑記. スプライト表示コマンド はコメントを受け付けていません »

ノベル・モード

 設計変更が終わって、ノベルモードを整備してみたよ。

110209

 折り返し&禁則処理をJava任せにしてるから、タマに違和感が出るけど。
 まぁ、仕様ということで。(^_^;

 これでテキストだけなら見ていくことができた。
 続けてコマンドを整備していくよ!

Posted in 雑記. ノベル・モード はコメントを受け付けていません »

多層Viewの注意点 ~redrawされない現象

 TextView が描画更新されなくなったよ。
 どうやら、onDraw イベント自体が発生してないみたい。
 invalidate() でrepaint しても効かない…。
 どないせいっちゅうねん?!

 一日中、あーでもない、こーでもないとコネくりました結果──
 どうやら原因は、View の重ね合わせにあるみたいだ…。

原因はView の多層構造

 作ってるアプリは以下のような構造になってる。

	<画面奥(下層)>

	「メッセージ表示」 (TextView)
	「選択肢表示」

	<画面手前(上層)>

 「メッセージ表示」がredraw されなくなるのは、「選択肢表示」をINVISIBLE にしてから。
 つまり「選択肢表示」がredraw されなくなってからだ。
 どうやら、上の層でredraw しないと、下の層もredraw しないらしい。
 どうりで、TextView でinvalidate() かけても描画更新されないワケだよ…。orz

 これは上の層が INVISIBLE の状態であってもredraw されない。
 また、下の層が上の層の描画範囲外の場合も、redraw されない。
 理屈はわかるけど、ひどい仕様だよ。まったく…。

まとめ

  1. 上層でredraw しないと、下層もredraw しない
  2. 上層が INVISIBLE の状態であっても同様
  3. 下層が上層の描画範囲外だとredraw されない

by the way…

 wrap_parent の多層構造となっている場合。
 最上層に透明なfill_parent のView を配置し、ソレにinvalidate をかけるようにしてやるといいかもしれない。
 今回、定期的に、最上層を描画更新するようにしたら、全体的に描画の反応がよくなった。
 てか、いままで手放しでTextViewが更新されてたのって、そういうことでもあったんだね。(^_^;

Posted in View, レイアウト. Tags: , , , . 多層Viewの注意点 ~redrawされない現象 はコメントを受け付けていません »

ゲームに適したLayout とは?

 プログラムは粘土をコネるがごとし。
 作ってるノベルアプリは、閉塞感がアチコチに見られるので、作り直しをしている最中。
 ちょうどいいので、「ゲームに適したLayout」について、復習してみよう。

※.Layout に関しては、↓コチラが詳しい
http://techbooster.jpn.org/tag/addview/

必須条件

 ”ゲーム”と一括りにしても、色々あるよね。
 だから、一般的なテレビゲーム・スタイルを前提とするよ。

 そこで必要な条件は、以下の2つだろうね。

	1. オブジェクトを重ねて表示する。
	2. 指定した位置に、オブジェクトを表示する。

 てっとり早く結論をいうと、そんなLayout はAndroid にはないんだ。

 条件・1に適合するのは、2つだけ。

	FrameLayout
	RelativeLayout

 でもこの2つとも、条件・2には適合しないんだ。
 なぜならどちらのLayout も、他オブジェクトとの相関関係やLayout の制約に縛られてしまう…。

 2つの条件を兼ね備えているのは、AbsoluteLayout だけ。
 でも、これは現在、非推奨で、eclipse で取り消し線を引かれちゃう、いらない子扱い。(w


「ボタン等のインターフェースは、Layout に従うこと。
 画像表示だけなら、View内で行え」

 おそらくAndroid はこういう理念なんだろね。
 まぁ、それはわかるし、その方が便利なこともある。
 必ずボタンは重ならず、整然と並ぶからね。
 でもさ、それじゃ困ることもあるんだよね。

 たとえばImageView をスプライトのように使う場合。
 リアルタイムにこだわらない、アドベンチャー・ゲームのようなのは、ImageView で十分。
 背景やキャラを複数のImageView で構成すれば、お手軽だし、Animation の恩恵も受けられるしね。
 AbsoluteLayout みたいなのがない現状、ゲームに適したLayout はAndroid に存在しない。
 困ったモンだ。

View を重ねて表示したい

 View を重ねて表示したい場合、FrameLayout、RelativeLayout のどちらかを使うことになる。
 それぞれの概略はこんな感じ。

●FrameLayout
 ・単純に重ねて、View を配置する。
 ・表示原点は、左上。
 ・Gravity 設定が特殊で、foregroundGravity を使う。

●RelativeLayout
 ・他Viewとの相関関係で配置する。
  宝の在り処を記すみたいでややっこしいらしい。
  「大きな木から右に三歩、そこから下って四歩、そこから左に二歩…」
  みたいな感じらしい。(^_^;
 ・配置設定をしなければ、Viewを重ねられる。
  けれど、設定をすると重ね合わせはできなくなるみたい。
 ・Gravity 設定は、他と同様のgravity を使う。

 一見すると、FrameLayout がよさげ。
 だけどpadding がなんかおかしいんだよね…。
 使ってると、なんのために存在するのか、わからなくなってくる。(^_^;

 どちらも似たりよったり、RelativeLayout を使うのが無難…
 っていうのが、今のところの印象かな。

指定した位置にView を表示したい

 最初に”できない” といったけど、実はできないことはないんだ。
 ただ色々と問題があるだけ。
 で、やってみたことと、問題をあげておくよ。

Animation を使う

 Animation を使って位置を指定する方法。

 TranslateAnimation で位置を設定して、setDuration を”0″ にする。
 そうすると、瞬間的に移動するから。
 setFillAfter とsetFillEnabled を設定して、移動後の状態を維持するようにする。

 肝心なのは、setFillAfter とsetFillEnabled の設定だけで、TranslateAnimation はフツウに移動してもいいんだけどね。

 問題は、View がボタン等のインターフェースだった場合。
 View の実体は元の位置にあるので、移動後の場所をクリックしても、実行されない。
 まぁ、インターフェースにこんな使い方をすることはないだろうけどね。(^_^;

padding を使う

 padding を使って位置を指定する方法。

 この方法だと、インターフェースの反応を維持しながら指定できる。
 ただし、ややっこしいんだよねぇ。
 Layout によっては意図した状態にならないし…。(^_^;

 ※.setPadding の引数
http://android.migimaki.com/category/view/padding

 と、まぁ、そんなこんなで、ない知恵を絞ってみたよ。
 もっと簡単でいい方法があったら、また追加していくつもり。

Posted in レイアウト, 雑記. Tags: , , , , , . ゲームに適したLayout とは? はコメントを受け付けていません »