折角だからMIDIにも対応してみる。俺は阿呆なので、MMSystemのMIDI APIに 挫折した経験があるのだが、PortMIDIは俺が理解できる程度には簡単だな。 latencyが指定できるからFM音源との同期も楽だね。
http://news.2-3-0.org/comment/comment_200606_442.php俺から見ると自ニュFは自ニュを参考にした感がアリアリなんだが。 リダイレクタの文面まで一緒なのはどうかなあと思った覚えがある。 それにしてもＦは相変わらずチャンコロがどうのと毎日相変わらずな感じが バンバンだなあ。そういうのはぁゃコロにやらしときゃいい。いや、むしろ ぁゃコロと手を組んでついでにナミコロとも手を組んで、完全にチャンコロ を排除した理想の投稿型アングラニュースサイトでも作ればいいのに。勿論 投稿したニュースは分割したバイナリで提供され、ニュースを見るためには 結合パスが必要。パスの入手にはお礼のコメントが必須となり、えーと五行 以上でお願いします。[#5] ところで自ニュF視点だからか、俺から見るとFを参考にした感がアリアリなんだが。
HW LFOは5.56Hzに設定するのか。どおりで一部の音色の鳴り方が違うわけだ。 リリースしたのが1999年だから、6年近く気づかなかったことになるな。
遊ぶっつうても、バッファ確保して再生準備が出来たら後の処理は全てこち らでやるから、あんまり遊んでる感じがしないな。とりあえず昔作ったナニ を移植してみることに。 で、VC++で作ったもの（正確にはHigh C/C++で作って、それをVC++に持って きたのだが）がそのままgcc4でコンパイル出来るなどとは思っていなかった が、まさかfmgenがつまづくとは……。
ここ最近はめんどいめんどいばかり書いていて、なぜこんなにやる気が無い
のかというと持久力と忍耐力が無いから。そんな奴がやるきレス度MAXになる
と、刺激を求めて他のことに手を出すようになる。
というわけでSDLをインストールして適当に弄っているのだがSDL_HWSURFACE
| SDL_FULLSCREENでサーフェスが作れない。
SDL_putenv("SDL_VIDEODRIVER=directx") は当然してあるとして、他に何か
必要なんだろうか。
とりあえずほっといて、SDL_Audioでも弄るかな。
16色全て真っ白なパレットが欲しくなって困った。しかし今更パレット配置 を変えるわけには……いや、いくけどさ。めんどい。 キャラタイルは必要に応じて再配置出来てるわけだから、同じ方法でキャラ パレットも動的に再配置出来るようにすればいいんだよな。次からはそうし よう。
その前にMMLについて少し。 MMLは「T120 L16 C4D4EFGA」みたいに記述するわけだが、ここで「C4」につ いて考えてみると、これはＣ（ド）を発音してから四分音符＝0.5秒の時間 何もしないということを意味しているのだ。 これって敵ス（中略） 書くのがめんどくなったので大雑把にすっ飛ばすけど、SMF→MMLコンバータ があれば、このようなMIDIコントローラを駆使してリアルタイムに敵の挙動 を定義することも可能なのだよ！ コンバータは過去に作成済なので、やろうと思えばすぐにも試せるのだが、 めんどいので誰か代わりにやってみてくれ。ていうか、めんどいばっかりで 中身が無いな。俺は近いうちに息をするのがめんどくて死ぬ。
聖書で再挑戦してみる。「光あれ」で世界が誕生するなんてOO的じゃないか？ まず創世記を全部突っ込んでみた。 http://ebible.org/web/Genesis.htmこりゃあかん！まあ確かに、全部突っ込んだら非OOな文面の割合が多いので こうなるのも無理はないか。「光あれ」の部分だけ抜粋して突っ込んでみる。bibleさんのOO度は39点です！ あんまりかっこよくないのでウォーニングです。ひどいものですよ実際。その結果……God said, “Let there be light,” and there was light. God saw the light, and saw that it was good. God divided the light from the darkness. God called the light “day,” and the darkness he called “night.” There was evening and there was morning, one day.うぉおー！神すげー！さすが神！GodさんのOO度は93点です！ 神です。なんかUMLとかXPとかJavaで.Netです。すごいです。
VRAMに多少余裕が出てきたので、調子に乗ってデカキャラをバンバン出して いたら、平気でライン制限に引っかかりまくってた。 128x128が6個 64x64が5個 64x32が4個 32x64が1個 32x32が6個 これら全てのスプライトが同時に横並びになる可能性があり、実際に横並び すると 1568 ドットになるわけだわ。ライン制限が 1210 ドットなので 300 ドット分のスプライトが消えてしまうのだ。うーん 128x128のスプライトを 豪快に減らすかー。 どうでもいいけどVisualboyAdvance 1.8.0-beta3はライン制限がそれなりに 再現されるので素晴らしいと思った。いちいち実機に持っていって確認しな くて済むものね。いつから再現されるようになったんだろう？
http://d.hatena.ne.jp/shinichiro_h/20060615 bullet.cで試してみたよ。中身はまあ、弾が生まれて死ぬまでの動作を擬似 タスクで記述してある、みたいな感じ。すげえ！ひょっとして、ぶっちぎりでトップじゃないか？kashiwaさんのOO度は14点です！ あなたのコードは全然OOじゃないのでコンパイルエラーです。さようなら。 もう来なくていいです。
EDGE 3Dのブラケットを利用して、DirectPad Proを作ってみた。パラレルポ ートのあるノートならこれが現時点で最も有効な環境じゃないかと思うのだ。 パラレルがあるなら、な……。 どうでもいいけど、押入れを漁ってみたらスティックが有りすぎた。写真に 写ってないのがあと三本あるのでどうかと思った。俺は近いうちにゲーム脳 をこじらせて死ぬ。
スプライトの回転に使う行列パラメータが、何故か一つ飛びで使われていた ので二時間くらいかけて原因を探っていた。最初はアラインメントの問題か と思って試行錯誤していたのだが、よーく探したら全然違うところに原因が あった。ここでX座標（9ビット）以外のビットをマスクしてる……つもりだったんだ けど、0xFC00は二進数に直すと 1111 1100 0000 0000だよおっかさん！ ~ 回転行列テーブルのインデックスを１ビット落としちゃって、一つ飛びになっ ていたんだよ！sp->attr1 = sp->attr1 & 0xFC00; sp->attr1 = sp->attr1 | spx;こう書き直したよ。ビット演算とかチョー苦手だよ。生まれてすいません(;´Д`) むしろビットフィールドを使って#define SP_XMASK 0x01FF sp->attr1 = sp->attr1 & ~SP_XMASK; sp->attr1 = sp->attr1 | spx;とでも書いたほうが安全な気がする。でもrotflagが立ってるときにrot番号 を hflip | vflip | rotnum の５ビットで表現しなきゃいけないので、やっ ぱりビット演算を書く必要は出てくるんだ。これわもう駄目かも分からんね。union { struct { u16 a0; u16 a1; u16 a2; } a; struct { u16 form :2; u16 color :1; u16 mozaic :1; u16 type :2; u16 doublesize :1; u16 rotflag :1; u16 y :8; u16 size :2; u16 hflip :1; u16 vflip :1; u16 rotnum :3; u16 x :9; u16 pal :4; u16 priority :2; u16 tile :10; } bin; } attr; sp->bin.x = spx;
面ごとのキャラクタテーブルを再構築していた俺であったが、色違いとかで 重複するキャラもいるわけで、そういうキャラは番号を合わせた方が都合が いいわけなのだが、そこまで考えだすと大変だ！でも今やっておけば後々に なって報われるはず。多分。
typedef struct {
u8 size; // 使用/空き タイル数
u8 ref; // 参照回数
u16 pat; // 実際に格納されているパターン
} ATTR_PACKED TILE_BLOCK;
u16 pattern_refs[MAX_PATTERN]; // パターン番号からタイル番号を逆参照する
こんな感じでタイル番号とパターン番号を結び付けてるんだけど、パターン数
が多いのでテーブルのサイズが結構バカにならないのだわ。そこで、面ごとに
出現するキャラクタを調べて、それぞれの面を構成するのに必要な最大パター
ン数分だけ割り当てるようにしてるところなのであった。例えば各面のボスが
平均120パターンなので、分離すれば6面分720パターン＝1440バイトほど稼げ
るっつーか、たった1440バイトを稼いだ先に何があるのか？
64x64サイズのキャラクタの回転アニメパターンが8枚あって（HVフリップ の組み合わせで32方向に回転）、それぞれのパターンが同時に画面に出現 する可能性があって、そうすると64x64換算で16枚しか配置出来ないVRAMは 狭すぎるという話であり仕方なく回転機能を使うように変更したら物凄く 滑らかに回転するようになって気持ち悪い。まあ4bit落としてやれば今ま で通りカクカク回転するようになるんだけど。それにしても、ドット絵が 滑らかに回ると気持ち悪いというのはどういうことか。これも オールド ゲーマーの サガか‥‥。
エロゲーの広告バナーがいつも最上段に入ってたり、ダウンロードリンク が異様に小さくなってたりして「なんだかなあ……」な感じなので、自作 のニッチなソフトを登録解除してきた。 まだVectorのソフト数が少なかった頃に依頼メールが来てそれ以来ずっと 置かせてもらってた。当時は登録するとVECTOR PACK for WINとかが貰えた んだよな。何気に重宝してた。 ちなみに通算ダウンロード数は7年間で400ちょいだった。ニッチすぎる。
参照カウンタ ＶＲＡＭ上のキャラ ２ ０ Ａ １ ０ Ａ Ａの登録を1個解除 １ １ Ａ Ｂ Ｂを登録 ０ １ Ａ Ｂ Ａの登録を1個解除 ０ ２ Ａ Ｂ Ｂを登録 Ａはまたすぐに使う可能性があるので取り合えず残す仕様になってる。 つまりＡからＢにキャラクタを変更するとき、二つ分の空きバッファが 必要なわけで、これがネックになった。仕方ないのでVRAMを毎フレーム 全更新するように変更して急場をしのいだ。 今までGBAの持つポテンシャルを捉えきれずにいた所があったんだけど、 ようやく掴めてきたかもしれない。
今のところコリジョンチェックは総当りでやっていて、敵弾120発と自機、 自機弾16発と敵10体をそれぞれ総当りしても、まあなんとかなってるんだ けど、いや実は、なんとかなってないので（全方位弾を撃つと処理落ちが 一瞬だけ発生する）なんとかする。なんかガクガクして見えるのは精神的 によくない。 というわけで手っ取り早くなんとかする方法として、判定関数をARM化した のだが…… THUMBからARMの判定関数を呼び出し、そこから更にTHUMBの関数を呼び出そ うとしたら止まってしまった。ASM吐かせてみたらblでブランチしてるのな。 longcall属性をつけなきゃいけないようだ。なんか、以前にも似たような ことを書いた気がする。学習能力無いな俺。
GBASPを縦に持つと、ちょうど親指の付け根辺りがスピーカーを覆う位置 に来るのでボリュームが下がってしまうのだ。
二月の始め頃に着手し始めたアレがようやく完成を向かえそうだ。４ヶ月 もかかったのか。殆どの期間はサボっていたような気もするけど。むしろ これからの煮詰め作業こそが本番という説もあるが。 これが終わったら次はいよいよアレだなあ。楽しみだ。
ｹﾞﾂﾏﾂｰ(´ω`)