ゲム部(20050618開設！)

AOC大会用

2008-09-19T00:32:50+09:00

＊２年越しのAOC大会 ---- 軽音旅行で持ち上がったこの企画･･･今週はやらないのかっ！！文責：chun ---- - 今週っつか明日だけどね。 -- chun (2008-09-18 21:00:08) - 明日何時だっけ？ -- 赤毛 (2008-09-18 23:50:51) - ９時とかだったっけか？あんま覚えてないや。そもそも誰がいけるんだったっけか？ -- chun (2008-09-18 23:56:44) - 急すぎてインストールも何もできてないぞ -- 邑 (2008-09-19 00:32:50) #comment

Diablo2

2007-02-08T21:58:16+09:00

DiabloIIはここか！

メニュー

2007-02-08T21:57:35+09:00

*メニュー -[[トップ]] -[[メンバーリスト]] -[[Diablo2]] -[[AOC大会用]] [[メニュー]] 左のメニューの編集はここから **更新履歴 #recent(5) **ゲム部 -[[ゲム部]] -[[パンヤ用]] -[[巻き毛杯]]

トップ

2006-06-19T08:39:31+09:00

|COLOR(ff0000): †ゲム部†| 何もないとこですが、くつろいでってくださいなー。各自が新規ページ作ったり、ページ編集したりできるようにもしてますんで、おもちゃとしてご利用ください(ﾟ∀ﾟ) 今んトコ、トップとメニューは編集できないようにしています。ご理解をば。ほんとに何もないのでアレなんで、次の大会の日程調整とかにココを使ってはいかがでしょうか？ AOCのページやらこのトップやら、どこかからリンクがががなんでしょうなー。ま、いいですか。 ---- - ここに適当にコメントいただけると喜びます -- 赤毛 (2005-06-18 08:27:06) - こんな感じで。 -- 赤毛 (2005-06-18 08:27:27) - ヽ(´ー｀)ノ -- mugi (2005-06-18 12:52:17) - なるほどね。さあ喜ぶがいい -- izawarz (2005-06-18 14:56:33) - ﾜｰｲヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノﾜｰｲ -- mugi (2005-06-18 15:03:36) - ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!! -- 赤毛 (2005-06-18 18:24:22) - あんま来ないなあ -- mugi (2005-06-19 01:45:27) - なんだここ！？(；･`д･´) -- chun (2005-06-19 01:54:10) - こっこんちわー、始めて来ました。頑張って下さい！ -- gort (2005-06-19 17:50:52) - 宣伝しといてねー。 -- mugi (2005-06-19 22:52:11) - にゃは、来てみた、なんかすごげ。 -- kuroneko (2005-06-20 01:14:00) - ほうう -- naga (2005-06-20 22:05:48) - 大会用のページを作成したので見ておくように。 -- chun (2005-06-25 02:42:56) - GJ!!皆もこんな感じで適当に使っておくれば -- mugi (2005-06-26 00:58:52) - おまいも投票しる！＞mugi -- chun (2005-06-26 01:34:56) - ↑メニューに追加したよ。 -- mugi (2005-06-26 17:23:17) - Thx! -- chun (2005-06-27 09:01:03) - ┣¨┣¨┣¨ ε=( ┌┌┌´ﾟ,_｣ﾟ)┐<ﾋｬｯﾊｰ -- akage (2005-06-29 04:47:56) - ﾜｯｼｮｲﾜｯｼｮｲヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノﾜｯｼｮｲﾜｯｼｮｲ -- のだ (2005-06-30 04:45:33) - 巻き毛杯！？見るしか！ -- mugi (2005-06-30 06:03:39) - 自演乙～ -- izawarz? (2005-06-30 08:29:17) - 自演乙 -- chun (2005-06-30 12:01:32) - じゃもういいです。 -- mugi (2005-06-30 22:17:55) - イース最新作ｹﾞﾄｰ　あれ？関係ないですかそうですか -- 赤毛 (2005-07-01 18:09:44) - (≧∇≦)b ｲｲﾈ!! -- mugi (2005-07-01 21:03:55) - どうも。お初です。パソコン買い換えるの、だいぶ先になりそうです、残念。＞イザ＆邑さま -- 渋近 (2005-07-02 12:36:33) - 誰だｗ -- 邑 (2005-07-03 00:43:05) - 整理しようかね -- mugi (2005-08-02 16:00:31) - 整理とゆーと、コメントログ消しますか？ -- 赤毛 (2005-08-03 01:04:26) - さりげに一周年ですね～ -- noda (2006-06-19 08:39:31) #comment(vsize=2,nsize=20,size=40)

GG

2005-09-07T07:36:56+09:00

*GGまとめ ---- **趣旨 GG(GenerationGap)を調査してみる。 ---- **項目（）内は模範解答 -ミニ四駆の漫画(ダッシュ四駆郎) -ゾイドの人を見せてみる(あ～これなんやったけ…ZOIDEや！) -ライダーのバージョン(BLACKRX) -漫画の名台詞(クリリンのことか) -漫画の名効果音(ズギュウゥ～ン、ざわ…) -おじさまが盗んだとんでもない物() -特撮もののバージョン(宇宙刑事シャリバン) -ウルトラマンのバージョン(セブン) -戦隊もの(太陽戦隊サンバルカン) -ゴジラの敵(ビオランテ) -最強の宇宙怪獣は(メトロン星人) -流行った小技(牛乳瓶のフタ) -クイズ番組(なるほど・ザ・ワールド) -アニメ番組(ドラゴンボール) -お笑い番組(カトちゃんケンちゃんごきげんテレビ) -金曜ロードショー(風の谷のナウシカ) -最初にやったゲーム(シティコネクション) -最初にはまったゲーム(Wizardry外伝2) -ゲームの裏技(ドラミちゃ～ん、ドラえも～ん) -最初に買った単行本(ドラゴンボール６巻) -定期購読していた雑誌(ジャンプ等選択制) -親にねだった物(ZOIDE、LEGO、ハイパーダッシュモーター) -脳内にこびりついて取れないアニソン(CHA-LA HEAD-CHA-LA、スターダストボーイズ、ユリア…永遠に) -Windowsのバージョンの経歴(98-ME-XP) -最初に自力でコンプした漫画(YAIBA) -子供心に響いた映画の名台詞(竜の巣だ、受け取れ勇者よ、スイカ頭～) -心に響いた映画の名シーン(T2の溶鉱炉、エイリアン２のラストのエレベータ、ジェダイの帰還の最後) -何度見ても飽きない映画(ジェイソンNYへ、T2、天空の城ラピュタ) -ドラえもんの秘密道具(ウマタケ、ウソ800) -のび太の？(恐竜、日本誕生) -給食の定番の献立(メルルーザの蒲焼) -最初に見たドラマ(フルハウス、家なき子、ひとつ屋根の下) -世にも奇妙な物語(ロッカー、自殺悲願、誘い水) - ---- 補完よろ ---- #comment

ゲム部

2005-08-08T23:49:25+09:00

*開発日誌的にちょろっと（05/08/08）　テクスチャをキャラクタ基底クラスに持たせた場合、派生クラスが生成される段階（つまり対戦開始時）でテクスチャをロードすることになる。といっても試合開始前にロード時間を設ければこの問題は回避されると思ったが、たとえば試合中に生成する必要のあるオブジェクト（波動とかソニックとか）、これらは生成されると同時にテクスチャをファイルから読み込むことになるのだがこれはいかがなものか。おそらく試合中にファイル読み込みなどやってはいけないと思われるので、となるとこの「テクスチャを基底クラスに持たせる」案が微妙になってくる。試合開始前に試合中に使われるであろうオブジェクトはすべて生成して待機状態にしておく、という回避策が考えられるがそれはメモリの無駄遣いではなかろうか。　かといってグローバル領域に大量のテクスチャを置いておくのも余りエレガントとは言えない気がする。構造体にまとめてしまえばそれでいいとは言えるのだろうが。　あ、ちょっと待てよ。そういえばシューティングの時は気にしてなかったが、例えば波動などの飛び道具はこれは当然キャラクタ基底クラスの派生クラスとして存在するのだろうが、これは誰が管理するのだろう？生成を行うのはプレイヤなのだから、この場合リュウクラスが波動クラスを所持していればよいのでは？こうすればリュウクラス生成時に同時に波動クラスが生成され、必要に応じて画面に表示させたり判定を出現させたりすれば…いや駄目だ、結局波動クラスはリュウクラスと同じライフサイクルを持つことになり、波動が出てないのにオブジェクトリストには居続けることになる。オブジェクト指向的（？）に考えるなら、波動はリュウが呼び出すと生成され、画面外あるいは敵にぶつかることでその生涯を終えるようにしないとあかんよな。　結局画像読み込み時の処理速度が問題なのだから（そもそも問題ある範囲なのかは不明だが、いざやってみて重すぎてゲームになりません、では困る。メインゲーム中はなるべく無駄な処理は行わないようにした方がよいはず）、そこだけ分離してしまうのが賢いのだろうか。　つまりテクスチャをプレイキャラ毎にまとめて、キャラ選択時～ゲーム開始時の間に画像ファイルだけまとめて読み込んでしまう、という。オブジェクトがリストに居続けるのは問題で画像をまとめて読み込んでおくのは問題じゃないのか、という声があるかもしれないが、そこはほらリストは毎フレームすべてのオブジェクトを回すのだから、なにもしないオブジェクトが存在する意味はないのですよ。納得。　よし決定、ほしたらテクスチャはキャラクタ毎にまとめておき、生成時に読み込む。つまりプレイヤクラスがすべての利用するテクスチャを生成時に読み込んでおくという手法でとりあえずやってみよう。 typedef class CRyu : public CCharBase{ struct{ LTEXTURE lTexStand; LTEXTURE lTexJump; LTEXTURE lTexHadouken; // 以降リュウが行動するであろう全ての状態をあらわすテクスチャを定義 }m_lTex; }CRyu, *PCRyu; 　といった感じ。　次に、テクスチャを一枚読み込んだとするとその一枚の中に何パターンかのアニメーションが存在（したり）し、これを描画時に切り替えて表示することで動きを表現するという手法を取るつもりなのだが、この切り替えるタイミング、要するに各パターンの表示フレームをどこに置いておくか、である。テクスチャのアニメーション数とそれに応じた各パターンの表示フレーム、軸ずれなどをまとめた構造体を一つ用意してみる。 struct CTextureProperty{ unsigned int iWaitFrame; // 表示フレーム int iXGap; int iYGap; // XY軸ずれ }; これのアニメーションパターン数分の配列を作成し、プレイヤクラスに持たせる。 typedef class CRyu : public CCharBase{ struct{ LTEXTURE lTexStand; LTEXTURE lTexJump; LTEXTURE lTexHadouken; // 以降リュウが行動するであろう全ての状態をあらわすテクスチャを定義 }m_lTex; int m_iAnimationPtn; // 最大アニメーションパターン数 CTextureProperty m_aTextureProperty[m_iAnimationPtn]; // ↑分のテクスチャ情報の配列 }CRyu, *PCRyu; 　な感じでどうか。コンストラクタでファイルから必要な情報を読み込んでおくことで大分データの分離が実現出来たのではなかろうか。　…あほな事に、というか単に勉強不足なだけだが、最大アニメーションパターン数が定義されてないのに配列の要素数に使おうというその感情がわからんとコンパイラに言われた。まったくそのとおりで、実際嫌な予感はしてたので別にいいけど。しゃあないからvectorに書き換えた。あれほしたら最大アニメーションパターン数っていらないんじゃ……？いりませんよね。 vector m_aTextureProperty; 　これでええはず。はず。次回予告・状態名・テクスチャファイルパス・ウェイトフレーム{ 　攻撃枠領域xn 　防御枠領域xn 　ぶつかり枠領域xn 　}xn 　といったデータファイルを用意してみるのはどうだろうか（えらい具体的なタイトルやな～）。おっ楽しみに～！ ---- #comment(vsize=2,nsize=20,size=40) ---- *覚書というか（05/07/31）　まずはこちらを御覧( ´∀｀)つ #ref(fight_img05073101.jpg) こちらは一分で描いたのでこんなんですが、こんなんでもまあ十分でしょう。ここから得るものを抽出すると・木と山と雲と雷・人形・下のゲージ・上のゲージ・時間はぅ、カプエスのしすぎで勝利ポイント数の表示や顔絵の表示などなんかいろいろ抜けてるような気もするけどヽ(ﾟдﾟ)ノ。でこれらをもうちょいまとめると・背景・プレイヤ（敵もプレイヤ）・体力ゲージ・SCゲージ・時間あんま変わってねぇな。でこのへんは全てキャラクタ基底クラスCCharBaseというのを用意して派生。これはいいか。これらをCApplicationクラスが適当に生成するという訳だが、時間はよしとして各ゲージの扱いというか実際のゲージ値はプレイヤが所持しているのだろうから、これが変化が起こったらCApplicaionに通知して更新描画を行うという方向で考えてみる。 LunaListに追加してしまったら実は各種オブジェクトのポインタを管理する必要はあんまなくて相互に情報を送信し合う必要が出てきた場合のみ中継役としてCApplicaionがそれぞれのポインタを管理、getメソッドで受信してsetメソッドに送信、みたいな形でプレイヤの体力を体力ゲージに反映させることが出来る。けどなんかキレイじゃないような。いっそのことプレイヤクラスがゲージクラスを包含してたらどうなんやろう。 typedef class CPlayer{ CLife Life_; CSC SC_; public: setLife(float Life){Life_.setLife(Life);} }CPLAYER, *LPCPLAYER; LPCPLAYER CApplication::pPlayer_; void CApplication::HitCheck() { if(攻撃が当たったら) { pPlayer_->setLife(こんくらいダメージ); } } みたいな。で今書きながら思ったのが上の「こんくらいのダメージ」ってどんくらいやねん、要するに攻撃当てた側が何出してたかが重要になってくるわけで、こんな技出してますよ的なあれを一度まとめて防御側に渡す必要があるのか。攻撃側の状態（例えば体力が下がると攻撃力があがったり、怒り状態だったりの補正）を攻撃側で行った上で攻撃値を取得し、setLife()で防御側の補正をかけてから代入？あそれ以前にこのCPlayerが持ってるCLifeクラスのインスタンスはリスト登録されてないから描画ループで呼び出されないような…あ、CPlayerがコンストラクタで明示的に追加してやればよいのか。 ---- #comment(vsize=2,nsize=20,size=40) ---- *でこんな感じ(05/07/25) #ref(stg050725.jpg) 画像はlunaサンプルSTGより。配布したりしてないから別にいいですよね？特にやってみたいSTGというのもないもので今のところこんな感じ。あ、弾は手製ですよｗ敵一体の動作パターンみたいなんを作ったので、これを拡張してイベントデータ扱いで外部データ読み込みが出来るようにしてみようかな。一応当たり判定もあったり。LunaCollisionクラスという非常ーに便利なクラスがあるので最近の若い者は録にあたり判定も出来ませんな。わしのことやけど。 ---- - 長くなってきたので各回毎にコメント欄を。 -- mugi (2005-07-31 15:11:28) #comment(vsize=2,nsize=20,size=40) ---- *遂にデザパタ登場か…？(05/07/13) え～しばらく続いたスプライト問題にもようやく中盤に差し掛かったとでも申しましょうか今日この頃、皆さんいかがお過ごしでしょうか。僕は元気にヒッキしてます。で、スプライトを各オブジェクトが生成されると同時に作成し、解体と同時に破棄という手順を踏んでいたんやけど（要するにコンストラクタで作成してデストラクタで解体）、この場合同じ画像を使うオブジェクトが使用するスプライトは一枚でいいんじゃないかというわけで、メンバに配列として static LTEXTURE m_lSpr[キャラクタの種類数] みたいな感じで持ってたんですよ。ほしたら複数オブジェクトを生成してどれか一つが解体された場合に、同じスプライトを持つオブジェクトは全て描画されなくなる、と。そら当たり前ですな。というわけで、解体は最後のオブジェクトが行うというかそもそも各クラスに一つしか存在しないというようにすればよいのではないか、ということで奴の登場ですよ。続きは後ほど。あーで結局使わずじまいというなんとも計画性のない手記だなあおい。 ---- #comment(vsize=2,nsize=20,size=40) ---- *小メモ(05/07/10) えと、ちょっとあれからテクスチャからスプライトへ移行したんだけども、ふと思ったのでメモ。現在LTEXTURE及びLSPRITEのインスタンスをキャラクタ基底クラスに持たせているのだが、例えば同じ画像を使用する複数生成されるオブジェクトの場合、同一のスプライトが重複してしまうのではないかという話。mbxではグローバルにスプライトの配列を用意して、アプリケーション初期化の段階でその配列の各要素にテクスチャから範囲指定で読み込んでいたわけだが、これは単にグラフィック画像データを一枚で済ませるという点だけでなく、生成されたオブジェクトはここから参照しなさいよということなのではということで今の段階では設計上問題があるのかもと思った。またその配列が二次元になっているのは下記参照ということで、要するに一列目において0番ならプレイヤのスプライト、1番なら敵Aのスプライト、という風に決められているのではないかと。どうなんだろ。あ、静的メンバにしたらどうなんか、な。勉強不足乙。 ↑あーそれだとオブジェクトが生成されるまでテクスチャを確保しとかなあかんからメモリのムダか。となるとやっぱりグローバルですかね。 *さすが詰まらなければ早いなぁ(´ι _` 　)(05/07/06) ↓のは夜中の話。で今昼間なんやけど、あれからリストでスプライトオブジェクトを（ほんまはまだテクスチャやけど）まわすことに成功。んでついでにサウンドクラスも作ってパックファイルからもういつでも音がならせる様に。ほぼLunaSTG（以降mbx）のLuna9.0c移植みたいな形で、ゲームシステム部分以外は結構パクリに近いのだが、そこはそれということで。むー、Ayameが初期化出来ないorz。Ayameが読めないとOgg使えないじゃないか。しゃあないから今のところ全部Wavで、短いループファイル作ってBGM代わり。とかいうてたけどLuna最新verにしたら全部解決した(||´・ω・) なんかしらんけどパックファイル対応してる関数が消滅してたのでさしあたってパック化はなしで代わりにOggが使えるようになって…ややこいなー。まぁフリーのライブラリなんだしどんどん改良してくれてるし文句いうてはいかんわな。感謝感謝。とりあえず身近な関数の変更だけメモ。 void LunaSound::CreateFromFile(const char*, bool); const char*pFileName:ファイル名　bool IsNoStop:わかんないｗ止まらないか否か？謎。 void Luna::SetFrameRate(long FrameRate); 以前あったLuna::SyncFramte()関数が隠匿されて代わりに現れてきたのがこれ。まあ差し替えるだけ。 void LunaInput::Refresh( void ) void LunaPad::Refresh(void) 内部へ。まあ書かなくてすんだということで。更新履歴は頻繁に確認せんといかんなー。 ---- #comment(vsize=2,nsize=20,size=40) ---- *二次元配列の謎を解く！(05/07/06) 　解く！つーか解いたので忘れないうちにｃ⌒っ*ﾟдﾟ)φ　ﾒﾓﾒﾓ... // スプライト生成 for ( long i = 0; i < 10; i++ ) { if ( i == 6 ) { Sprite[i][0] = LunaSprite::Create( 512, Graphic, BLEND_NORMAL ); RECT uv = { 0 }; Sprite[i][1] = LunaSprite::CreateLaser( LASER_DIV, &uv, Graphic, BLEND_ADD ); } else { Sprite[i][0] = LunaSprite::Create( 512, Graphic, BLEND_NORMAL ); Sprite[i][1] = LunaSprite::Create( 512, Graphic, BLEND_ADD ); } } main.cpp内でのひとコマなんやけど、注目すべきはSprite[i][1]のある行。ここでケツの引数がBLEND_ADDとなっている点、さらに描画部分でSprite[i][0]の次にSprite[i][1]をレンダリングしている点から、まあレーザやら弾やら、そういった光るやつを加算合成しているのだ。多分。というわけで解決。進行具合:LunaTextureを用いてキャラクタ基底から派生させたオブジェクトの画像を画面に表示するところまで。しかし今使ってるのがLunaDx9.0cでこのSTGはLunaDx8で書かれた奴やからもうない関数やらあったりして混乱する(´･ω･) ---- #comment(vsize=2,nsize=20,size=40) ---- *キャラクタの生成(05/06/28) 大概のオブジェクト（見えるもの）はCSpriteクラスの派生クラスである。CSpriteクラスはメンバ変数としてSortという列挙型を保持し、これによりどの種類のオブジェクトか判断している。例えばCPlayerクラスはCSpriteクラスを継承している。このとき、CPlayerのコンストラクタでCSpriteクラスのメンバイニシャライザを利用して、変数SortにSORT_PLAYERを代入している。 CPLAYER::CPLAYER( void ) : CSPRITE( SORT_PLAYER ) これにより、後々当たり判定のチェック等で、オブジェクトの種類を調べることで分岐をたてやすくなっていると思われる。 void CApplication::AllHitCheck( void ) { //-------------------------------------------- // 自機＆妖精とコイン //-------------------------------------------- { LPCSPRITE p1 = (LPCSPRITE)SpriteList.Top(); while ( p1 != NULL ) { if ( p1->Sort == SORT_PLAYER ) { LPCSPRITE p2 = (LPCSPRITE)SpriteList.Top(); while ( p2 != NULL ) { if ( p2->Sort == SORT_COIN ) { POLYGON2D poly1 = { p1->HitCount, p1->lpHitPt }; POLYGON2D poly2 = { p2->HitCount, p2->lpHitPt }; if ( LunaCollision::Polygon_Polygon( poly1, poly2 ) ) { AddGold( 50000 ); p2->Damage( 0 ); } } p2 = (LPCSPRITE)p2->Next; } } p1 = (LPCSPRITE)p1->Next; } } こんな感じ。いかんせんリスト回すためにキャラクタ基底クラスは必須ぽ。とりあえずメンバ変数及び関数についてはのんびり増やすとして、リストに追加削除回して描画までできんことには…。 ---- #comment(vsize=2,nsize=20,size=40) ---- *Luna製STGの解析(05/未明) 　とにかく絵を持つクラスというクラスはCSpriteから派生している。これはBase.hにグローバルで置かれているCList型のインスタンスであるSpriteListにオブジェクトを突っ込み、CSprite型にキャストしてリストを回すことで全てのオブジェクトに対して動作の指示が出せるというものだと思われる。（CApllication::Main()参照のこと）　しかしSpriteListにオブジェクトを追加している部分が見当たらないんですが、これってどういうこと？(,,ﾟДﾟ)∩ｵｾｰﾃ一応CApplicationクラスが静的にCPlayerクラスのポインタを持ってて、そいつにnewしたCPlayerへのポインタをCApllication::SetPlayer()というこれまた静的な関数でメンバ変数にコピーしている。この作業を行うのがCApplication::SceneStg()であり、実際シーン開始時（CApplication::SceneFunc[現在のシーン]()内)にCPlayerはnewされている。のだが…。 ---- ﾊｹｰﾝ自己解決。CSpriteのコンストラクタで CSPRITE::CSPRITE( eCharSort sort ) { // 処理リストに追加 SpriteList.InsertEnd( this ); } とあるねorz。この時点でnewしたポインタはリストの前の要素のメンバにあてられるということでいいのかな。ソースにSetPlayer(new CPlayer());とあるもんだから、あれnewしたポインタは誰が指してんの？って思ってたんだが。 05/07/04追記 ↑なんか変なこというてるぞ～。CApplicationクラスがCPlayerクラスへのポインタを静的に保持してるんだから、SetPlayer()関数でそいつにアドレス代入してるんだからそれでいいのじゃないのか。前回気になってたのはおそらくSetPlayer(new CPlayer());のCPlayerの後の括弧なによ？って思ってたんやろうが、これはただコンストラクタ呼び出してるよっていうだけなんよね、こういう書式もありだったと知った。(´･ω･`)ｼｮﾎﾞｰﾝ ---- 次。もうひとつのグローバル変数であるSprite[10][2]の部分。これはLSPRITE型のインスタンスで、LSPRITEはluna.h内で typedef class LunaSprite LSPRITE; となってるので、要するに画像関係はこいつに託せばよいと。でまあ単純にパックされた画像をループでまわしながらSprite[i]に放り込んでるので、 Sprite[1][0]はなんの画像で、とかいう風にきまってるぽ。説明はないけど作者ならわかるというか。 Sprite[10][2]やから、１０＊２で20枚画像があるということで。各スプライトにおそらくアニメーション用の画像も入ってるので実際はもう少し多いということか。で、CApplication::Main()内で //------------------------------------------- // 画面描画 //------------------------------------------- for ( long i = 0; i < 10; i++ ) { Sprite[i][0]->Rendering(); Sprite[i][1]->Rendering(); } とあるので、おそらくSprite[][]の後半の配列はレイヤーを表してんじゃないかと。この場合二層のレイヤーという。 ……いや違う、この順番だとそういうレイヤーな感じにならんじゃないか。何故二次元配列に……？ ---- #comment(vsize=2,nsize=20,size=40)

