(T/O)
久々にgbadevを見てた。 How to copy a function from ROM to RAM? 「CODE_IN_IWRAM で main()の呼び出し前にコードが IWRAM に配置されるように なるのは知ってるけど、好きなタイミングで転送して実行したいときはどーすん のさ？」という話題。 テキトーに流れを書くとこんな感じか。でまぁ意訳はさておき、オーバレイ領域はgba_cart.ldで定義されてるっぽい。・くくく……コンパイラもリンカも それどころか誰だって てめーの気持ち 呼び出したいタイミングなんか 分かりゃしねーんだヨ ・UZEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE１１１ せめて転送するための領域くらいはあらかじめ確保出来ないのか？ ・リンカに用意されてるIWRAM overlayを使えヨ でも俺はやり方を知らねーし 俺が知らねーってことは 知ってる奴はここにゃ 居ねーだろうナ ・使えねー野郎だな。変わりにEWRAM使うのはどうなのYO？？ ・EWRAMはそんなに速くねーよ？ ウェイトが2/2だろ ROMは3/1だからな EWRAMにコードを置く意味なんてねーのヨ むしろ遅い 悪魔のRAMだナ （ここで救世主が登場） ・IWRAM overlayなんて簡単じゃねーかよ。黙ってこれ使っとけ（envが貼られる） ほら引っかかった。こいつ、神奈川OCNだ（笑） ・すげえ、すげえよアニキ！１２２併せて読みたい：3.6.9 オーバーレイ記述 .iwramN に配置したコードを ( __load_stop_iwramN - __load_start_iwramN ) のサイズ分 __iwram_overlay_start に memcpy して呼び出す、てことみたい。 まー知識として覚えてはおくけど、オーバレイってリアルタイムゲームじゃ使い どころが無い気がするんだ……。__iwram_overlay_start = . ; OVERLAY ALIGN(4) : NOCROSSREFS AT (__iwram_overlay_lma) { .iwram0 { *(.iwram0) . = ALIGN(4);} .iwram1 { *(.iwram1) . = ALIGN(4);} .iwram2 { *(.iwram2) . = ALIGN(4);} .iwram3 { *(.iwram3) . = ALIGN(4);} .iwram4 { *(.iwram4) . = ALIGN(4);} .iwram5 { *(.iwram5) . = ALIGN(4);} .iwram6 { *(.iwram6) . = ALIGN(4);} .iwram7 { *(.iwram7) . = ALIGN(4);} .iwram8 { *(.iwram8) . = ALIGN(4);} .iwram9 { *(.iwram9) . = ALIGN(4);} }>iwram = 0xff __iwram_overlay_end = . ;
スプライトばかりかまけていて、BGは殆ど手をつけてなかった。なんとかしたい。 これまでキャラクタチップとタイルマップを手動で管理していたが出来ればある 程度自動化したい。チップを描いてマップエディタで並べてー、チップを修正し たらマップも適当に修正してー、という二元管理は面倒だ。 そこで、巨大な１枚絵のビットマップから直接チップとマップを生成するように してみた。 キャラクタベースは16k単位（16色, 16x16サイズ で128個のチップ相当）なので、 BG1面につきチップの数は最大128個まで、という制約を設け、似通ったチップを HVFLIP込みでバシバシ代替していく戦略を取る。チップが類似していることを判別するアルゴリズムはどうしたかというと…… …… 続く。（多分続きません）
クリスマスやら間食やらで一気に太ってしまった。若干寒さに強くなったような 気がする。脂肪侮りがたし。
ARCANACRA v0.4.3 Black Label あとで読むとか言いつつも今流し読みしてるんだけど、面構成スクリプトが興味 深い。ウェイトにすら２の乗数を使わずにいられないのはサガなのか。 海外勢のスコアラがボス戦で固定オートロックをキメてスコアを伸ばしてるんだ けど、俺はその仕組みがいまいち分からず伸び悩んでいた。が、ソースを読めば 一発で分か……あれ？えーと……。ううん、あとで読むわ。
このところの俺は、シガタケさん( 画展 )のミクスマイルズを見てすっかりトキ めいてしまっていた。だってだって、なんでか知らないけどGBAネタなんだもん。 ネタ画像として完結しているものを具現化するのも野暮だよなーと心の片隅では 思いつつ、約半月後……(WMV9, 音声無し) それっぽく動くところまでは出来た。 んで、例の抱き枕騒動で初めて知ったのだけど、クリプトンの二次創作ガイドラ インを見たら……
となっており、つまり同人誌を書くのはOKだけどゲーム化は駄目だったんだよ！ な、なんだってー。 そういうわけで、オタが一人で暴走し、勝手に自爆した、という心暖まる日記を お送りいたしました！画像の二次創作についての弊社のガイドライン 弊社がキャラクター・ボーカル・シリーズのために公開している画像 （以下「原素材」）がモチーフとなっている制作物（以下「二次創作 物」）については、個人または同人サークル等が、自らの創作により、 営利目的ではない趣味の範囲で制作し頒布する場合（但しゲーム作品 を含むプログラム、立体物、衣装を除く）に限り、一切の制限を行っ ておりません。
absoluteなのかobsoleteなのか分からんよー。
メガドライブ用ソフト "Pringles Game" うおー、凄い。メガドラ発色だ！カートリッジ俺も欲しい！ それは置いといて、開発環境がSGCCなのが気になった。さすがにSGCCは古いと思 うので新しめのをアップしておいてみた。 DevkitGen.zip (39.91 MB) 中身はwindows向けにコンパイルした m68k-gen-elf-gcc 3.4.6 / binutils 2.17 / newlib 1.14.0 やら。 3.4.6 なんて古いじゃん？って人もいると思うけど、個人的には 3.4.6 が最強 なので無問題だ（特に根拠は無いです）。次に最強なのが4.1.2なので、Windows の人はここらへんを元にビルドしてみればいーんじゃないかと思う。なんか色々 ハマってるけどLinuxでビルドしたらノーエラーでフィニッシュだった。酷いん じゃないかと思う。 -- ううん、crt0.S やら headerfix ツールやら作っていたはずだけど、いつぞやの HDD内ソースファイル削除キャンペーンで全部消滅したみたいだ……。悲しい。
ラスタ分割するためにテーブル参照していたのを、その場計算に変えてみた。 この計算は、ラスタブロック構造体の総スプライト数を加算するためと、実際に スプライトをラスタブロックへ振り分けるためと、でスプライト一個につき二回 行っている。あまり真面目な計測法ではないけど、計算が終わった瞬間にパレットを書き換え る方法で目視してみたら、スプライトを128個置いたとき、後者の方が2ライン分 （＝2,464サイクル）速かった。 前者が遅いのはROM参照が遅いから、かしら。ためしにテーブルをRAMに配置して みたら、後者と差が出なかった。ならRAMを使わないで済む方がいいよね。 -- ここからは妄想なので読まなくていいです。 まじめじゃない計測結果を元に、ちょっと真面目に考えてみた。（なんと意味の 無いことを……）#if !defined(CALC_RASTER_ORDER) static const u8 y_order_table[256] = { 0x1,0x1,0x1,0x1,0x1,0x1,0x1,0x1,0x1,0x1,0x1,0x1,0x1,0x1,0x1,0x1, ... }; u8 array_index = y_order_table[n->sp.attr0]; #else u8 array_index = n->sp.attr0; array_index += 16; array_index >>= 4; #endifARM TRMによると前者 後者 108: e59f3074 ldr r3, [pc, #116] 10c: e7d6c003 ldrb ip, [r6, r3] 110: e51b3030 ldr r3, [fp, #-48] 108: e51b3030 ldr r3, [fp, #-48] 114: e3ca2cfe bic r2, sl, #65024 10c: e3ca2cfe bic r2, sl, #65024 118: e1800003 orr r0, r0, r3 110: e1800003 orr r0, r0, r3 11c: e1822005 orr r2, r2, r5 114: e1822005 orr r2, r2, r5 120: e51b102c ldr r1, [fp, #-44] 118: e51b102c ldr r1, [fp, #-44] 124: e1c400b8 strh r0, [r4, #8] 11c: e1c400b8 strh r0, [r4, #8] 128: e1c420b6 strh r2, [r4, #6] 120: e1c420b6 strh r2, [r4, #6] 12c: e1c460b4 strh r6, [r4, #4] 124: e1c460b4 strh r6, [r4, #4] 130: e59fe050 ldr lr, [pc, #80] 128: e59fe054 ldr lr, [pc, #84] 134: e1a00081 mov r0, r1, lsl #1 12c: e1a00081 mov r0, r1, lsl #1 130: e286c010 add ip, r6, #16 138: e59f404c ldr r4, [pc, #76] 134: e59f404c ldr r4, [pc, #76] 13c: e59f2030 ldr r2, [pc, #48] 138: e59f2034 ldr r2, [pc, #52] 140: e19030be ldrh r3, [r0, lr] 13c: e19030be ldrh r3, [r0, lr] 144: e1a0c08c mov ip, ip, lsl #1 140: e1a0c1ac mov ip, ip, lsr #3 144: e20cc01e and ip, ip, #30GBATEKによるとldr 1S+1N (PC のロードなし。ロードされたワードを次の命令で使用) ldrb 1S (PC のロードなし。) add 1S and 1Sなので、 前者(ROMバージョン)が 1S+1N+1S + 8+5 = 16 前者(RAMバージョン)が 1S+1N+1S + 1+1 = 5 後者が 1S+1S = 2 ROMバージョンと比較すると 14 cycles速い。128個 * 2 * 14 = 3,584 RAMバージョンと比較すると 3 cycles速い。128個 * 2 * 3 = 768 ってことで、 ROMバージョンは 3ライン(3,696) ＞ 3,584 ＞ 2ライン(2,464) RAMバージョンは 1ライン(1,232) ＞ 768 ＞ 0ライン( 0 ) という結果が出たのかなぁ。 まぁ、タイマカウンタ使って真面目に計測しろよ俺って話なんだけど。Region Bus Read Write Cycles Work RAM 32K 32 8/16/32 8/16/32 1/1/1 GamePak ROM 16 8/16/32 - 5/5/8
もう何回書いたか分からない話題ですが、また新たな思いつきが。 結局のところスプライトダブラは縦方向の表示数は増やせても、横方向には増や せないので、XSPと同じ16x16サイズで奥様うっとりレーザーを撃つと、（128個 を分割した）64個のスプライトバッファがあっという間に使い尽くされてしまう のだった。 と、ここで、GBA/DSのスプライトはマトリクスのサイズが変えられることを思い 出し、横方向に伸ばしてやればいーんじゃんと思いついたのだ。タイルの管理が 面倒くさそうではあるけど、連続した空き領域が一箇所も無いことは滅多に無い 《否定の連続》ので、用途を限定すればなんとかなるか。 しかし、更によく思い出してみると、横方向の可変サイズは 16x8, 32x8, 32x16, 64x32 の四つからしか選べないのだった。 んーここは 16x8, 32x16, 64x16, 64x32 と、お答え頂きたかった。32x8なんて使う機会無いよ……奥様がっかりレーザー （通称：グラディウスレーザー）に使えるぐらいかなぁ。
BricksOSのソースは非常に読みやすかった。頭の中でうっすら設計していたもの がそのまま具現化されていたようにすら思える。なじむ、実に馴染むぞ！ Linux 2.6 for MMU-less ARM Projectなるものを見つけてしまったので取り合え ずパッチ内容をパッチ形式のまま生で読んでみたものの、一瞬で挫折した。当て て読もうかとも思ったけど、スレッドが欲しいだけなのに脱線が過ぎるので、あ、 スレッドもそんなに欲しくは無いんだった、まぁとにかく深追いは止めました。 根性無しですいません。
特に何か必要があってというわけではないのだが、長い時間かけて重い処理をし ている間に他の何かをやるーみたいな、ずばり PS 版リッジレーサーのローディ ング画面みたいなことをやってみたいというか、GBシレン２のマップロード中に 歩き回るイタチとか、セーブ中にロボが踊るマリオペイントでも可。 例を挙げたらキリが無いので、陳腐なシューティングをリアルタイムに動かしつ つ、裏でライフゲームを動かす場合を考えてみる。 簡単に実現するには、VBLANK割り込みで画面更新しつつゲームループを回して、 メインループでライフゲームを回してっと……。簡単すぎるなぁ。これはこれで 有効だけど、メインループでゲームループを回しつつ、重い処理をしてみたい。 タイマ割り込みをトリガーにしてコルーチンを回し、リアルタイムで切り上げれ ば、取り合えずノンプリエンプティブっぽい処理は出来そうか。ライフゲームの セル一行ごとに co_resume(); で……。ライフゲームは単位時間がほぼ一定だか ら、割り込み間隔の調整も楽だな。 しかしいちいち手動で処理を返さなきゃいけないのが気持ち悪いなぁ。やっぱり スレッドしか無いかな。というわけで JaysOS とか BricksOS のソースを読んで みたり。
一時期61キロ台まで行ったのはなんだったんだ……というか最近ストレスを間食 で発散してるのでよくない。無駄食いしたら減らんよね。
１ヶ月ほど連続して使っているとエクスプローラやデスクトップの挙動が不審に なり描画が乱れ、他のソフトも体感できるほど動作が重くなる。なんなのだろう と不思議がっていたところ、たまたまタスクマネージャを見てみたら、GDIリソー スのリークが原因っぽかった。特定のアプリケーションを長時間表示していると描画が乱れる (WindowsのGDIオブジェクトを大量に消費する) 「"GDIオブジェクト" の値が約9000近くになると、 Windows の描画が乱れるよ うになります」の辺りなどそのまんま。自分の場合ASTEC-Xじゃなくてexplorer だけど。 問題は何のアプリが原因なのか、だけど、１日中（どころか１ヶ月の間）ずっと 起動している某人気ブラウザがあやしいのではないかと思っている……はっきり しないので伏せておくけど。使用をやめるか、ソースを追って直すか、どちらも 無理な話なので、諦めて不具合と付き合うことになるなぁ。
２年近くホイールが壊れたままで何の不自由もなく暮らしていたのだが、3Dモデ リング・レンダリングツールを物色してみたら、拡大・縮小が軒並みホイールに マウントされているので、これはちょっと不便だなと思うようになった。 Firefoxのカーソルスクロール量を変更するために SuperScroll を利用していた のだが、更新が途切れて久しく、Firefoxアプデートのたびに index.rdf を書き 換えたものをインストールし直すのが面倒なのもあり、 Yet Another Smooth Sc rolling に乗り換えることにした。スクロール量が変更できるだけでなく、動作 も滑らかになって、とてもいい感じだ。 縦だけじゃなく横のスクロール量も変更できるといいんだけどな……。
最近気づいたことがある。量る直前に食べた分がダイレクトに体重計に反映され ているということだ。今夜は豚汁をどんぶり二杯食べた。 ひょっとしたらベース体重は変わってないのかもしれないな。
あ、どうもです。感動して勝手に作っちゃいました。
……今気づいたのですが転載については規定がありますが使用についてはその規定が当てはまらないんですね。
ここでネタにする前に、先にお伺いを立てるべきでした。すみません。 (2007/12/27 12:34:14)
ちょっとビビリすぎてたかな。実はまだビビってたりしますが。
ところで、追加でグラフィック描いたりしませんか？
モグラ型重装甲車とか欲しかったり^^; (2007/12/28 16:41:56)
kitsuneさんは技術部の方ですよね？あの動画にはおおいに発奮されました。
クリプトンの件は、取り合えず頒布を考えずに突っ走って、区切りが見えたらそのとき考えようかなと思います。
シガタケさん、メールお送りしました。どうぞよろしくです。 (2008/01/02 00:47:10)