シューティングゲーム製作技術総合　３機目

**名前は開発中のものです。** · 04/06/16 07:45

ゲームプログラマなら誰もが通る、もしくは、通った道。青春の香り？
それは「シューティングゲーム製作」・・・。

このスレでは、そんなシューティングゲームの製作技術や技術の検証、成功談
失敗談笑い話、難易度の設定方法論、多弾の是非などについて語り合いましょう。
もちろんBulletMLなどで弾幕を作成してみたり、自分の作ったシューティングを
晒してみたり、プロジェクトをはじめてみるなどもOK！

ただし、シューティングの未来とか既存のゲームの話題などは、関連する他の
スレでやってくれ。

■前スレ
シューティングゲーム製作技術総合　２機目
http://pc5.2ch.net/test/read.cgi/gamedev/1073736474/

**名前は開発中のものです。** · 04/07/30 14:16

>>827
確かに、Savage系ではあるが。

**名前は開発中のものです。** · 04/07/30 14:48

ちなみにインテルのUMAである855GMで６０～６２ｆｐｓ
CPUはPentiumM/1GHzな
ゲームオーバー時だけ大幅にfpsが下がるがゲーム中は安定

**名前は開発中のものです。** · 04/07/30 16:19

>>826
昼休みにDirectX版を作ってみた、良かったら試してみてくれ。
要DirectX8以上。
これで安定するとしたら、ドライバのOpenGL実装がマズーだという可能性大。
Irrlichtの問題なんだろうが、DirectX版の方が２割ぐらい速い。
妙なこだわりを捨てて、IrrlichtでのWin版はDirectXで組んだほうがいいのかorz
（define一発で済むと言えばその通りだしなぁ）

http://gamdev.org/up/img/934.zip

スレ違いな気がするが見逃してくれorz

**名前は開発中のものです。** · 04/07/30 17:02

大幅にフレームレート上がったよ
１６０くらいでるようになった
ファイルサイズも小さいしな

ただ、ボスが出ると９０くらいまで、そしてその後いっきに７５くらいまで
下がった後そのあとそれくらいで安定した

どっかでへんなの掴んでるんかね

**名前は開発中のものです。** · 04/07/30 17:46

>>830
今度は他のソフト起動してても速くなったよ
ただ、今度はGAME OVERになってずっと爆発してる（バグ？）
画面構成も良いし、おもしろくなるのでは。

**名前は開発中のものです。** · 04/07/30 18:08

>>831
ふと思ったが、そのマシンそもそもGLのH/Wアクセラレーションが
効いてなかったりなんてことない？
ttp://www.delphi3d.net/hardware/glinfo2.zip
これの結果とかどうなる？

**名前は開発中のものです。** · 04/07/30 20:03

DirectXで７５ｆｐｓ、OpenGLで６２ｆｐｓ
値としてはそれなりのものがでてるかと

**名前は開発中のものです。** · 04/07/30 20:12

>>832
お、動きますたか。よかっつよかっつ。
こちらも貴重なデータをいただきますた。ty
「オンボードVGAあたりだと、
　DirectXはともかくOpenGL実装はサボっているドライバあり」
というのは貴重な教訓ですわ。
ゲームオーバー後進展が無いのは単にその先未実装だからじゃｗ

>>831
こっちでも現象は確認した。
（昼休みにチャチャっと実装したのでそこまでは確認してなかっつ）
IrrlichtのTechdemoとかでも、DirectX使用時に限り、序盤に
「君いくらなんでもそのFPSは変じゃろ？」
という値が出ることがあるので、
ひょっとするとIrrlichtのDirectXドライバのFPS計測関数のバグかもしれん。

というわけで、スレ汚し失礼。STG作成スレに帰ります。

STGを最初からみんなで作るスレ
http://pc5.2ch.net/test/read.cgi/gamedev/1014709311/l50

**名前は開発中のものです。** · 04/08/01 05:59

http://www.geocities.jp/gikoneko200408/
意見を聞かせてください。

**名前は開発中のものです。** · 04/08/01 06:01

意見も何も全然完成してないじゃん。
この程度で意見求めるのはどうかと思うよ。

**名前は開発中のものです。** · 04/08/01 09:12

>>836-837
ﾜﾛﾀ

**名前は開発中のものです。** · 04/08/01 11:54

>836
君は835の書いたスレへ行くのが吉。
とりあえずどんなゲームになるのかくらいはページ作ろうな。

