July 22, 2007.

Badminton Scorer

相変わらず土日は遊んでばかりでパソコンに触っていません。先日から話に上がっているS!アプリですが、画面がほぼFIXしたのでキャプチャ画像をUPしてみました。大抵の人が「テニスゲーム？」と思うでしょうが、バドミントンのスコアを数えると言う地味なアプリです。キーの左右でスコアをカウントし、コート上の名前が立つべき位置に移動します。ラリーポイントになってから、場所がよく分からなくなるので意外と重宝するのではないかなぁと思い作りました。一応下段にスコア表もどきもあって、色が塗られる仕様になってます。

UNDO機能が無い、サイドチェンジに対応していない、そもそも21点になってもゲームセットにならないなど残作業は山積みではありますが、一応実機で動作しています。あと１週間ちょっとで完成できるでしょうか？公開申請期間を考えると週末には完成していないと厳しいスケジュール。

ちなみにベータ版をバド仲間の何人かに見せたところ、「凄い」「暇人」「なんの役に立つの？」「使えん」「１年前なら重宝していた」など暖かいエールを頂きました。スコアを通信越しにサーバに蓄積するなどの機能があれば素敵だと思うのですが、一般作者登録では実現できないので....。

さて、先日よりMIDPでアニメーションを実現するための方法を調査中です。Spriteを使わない場合だとひたすらgetImage()＆drawImage()するしかないわけです。で、PNGなら大丈夫なのは分かったのですが、byte配列で保持した場合に透過色が使えるかどうかがまだわからず。画像でやってもいいのだけれど、左右反転ができないので、byte配列にしておいて、プログラムで左右・上下の反転を実現すればデータが1/2or1/4になるなぁ、等と考えているのです。2色にして、1byteに4dotずつ格納すれば8byteで32x32の画像がかけるのだけれど、そこまで頑張ってプログラムを書くべきかどうか...。データ圧縮面なら既存画像フォーマットを使った方が楽なんだよなぁ...。

あとはアニメーションの実現方法も懸案中。たとえば秒間10コマでアニメーションをやるなら、アニメデータを以下のように作成しておいて、Thread.sleep(100)しながら以下のようなリストをよみ、drawImage()していけば良いはずです。

int[][] anime1 = { //imageID, x-corrdinate, y-corrdinate

　　{image0, 100, 100},

　　{image1, 120, 100},

　　{image2, 130, 100},

　　{image3, 140, 100}};

しかしこの書式だと、10秒間静止してから動き出すアニメを作った場合、100個無駄なフレームを作ってから1個有効なフレームを挿入することになるわけです。で、gif動画と同様、以下のような書式が考えられます。

int[][] anime2 = { //imageID, x-corrdinate, y-corrdinate, wait(msec)

　　{image0, 100, 100, 10000},

　　{image1, 120, 100, 100},

　　{image2, 130, 100, 100},

　　{image3, 140, 100, 100}};

うん、よさげ。でもこの書式で10キャラを同時に描画する場合、10キャラ分のダウンカウンタを準備する必要があります。100キャラ使いたいシーンがあると100個分いることに...。100キャラが同じタイミングでアニメする(例えば蟻の行列とか)場合、非常に無駄が多い。かといって、長時間起動時のヒープのフラグメント化を回避するためにも、携帯アプリで動的配列確保は避けた方が無難。どこかにラインを引いて仕様を決めないと。

Copyright 2007 barista. All rights reserved.