2009年9月10日木曜日

ドロネー図&ボロノイ図


最近、携帯の「コロニーな生活PLUS」ってサイトで遊んでます。
http://pc.colopl.jp/pages/wl/welcome.html

簡単に言えば自分が移動した距離に応じてポイントがもらえ、それで土地を育てるみたいなサイトです。

そこのサイトの位置情報というのがボロノイ図で作られているということなのでそれを再現しようと画像な感じで作ってみました。

画面をクリックしていくと、そこに点が打たれていって、3角形で分割しています。
青い線が「ドロネー図」
緑の線が「ボロノイ図」


まー久しぶりに高校数学的な部分使いましたね~

ネットがあるから助かりますが、方程式とかプログラムにそのまま使えんのでプログラム的な事をしている所を探すのに苦労しましたw

やっぱりなんでも使わないと忘れますね。ちょっと数学勉強しる

2009年8月18日火曜日

【BREW】マスコットカプセル

久しぶりのエントリー

最近BREWでマスコットカプセルを使用しています。
本日判明したのですが、マスコットカプセルを使用する場合、2D系のAPIを使用するためには
IMICRO3D_mcext_BindColorBufferなどを使用してやらないといけないのはサンプルの通りなのですが、IGRAPHICS系のAPIには非対応でIDISPLAYインターフェイスのみサポートしているらしいです。

なので、円とか多角形を描画する場合はプリミティブなどで代用する必要があるようです。

なんだかなー

2009年1月9日金曜日

BREWメモ

ソニーエリクソン系の端末にて、マナーモード状態で電源キー押し終了以外の方法でアプリを終了すると、その時BGMが”内部的”に鳴っていた場合、何故か終了寸前に音が少しなる現象が発生。
内部的っていうのはマナーモードだけどアプリ内の設定では音量がONの状態の事で、
普通にプレイしている時は音はなっていない。
まだソニーエリクソン系以外の端末だと今の所この現象は確認できてないから機種依存かな・・・・

原因はまだいまいち分かんないけど、終了直前は音全部止めるのが安全?

2008年12月10日水曜日

iPhoneメモ - AVFoundation

iphoneOS2.2から追加されたAVFoundationフレームワーク

今日ループ曲を鳴らしてるとループのタイミングで音が一瞬途切れていることに気づいた。
調べてみると、どうやらエンコードによって変わるらしい。

●以下の三つの形式だけチェック
wave - 問題ない
Appleロスレス - 問題ない
aac - おかしい (320kbps, 192kbps, 32kbps)

ロスレスとaacはitunesでエンコード。
上の二つは音もいいんだけどサイズも大きい。ソフトバンクの3G網で落とせる10M以内に抑えるならレートを下げるしかないのかな?
もっとちゃんと調べればもしかしたら大丈夫なのかもしれないけどさ・・・


--
ちなみに音の鳴らし方のメモも

NSString* path = [[NSBundle mainBundle] pathForResource:@"title" ofType:@"wav"];
AVAudioPlayer
* player = [[AVAudioPlayer alloc] initWithContentsOfURL:[NSURL fileURLWithPath:path] error:NULL];
[player play];


こんな感じで簡単に音を再生できます。

2008年9月14日日曜日

リーグ戦スケジューラー

個人的に参加している某ゲームの対戦会用に、リーグ戦のスケジューラーを作りました。
メッセとかに貼り付けれるように、リーグ表とか順位表とかも表示するようにしています。
以下がそのイメージ












巷では.Netがはやってそうですが、知らないのでMFCを使用。


デバッグは5~12人まで目視で行いました。
それ以上、以下はしていないのでミスがあるかも。

アルゴリズムとしては
-------------------------------------------------------------
1:まず奇数人数の場合、1人ダミーの人を入れて偶数人数化します。(後でダミーと当った対戦は除外)
2:A vs B で左の人をホスト、右の人をクライアントと呼ぶ
3:各回戦ごとにホスト基準で対戦相手を検索開始する。
4:検索順は A~F の6人の場合 A>B>C>F>E>D となる、 注意するのは(人数/2)を超えた場合最後の人から戻ってくるような検索の仕方に変わること。
5:基準のホストが決まったら次に対戦相手のクライアントを探して行く。
6:この時 クライアント候補は F>E>D>C>B>A>F>E... と 1回戦内でループしていき、対戦相手が決まったら、次に相手を決定するホストは直前のホストの相手-1の位置にいる相手から検索を始める。
7:例えば、最初の試合が A vs Fになった場合、 次にホストとなったBはEから検索を始める。
8:対戦相手が決まらなかった場合、クライアント検索開始位置は変わらず、4に戻る


プログラムソース的には 以下を回戦数分繰り返す。というか試合数が最大になる回戦まで繰り返す
int mMemberNum = x; // グループ人数
int client = mMemberNum- 1; // クライアント候補の人のID
bool roundCache[mMemberNum]; // 各ラウンドごとに対戦相手が決定したかどうかを表すフラグ
int league[mMemberNum * mMemberNum] // 各対戦情報を管理する配列
int roundCount; // N回戦をあらわす
for( int hostCount = 0; hostCount < (mMemberNum); hostCount++ )
{
     int host = hostCount;
    // ホスト位置が半分を超えたら、最後の人から逆方向にホスト位置をずらしはじめる
     if( host >= (mMemberNum)/2 ) host = (mMemberNum-1) - (host-mMemberNum/2);
    // ホスト候補の人が既に対戦が決定している
    if( roundCache[host] ) continue;

    for( int count = 0; count < (mMemberNum); client = (client - 1 + mMemberNum) % mMemberNum, count++ )
    {
        // クライアント候補が自分なら飛ばす
        if( host == client ) continue;
        // その人が対戦相手決定済みなら飛ばす
        if( roundCache[client] ) continue;
        // すでにクライアント候補の人とは対戦している場合は飛ばす
        if( league[(host *mMemberNum) + client] != -1 ) continue;
        // 対戦情報を設定
        league[(host *(mMemberNum+gisou)) + client] = roundCount;
        league[(client *(mMemberNum+gisou)) + host] = roundCount;
        roundCache[host] = true;
        roundCache[client] = true;

        break;
    }
}


--------------------------------------------------------------

無理やりな思いつきのアルゴリズムだからかなり穴があるかもしれない。

2008年5月23日金曜日

続・シャープ端末の罠

またまたシャープ端末のへんてこりんな仕様?が発覚。

Imageデータをそこそこの枚数用意しただけで速度が遅くなるみたい。
量は結構端末によってまちまちみたいだけど、シャープ端末のは酷い。
なんたって最新機種でもおこるし・・

null値のImage配列だけでも影響が出る。
画像を沢山使うアプリだとそれだけでもうPSみたいなローディングがw

今後、そういうことも意識してプログラムしていかないと行けないな。(てかシャープが改善しろよ・・・)

2008年5月12日月曜日

Android Developer Challenge

落ちました。入賞ならずorz

まぁそう簡単には行かないと思ってたけどさ
ありきたりなアイディアだと思ったし、多分Googleが求めている物はもっと違う物なんじゃないか?
とも感じてた。

これから入賞者のアプリを見れる機会があるだろうし、そこで感銘を受けようw
家でも開発したいけど、家のPCだと重くてきついかなぁ。

新しいPC買わないとなぁ