**836** · 04/08/01 14:38

分かりました。

**名前は開発中のものです。** · 04/08/01 22:34

みなさんSEってどうしてますか？
自分はフリー素材頑張って探してるのですが見つからない
とくに弾発射と爆発音…

**名前は開発中のものです。** · 04/08/01 23:04

>>841
普通に「効果音著作権フリー」とかでググるだけで
そこそこ見付かると思うけどなぁ。

**名前は開発中のものです。** · 04/08/01 23:15

そんなんじゃゲーム作る気がないとお(ry

**名前は開発中のものです。** · 04/08/01 23:15

音を自作できるツールで頑張ったりとか。
ttp://hp.vector.co.jp/authors/VA016505/wg.html
は入門用にいいかも。

難易度は上がるがこういうのもある。
ttp://www.vector.co.jp/soft/win95/art/se045171.html

そのうち自作でツール作ってみたいね

**名前は開発中のものです。** · 04/08/02 05:56

あのー・・・
基本的なことで申し訳ないのですが

現在のリフレッシュレートってどうやって取得するん？

ヘルプ見ても
「ウィンドウモードの場合0」だとか
「デフォルトの場合0」とかしか書いてない・・・

**名前は開発中のものです。** · 04/08/02 06:06

計測するしかないんかなぁ

**名前は開発中のものです。** · 04/08/02 09:46

>>845
HRESULT IDirect3D9::GetAdapterDisplayMode( UINT Adapter, D3DDISPLAYMODE *pMode );
で取れたけど。
845が使ってるDirectXのバージョンは？

**845** · 04/08/02 17:03

どもども。
>>847
９でつ。
GetAdapterDisplayModeだと０とか帰ってきたりするでつ・・・
諦めて自分で計測しまつ

**名前は開発中のものです。** · 04/08/02 17:07

すまん。もしかしたら勘違いしているのかもしれん。

ウチの環境ではそれでリフレッシュレートの値取れるんだけど、
ヘルプに「RefreshRate。この値が 0 の場合、アダプタデフォルトを示す。」って書いてあったんだ。

もしかして、これはディスプレイモード指定時時にアダプタデフォルトを示すには０を指定する、って意味で
GetAdapterDisplayModeを使った時はリフレッシュレートの値がちゃんと帰ってくることが保障されてたりするの？

**名前は開発中のものです。** · 04/08/02 19:54

ノートなんかだとリフレッシュレートが取得できない場合が多い。
俺のも必ず０が返ってくる。

**名前は開発中のものです。** · 04/08/02 21:34

>>850
(´・ω・｀)そか・・・
やっぱ０が返ってくることもあるのね
しかたないので、取得計測両方して、差が大きかったら計測値を採用、でやってみまつ。
ありがとん。

**名前は開発中のものです。** · 04/08/02 23:20

基本的にデジタルディスプレイはダメでは

**名前は開発中のものです。** · 04/08/03 10:22

9xもダメかも

**名前は開発中のものです。** · 04/08/03 11:06

OSによって取れたり取れなかったりしたような
98では0が返ってくるけどXPや2000では取得できたような

**名前は開発中のものです。** · 04/08/03 14:25

>>854
確かそうだよな

リフレッシュレートでは俺も以前フレームレート絡みで色々と試行錯誤したが、
結局Windows環境である限りどうにもならんと諦めた記憶が

**名前は開発中のものです。** · 04/08/03 15:13

実測モードを付けておけば万全…かな？

**851ですが** · 04/08/03 20:05

結局実測して取得値と比較しますた。
取得値６０で実測値が６１だったら　６０を採用
取得値０で実測値が６１だったら　６１を採用
みたいな感じで。

>>132の言ってる内部ＦＰＳ３００と組み合わせたら(・∀・)e!感じ
おまいらにもおすすめですよ

**名前は開発中のものです。** · 04/08/03 22:24

>>132を見て思ったことだが、リプレイの実装についても話し合ってみたい。
俺はまだその段階までたどりついてないけどね。

**名前は開発中のものです。** · 04/08/03 22:46

リプレイは早期に搭載して「ちゃんと再生される」段階まで確認できてると、あとが楽かも
内部300FPSでも、従来どおり乱数シードとキー入力だけで問題ないよな

**名前は開発中のものです。** · 04/08/03 23:38

バッファが埋まってしまったら、追加バッファをアロケートするわけだよね。
プレイヤーが何もしないとどんどん使用メモリが増えていくのが不安なので、
今作ってるのは制限時間を設けてフレーム数に限度を付けてるんだけど・・・。
制限が無いゲーム作ってる人はあまりそういうことは気にならないのかな。

**名前は開発中のものです。** · 04/08/03 23:49

・ステージごとにリプレイデータを書き出してバッファ掃除
・ステージは強制スクロールで、ボスも自爆
・なので、バッファは固定長
というゲームしか想定したことがないなあ

**名前は開発中のものです。** · 04/08/03 23:52

時間無制限の場合は、何らかの形で休憩ポイントみたいなのを設けて
その間に一時ファイルとかに書き出しちゃったほうが良いような。
STGだとループゲーでない限り、気にするほどでもないと思うが。

**名前は開発中のものです。** · 04/08/03 23:53

・何も考えず直にファイル書き出し

**名前は開発中のものです。** · 04/08/04 00:17

>>861
まてまて。バッファ固定長？
それってフレーム毎のボタン入力情報を保持しとくってことか？
それだとデータ量凄いことになるべ。内部３００ＦＰＳでは大変大変。

あれですよ。
大体１フレ毎にボタンのON/OFF切り替わるわけじゃないんだから、
フレーム毎のボタン入力情報じゃなくて、
ボタン毎の押されたフレーム数情報を保持したほうがいいですよ。

例えば、Ａボタンが３００フレーム押されなくて、次に２０フレーム押されたときは
A { {OFF,300} , {ON,20} }
みたいな形で保持した方がメモリ食わんですよ。

**名前は開発中のものです。** · 04/08/04 00:19

ほじ（ホヂ）【保持】
―する
〔そうする△意義（必要）のあるものについて〕そのままの状態を持ち続けること。

・・・漏れは日本語がヘタのようだ。
みんなは保持しないで保存してくれよな。

**名前は開発中のものです。** · 04/08/04 00:58

シューティングならPlayer当たり8bitもあれば十分だよね。
300FPSでも1時間記録して1MB程度なので余計な事しないほうが
いいんでわw

漏れはファイルに逐一書くほうが楽だと思うけど。

**名前は開発中のものです。** · 04/08/04 01:17

リアルタイムでランレングス圧縮かけてる。

**偽ガルーダ** · 04/08/04 04:51

現状報告というか、ＵＰしてみました。
http://gamdev.org/up/upload.php

ボスの実装は結局出来てません、、。
どういう攻撃させるか思いつかない、、。
意見募集します。

**名前は開発中のものです。** · 04/08/04 08:35

>>868
乙。
やってみた。動作に問題はなさげ。
以下疑問質問。
・キー入力に対して自機の反応がかなり遅いんだけど何故？
・左右スクロールは無し？
・自機はセセリたんですか(*ﾟ∀ﾟ)＝3

こっちの環境書いとくね。
AthlonXP2400+、RADEON9600pro、WinXPpro、DirectX9。
いじょ。ガンバレ。

**名前は開発中のものです。** · 04/08/04 09:34

>>868
キー入力されてから実際の動きに反映されるまでの遅延が凄すぎ
おかげで弾幕が全く避けられん
確かにUSBジョイスティックの入力をDirectInputが拾うまでの遅延はあるのは
知ってるが、それ以上に遅い気がする

当方環境
P4-2.4C Radeon9600np Win2k DirectX9

**名前は開発中のものです。** · 04/08/04 11:49

＞868　すげーヽ( ・∀・)ﾉ
AthlonXP2500+/PC2700 1280MB/RADEON 9800Pro/Win2k/DX9cR
ほぼ60fpsを維持。他二方が言ってた入力遅延は起こらなかった。
パッドは、psxpadドライバを使ったSFCコントローラ(パラレルポート経由)

**871** · 04/08/04 11:54

連続書き込みｓｒｙ

USB接続のゲームパッド持ってることを思い出したんで、そっちでやってみた。
結果は変わらず、遅延は感じられなかった。なんでだろ？

**名前は開発中のものです。** · 04/08/04 13:49

AthlonXP2000+、GeForce FX 5200、Win2k、DirectX9b、サンワのUSBパッド
1ボスが爆発で40程度に落ちる以外は概ね60程度を維持してる。
入力の遅延は全く感じず。

**名前は開発中のものです。** · 04/08/04 15:35

偽ガルーダ
設定にXML使うのはいいんだけどSOAPってあたりが激しく疑問だ

PentiumM1GHz/855GM

爆発時以外常時６０ｆｐｓ安定
ＵＳＢパッド遅延無し

**名前は開発中のものです。** · 04/08/04 16:05

P1.6GHz XP Geforce4440ノートPC DirectX9
60fps維持、ボスキャラ爆発で57fps前後
ジョイパットないのでキーボード操作、全く問題なし
ボスキャラ作って断末魔「お嬢様ー」と叫ばせて欲しい

**名前は開発中のものです。** · 04/08/04 18:51

Cerelon400相当/TNT2
タイトルから先が動かなかった…。
後日別マシンで動かしてみよう。

**名前は開発中のものです。** · 04/08/04 19:33

P4-2GHz/Radeon9200/dx9
タイトルから進まず。desktopのリフレッシュレート85Hzが、titleでそのまま使われてる。
dxdiagで60Hz強制上書きにすると、ちゃんと60Hzになる。そこからZ押しで強制終了。

**名前は開発中のものです。** · 04/08/04 22:34

>>868
PenIII / 886MHz
Mil.G550
SVGA 60Hz
Win2K

起動してもLoading Please Waitが出たまま反応せず。

**名前は開発中のものです。** · 04/08/04 23:09

>>868
Pen-M1.6G/RADEON9000Mobility/Mem1G/WinXP
DirectX9b+OMEGA DRIVER
FPS300～400前後でフレームリミッタ効かず

**偽ガルーダ** · 04/08/04 23:26

ご協力感謝します。参考にします。
粘着してた甲斐がありましたｗ

＞・キー入力に対して自機の反応がかなり遅いんだけど何故？
自分の所で、症状が出ているのか、判断出来ない状態です。
明らかに判るレベルでしょうか？調査します。

＞・左右スクロールは無し？
取り合えずは、なしです。（手抜きです

＞・自機はセセリたんですか(*ﾟ∀ﾟ)＝3
その反応を期待してそうしましたｗ

＞その他、動作しない
調査してみます。

入力には、DirectInputを使用してます。
DirectXは9.0bを使用しています。
今の所、テクスチャは512*512,400*480の２種類を使用してます。
XMLパーサーには、Microsoft XML 4.0 Parser を使用してます。IE5.0以上？が入ってればＯＫだったかも、、。
ビデオカードは、ハードウェアT&Lを前提として組んでます。(Direct3Dです)

**名前は開発中のものです。** · 04/08/04 23:50

>>874
ほんとだｗ
なぜSOAP・・・

**869** · 04/08/04 23:54

セカンドPCでやってみたが、こっちはそれほど遅延はなかった。
けど全く無いわけじゃないと思う。869で書いたPCは誰でもわかるほどの遅延。
今回テスト環境
AthlonThunderbird1.0GHz、GeForce2MX、W2k、DirectX9。
ちなみに今回はUSBキーボード。869はPS/2キーボード。

**名前は開発中のものです。** · 04/08/05 00:06

いや、XMLパーサとSOAPは関係ない
あきらかにちがってる
たぶん参考にしている書籍かなんかがSOAPだったんだろうなぁと

どっちみち紛らわしいしやめとけ
俺みたいに仕事してればひっかかるから

**偽ガルーダ** · 04/08/05 00:07

>>874,881
何故にSOAPてのはですね、、。
ツール側のシリアライズ、デシリアライズに使われていてですね（Ｃ＃で組んでます）、
それを未加工で使わせてもらってます。
そのデータから、必要なメンバだけを使用しているわけです。
間にコンバータ挟むと、修正の際も含めて、工程が倍になるかなー？という所での実験です、、。

>>869
サンクスです。そですかー。
では、こちらの環境では、再現出来てないです、、。
今、取り合えず、デバッグモードでトレースしてます。

**名前は開発中のものです。** · 04/08/05 00:19

いや、Ｃ＃だろうがSOAPヘッダつける必要はないだろう

**名前は開発中のものです。** · 04/08/05 01:01

>869
やってみた
細かいことだけどキャラが画面端にいくとぷるぷるしてるのが気になった
後全体的に弾速がかなり遅いね赤状態でちょうどいいぐらい

**名前は開発中のものです。** · 04/08/05 01:22

入力の反応が遅いんで微妙なところかと

**名前は開発中のものです。** · 04/08/05 02:31

偽ガルーダやってみました。
他の方も言ってますが、キャラの移動がもっさりしてるような気がします。
あと、斜め移動が縦横移動より速い気がします。ルート2倍かな？（知ってて放置してるのだったらすみません。
まだ荒削りの段階なのでしょうが、よく出来てるなーと思いました

**名前は開発中のものです。** · 04/08/05 02:57

そいやグラVは斜め移動速度はルート2倍だね。
縦STGでは最近あんま見ないな。

**偽ガルーダ** · 04/08/05 05:06

偽ガルーダ、途中ver.0805をＵＰしました。
http://gamdev.org/up/upload.php

D3D,debugで例外が出ていたので、修正しました。
後、簡易マニュアルを付けました。
内容はほぼ一緒です。

エラー処理等、時間掛けてみてみます。

**偽ガルーダ** · 04/08/05 05:09

>>886,888
はい。単なる手抜きです。
追々直す、、かもです。

**877** · 04/08/05 12:15

同じく、タイトルでゲーム強制終了。
一応、他のアプリのウィンドウ位置が復元されない(破壊される)ことをもって強制終了と判断してる。

**869** · 04/08/05 12:44

そいや前のバージョン終了するときエラー音出てたな。
今度のは平気っぽいです。

**名前は開発中のものです。** · 04/08/05 18:12

偽ガルーダ見ても自分で書いてるコードでテストしても、こうも入力の遅延が
大きいのを見せつけられると暗澹たる気分になってくる
STG、特に2D弾幕系を作る環境じゃねえよ
ぶっちゃけ製作のモチベーション下がる…

**名前は開発中のものです。** · 04/08/05 18:35

うちではそんなに遅延してないと思うが…
入力の遅延は正確な計測ができないから(プレイヤーの感覚しかない)、難しいな

**名前は開発中のものです。** · 04/08/05 19:00

ジョイパッドの方向キーをほんの一瞬”ﾁｮﾝ”ってな感じで押してみるとわかるよ。

アーケード基板やファミコンでもキー入力された瞬間にキャラクタの動きが即座に
反映されるが、偽ガルーダに限らずDirectInputで同じ事やるとキー入力（↓）
されてそれが離れた（↑）後でやっとキャラクタの動きに反映される。

**名前は開発中のものです。** · 04/08/05 19:05

ジョイパッド持ってないのでわからないけど

>>896
キーボード操作でもそうなります？

**名前は開発中のものです。** · 04/08/05 19:07

遅延って仕様なの？
どうしようもないのか？

**名前は開発中のものです。** · 04/08/05 19:13

>>897は、>>894の内容へのレスでした。
>>890やってみたけど、うちの環境ではキー入力の遅延はなかったです。

**名前は開発中のものです。** · 04/08/05 19:27

USBゲームパッドを語るスレ Part 3
http://pc5.2ch.net/test/read.cgi/hard/1087382918/

なにかヒントは無いか。

**名前は開発中のものです。** · 04/08/05 19:43

>>896
まぁDirectInputだけの問題でもない
環境依存かと
ちみのマシンはかなり遅延でているようだが

極論いえばリアルタイムＯＳじゃない時点でお察しください
リフレッシュレートをDirectXで確実に変える方法もないし
ゲームに適した環境でないのは確か

**名前は開発中のものです。** · 04/08/05 19:52

偽ｶﾞﾙｰﾀﾞ、うちの環境では開発用のメイン機が一番遅延大きかったんだよな。
自分で作ってるゲームはこんなに遅延出なかったんだが…。

**名前は開発中のものです。** · 04/08/05 20:05

遅延ってOSとかDirectXが原因ってのもあるけど、パッドが一番悪いんでないの？
I/FSEGAだと遅延を感じたことはないし、USBだとはっきりわかる

**名前は開発中のものです。** · 04/08/05 20:08

>880
ところで、テクスチャサイズ400*480なんてけったいなサイズは、
ちゃんと2の累乗まで水増しして作ってるのか？

**902** · 04/08/05 20:41

>>903
俺はキーボードでテストしますた。

**名前は開発中のものです。** · 04/08/05 21:02

遅延といっても原因はひとつだけじゃないからな。
1)パッド→PC
2)入力の内部処理
3)ゲーム進行の演算内部処理
4)描画処理
5)ビデオカード→モニタ
画面に出るだけでこれだけ段階があるんだから
どこか噛み合わなければ遅延が出る。
2～4は出来る限りアプリ側で解消したほうがいいけど。