プロジェクトX

2005-07-15T02:24:03+09:00

しりとりのシムテムについてまとめてみますかみたいな。 ---- *パネルについてサイズは64*64 読み方として、３通りくらいもつどの読み方をしたかで、重み（ポイント的な）が違う #comment(vsize=2,nsize=20,size=40)

ゲム部/お絵かき掲示板ログ/1

2005-07-06T10:36:12+09:00

#ref(1120613772.png) #comment ----

メンバーリスト

2005-07-02T12:37:12+09:00

ここへ訪れたメンバーさんは、名前を書いていってもらえるとありがたいです(｀・ω・´) - akage - mugi - izawarz - chun - 邑 - naga ---- - きたぜー -- 邑 (2005-06-20 22:04:01) - こんなページが！！&br()俺も参加できる案を模索してくれ。。&br()俺にはわからんのだ！ -- Annie (2005-07-02 03:12:18) - 来たー！ -- 渋近 (2005-07-02 12:37:12) #comment(vsize=2,nsize=20,size=40) ファイル編集の仕方がわからない人のためにコメント欄を↑ 名前入れて「来たよー。」と二言三言。

巻き毛杯

2005-06-30T05:58:41+09:00

*巻き毛杯 **巻き毛杯とは [[ゲム部]]によるパンヤ非公開大会。人数がそろい次第（四人以上）不定期に開催予定。 **システム参加者は参加費として50cp（500円）を用意、マスターアカウント（捨て垢or誰かが管理者）にCPとして貯める。大会結果により各自pt（ポイント）を得、pt=cpとして自由に使用することが出来る。要するに皆で集めたcpを奪い合うという構図。 **pt発生条件 -トップ -ベストリカバリー -ベストスコア :ベストスコア|大会スコアが自己記録に最も近い者に与えられる。ただし自己記録を更新した者がいる場合、より多く更新した者に与えられ、さらにpt二倍とする。 ---- pt値の設定及び発生条件等、ご意見ご要望あれば↓にて。あるいは勝手に編集するよし。 ---- - いいですな。ptは上から5/5/3ぐらいかなー。それとベストスコア対象が複数いる場合はどうなるんかね -- izawarz? (2005-06-30 05:32:54) - そうねー、更新すればトップよりpt上っていう。複数いた場合はPPで同様に、大会PPが自己PPを～っていう感じでどうでしょ -- mugi (2005-06-30 05:55:33) #comment(vsize=2,nsize=20,size=40)