考えるとか書いてるけど何も考えてません。 本来奥にあるはずのスプライトがラスタブロックの境目で手前に表示されてしま うという問題。なんとかしなきゃな……。
ありがちなSTG戦車を、土台を親、その上に砲台を子として設けてみる場合で 考えてみたい。構成要素はとりあえずこんなもんで。 (1) 移動するのは土台 (2) 土台は砲台が生きている間、弾に当たらない(親:ヒット属性の変更) (3) 砲台が死ぬと、土台はゆっくり停止する(親:移動スクリプトの変更) (4) 砲台は常に土台の真上に位置する(子:表示座標の相対・絶対) (5) 土台は移動方向に回転表示 (6) 砲台は射撃方向に回転表示 この中で親子関係を持たせて活きるのは2・3・4なわけですが……。 (4)は子が親を参照するだけなのでいいとして、(2)と(3)は親が子を参照する とか、子が親にメッセージを送るとか、あるいは子が親を直接書き換えるとか、 なんにせよ親をどうにかしないといかんわけです。 で、えーと、なんか色々考えてたんだけど言葉にするのも最小限のコード例を抜 粋するのもめんどくさいのでそのうち続きを書く(多分書かない)。とりあえず、 いろんな実装が見てみたいなーということが言いたいんです。どっかに無い?無いか。以前、ネタで三重マッドボールを作ってみたら、結構大変だった。外側の砲台を 破壊したときは内側の連絡橋も同時に壊れなくちゃいけなくて(逆に、連絡橋を 先に壊しても外側の砲台が壊れる)、本体→連絡橋→砲台→砲台同士の連結橋と いう順番で親子関係を持たせてみたらコードが滅茶苦茶になった記憶がある。け ど、どう滅茶苦茶だったのかは忘れた。(オイオイ) 確か、外から順番に壊す 分には大丈夫なんだけど内側の本体を真っ先に破壊すると、子供が変なところを 参照してぐだぐだになったような。まぁどうでもよい話です。
http://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=20080127 エラーメッセージは以下の通りなので、キャストすれば通るとして……error: conditional expression between distinct pointer types `ChildA*' and `ChildB*' lacks a castちょっとコードを変更してみる。としたとき、結果が……class Parent { public: virtual ~Parent() { printf("~Parent\n"); }; }; class ChildA : public Parent { public: virtual ~ChildA() { printf("~ChildA\n"); }; }; class ChildB : public Parent { public: virtual ~ChildB() { printf("~ChildB\n"); }; }; Parent* doit(int n) { return (n & 1) ? reinterpret_cast<Parent*> (new ChildA()) : reinterpret_cast<Parent*> (new ChildB()); } int main() { Parent* pa = doit( 0 ); // ChildBが返ると思うんだ ChildA* ca = reinterpret_cast<ChildA*>(pa); ChildB* cb = reinterpret_cast<ChildB*>(pa); printf("Parent pa:%p\n", pa); printf("ChildA ca:%p\n", ca); printf("ChildB cb:%p\n", cb); delete ca; pa = doit( 1 ); // ChildAが返ると思うんだ ca = reinterpret_cast<ChildA*>(pa); cb = reinterpret_cast<ChildB*>(pa); printf("Parent pa:%p\n", pa); printf("ChildA ca:%p\n", ca); printf("ChildB cb:%p\n", cb); delete cb; return 0; }ふおおお、爆発する! C++ が爆発する! そんなの当たり前だろと言われそうだけどちょっと感動した! しかしこちらも、結局、中で何が起こって解決されてるのか分からない。 今度はポインタの指している値も一緒だし。 まぁ、いいか……。Parent pa:0x2000010 ChildA ca:0x2000010 ChildB cb:0x2000010 ~ChildB ~Parent Parent pa:0x2000010 ChildA ca:0x2000010 ChildB cb:0x2000010 ~ChildA ~Parent
http://alohakun.blog7.fc2.com/blog-entry-891.html http://d.hatena.ne.jp/kmaebashi/20080121 おぉーなるほど。 とか言って、実はまだイマイチ分かってなかったり。 C から B にキャストした b を delete したときも、結局 ~C, ~B, ~A の順番で デストラクタが呼ばれるなら、中身は一緒でいいんじゃないの?なぜポインタを 変える必要が?と思ってしまうのでした。 なんつーか、vtblがあるからってことは分かっても、そこから先で具体的に何を してるのかってのが、いまいち想像できない。 想像できないなら答えを見ればいいじゃん、というわけで、メモリを覗くことで 表層から強引に理解してみようかと。理解出来たらいいなーくらいの気持ちで。 -- 先に書いておくと、アサッテの方角へ向かって無駄な努力をした挙句に 結局なにも分からなかったので、というか何が分からないのかすら分から ない状態になったので、理解済みの人は、 Ctrl-W をおして下さいね! -- casttest.gbaを実行して、エミュレータのデバッグログから *a と *b を得る。 (VisualboyAdvance の Tools → Logging)で、nm と map の出力を併せて読むと、ここらへんか。CTOR A CTOR B CTOR C c:0x2000010 b:0x2000014 a:0x2000010 DTOR C DTOR B DTOR Aとりあえず A の方を制覇していこう。 _ZTV1A こと vtable for A は……08010a84 V _ZTV1A 0x10 vtable for A 08010a94 V _ZTV1B 0x10 vtable for Bもう A::~A() が登場しちゃったよ。早くね? でも無視して _ZTI1A こと typeinfo for A を見て行く。08010a74 V _ZTI1A 0x8 typeinfo for A 0800f830 W _ZN1AD1Ev 0x18 A::~A() 0800f848 W _ZN1AD0Ev 0x24 A::~A()なので……名前マングリング・ベイのアホー。 やたら長い名前の方は libstdc++.a(tinfo.o) から持ってきているのか。 無視して _ZTS1A を……っと、中身は 0x4131 と書いてあるだけだった。 やったー! A の終着点ですよ! でも、この数字が何を意味しているのかは想像できません!(当たり前だ) 巻き戻って vtable for B を追ってみる……08010b38 V _ZTVN10__cxxabiv117__class_type_infoE 0x2c vtable for __cxxabiv1::__class_type_info 08010a7c V _ZTS1A 0x4 typeinfo name for Aしかるのち08010a68 V _ZTI1B 0x8 typeinfo for B 0800f86c W _ZN1BD1Ev 0x18 B::~B() 0800f884 W _ZN1BD0Ev 0x24 B::~B()で _ZTS1B は…… 0x4231 ですね!やったー! ついでに _ZTS1C は 0x4331 でしたよ!やったったー!るんぱっぱー! あぁ……たぶん __cxxabiv1::__class_type_info で何かしら解決してるんだろ うけど……。ごめん。もう限界だ。さようなら。08010b38 V _ZTVN10__cxxabiv117__class_type_infoE 0x2c vtable for __cxxabiv1::__class_type_info 08010a70 V _ZTS1B 0x4 typeinfo name for B
http://d.hatena.ne.jp/Isoparametric/20080124/1201185062 test.cpp: In function 'int main()': test.cpp:28: error: 'printf' was not declared in this scope へー。printf() はぶるちん関数じゃないんだ? ってのはどうでもいいとして…… c:003D3E78 b:003D3E7C a:003D3E78 へー。多分vtblの絡みなんだろうけど、しかし何故 b だけ違うアドレスになる んだろう。むしろ、 a と c のポインタが同一であることに注目するのかしら。 デストラクタのアドレスが取得できれば一発で理解出来る気がするけど、取り方 が分からなかった。というか取れないのか……。ふむ。
http://shinh.skr.jp/m/?date=20080126#p01 gnome-volume-controlやらを起動すると、それまで使っていたfirefoxのメニュー フォントが突然大きくなる現象を思い出した。あれはgconfが有効になるからだっ たのかな。 7.04 から xscreensaver がリポジトリから外され、代わりに gnome-screensaver を使うようになったら、この現象は目にしなくなった。 どうでもいいけど window shade ってどんなときに必要なんだろうか。個人的に は、タイトルバーをダブルクリックしたら最大化する方がよほど便利なのだけど。 6.10 のときは自前でコンパイルして入れたから、ついでにダブルクリックで最 大化するように修正したのだけど、7.10 だと リポジトリに入っちゃってるもん だからそっちを使っちゃってるもんだからウインドウがシェードしちゃってるん だもんだから、微妙に使いづらい。 ~/.fluxbox/init に設定項目つけて shade と maximize を切り替えられるよう に作り変えたら採用されるかしら。
http://www.success-corp.co.jp/blog/index.php?itemid=74 へー、ライデンファイターズってフルアセンブリだったのか。386のCPUパウワー を持ってすればCでも余裕だろうと思っていたけど、そうでもなかったのかしら。 ひょっとしてリアルモードで動いてたのかしら。 へー、Unreal Modeなんてあったんだ。ちょっと386触りたくなってきたな……。 TOWNSの開発環境をうんづで再構築してみるべか。
中途半端な出来だが音も鳴るようになり、タイトル画面とオプションメニュー、 そしてゲームオーバーも実装した。あとはゲームクリアを実装して、データ的な クオリティアップとバグ退治、そして面構成か。 面構成なー。どうしたもんだか。悩んじゃうわね。誰でも編集できるようにして あれば悩み無用なのだろうけど、現状、コンパイラが必須だからなー。
PSGに対応した似非MIDIドライバのソースがいつぞやの事件の余波で消えていた。 今頃になって判明するなんて。ガックリ。対応前のソースが発掘できたので組み 込み。 そんでもって、SEを作っていた。 爆発音とともに断末魔を入れるのだが、も、も、モグラの鳴き声ってどんな…… というか、そもそも鳴くのか? 鳴き声が分かったとして俺に作れるのか?擬音 でやってしまうか?キュイキュイ鳴くのか?俺が鳴くのか?あンた、背中が煤け てるのか?
4枚のBG全てを使い切っているのでどうしようかと一瞬考えたものの、結局スプ ライトで作ってしまった。やっぱりスプライトですよ。もうねえ、大変ですよ。 perl やってて split が sprite に見えてきますし、boost::spirit も sprite に見えてきますから。三ツ矢サイダーなんか持ってこようものなら、スプライト と言いますよ、わたしゃ。あとね、えーと。うんとね、すいません、もう思いつ きませんでした。
動画撮ってみました。(WMV 60fps) 前回の動画に比べると、背景の描き込みが詳細になり、ミクもアニメーションす るようになり、敵バリエーションも増えて、見栄えが良くなったのでは無いかと 思います。シガタケさんがリファイン素材を提供してくださいました。個人的に お下げのフリフリが嬉しいんですよねぇ。ふりふりと。 動画では前後のフレームを半透明合成して点滅時のチラつきを抑制しています。 実機でも残像が残ってこういう風に見えるので、それの再現風味ですね。 普通の人は、エミュレータでしか遊ぶ手段を持っていないと思いますが、エミュ レータにもモーションブラーを掛けるフィルタ機能がついているのでチラつきを 前提に作っても支障は無い感じです。 しかし、そもそもチラつかないように作るべきなんですよねぇ。なんていうか、 スプライトを過剰に出せること自体が嬉しすぎて、ついやりすぎてしまうので、 そろそろ抑制することも覚えるようにしないといかんですね。
先週は殆ど手をつけられなかった。今週は少し時間を回したい。 残っている作業を思いついただけ箇条書きしてみる。 ・シーン切り替え(タイトル、ステージ、オーバー、クリア)と、それに伴う 画面エフェクト作成 ・アイテムジェネレータの差し替え ・アイコンの書き換え、差し替え ・道中を真面目に考える ・出せるだけスプライト出せばいいんだろ?みたいなエフェクトばかり作って しまうので何か代替手段を考える ・おトイレ、アレンジ、効果音編集 必要な要素はおよそ再現しおわったけど、再現しただけじゃ芸が無いよなー、と 思い中。エフェクトや難易度なんかは絵柄に合わせるべきか。 そう考えると音源もネタを絡めたアレンジが必要かなぁ。しかし、ロイツマとか どうやって絡めたものだか。書き下ろしちゃうのも手かなぁ。 プレイヤーの視線移動を考えると、必要な情報は敵だかアイテムだかに近い位置 に出すべきなんだよなー。自機のソバに置いたのでは、いちいち見てられない。 しかし適切な表示位置が思いつかない。
なんか出てきたのでアップ。 ♪ DARWIN 4078 - start 〜 bgm1 PMDソース 頼まれて作った耳コピーもの。割とそのままかな。元がOPLで太い音なのに対し、 こちらはOPNAなので若干細いか。音源クロックの都合で少し音程が高いです。 MMLをつけたので、誰かBGM2とBGM3とGAME OVERとNAME ENTRYを作ってください。 デコ祭が始まるよ。 ♪ GALAXY FORCE II - Beyond the galaxy PMDソース FM TOWNS版のハウスアレンジを、更にPMDPPZにコピーアレンジしたもの。 SEGA AGES 2500シリーズ Vol.30 ギャラクシーフォースII へのTOWNS版アレンジ 収録を祝うべく発売日あわせで用意していましたが、内蔵音源ともDA音源とも つかない中途半端な出来になったのと、あと、そもそもお祝いにならないような 気がして、お蔵入りに。 MMLをつけましたが見ない方がいいような気がします。 ♪ AFTER BURNER II - AFTER BURNER (最初のサビまで) まだAB2のサントラを持っていなかった頃、雑誌投稿や草の根BBSのコピー作品を 聴いたり、様々な情報を総合して、アーケードの音源を妄想したもの。しょーも ない音源ですね!
http://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=20080120 やばい、まさにナウ、今から、「なんとなく」でmallocのせいにする日記を書く 所だった。全然面識のない方なのに何故バレたんだろう。(ヒント:単なる偶然) 先日コルーチンで敵ジェネレータを作ったが、その際、敵を生成する瞬間ハング アップするのでスタックサイズを増やして対処した。 で、そのスタック領域を確保するときにmallocを使ってたわけで、つまりコルー チンからコルーチンを生成するときmallocがコールされてたわけで、コールして チーンなわけで、mallocがスタック喰いまくってたに違いないと。(敵ジェネレータ生成直後:赤い部分がスタック領域)
(敵ジェネレータが敵を生成した直後) そんでもってmallocの代わりに自前の配列プールを使うことにし、コールチーン 的には一応解決したものの、一応mallocの動きを調べてみても損は無い気がした ので、newlibを落としてきて malloc でgrep。ひたすらgrep。
で、_malloc_r はnewlib/stdlib/malloc.c(191): _DEFUN (malloc, (nbytes), _PTR _DEFUN (malloc, (nbytes), size_t nbytes) /* get a block */ { return _malloc_r (_REENT, nbytes); }で、 mALLOc はnewlib/stdlib/mallocr.c(1002): #define mALLOc _malloc_rmALLOc だけでかなりスタック消費してそうな感じだけど一応先に進む。 で、malloc_extend_top はnewlib/libc/stdlib/mallocr.c(2319): Void_t* mALLOc(RARG size_t bytes) Void_t* mALLOc(RARG size_t bytes) { ... remainder_size = long_sub_size_t(chunksize(top), nb); if (chunksize(top) < nb || remainder_size < (long)MINSIZE) { ... malloc_extend_top(RCALL nb); ...で、MORECORE はnewlib/libc/stdlib/mallocr.c(2132): static void malloc_extend_top(RARG INTERNAL_SIZE_T nb) static void malloc_extend_top(RARG INTERNAL_SIZE_T nb) { char* brk; /* return value from sbrk */ ... brk = (char*)(MORECORE (sbrk_size)); ...で、_sbrk_r はnewlib/libc/stdlib/mallocr.c(304): #define MORECORE(size) _sbrk_r(reent_ptr, (size))で、_sbrk はnewlib/libc/reent/sbrkr.c(52): _DEFUN (_sbrk_r, (ptr, incr), void * _DEFUN (_sbrk_r, (ptr, incr), struct _reent *ptr _AND ptrdiff_t incr) { char *ret; void *_sbrk(ptrdiff_t); ...と。ようやく終点に辿りついた。 こんなに入れ子してたらそりゃスタック食うよなぁと思いました。 ん、ちょっと気になるところが……libgloss/arm/syscalls.c(591): _sbrk (int incr) caddr_t _sbrk (int incr) { extern char end asm ("end"); /* Defined by the linker. */ static char * heap_end; char * prev_heap_end; if (heap_end == NULL) heap_end = & end; prev_heap_end = heap_end; if (heap_end + incr > stack_ptr) ...へぇ、こうすれば C からスタックポインタ参照出来るんだ。おもしろ。/* Register name faking - works in collusion with the linker. */ register char * stack_ptr asm ("sp");
一応覚えておこう。 VALUE DOMAINで年間12,000円弱かぁ。 ネタで取得して腐らせるには微妙な値段……。
MP4/H.264で投稿できるらしいので登録してみた。 動画サイトじゃなくて動画SNSなのね。動画をアップロードしておしまい、では なく(少なくとも表向きは)日記をつけて動画を追加するという形式なので精神 的に面倒くさいかな。 うーん、mp4でアップしてもそのまま使われるわけじゃないのか。 ローカル* Movie Info * Timescale 600 - Duration 00:02:36.671 Fragmented File no - 2 track(s) File Brand avc1 - version 0 Created: GMT Sun Jan 13 23:04:49 2008 File has root IOD Scene PL 0xff - Graphics PL 0xff - OD PL 0xff Visual PL: AVC/H264 Profile (0x15) Audio PL: No audio capability required (0xff) No streams included in root OD Track # 1 Info - TrackID 1 - TimeScale 240000 - Duration 00:02:36.673 Media Info: Language "Undetermined" - Type "vide:avc1" - 9392 samples MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21 AVC/H264 Video - Visual Size 320 x 240 - Profile High @ Level 5.1 NAL Unit length bits: 32 Self-synchronized Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 00:02:36.501 Media Info: Language "Undetermined" - Type "soun:mp4a" - 3668 samples MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40 MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 24000 - SBR SampleRate 48000 Synchronized on stream 1zoome* Movie Info * Timescale 600 - Duration 00:02:36.721 Fragmented File no - 2 track(s) File Brand isom - version 1 Created: GMT Mon Jan 14 12:38:59 2008 File has root IOD Scene PL 0xff - Graphics PL 0xff - OD PL 0xff Visual PL: AVC/H264 Profile (0x15) Audio PL: AAC Profile @ Level 1 (0x28) No streams included in root OD Track # 1 Info - TrackID 1 - TimeScale 30000 - Duration 00:02:36.723 Media Info: Language "Undetermined" - Type "vide:avc1" - 4697 samples MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21 AVC/H264 Video - Visual Size 320 x 240 - Profile Main @ Level 3 NAL Unit length bits: 32 Self-synchronized Track # 2 Info - TrackID 2 - TimeScale 44100 - Duration 00:02:36.595 Media Info: Language "Undetermined" - Type "soun:mp4a" - 3372 samples MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40 MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 22050 - SBR SampleRate 44100 Synchronized on stream 1(ありゃりゃ、ローカルは High Profile でエンコしてた……) 60fpsが30fpsに落とされてる。まぁFlashでは再生厳しいだろうからいいけど。 映像の方は事前にブラーかけて30fpsへ落としておき Main Profile で、音声は 44,100Hzにダウンコンバートして AAC LC か。 ていうか、向こうで勝手にAVCにエンコしてくれるから気にせず無圧縮AVIを垂れ 流しても構わなかったりするのかしら。 イチカシのタグがあった。熱いなぁ。 http://www.zoome.jp/diary_tag_diary_list?q_tag=%BB%D4%CE%A9%C7%F0
DSLiteを借りてGBAモードで実機チェック。ものすごい残像っぷりに目眩がして きた。GBAだけならともかくDSも一応視野に入れると、もっと弾速を下げないと 駄目だなぁ。 デジカメに動画モードがあることを思い出し、比較用にGBMicroとDSLiteの両実 機を撮ってみたのだが、操作しながらだとどうしても顔が映りこんでしまう。 困る。
アイテム関連、パワーアップ演出、自機ダメージ等を実装。ダメージが入った事 により、単なる技術デモからクソゲーへと昇格する。テストプレイをするときも 緊張感が出てきた。しかしまだ全然遊べたもんじゃないです。 アイテム入れたら画面がえらく見づらくなった。なんとかしたいところ。 パワーアップは……現状だと弾数=攻撃力なので、自機を強くするには弾をたく さん出せばいい。しかしそうするとスプライトを増やすことになって……。逆に ノーマル状態の弾数を減らすと、見栄えが寂しい。攻撃力だけを増やす方向だと パワーアップしていることが分からん。 強さを何とかしないと敵の固さも決められないので、とりあえずは弾数を微調整 する方向でカバーするか。
スプライトのPCGパターン数が512枚を超すと sp_sort() が無限ループするので 直すように。……超連射GBAでは 1900 枚登録しても問題無いんだけどなぁ。 追記:直した。
小回りも効くしすげー楽だ。もうコルーチン無しで生きて行くことは不可能だよ。
一枚絵から矩形パターンを切り出して、 そのパターンを複数並べてフレームをつくり、 更にそれらのフレームからアニメーションを作り、 あと、フレーム内でコリジョンも複数設定出来たりしちゃって、 最終的にXMLとかYAMLで出力する。 (更にXMLとかYAMLを、CLIツールで処理してソースにする) みたいなツールが欲しいですヨ!オイラは。
ポインタの配列が int *hoge[]; なら、ポインタの配列のポインタの配列は int *(*fuga[])[]; になると思うんだけど……。で、それを外から参照していくと fuga[] // ポインタの配列のポインタ *(fuga[]) // ポインタの配列 *(fuga[])[] // ポインタ *(*(fuga[])[]) // 実体 になるよなぁ。 ここまで考えたところで脳がショートしたため、ポインタテーブルのポインタテー ブルを作るのを諦め、ダサいけどコードに直接ポインタを記述することにしたよ。
スプライトが横並びしまくって欠ける現象が起こりまくってるのでなんとかする。 具体的にはレーザーを間引きして……ううぅ。それでも足りなかったので、スプ ライトサイズを調整。今まで全て16x16で表示していたのを、8x8で収められる物 はそのようにアトリビュートとパターンを変更するようにした。 あれ、でも 16*64 = 1,024 < 1,210 だから欠けるはず無いよな……と思ったら、 いつの間にか DISP_HBLANK_OAM_FREE を立ててた。そりゃ上限954なら欠けるわ。 きっちり70ドット分消えてたわよ。 ※ DISP_HBLANK_OAM_FREE: REG_DISPCNT の bit5 libgbaでは定義されてないので勝手に名づけました
体重とチップというわけで、続きを書かれていてビビった。すごいビビった。せっかくなので 自分の取った方法も書いておこうかしら。 16x16のチップを上下左右反転したパターンでそれぞれCRCをとり、逐一線形検索 をし、ヒットしなければstd:vectorに突っ込みそのままindexにするという、至極 愚直な戦略を取りました。 CRC32を選んだのは、4bitインデクスカラーで縦横のsumを取ると全然関係ないパ ターンに誤爆しそうな気がしたのと(もちろん気がしただけでテストしてない)、 比較が一瞬なのと、あとCRCそのものとは関係ないけど上下左右で取っておけば比 較に引っかかったときHVFLIPパラメータも一緒に得られて楽だったから、という。 sumと比較した上でCRCを取るという戦略を取ればよかったのかな。 類似に関しては自分としてはOPTPiXのキャラクタ圧縮相当の機能を想定していた のだけど…… それで結局どうしたかというと…… …… 人力で調整してカバーしたという。(すんませんこんなオチで)勝手に続きを書く。チップが類似していることを判別するアルゴリズムはどうしたかというと…… …… 続く。(多分続きません)
BG1枚を複数の用途で使うために、VCOUNT割り込みを複数任意の位置で発生でき るようにする。 最初は、割り込み先をラッパーで包んで分岐しようかと思ったけど、スプライト ダブラの転送開始タイミングが結構シビアなので、ダブラの方で割り込みタイミ ングとジャンプテーブルを管理することにした。 これでモンスターワールドIVの1画面多重スクロールとか、シャドウオブザ(中 略)と同じことが出来るようになったんだぜ。こーいうことをやるとラインバッ ファなゲーム機を触っているという実感が凄く沸いて嬉しいし、楽しいのだった。
三が日は吐きそうになるほど食べまくった食べさせられた食べざるをえなかった ので、こりゃ太るだろうなーと思ったのに、何故か痩せていた。帰省で精神的に 疲労したから脳の方で消化してくれたのかしら。
BGMとSEを作り始めた。 おトイレ……もとい音入れは、本当なら最後にやるべきなんだけど、スプライト ダブラと同時にサウンドドライバが正常動作するのをテストしておきたかった。 負荷チェックと、あと、あまり大きな声では言えないけど自分のコードの信用の ならなさは異常なので。 ちょっぱーゴリゴリのドラムがどかーんでハモンド兼オケヒコーラスがちょわー バッキングギターがぶりばりー。効果音が2音追加でPCMは合計6音。ほんでDMG 音源でメロを慣らして、負荷が18〜19%くらいか。ちょっと弾幕は厳しめかな。 まぁどうしてもヤバかったら音質下げればいいか。
帰省していた。 教育方針により分別が付くようになるまで息子にゲーム機を買い与えないつもり だったらしい親戚が、スーパーマリオくらいはやらせてもいいかと思ったらしく 「あンた持っていたわよね」という話になったので、ファミエイトを購入しソフ トと共に持って行く。 そういう経緯で初めてゲーム機で遊ぶ子供のプレイをジラジロ見ていたのだが、 なかなか興味深い。(プレイしたのはマリオ3) まず、必要な場所で左に進めない。左右キーの使い分けにまだ身体が慣れていな いのと、右に進みたい気持ちが強いのと、で、簡単に罠に引っかかってしまう。 1面最後のノコノコを踏んでそのまま右のブロックに乗り、そして進むと、土管 の手前に空いた1マスの穴に、ジャンプする間もなくスッポリと落ちてしまうの だった。ことごとく落ちては、ケラケラと笑っていたよ。 次に、Bダッシュ出来ない。2ボタンの使い分けどころか、そもそもBを押して いない。ボタンと指の配置が ⊂ じゃなくて ∪ なので、両方同時に押すのは無理がある。1面中盤にある大穴にあと一歩という ところで吸い寄せられるように落ちて行くのを見ては、カプカプと笑っていたよ。 マリオシリーズの他に持って行ったソフトも、左右移動とボタンジャンプのプラッ トフォームスタイルばかりだったのだが、この子にはまず上下左右へ自在に動け Aボタンで弾が撃てるシューティングをさせるべきだったのだ、と思うのだった。 指を慣らす必要がある。 スターフォースから始め、ゆくゆくはバトライダー上級を全ボスALL出来るように まで仕込……いやなんでもないです。
Hello webmaster
I would like to share with you a link to your site
write me here preonrelt@mail.ru (2009/03/05 03:37:55)