**名前は開発中のものです。** · 04/08/05 22:44

MS SideWinder Joypad(レガシーな方)だがやはり遅延を感じるな
入力から3フレくらい遅れて感じる

**名前は開発中のものです。** · 04/08/05 23:48

なんかもっさりしてるね。
自分が今作ってるプログラムだと遅延はほとんど無いんだがなぁ・・・
ちなみに SMART JOY PAD 3 でプレステ２のパッドを使用してる。

**名前は開発中のものです。** · 04/08/06 00:20

なんか加速度付いてる感じ？
止まる時にタイムラグを感じるわけでもないような気も。

**名前は開発中のものです。** · 04/08/06 09:36

>>906
既に問題が絞れた上での議論なんだが…
それの1か2、特に1番目の入力の取り込み遅延が問題なﾜｹで

**名前は開発中のものです。** · 04/08/06 13:38

今回のに関して既に絞れてるとは言えないと思うが…。

**名前は開発中のものです。** · 04/08/06 14:14

見てないので適当に書くけど、Win32のjoyGetPosではどうなん？
DirectInputって微妙に信用ならんし設計も気に入らんので使ってない俺。

**名前は開発中のものです。** · 04/08/06 15:01

「画面端でぷるぷる、に入力遅延の謎を解く鍵が！？」

などと、てきと～な事を言ってみる。

**名前は開発中のものです。** · 04/08/06 15:06

　∧ ∧∧ ∧
　(ﾟДﾟ≡ﾟДﾟ)　ﾌﾟﾙﾌﾟﾙ
　　　|し　|つ
　　⊂__　|
　　　し'

　(( ∩ )) ﾌﾟﾙﾌﾟﾙﾌﾟﾙ
　　γ'⌒ヽ∧ ∧
　　し'ゝつ( ﾟДﾟ)つ

**名前は開発中のものです。** · 04/08/06 15:21

画面端ぷるぷるは単に座標のリミットを移動後に処理してるからじゃない？

**名前は開発中のものです。** · 04/08/06 18:55

>>914
あはは！

**名前は開発中のものです。** · 04/08/07 00:28

亜覇破！

**名前は開発中のものです。** · 04/08/07 11:43

結局Windows環境では弾幕シューは不可って事でＦＡ？
やるせねえな

**名前は開発中のものです。** · 04/08/07 12:14

さあ…
しかし俺は自分のゲームでは偽がルーダのような遅延出てないんだが…。

**名前は開発中のものです。** · 04/08/07 13:47

Windowsの同人ゲーで弾幕シューだらけの状況を見て何を寝惚けたことを。

**名前は開発中のものです。** · 04/08/07 13:53

プログラムが悪いんだろ。環境のせいにすんな

**名前は開発中のものです。** · 04/08/07 14:46

(1) ヘンな変換器など環境依存な条件で遅延が起きる
(2) 環境は問題ないが、プログラムの都合で遅延する。プログラム次第で遅延なしにできる

大部分のWindows用STGは遅延しない。(1)と(2)の遅延の内容は別。
今回の問題は(2)なんじゃない？
うちではタイトルでボタン押すと落ちるので確認できてないが。

**名前は開発中のものです。** · 04/08/07 15:28

そりゃ、メモリー破壊起こしてる可能性が大だな。

**名前は開発中のものです。** · 04/08/07 15:52

Windowsのメモリー保護が強化されたとはいっても、
実行中の他アプリの動作に影響を与えなくなっただけで、
実行しているアプリ自信のメモリーデータに対しては、
保護しないからな。まあ、保護できるとも思えんけど。

**名前は開発中のものです。** · 04/08/07 15:53

というか、アプリがアプリ自信を破壊するのは
さすがに保護できるとは思えん。

**名前は開発中のものです。** · 04/08/07 16:23

しかしこの、メモリー破壊という言葉はどうにかならんか？
メモリーが物理的に壊れたと、勘違いするヤシが多いと思うが。

**名前は開発中のものです。** · 04/08/07 17:20

弾幕シューは不可なWindows環境もあるって事じゃないの？

シューティングゲーム製作技術総合 ３機目

シューティングゲーム製作技術総合　３機目