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

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

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

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

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

■過去スレ

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

シューティングゲーム製作技術総合
http://bbs.gamdev.org/test/read.cgi/gamedev/1056635103/

■関連スレ
PCで出来る2Dシューティング(STG)総合スレ12
http://game6.2ch.net/test/read.cgi/game/1083576811/
★シューティングゲームは終わらない-STAGE28-
http://game6.2ch.net/test/read.cgi/famicom/1084795165/
G-わんげ鳩大往生XII〜絆ダウン〜 4stage
http://game6.2ch.net/test/read.cgi/arc/1069685469/

■関連スレ
FPS(ﾌﾚｰﾑﾚｰﾄ) VSYNC(垂直同期 ﾘﾌﾚｯｼｭﾚｰﾄ)
http://bbs.gamdev.org/test/read.cgi/gamedev/1063274576/
リフレッシュレートに関する論争
http://piza.2ch.net/tech/kako/972/972165437.html

■参考リンク
フリーソフトで面白いゲーム まとめページ シューティングカテゴリ
http://www.frgm.org/cgi-bin/s.php?g=stg&b=n
BulletML
http://www.asahi-net.or.jp/~cs8k-cyu/bulletml/
白い弾幕くん(BulletML＋Lua)
http://user.ecc.u-tokyo.ac.jp/~s31552/wp/sdmkun/

■エフェクト作成ツール
aBOM
http://www1.odn.ne.jp/ceb94660/
BombMaker(explosion maker)
http://www.pluto.dti.ne.jp/~nkf/
Detonation
http://www.vector.co.jp/soft/win95/art/se173882.html
GraphicsGale
http://www.tempest-j.com/
発色弾
http://diry.net/mia/

お疲れ様です！

お疲れ!

前スレ>>991

falseだと思う。
１秒間に１回だけ1/60に間に合わないとすると、
１回だけフレームが更新されず、１秒間に５９フレーム描画になるんじゃないだろうか。
３０になるのは、（安定して）毎フレーム間に合ってない時では？

解釈のしかたによるんでない?
感覚的にはふつ〜に
グラ３みたいに
処理落ち中は30で動いてて
処理落ちがしなくなったとたんいきなり60に戻って
あぼ￣んっていう

FPSって、きっちり１秒ごとに計算するのが当たり前？

１秒ごとでない間隔で、算出してるのもあるみたいだけど

μ秒で時間を測れるタイマーがあるよな。
コレで計算すれば、１フレーム毎に計算する事も可能だ。
FPSというのは一秒間に書き換えられる画面の数だから、
[FPS]=1,000,000/[タイマーで計測された値]
で、FPSが出せる。

いや、それはわかってるんだけど・・・

俺がなんかおかしかったかな・・・

>6
991の言い方だと>5になるっしょ

>>6
推測で、>>10の補足をすると、
処理落ち中か、そうでないかは１フレームごとに判断される。
当然、秒単位より細かいタイミング。
ゲームで秒という単位を意識することはないと思う。

ｆｐｓって言葉を考えると秒なんだけどね。

一般的なFPS計算では
ある程度の長さの単位時間で区切って(必ずしも1秒ではない)
[フレーム数]/[単位時間(秒)]で計算して、[単位時間(秒)]毎に更新してる

で、
>>8
VSYNC取ってる限り1フレームにかかる時間は
処理落ち掛かってても(n/60)秒って離散的な値になるわけで
その逆数から算出する方法だと60,30,20,15…のように離散的な数値となる。
だからusで時間計測しても何の意味も無い。
このタイプでFPS表示をしてるゲームはとりあえず見たことが無い。

突然30FPSと60FPSの差が出てしまうのはウェイトの取り方に問題があるんでないかと
yaneSDKの方法ならそんな離散的な値をとることはなくなる

負荷がかかってフレームスキップよりは処理落ちさせたほうがいい
というゲームもあるけどな
細かい動きが重要な２D系はそうなんじゃないかな

しかし処理落ちしっぱなしだとゲーム変わっちゃうからなー。
低スペックPCでやるとゲームが簡単になっちゃうのは避けたい。

推奨スペック満たしていないマシンなんてべつに処理落ちしてもいいだろ
推奨スペックがやけに高いとかじゃないのなら別に切り捨ててかまわないような

６００MHｚ、ビデオも８１５や８３０以降のUMAなら半透明がんがん使っても
２DSTGとかならまず問題ないしね

逆にどうすればここまで重くできるのか・・・と悩むゲームもあると思う

>>17
学校でTAとかやってて課題のコード見てると、なんでこの処理するだけなの
こんなアルゴリズムしか考え付かないんだろうっていうものすごいことやる
人ざらにいるよ。

バイナリサーチやクイックソートみたいに大層なものじゃなくてもじゃなく
てもただメインループまわすだけでもどんだけでも遅くできる要素はあるけ
ど、あなたは正しい方法をある程度知っちゃってるからどう重くしていいの
か分からないだけだと思う。

>>1
エクステンド乙

ム板でこんなん見つけた。かっこよすぎ。

将棋シューティング　裸王
http://ece4co.vis.ne.jp/shooting/raoh.html

>>17
いあースコアランキングとかやってリプレイ見たとき思ったんだけど、
なんか処理落ちするような低スペック機でやると簡単になっちゃって
不公平かなーと…。

ゲーム中に処理落ちした総フレーム数を記録しておいて
一定以上処理落ちしている場合はランキング側で
集計対象から外すとか。後ろ向きな方法ではあるけど。

エディタでまだ何も入力していないのにオートコンプリートが作動した。
候補確定キーだけ押し続けていたら、そのままコードが完成した。

>7
俺の場合だけど、
Nフレーム分のリングバッファを用意して、毎フレーム時間を入れていく。
で、現在の時間とNフレーム前の時間との差を用いて、
「N/時間差」で最近Nフレームの平均FPSを毎フレームを求めている。

割り込みｽﾏｿ。
Ｃマガの来月号の予告でシューティングのタスクシステム
の記事があるみたい。

過去に出てきてそうな話題だけど、過去ログ見えないんで質問。
Windowsで「現在の時間」をとるのに一番いい（精度・機種依存の少なさなど）
のって何かな？（VSYNCを利用するのは除いて）
timeGetTime使ってるんだけどmsよりもうちょい細かいのが欲しいんだけど、
QueryPerformance系っていまいち説が多いし・・・

>25
2に張ってある関連スレを参照汁。

>>24
シューティングである必要を感じないな
Cマガも必死だ・・・

>>24
ライターが誰なのかが気になる。

というか、おまえらどうやって1/60秒のトリガ作ってますか

タイマの差分で１６．６６ｍｓまつしかないんじゃない？
リフレッシュレート６０で同期できるときはそっち使うことにしてもいいと思うけど。

つーかまだ詳しくないからできるかどうか知らないんだけど。

俺は QueryPerformanceCounter 使ってるけど
ノートPCとかでCPUの周波数が変わったりしたときに
ちゃんと動く自信ない…。

デジタル液晶にリプレースされた今、もう1/60秒にこだわる理由はないのでは

1/60秒にこだわる必要はないが
1フレーム分を表す単位時間は結局必要になるわけで
アケやコンシューマでよく用いられてる1/60をあえて使わない理由もなかったりする。

まあ液晶も普通のモニタも1/60に対応してない奴なんてないから無難なんですよ
対応してなかったらそのモニタが悪いっつーことでｗ

むしろ液晶がディスプレイの９割を占めるようになった今
６０Hzで固定されていて実に具合がいい

アナログのディスプレイの話じゃないすよ
1/60秒よりms単位の方が使いやすいなら、50fpsとか100fpsでもよかろうと

タイマー　評価：☆★★★★
間隔が短いと精度が著しく悪くなる
実用になるのは20〜25FPSぐらいまで
とにかくCPU使用率を低く抑えられるのが利点
実装も簡単

timeGetTime　評価：☆☆☆☆★
1/60秒を正確に取るにはやや精度不足
動作環境に左右されづらく多くの機種で安定動作
精度不足とはいっても通常の人間の目でわからないレベルなので
1フレームの長さを可変(17,17,16,17,17,16......�_秒)にして無理やり60FPSにしたり
16�_秒もしくは17�_秒固定で60FPSにこだわらない（秒あたりのフレーム数より
フレームあたりの時間にこだわる）実装などがある
動作する機種の多さと精度のよさ、実装の難度のバランスが取れていて人気がある方法の一つ
CPU使用率をいかに落とすかが話題になりやすい

QueryPerformanceCounter　評価：☆☆☆★★
伝説的に古い機種、周波数が動的に変わる機種で不具合が出る可能性あり
とはいっても実際はなかなか遭遇することはないだろう（これから増える？）
DirectX(Vsync)を使わない方法ではもっとも精度が高い

Vsync 評価：☆☆☆★★
DirectXを利用しなおかつ全画面モードのみで使用可能
1/60をもっとも正確に取れる方法です（1/60という数字が出てきたのがVsyncのせいなので当たり前ですが)
Vsyncはリフレッシュレートに左右されます
最近のPCモニタは高性能化され60Hzより75Hzや85Hzで常用されることが多くなりました
なので1/75や1/85ではなく1/60にするためにリフレッシュレートの変更が必要です
DirectXの初期化時に簡単にできるのですが一部のユーザーはリフレッシュレートを変更されるのを嫌い
不評を買ってしまう場合があるようです。
60Hzだとチラツキ（※)が気になるので変えて欲しくない。全画面はより弁（他のウィンドウサイズが勝手に変更されるバグ）になるから嫌だ。など問題も多いです。
また、Vsyncに間に合わなかった場合の時間ロスも大きくスペックギリギリの機種には不利な方法です。
※ 他に適当な言葉がなかったのでチラツキと表現しますがFPSを語る上でチラツキというのは誤解を生みやすい言葉です。反省。

>>36
ティアリングが萎える人間もいる

ＯＳにリアルタイム性のないもの使ってる以上
バックグラウンドで何も動かしてなくても負荷がない場面で
処理落ちやらなんやらがおきて萎え萎え

それがやっぱり昔からやってきた人間には理解不能

可変フレームレートのゲームならまぁティアリングは許容する

長文＆勝手な評価でｽﾏｿ
一応、数本作った上で調べてきたことをまとめてみました
ツッコミあればおながいします

より弁はVsyncじゃなく全画面の問題(timeGetTime利用時でもDirectXや全画面ぐらい使う)だったりと
書きたかったことを適当なところにインサートした感じもありますが勘弁してください

マルチメディアタイマが入ってませんが全く使ったことがないです。誰かレビュきぼん

P.S.
60Hzに対応してないレアなディスプレイもってますw

DirectXってリフレッシュレートの変更ができない環境のほうが多いんじゃ？

>>38
んじゃ、デジタルのディスプレイは許容しないということ？（そこまで酷い画面割れする？）
それ以前にWindowsでプレイするのが理解不能と？？

>>40
dxdiag使ってもダメか？

とりあえずリフレッシュレートスレくらい読もうぜ。既出しまくりだから。＞yqbKU33t

>>43
tnx
大体分かったけど、結局完全な同期方法を持たないプログラムが
タイマー等で中途半端に画面更新更新周期に合わせようとすると
画面が割れっぱなしになってしまうんじゃないすか？

>37
乙。
QueryPerformanceCounterが一番重いことも書いといた方がいいかも。
ちょっと多めに3D入れると、快適に動くスペックが、
QueryPerformanceCounterとtimeGetTimeでは全然違うし。
あと、このスレまでにあったtimeGetTime3倍掛けのやり方も書いた方が
いいんじゃないのかな。俺、VSyncを除けば
あれが現段階で一番バランスとれていると思う。

>>42
それ解決方法になってない

手動じゃなくてプログラム上で変えるってこと？
それはあきらめるしかないな。

ということはVsync取れなければ60fps位で回すのは辞めた方がいいね

正確に同期が取れないなら、あえて大きく周期を変えたほうがいいのかな？
60Hzなら、16msとかで取るとティアリングの位置が毎回近い位置になるから目立つけど、
20msとか10msならバラけるぶん目立たなくなる？

>>49
たしかに40fpsあたりにすると目立たなくなる
ものによってはこれでもいいだろうね

STGだとちょっと滑らかさが段違いできびしいかな

現実的には垂直同期ループテストして６０Hzっぽかったらそのまま垂直同期だけ、
多すぎるようだったら時間管理で16msで、というのが一番問題ないね
ウインドウモードでもそのまま時間管理にいくし

>40>47
最近のならたいてい対応してないか？

今ちょっと使ってるKyroIIな奴でさえ、設定できるんだけど。

>50
ところがどっこい、ShootingGame（仮）は20fpsでビックリ。

速い弾があるかでだいぶ変わるね

画面内に移動速度が速いものが無ければfpsが低くてもなんとかなると思うけど。
50fps(20ms)位でまわしておけばいいのかなー。
若しくはモニタの周波数になさそうな90fpsとか。

まぁ60FPSでまわせるなら、それより下を選ぶメリットはほぼ無いとは思う

50fpsやってみればわかるけどがたつく

なんかいまさらな話題な希ガス

50fpsだと60Hzのディスプレイを使った場合、10フレ分だけ同じ状態で
表示される訳だからかなりガタつくでしょ。
仮に100Hzのディスプレイを使ったとすると、全てのフレームが２回ずつ
表示されるわけだからスムーズになると思う。

もちろんこれは人間の目の能力云々の話とは別で

>>58
それは垂直同期が６０Hzだから時間管理で６０ｆｐｓだとがたつかないと
いっているようなものだ

実際は近いからこそがたつく

CRT使ってる人って、リフレッシュレートどんくらいにしてるの？
アクセス解析でコレわかればなー。

80Hz位にはするね
60Hzはちらつきが目立つ

俺は70〜75くらいかな。
上げすぎるとボヤけるんだよな。

CRTは８５で液晶は６０にしてる。というか液晶は６０しか選べないが・・・。
同期取れなきゃいくらだろうがガタ付くよ。同期取るタイミングが２フレーム置きか３フレーム置きかは別にして。

高解像度状態での60Hzは目に見えてチカチカするから75Hz
ゲームをやるときはDirectX診断ツールで60に上書きしてる

俺は普段は、75・・・にしてるつもりだったんだが、今確認してみたら60になってた
まぁ、慣れたら気にならないね・・・

ちなみにXPとかじゃないから、解像度別にリフレッシュレートとかの設定が保存されたりして、
微妙にラッキーだと思うことがある。

>>59
ティアリングとがたつきを勘違いしてる

>>66
ここでいうがたつきはティアリングのことかと

横槍すまんがティアリングじゃないがたつきってあるんだ

2フレーム分の更新を行ったが表示は1フレームしかできない→コマ落ち
垂直同期が取れずに1フレーム中に2フレーム分の表示がばらばらに表示されてちらつく→ティアリング

ってことではないかと

リフレッシュレートとｆｐｓを一致させないとカクカクするのががたつき
２Ｄスクロールゲームで試すと分かりやすい
ティアリングは垂直同期待ちしないで書き換えた裏画面を表にして
表示した時に画面に水平な線が何本か走る奴でしょ
ディスプレイの電子銃？がまだ水平走査している時に反転しちゃうわけだから
そうなるのは当然だよね

>>70
そうそう
がたつきという表現が明確に定義されているかは知らないけど、描画レートとリフレッシュレートの
回数の違いにより描画フレームが、0123345677等のように特定のフレームが他のフレームより多く
表示(又は逆に間引かれる）されてしまうのが原因。
高速の直線弾などボコッと1フレーム停止たように見えてしまう。

ティアリングは画面割れで、走査中に表示メモリを書き換えると生じる。同期待ちのメカニズム
を持たないプログラムではこれを避けることができない。
切れ目は描画レートとリフレッシュレートの差の周期で画面を縦に移動するので、この差が小さいと
ゆっくりと切れ目が画面を移動するため大変見苦しい。

あと、リフレッシュレートと関係のない問題として、ブレがあり、fpsが低いゲームなどで高速に
オブジェクトが移動すると残像が生じる（目の能力や、液晶の反応速度に因る）

ちなみに、より弁にならない対処方法。

画面モード変更前に、全部の画面を閉じておく。
いちいちハンドルチェックするのはめんどいので
キーボードイベントでウインドウズキー（VK_LWIN）+Mを入力すれば全部閉じる。

復帰時には画面サイズを戻してからVK_LWIN+シフト+Mキー。

全部の画面をって言い方は変だったな。全部のウインドウを閉じておくに脳内変換してくれ。

そして今気がつく。全画面ゲームってウインドウズキーの処理にだいぶ苦労するな。
いろんな全画面ウインドウズゲーでテストしてるんだが、ESCと同じ扱いで終了させたり
画面モードを戻してタスクバーにしまったり、みんな色々やってるようだ。
キー入力を渡さずに無効にする方法はないんかな？

そういえばフラ板行くとfpsさえでかければマンセーな輩がいるな

おれおれ。

いや、ID的に>>75自身か。

ウインドウズキーはマジウザイ

ALT+TABも

Managed DirectXのDirectInputにはNoWinKeyってフラグがあったがｗ
分かってんなら付けるな馬鹿MSが

オレオレ自演？

ｆｐｓの話になると確実にスレが荒れるな・・・

>>82
そのための専用スレですよ！！

FPS(ﾌﾚｰﾑﾚｰﾄ) VSYNC(垂直同期 ﾘﾌﾚｯｼｭﾚｰﾄ)
http://bbs.gamdev.org/test/read.cgi/gamedev/1063274576/

え、煽り合いを楽しんでるんでしょ？

そんな(煽り合いを楽しむような)連中と一緒にしないでくれ。といっても今回のｆｐｓ話題にはほとんど参加してないが。

ゲーム製作を楽しもうぜ。

まず、動くもの作らんとダメだな。うまくいったのを晒してくれればみんな使うだろうし。

おいおまいら、ウインドウズキーを無効にする方法を見つけましたよ。
普通はキーを離す時にメニューが出るのだが、WINキー押し→別なキー押し→WINキー離しだとメニューは出ない。
なので、WINキーが押されたら別なキー、例えばシフトキーを押して離したという情報を加えてやればいいんでつよ。

ただしCTRL+ESCなんかの複合動作でのメニューオープンなど対応できないけどな。

なるー。
まあWinキーを誤って押してしまうということには対処できるな。
同時押しはユーザーは分かっててやってるわけだからほっといて良いかも。

DX9でＷｉｎキー無効にする機能が付いたと思うんだが。おまいらＤｉｒｅｃｔＸのバージョンいくつで開発してんのよ？

3か5あたりが通かな。

俺は容赦なく9だが。

NT4.0も桶なDX3ﾏﾝｾｰ

>>90
9はDirectInput変わってないでしょ。
DISCL_NOWINKEYならDirectX7で既にあるのは確認した。

あったのか、しらなんだ。でも、対応して無いゲームばっかりなのはなんでだ？

>DISCL_NOWINKEY
> Microsoft Windows キーを無効にする。このフラグを設定すると、
> ユーザーは誤ってアプリケーションを終了することがなくなる。
> ただし、デフォルトのアクション マッピング ユーザー インターフェイス (UI)
> が表示されている間は DISCL_NOWINKEY フラグは無効であり、
> デフォルトのアクション マッピング UI が存在している間は
> Windows キーは通常どおり機能する。

よくわからんがほぼ役に立たないってことか。

アクションマップなんて使わないから充分役に立つぞ

Managed DirectXを使っているがDirectInputは激しく楽に使えるぞ
というかマジでMDX便利ですって

というか、DX9.0ｃから付属してるサンプルフレームワーク使えば、初期化ではまることはない。
思い道理に動作させられるようになるのは時間かかるだろうけど。

Ｐ−１３３とかターゲットにしてるんじゃなければ、さっさちＤＸ９．０ｃにしたほうがよさげです。

さっさちage

地点ＡからＢに向かってじょじょに減速してって、
地点Ｂでピッタンコに止まるようにしたいんだけどさ、
どんな計算したらいいんだか、わかる人オセーテ

積分習ったなら一発。
ゲームに使う数学物理学のスレがあればそっちむけの話題か。
数学や物理をどこまで習ったか書いてもらえると教えやすいかもな。高校2年くらいならもう習ってるかな。
習ってなくても時間かけて試行錯誤でやっちゃう人もいるが、それはおいといて。

この式を使いたい条件に合わせて変形汁。

x - xo = vo × t + a × t / 2
(xo:初期位置,x:目的地,vo:初速度,a:加速度,t:時間)

ちなみに減速だと、加速度はマイナスになるな。

>>101
直線上の場合なら、初期速度を vi , 時刻Tでの最終速度を 0

v(t=0) = vi
v(t=T) = 0

として、減速の原因となる逆向きの加速度を c とすると、時刻 t での速度は

v(t) = vi - c*t

で、位置（初期位置はr=0と仮定）はその積分で

2
r = vi*t - c*t /2

になる罠。加速度 c と止まるまでの時間Tの関係は自分で考えてね。
経路が直線じゃない場合は、もうちょっと難しいけど出来るよ。

一応書くが離散積分の場合はそれなりのことをせんとピッタリにはならんよ。
例えば前進オイラー法で積分するときに45ドットを10フレームで動いて停止する場合の解として

int velo = 10;
int pos = 0;

for(int i=0;i<10;i++) {
　velo += -1;
　pos += velo;
}

ってのがあるけど、>>103の言う方程式で計算すると矛盾する
45 = 10*10 + (-1)*10/2 = 50
連続な方程式が使えるのはdt→0の時だけ

dt が大きい場合を聞いているのでは？

ゲームなんだから厳密でなくてもいいと思う。

移動量＝残り距離/10

10は適当な数値。大きいほど遅くなる。
整数だと、残り10ドット未満で停止するから、残り距離/10+1とか足かせしておく。
浮動小数点だと、いつまでも減速しながら近づくから、残り１ドット以下になったら移動終了ってしとけ。

等加速度運動でいいんなら、等差数列をつかうとうまくいくよ

>107

簡単で使い勝手よさそう
使わせていただきますm(_ _)m

>>105
あ、間違えた。>>103

x - xo = vo × t + a × t × t / 2
が正解。

>>107
俺の秘蔵のテクを勝手に書くんじゃねー

というか便利ですよこれは、本当に。

よかったよ。
記憶違いか積分を忘れたか、と焦ったじゃないか。
思わず生徒時代の物理の教科書引っ張り出したよ。
来年３０になるしな、高校時代なんてもう遠い日の思い出。

>>110
俺も後で見直したときに式が間違ってた割りに答えが合ってて笑ったんだが…
「45 ≠ 10*10 + (-1)*10*10/2 ＝ 50 だから矛盾」かな。
ちなみに>>103のまま計算すると値は95

>>107
一見便利そうだけど、
時間tでX移動したいとか思ったとき
結構めんどくさくねえ？

厳密に動かしたいんだったら厳密な方法でやればよろしい。

加速度やら、疑似空気抵抗やら、摩擦やらを入れると、挙動としては正しいし、
動かしても納得の出来る動きになるけれども、計算が面倒になるよな。

まあ、現実の戦闘機にＳＴＧみたいな動作をさせるのは無理
だから、そこまで気にする事ではないのかもしれんケド・・・

シューティングにそんなの望んでる奴がいるのか疑問

もったりした動作が良いなら、等加速度運動が良いし、
その状態でごく自然な最高速度を設定したいなら、
空気抵抗みたいなモノを定義しとけばいい。
その意味では、物理学は大事だと思う。

けれども逆に、ゲームの面白さと物理的な説得力は、
必ずしも結び付くモノでもない。

これは、シューティングに限った話ではないな。
むしろ、どのジャンルにでも言えることだと思う。
ゴッチャにしてる人が多いケド。

等加速で止まる程度ならともかく、いろいろ変数が増えると手に負えなくなる予感。

現実の機械だって、こういうことは解析的にはやってないんとちゃう？
ファジー制御とかである意味適当に止めてそうだが。

必要無い、でFA

プレイヤーが思ったとおりに動くようにするのが一番いいんですよ

製作者が楽しいと思えるゲームなら、
遊んだ人間が楽しいと思える可能性はある。

当然のことを勝ち誇ったように！

クリエイターに当然という言葉は必要ない！

>>124
製作者の楽しめないゲームが売り出されている限り、
こーゆー話は出てくると思うぞ。

つまんないと思いながら作るんですか・・・

>>127
実際、それで商業辞めて同人に来るヤシも少なくは無い。

最初は楽しいつもりなんだけどね…
先に役員を喜ばせないとイカンのよ…

だから、製作者自身が楽しめるゲームなんてほとんどないって。

どんなに良くできたゲームでも10時間や100時間で飽きてしまうのに、
それを作るのには月単位、年単位の時間がかかるんだから。
ものづくりは甘くねー

>>130
> どんなに良くできたゲームでも10時間や100時間で飽きてしまうのに、
> それを作るのには月単位、年単位の時間がかかるんだから。
> ものづくりは甘くねー
MMORPGとかなら年単位で遊ぶから大丈夫。
... と、思ったが、あれは開発時間もさらに、だしな。

敵キャラの配置決めた後実際に遊んでみて楽しくて仕方ないんだが…。
そんな俺は幸せなアホですな。

俺「とりあえず最低限の敵出しした」
　↓
俺「おもれー」
　↓
テストプレーヤー「おもれー。これこれこうしたらどうよ」
　↓
俺「修正したー」
　↓
テストプレーヤー「いいかんじじゃん。続き作れよー」
　↓
俺「うーん。めどいしちょっと調整を…」
　↓
俺「うーん。もう少し調整を…」
　↓
俺「あーん。調s(ry」
　↓
テストプレーヤー「さっさと続き作れよ」

>>132
いいじゃないか、まさに理想的だ。
楽しいうちはモチベーションも維持するのも楽だし、なにより作業が苦痛じゃないっしょ。

>>132
そのモチベーションを最後まで持っていられるんであれば大変素晴らしい。

>>130
確かに甘くないね。けどプレイに関しては、
シューティングは一回クリアしただけで終わらないが理想だから、
やはり飽きないゲームが理想だね。
そりゃぶっつづけで何時間も連続、では飽きることあるだろうけども。
何度でもたのしめるもの、それには今までにないような
新ｓ（ｒｙ

そかなぁ？
Flashのゲームなんか、ベクタあたりに転がってるシューティングより
はるかに面白くよくできてるのが結構あるけど、あまりやり込まなくても
手軽に最後まで見せてくれるのでありがたい。
昔はゲーム自体少なかったし、ネット環境も悪かったから同じシューティング
を何度もプレイしたけど。

アタリ判定について詳しく書かれてるサイトない？

それはクリアすることにしか楽しみを見出せてないからそう思うんだよ。
オレなんかはドドンパチが好きなんだが、ＨＩＴコンボが繋がってるのが楽しいので
クリアするよりも5面いって生き残ることの方が楽しめる。

５ボスまでノーミスでいけるようになってもクリアしたのは2回だけだｗ

忙しいけどより多くのゲームをプレイしたい人もいるだろうし、作者の挑戦に
応えたい人もいるだろう。
攻略してもらいたい作りか、自分のメッセージ（やりたいこと）をより多くの
人に伝えたいのか、その辺も考えて調整する必要はある。

ただよほどの物でない限り、ほとんどのゲームシステム、ギミックが徒労と
なって日の目を見ることがないという危険性は否めない

敷居は低く、学習効果が高く、それでいて奥が深い
ってのが理想なんだけどね。
言うは易し。

１プレイを短く、クリア自体は楽、けどプレイによってスコアに差が出るような．．．
最近のプレイスタイルから見ると某自爆ゲーみたいなのが理想的かも

その方向性を突き詰めていくとミニゲームになっちゃうからな。
理想を追い求めるのも悪くないが、加減も大事だよ。

ミニゲームってのもイマイチわからない言葉だな。

>>138
ちっとも詳しくないが
こんなん張って混乱させてみる
ttp://www.aya.or.jp/~sanami/peace/memorial/code11-20.html#CODE14

>>145
>やねさんからVisual C++6.0に付属のSTLはHewlett-Packard製であるとの指摘をいただきました。
この指摘も間違ってるし…

>>146
本当はDinkumware製だっけ？

ttp://www.geocities.jp/koumotsh/
の20041102すごいな、多弾ベンチマークってとこか
うちだと弾15000発くらい出た
全画面モードだと起動直後に500〜700に抑えられてしまうけど
DirectXを9.0cにするとか、VC環境入れて手元でmakeするとか、そのあたりはまだ試してない

XPSP2プレインストールマシンだけに最初からDirectX9.0cだがまったくうごかねぇよ

>>148
凄いというよりキモイ。
実際、ゲームにして何がおもしろいのかわかんねぇーし。

ベンチマークとゲームの面白さが関係するという発想がわかんねぇー

>>151
おれもわかんねぇーｗ

ジェノサイドサーキットの人だね。

ベンチマークといわれてFF11やゆめりあ、3DMarkなど、
処理速度計測よりもゲームのデモのようなものをイメージしてしまう人も、最近は多いのかも知れないな。
ベンチ詳しくないんで今適当にぐぐってタイトル挙げただけだが。

ベンチといえば、森ベンチしか浮かばん

ちゃちゃベンチがメインだった

ゲフォ専用のなにかを使っているんだろう。ガメンクリアもしてないみたいだし、ウチでもうごかね。
AthlonXP3000+ RADE9800XT

>>157
アホちゃうか？ゲフォ専用？
HardwareShadowMap使ってるように見えるか？
WBufferDepth使ってるように見えるか？
ソース入ってるのに読めないの？文盲？

単純な話だよ。DirectXのプロパティでreleaseに変えてみ。debugだと引っかかる。

いやそんな罵倒しなくていいから

実は本人

読めて当然と思っている模様。

ずいぶん気に障ったみたいだなｗ　ソース読んで動かすほどのものなのか。

＞文盲？
動かす方法があるならちゃんと書いてURLはっとけや。いちいちソースみてるやついるか？

main.cppに
static BOOL            systemTask(void);
static BOOL            SystemTask( void );

ってあるけど、どこからも読んでないのはいいとして、あやしげな名前の付け方してるな。
良く間違えないもんだ。


つーかどこ読めばdebugモードだと動くってわかるのか、ＤｉｒｅｃｔＸ初心者のオレにもわかるように教えてくれよ。

>>158
見てないから知らんけど
それって、DirectXのエラーでアボートなりアサートなりしてるて事か？
ようするにバグがあるとｗ

なんか俺、作者扱い？それは嬉しいな。
「森のクリスマス」以来のファンだし。

とりあえずID:x7tYJ7viは必死過ぎるから。

客観的に見て必死なのは158だと思うがな

いや、159のEUpD603bが必死過ぎるぞ。

必死な人の多いスレでつね。

158がもう少し普通の書き方してりゃこんな展開にはなってないと思うが…

>>158は>>157の言動にカチンと来たみたいやね。
まあ、158はハードウェアマニアなんだろな。

というか普通は、
わざわざ参考になりそうにないようなソースは読まんぞ。
参考になりそうなソースなら、話は別だが。

ID:gc/yghlK必死だなwwww

IDと冷めた視点からして170が作者

滅殺回路のひとだね。有名な人じゃん。
本職が絵描きらしいからバグぐらい見逃したれよ。

http://www.itmedia.co.jp/news/articles/0411/04/news023.html

・・・・もうね、アフォ（ｒｙ

アメリカ人はバカなので仕方ありません。

ってことはなにかよ、俺ら自分の作ったゲーム、
英語版Windowsでは起動できないようにしなくちゃならんわけ？
やってらんねー。

どういう判決が出るかだよな

リスト見ると日本叩きが目的じゃないのか

"TV"じゃなければおっけー

なんて理由がとおったりしたら笑えるけど、特許だと意外とあるかも。

>>179
全然。
EAやLucas、THQ、Ubiだって入ってるじゃん。

でも日本企業が明らかに多いわけで。
・・・ああ、日本の技術力が高いからか。

別に日本の技術力が高いわけでは無いが

>>163
debugモードとDirectX初心者って何か関係あるのか？

しかしＰＣには甘く、家庭用ゲーム機がその主な矛先だったら　((((；ﾟДﾟ)))ｶﾞｸﾌﾞﾙ

Σヽ(ﾟДﾟ; )ﾉ
M$の陰謀かっ！？

UbiにVivendiにEAだろ。全然PCに甘くないし。
・・・そういえば確かにリストにM$入ってないな。

NINTENDOも入ってない。つまり、弱腰企業を狙い撃ち。

あるいは既に和解を済ませてるか。
コイル氏事件なんてのもあったな。

アメリカは交渉が主体の国だからね。交渉で弱気になれば、必ず負ける。
なぜならあの国では、論理はあくまで、交渉のための道具にすぎないから。

>>188
任天堂、ソニー、マイクロソフト。
ハードやシステムを供給しているところを避けている感じがする。

>>191
下手にそーゆー所を訴えると、訴えの前提になる足元を、崩されかねないからだろ。
なるべく無知なヤシを狙うのが、こーゆー連中のやり方。

なんかやり口が総会屋と変わらん気がする

まあアメリカだし

BulletML記述に関して、質問があるんですが、どこで聞いたらいいでしょうか？ここですか？

>>1を見るに、ここで良いっぽい。たぶん教えられる人がいる筈。

それでは質問させて頂きます。
BulletMLで敵機から自機の距離を得ることは出来ますか？
Luaじゃなきゃだめでしょうか。
あと、そもそもBulletMLで弾幕を作れるようになるには、どうすればいいでしょうか？ソース見て研究？

うむむ、教えられる奴が降臨しないな。
すまんが俺にはﾜｶﾗﾝ。

BulletML使い、以前は見たんだが最近は多忙か留守か
こういうときこそBulletMLを普及させるチャンスなんだけどな

ﾏﾀｰﾘ待ってます。

・BulletML使ってるゲームの.BMLファイルをいじる
・webにいくつかある、BulletML体験Javaアプレットをいじる
このあたりが入り口なのかな？
リファレンスはLibBulletMLあたりかその他の付属ファイルか。
BulletMLを実際に組み込んでみる際のコツを解説したページもあったな。
BulletMLwikiあたり作って情報集めるのがいいのかもな。
それに類するポータルがもうありそうな気もするが。

このスレで聞いていい物かどうかわからんが聞いてみる。

ある画像にぼかし処理いれたいんだけどどうすればいいのかわからん。
ソースつきで誰か解説頼む。

「ぼかし処理　ソース」でぐぐったらトップにそれっぽいのがヒット
もうすこし検索ワードを工夫すればもっとヒットするだろうな

>>197
誰か他の人が答えるかなぁ〜と思ってたんだが誰も答えないんで答えとく。

BulletMLでは自機までの距離を得ることはできない。
勿論、自分で仕様を拡張しちゃえばできないことはない。libBulletMLはオープンソースだし。
まぁそんなところで。

>>201>>204
ありがとうございます。正直言って、僕プログラミングはかじったこともないんですが、
このへんを切り口に頑張ってみます。

DOSでも使える弾幕のツールってあるっけ？　友達が聞いてきたんだけど・・・・

よくわからんがPC-98DOS用シューティングツクールとかの話か？あるか知らないが。

なんで今更DOSなんだ

専門学校でDOSのゲームを作ってるらしくて・・・スレ汚しｽﾏｿ

DOSでも何でも基本は同じでしょう。
『弾幕のツール』が何を意味してるのかサッパリ検討が付かんけど･･･。

BulletMLのコンセプトは面白いと思ったけど、
こんなんそのまま使えるような単純なシューティングなんて作ってねーしとか言ってみるﾃｽﾂ

技術ある人は自作するから使わないし、技術無い人は使いこなせない、そういう感じ。
ABA GamesのSTG見てるとかなり高度なこともできているようだけど、
あのレベルでやろうにもBulletML以外の部分が必要(?)に見えて結局やれない。
ソース読んで盗める技術のある人にとっては問題ないのかも知れないが…。
BulletMLだとかゆいところに手が届かないようだ、じゃあ使うのやめて自作だ、という人はいると思うんだが、
そのかゆいところに手が届きづらい例と対処法の蓄積があるといいようにも思う。

ABA Gamesの新作出たけど、やっぱあれもBulletMLだね。
あの人の作品って細かいギミックとかじゃなくて、
一発ネタとセンスで作ってる感じだからBulletMLで十分なんだろうね。
なんだかんだ言っても、BulletMLはABA Games専用なんだろう。

TUMIKI Fightersは割と遊べる難度調整だったなあ
あれのおかげで、そうかBulletMLもまともなSTG作れるんだ、と思ったものだ

乱数否定組が沈黙するABA Games

↑自演乙。

え、神様降臨？？

本人じゃなかったら
他人の作ったもので威張り散らす勘違い君だな

乱数否定組とか勝手に集団にして敵視してるし
沈黙するとかも勝手な妄想だし

・リプレイファイルに乱数の種を記録するといいよ　→　リプレイの是非で荒れた
・ある種のゲームは乱数をできるだけ減らすと面白いよ　→　乱数ゲーを否定されたと勘違いして荒れた
こんなとこだったか。

>>216 ･･･ 湿気た撒き餌
>>217 ･･･ ボケた
>>218 ･･･ 食い付いた
>>219 ･･･ 相槌打った
>>220 ･･･ 冷静に火消し
>>221 ･･･ 氏ね

s/216/215/
s/217/216-217/

わけわからん

>>221
ノリツッコミかよ？

言ったネタをなおしたらおしまい

ネタ投下。
もまいらCマガジンのタスク特集は見ますたか？

それは今でも買えるものですか

見たけどびっくりするくらいイラネ

Cマガ買ってみました。
関数ポインタ + ワークエリアってまんまクラスだと思うんですが。
結局昔の人がCでクラスのような考え方を実現するために編み出した技で、
Cしか使えない環境ならまだしも C++ でわざわざやるメリットがあるのか
疑問に思いました。

>>226
ツマンネーネタはイラネーヨクズ

（´・ω・｀）ショボーン

クラスとコレクション使えればいいだけなんだよな

タスクシステムってステートマシンと思っていいの？

Cつーか、アセンブラで編み出した技だな

異種の物を複数登録して順番を並べ替えたりすることが
自然にできる上に高速でタスクはクラスとは違ったメリットがあるな

それは共通のインターフェースから継承させるのと同じじゃないのか。

なぜタスクがゲーム向きかというと
ワークはあらかじめ確保されている中から割り当てる
だから、
mallocなどをしないので頻繁にオブジェが生成/死亡されても
メモリが断片化しない &
家庭用ゲーム機のようなメモリの限られている環境でも使いやすい

それとプライオリティの概念がある から　PAUSEも簡単に実装できるし

とにかくタスク固有の機能は色々とメリットがあると言うこと

そういえばC++版のタスクシステムも紹介されていたなあ

パソコン用のゲームなら敢えてタスクつかわなくてもおk？

>>238
てことかもw

ステップ処理で書くよりも、驚くような効果が簡単に書けるね、タスクだと

オブジェクトプーリングというのもあるし、
一概に言えないけどね。

>mallocなどをしないので頻繁にオブジェが生成/死亡されても
メモリが断片化しない new/delete のオーバーライドでいいじゃん。
うまくやれば可変長にも対応できるし。

もしかしてメモリプール + リストでオブジェクトを管理して、
オブジェクト内に、現在の状態を処理する関数のポインタを持たしてやることを
単にタスクと言うのかな？

実装方法の違いだけだからそれでいいんじゃね？
単にタスクって単語はあいまいすぎるしな

しかし、断片化しまくりのnew使いまくりのGC前提のJavaですら
アレだけ早いのはうまい管理してるんかね？
ヤング領域のGC速度はやすぎ

GCを言語レベルでサポートしてる場合は
手動でメモリ管理する言語よりむしろ速いことが多いらしいよ。

>>244
速いのは当たり前
問題はいつ遅い瞬間が来るかだ

>>245
それ細かいこといったらリアルタイムOS搭載してないマシンでは
常にそれが起こる可能性がある
仮想記憶搭載している時点でまずあてにならないな

タスクと呼ばれるものの考え方を理解するメリットは仮想メモリもってないコンシューマ系に
そのまま生かせることだろうけど。

せめてGCが任意のタイミングでも呼び出せるようになってれば使いやすいンだがなぁ。

任意のタイミングで呼ぶことはできるよ

壁|・） ｺｿｰﾘ





壁|ミ ｻｯ

よかったな

Javaなんかはgcを呼んでも、その時にgcが起こるかどうか保障されない、だからね。
携帯Javaの場合はちゃんと任意のタイミングで起きる。

一応仕様としては保障はされないが
J2SEでSUNの実装でちゃんと呼ばれる

が、old領域もGCするので意味なし
ループ中で使うメモリ量を把握してヒープ領域とnew領域の割合とかいじって
System.gc()は呼ばないほうが早いというわけだ

JavaはGC時間が１ｍｓ切ってるので通常のWindowsアプリなら
なんの問題もないと思われ

newの後のdeleteは意識はしないが使ってるメモリ量は把握してコントロールできてないと
GCおせーって思う馬鹿が出現するから注意

なんかタスクとメモリ管理が混ざっちゃってる奴いねーか？

> それとプライオリティの概念がある から　PAUSEも簡単に実装できるし

ここが理解できないんだけど、
PAUSEって何ですか？

>>254
アクションゲームでさ、
コントローラのStartボタンを押したら画面に「PAUSE」
とか文字がでてゲームが一時停止するでしょう？
あれのことだよ
つまりそれぞれのタスクがプライオリティとかの値を持っているから
指定したプライオリティのタスクは一時的に停止状態にするとかできるからこういう機能も
タスクなら簡単に実装できるってこと
一時停止だけじゃなく場面が変わる時に敵の球をまとめて消すとかそういう事にも使える

PAUSEさせる場合は素直にゲームループの処理関数の制御を
PAUSE関数（処理は一切しないで描画のみ）に移行させるだけだなあ

>>255
分かりやすい説明をありがとうございましたm(_ _)m

タスクでのPAUSEはSLEEP(一時停止)していない
タスクは動いたままだから
キャラは止まっているけど
背景は動いてるとか みたいな事とかできたりするわけよ

タスクって便利な言葉だなぁ…。
何か特別なことのように感じるよ。
個々のオブジェクト毎に管理番号、状態番号を
持たせるってのはゲームのプログラムじゃ当たり前な気がするけど。

もうひとつタスクのテップ処理との大きな違いは
タスクはプライオリティ(優先度)順に実行される点

キャラクターとかは普通、個々のタスクは自分で描写しない

オブジェの描写専用タスクを作ってここのタスクが登録したオブジェを表示したりする
これもタスクと似たようなリスト構造になったものを使って背景の後で優先度順に描写されていく

ステップ処理って何？

>>260
描画は一つのタスクがまとめて行うってことですか？
もしそうならサウンドの再生なんかも普通は一つのタスクでやるのかな。

>>262
DirectSoundの場合はサウンドにタスクいらないんじゃないかな

各キャラの描画もそれぞれ別タスクじゃないの？

クラス(タスク)の設計による、
タスクシステムの枠にとらわれてクラスの設計が制限されるのでは本末転倒かと

あー、タスクもすっかりいかがわしい言葉になっちゃったね。まるで幸運を呼ぶ壷。
「プロが使う秘蔵のテクニック」みたいなノリで、偶像化されてしまってる気がするよ。
お前実際にそれで１本作ったことないだろってヤツが平然と語ったり記事書いたり。

最近はタスクなんて口に出すのも恥ずかしい。マジで。
これ一発で、ワナビーかフェードアウト組認定されかねんもんな。
「いわゆるタスク」とか前置きつけてみたり（ｗ

アセンブラやC時代ならともかく、今ならまずC++で普通にOOPしろよと。
それで追いつかないような規模や複雑さのプロジェクトになったときに
初めてここの日記↓のリンク先のような議論が生まれるんだけど、
http://www.radiumsoftware.com/0307.html#030702
ほとんどの人には関係のない話だべ？

>>266
まあ昨今の3DゲームならC++じゃないとやってられないだろうね
実装の一つの手段としてそれを用いているわけでイカベーダも
ダウンロードしてきたサンプルのタスクシステムを使った物

趣味の範囲でやってるから古いやり方にとらわれのフェードアウトがどうのとかあんまり関係ないんじゃないかな

複雑なのはOOPじゃないとやってられない
単純な２DSTGはOOPの恩恵も大きいのでOOPじゃないとたるい

どっちにしろ必要だな
PC対象ならなおさら

>>266
＞後になって，プレイヤーが「ドア」と会話する必要が出てきたのだ！
ﾜﾗﾀ

まぁ高度なのをやりたい人は高度なとこに進めばいい

>>266
俺もC++しかしらないときに継承ばかりではまったことがある

Javaをやるようになって継承と実装という考え方で涙がこぼれそうになったのを覚えている

今思えばかなり恥ずかしい過去だが、もう7年以上前なので時効

まぁ、そんなこと知ってても知らんでも完成してしまえば関係ない罠

中にはシューティング海原雄山みたいなのがいて
「こ、これはOOPだがそこらの素人の物ではない！、なにか別の．．．」とか言ってるかも

死のダイヤモンド！

>>256
ポーズメニューがオーバーレイ表示されるような仕様が来たらどうすんだ？

継承だとコード重視になるね。
データドリブンで賄えるなら、タスク管理が都合が良いかも。
両方使えるようにするのが一番か。

いい加減Ｃ＋＋に移行したほうがいいんだろうが、最近Ｃ言語しかサポートしてないハードやらされて
Ｃでよかったなと思ったよ。
Winでなんか作るときはなんちゃってＣ＋＋プログラミングだが、使い慣れてないとなかなかしんどいね。

練習がてらにタスクシステムとやらをＣ＋＋で構築してみるのがいいんじゃないかな。なんでもいいなら。
１度も使わずにアレコレいっても良くわからんもんだし。オレはシューティング作るならＣで十分だけど。（ワラ

プライオリティがあればタスクシステムじゃなくてもいいってこと？
タスクシステムの解説をいくつか読んだけどプライオリティの説明はおまけ程度か
省かれているものばかりだったのであまり重要な機能じゃないと思っていたよ。

プライオリティとかいう名前の割に、種類とかそういった意味でも
使われてるのが気になる。

プライオリティーという表現が一般的なのかどうか分からないけど
プライオリティーがある範囲内の数値のタスクを停止させたり
タスクリストから削除したい場合に便利という程度かな
これはタスクシステム特有の物ではないと思うけど
例えば弾幕シューティングで、今画面内を沢山の敵弾が動いているものとして
Ａという敵キャラが吐いた弾だけを消したい場合、Ａから吐かれた弾にＡとの結びつきを表す情報を入れておく
タスクリストを先頭から辿って、Ａ情報が含まれる弾タスクを消す

処理の優先度を表すことに変わりないが、作る時にはオブジェクトの種類と考えた方が都合が良いという皮肉。

タスクの利点とされる「汎用性」は果たして意味があるのか、最近わからなくなってきた。
処理の順番に柔軟性を持たられせる意味も、全てのオブジェクトを一元管理できる意味も
チェンジタスクの意味も、本当にあるのか？

どうせ作りやすくしようとすればするほど汎用性なんか失われてゆくんだ！全て無駄だ！

何でも出来る行儀の悪いプログラムになりがち。

チェンジタスクの派生型としてコールリンクって言うのもあるね
BASICでいうGOSUB RETURNみたいなの
漏れはその存在を知って自分で実装したけど

あと一定回数停止とか

>>278
そこで新しく追加された変数が属性ですよ
優先度に対して一斉から　属性に対してに変わっただけだけど

で、さらに進化したのが親子タスクだね
親が死ねば子も死ぬっていう

これはサイトで公開されてる奴にはないね

優先度はenumで(PLAYER,ENEMY,PSHOT,ESHOT)ってかんじで表現したようなものじゃなくて

0x0000から0xffff という範囲にすると汎用性があがるね

まあ必要になったらタスクを拡張して機能を付けちゃえばいいんじゃない

>>281
?
ttp://www.hh.iij4u.or.jp/~peto/index.shtml

>>282
そうです まあそこの受け売りみたいな
2chにアドレスはるのって気が引ける

犯人は手に噛み傷を負ってる可能性大だな

閉鎖って・・・いまのうちに保存しておかねば

閉鎖・・・マジだ。
ということでHPを丸ごと保存しましたｗ
ロジシャンロードの管理人って、ゲームプログラマなのかな。

今まで列挙されたタスクシステムの機能は全てSTLに含まれているわけですが
そのあたりはどうお考えですか？

STL?

プライオリティ付きタスクのことを言ってるならpriority_queueのことかな。
まあ「タスクシステム」なんていってもあんなものは結局
メソッドつきオブジェクトのコレクションでしかないからなー

まあ仮想関数よりは関数ポインタのほうが速い罠

仮想関数より委譲使わない？

>>287
STLにタスクシステムのようなものが含まれているんですか？
よろしければ詳細をおながいします。

俺がＣ＋＋で組んだ時は、仮想関数,list,vectorぐらいしか使わなかった。
生成にファクトリ、チェンジタスクにステートパターン使った。
タスクマネージャクラスで管理。こんな感じ。

まぁ、ゲ製ですから

最近C#に移ったが全然遅く感じない。生産性が上がりすぎで満足してる。
C++にしてもその辺のシステム周りの速度低下なんか気にしなくていい。
仮想関数の呼び出しが遅いったって微々たるものだよ。

プライオリティの設定なんぞしなくても
STLならlist<Enemy*>、list<Bullet*>、…って感じで何本もリスト用意するだけ
(ちなみにSTLは速度に最適化してあるため速度云々の話は無視できる)

まあ如何にして楽に作るかですよ

なるほど、参考になりますです

>>295
逆コンパイルするから晒してくれ。

>>295
いまさらだな

.NETとJavaをずっと使ってきた俺はもうC++とか組む気にならねー
それくらいの生産性の違いはあるよな
型が強いとかコンパイルチェックが強いとしぜんとバグは取れるし
そのぶんゲーム自体にかける時間がとれる

昔はこれでもポインタ操作がないことに不安を覚えたものだ＞Java
よくよく考えると8bit時代Basicで遊んでたわけだから
ポインタ使うかどうかなんて方法論でしかない
ならないほうが後から追いやすく安全だしね

一人で作ってるならまだいいがC++だとほんと人による能力の差が影響しすぎる

最近はJavaのServerHotSpotVMをリアルタイム系で生かす方法が
あるかどうか調べるのが熱い

まぁ２DSTGならインタプリタモードでも余裕だけど

語りたいだけ語ろうや
ここなら少しくらい恥ずかしいこと言ってもスルーしてくれるし

>>295
ﾊｹﾞﾄﾞｳ
さらにEnemyやBulletがoperator newをオーバーライドして
メモリプールから割り当てるようにすると。

>>295
親子関係を持たせるのが面倒そうだから今まで敬遠してきたけど
その辺どうなの？

>>298
出来ればどの程度いけるのか晒して欲しいな。
参考になるものがないから、取り敢えずＣ＋＋で作ったけど。

>>300
その辺は手付かずなんですが、Enemyなりの、最大サイズを数種類、数百個単位で
メモリプールを用意しておく。という感じ？(STLPortの内部defアロケータはそんな感じだとかどっかで見た)

>>301
基底クラスは同じでしょう。で、キャストとか。
突き詰めるとツリー構造になりそうな気がする。
コンポジット使ってるとか。

＞まあ如何にして楽に作るかですよ
同意。俺もこれを意識するようになってから、ゲーム製作の進捗が大きく進んだ。

シーン切り替えとかが死ぬほどめんどくさいんだけど
なにかいい手法ってないのかねえ

>>302
そうそう。
ある程度の種類ごとの最大サイズで確保する。
テンプレート使って種類ごとにプールを持っておけば、
例外的にデカいクラスのせいで無駄な領域確保する必要もない。
初期化時に確保する数を指定出来るようにしておけば
余計なもの作り過ぎないで済むし。

どの辺りが？
自分の場合は、タスクに似てるけど、別のクラスを用意して管理してる。

現状では、タスクを全削除＞生成してるけど、予定では、ゲーム中で共有するタスクと、
ステージ固有のタスクに分けるつもり。
ＳＴＧの場合はあまりいらないか？

ステージ切り替えがメンドウなのはステージ間に持ち越すデータをいきなり定義してしまうからだろうなぁ。
たとえばＳＴＧだと自機の種類とか残機とか。
ステージ間を持ち越すデータを管理する処理系作って、ステージ作るときにそこからステージ側にわたしてやって
終了時に戻すような流れにすれば比較的無難に収まるかと。
リスタートなのかクリアしたからなのかの判断してから戻すようにするとかね。

適当に作ってはまることもままりますが。

>>302
一番気をつけるのは絶対的な速度的なことではなくGC時間
これのチューニングを出来上がったあとにするだけ
使用するメモリ使用量とかによって数値をいじるだけだからそんなに大変なものではない
ゲームの種類によっても調整方法はかわるだろう
たとえば数分間しばらくGCはでてこないが、GCがいざおきると0.5秒かかるとかで遅い
というほうを選ぶ場合もあるだろうし、こまめにGCがおきるものの1回のGCにマイクロ秒
単位を期待するほうを選ぶ方法がある
STGでは主に後者かな

実際にJavaで２DSTG作ってもCPU使用率５％いくかどうかなんで
速度部分にはまったく問題ないね
インタプリタモードでも１０％いくかどうか
だからVBだろうがHSPだろうがなんだろうが言語は問題じゃねー

それならば安定した品質がかける言語を選ぶべきだろう
人によっていわゆる合う言語は違うだろうけど

ちなみにJavaでインタプリタモードにするとアクセラレーションがきかない描画で
いろいろと重くなるのでさすがにお勧めできない

SDLをJavaから動かせばLinuxでもWindowsでもコンパイルのしなおしすらいらずに移植できるな
アクセラレーションも問題なくできるし

ちなみに.NETのほうがゲームに向いていそうでありながら情報が少ないので
Javaベースで開発、移植したほうがいいかもしれない
本当にJavaと.NETはちょっとしたところだけが違う

あと.NETは名前が悪い　googleとかで検索条件にいれにくい

検索で調べることしかできんのか？

頭の悪そうな煽りが始まりました

>>308
いいこと聴いた

久々に来たらシューティング製作とは関係ないスレになっとるな
くだらねえ

雷電IIのリーマンレーザーで盛り上がってた頃が懐かしい

何だじじぃ。昔を懐かしむばかりで周囲に合わせられなくなったら終わりだぞ。
文句を言う前に自分で雰囲気を作ってみてはどうだ？　くだらねえ

ま、そんなのはどうでもいいんだが、当たり判定の今の流行ってどういう感じ？
ちまちまと座標確認するのは変わらずなんだろうか。
長方形、半径、いっそ１ドット、どういうのがいいんだろ？

当たり判定に流行も糞もねぇ

・現在流行だと思うゲームの判定を調べる
・自分が真似したいゲームの判定を調べる
好きなのを選べばいい
質問する前に、自分の作ってるSTGの判定とかそれについての考えを晒せば？

半径はお勧めしないよ。
長細いのとか設定するのに複数の円が必要になるから結局手間になるだけ。
長方形と不定形の組み合わせがいいかもね。
弾とかは長方形で大きいものが不定形。

>>317
不定形というのは、物体の領域のマスク画像みたいなのを予め用意しておいて
１ピクセルずつ判定するということ？すごく重そう。

不定形->多角形=三角形の集合です。
意味不明でごめんなさい。

処理は重い部類だと思うけど自由度が違う。

そんな細かく形に合わせて判定する必要があるとは思えんが。
前もこんな話でたなあ。

あ、多角形ね、なるほど

>>320
細かくなくてもいいのさ。
菱型のシルエットの敵や、回転するアームとかに判定を付けるのに
矩形を沢山、円を沢山、よりもそれっぽく付けれれば。

まぁ、PCがくそ速いいまなら自分がやり易いようにするのが一番だけどね。

俺は矩形判定でやってるなぁ。
敵とか自機とかのオブジェクトクが矩形判定を複数所有する　みたいな。

オブジェクト回転させると、x,y方向固定で中心座標だけ回転するっていう、
グラIIIのシャドーギアみたいな仕様。
そこそこな数に分割すれは十分実用範囲だ。

そしてこうなるわけだ
http://www.pureweb.jp/~targest/sagifile.htm

>>323
おまえグラIIIやったことないだろ

ていうか、>>323が主流だと思いますよ。
回転による絵からはみ出る判定も、判定の隙間もちゃんと設定すれば発生しない。
俺は面倒くさいからやんないけど。
まぁ、頂点位置を作るもの面倒ですけどね。

ショット方向と垂直方向に長い長方形をはみ出さないように置いておけば
大体バレないような気がする。

まーモノには限度と言うものがあるが。

323のやり方が解りません・・　図はないですかね・・
私は ttp://www5d.biglobe.ne.jp/~seiichit/yusyayo1.html　でやってますよ

当たり判定専用マスク使用
自機当たり分のメモリだけ調べればいいので簡単
マスク使用しなくても爆炎処理とか別レイヤーでやればおｋ

レーザーとかにカプセル状使ってる。

２Ｄなら矩形で十分ですよ。
３Ｄ使ったり、回転する物体にグラディウスのレーザーがきっちり形に添って
着弾して欲しいとか思わなければなー。

>>328
ほい。
http://gamdev.org/up/img/2009.jpg

>>326氏や>>237氏の言うように、必要なだけ細かく設定すればOK。
要は如何にそれっぽい判定を作るか。
SS版シルバーガンがあれば、当たり判定表示モードでプレイしてみるといいよ。

グラIIIの素敵判定はこれを見ればw
http://members.at.infoseek.co.jp/lbl/myweb2_015.htm

>>332
最低だねｗ＞あたり判定

必要以上にちゃんと（？）作っても誰も気がつかないしね。だいたいでいいんですよｗ
（グラ３の評判はアレですが）

人的リソース、もっと直接的に言うとオレらのゲーム造ってる時間なんぞは限られるので
どーでもいい部分としっかりチカラ入れる部分を見極めないといい具合に出来上がりませんよ。

ネタに対して野暮なことは言わんでもよろしい

>>332
�dクス　回転する場合はちょっと面倒なんですね　ですがいい当たり判定ですね

>>332の程度で十分だよ
これが問題になるケースはまずない

これが普通なんじゃないのか。
見た目通りにやろうとしてるアホもおらんだろう

グラ３も68000あたり使ってるんだっけ？
グラ２が68000を２個積んでるってのはX68の移植に当たって散々話題になったので知ってるんだが。
いまのCPUの100倍くらい遅いんだから、まあがんばったほうだと思ってあげるのが吉ですよ。

グラディウス3は必要以上に大きくとってるから文句言われるのであって
細かく設定していないからというのとはちょっと違うだろう。

ゴーファーのおでこも有名だね

横シューで不用意に地形に近づくのはご法度ですよ。
そんなんでバランスとってるから廃れたんだろうけどな。

しかし横シューのほうが長期シリーズが圧倒的に多いぞ。
やっぱ横のほうがビジュアル的に有利→世界感やら設定を持ち始める
→シリーズ化、ってことだろうか？

一理あるなぁ
縦シュー派が本当にＳＴＧ好きな人なんだろうなって思うわ
ヘタレな自分は横シューの方が好きだけど

縦シュー→ﾄﾞﾗｸｴ
横シュー→FF

すまん、オレはウィザードリィ／ウルティマのほうが先にピンと来たｗ

点＆線が軽いしフレキシブルでオススメ
管理が面倒だけど

巨大物体も線でつか？

線というのは直線の方程式のことでつか？

>>343
横画面でコンシューマとの相性が良いのが最大の要因では？

多角形の判定はそれほど面倒じゃない。

凹型はめんどい。

矩形でいいよめんどくさい…ｗ

円

円てどういうとき使うん？

日本円

忘れたけど、シルバーガンが円だったんだっけ？

>>355
丸いもん同士の当たり判定を取るときとか？

>>357
確かシルバーガンは矩形じゃなかったっけ。

円も矩形で近似できるからつかわんなあ

円オンリー最強。

真円なら楽かもしれんが横長とかいろいろとかわるようなら厄介だし、
当たり判定は1キャラで矩形の可変長配列を持つようにしてどれかにあたればHITとするのが
普通な希ガス

自機の死亡原因はギガシリーズみたいに被弾のみ、敵と接触無しなら
円（というか２点間の距離）だけでスマートに可能

>>326
細長いレーザーとかは円の集合体として考えるのかな。
串団子みたいやな(笑)

円は回転するものに適している。
>332のように回転具合によって判定に違いが出ることがない。
追加して線（カプセル）判定も使えるし。

>>363
もっと手抜きするなら
先端部のみ判定

意外と気にならない

当たり判定を行うとき

・攻撃側から防御側を見る
・防御側から攻撃側を見る

細かい事かもしれないけど、皆はどうしてる？

一箇所で両方にフラグ付けしてやって
攻撃、防御、どっちも同じ方法で参照

>>366
俺は「自機側」「敵側」に分けてる。
判定処理を行うのは基本的に敵側のクラス。
敵弾の判定領域のほうが複雑な形をしてるものが多いしね。

自機弾・敵・敵弾といった種類毎に別のリストで管理してるので、
必要な組み合わせでイテレータを取得してループで判定関数に放り込む。
自機・自機弾・敵・敵弾は衝突可能クラスを継承してるので処理は同じ。

衝突可能クラスで共通化か・・ちょっと目から鱗。

自機・自機弾・敵・敵弾をどこまで基底クラスで共通化するか迷ってる。
変数は座標・向き・大まかな大きさ・出現後フレーム数あたりかな？
関数はmoveとdrawとか。

寝る前に書いたが、良く見たら凄い言葉足らずじゃんか、既に寝てたのか俺は。

・攻撃側から防御側を見て、当たっていたら防御側のHPを減らし、自分の事後処理を行う
・防御側から攻撃側を見て、当たっていたら自分のHPを減らし、攻撃側に当たった事を通知する

って書かなきゃ駄目じゃん、俺。

オレの場合、当たり判定はマウスリスナーっぽい自作リスナーを利用している。

当たり判定登録の構造体と結果通知構造体をそれぞれポインタで登録するようにしている。
結果通知を共通化すれば複数のあたりを一挙に受け付けられるし、フラグ見るようにすれば全体で
1発しか当たらないとかもできる。

点と矩形で処理わけてるが、構造体はどっちでも同じものを使ってる。

同じもの使っておけば、途中で敵同士を当たり判定させたいとかってなっても困らないしね。

>>363
楕円。

楕円同士の衝突判定ってすぐに思いつかないんだけど
なんか上手い方法あるんかな

楕円がどういうものかわかってれば円と似たようなものだと思う
計算量は円の二倍になるっぽいけど

敵や自機は矩形、その他は点、でいいんでね？

だ円だと、
それぞれの角度もつかって、弧までの距離2つの合計を出すって事かな。
まあ、だ円使うよりは、複数の円なり矩形を使った方がいいよなやっぱり。

円どうしだったら
（自Ｘ-敵Ｘ）２乗+（自Ｙ-敵Ｙ）２乗が
（自円半径+敵円半径）２乗以下なら当たり
ってだけで計算が楽だけど、楕円の場合は苦しいな

回らないなら楕円の方のＸＹを比率倍で計算するだけですむが
回転角がついている場合、ややこしい計算が必要になるだろうな
計算方法想像するのもﾏﾝﾄﾞｸｾ

337のやり方に同意

全部カプセル型最強

CAVEゲーの様なショットと低速移動を１つのボタンに割り当てる場合について質問があるのですが。

ショットを連射しつつ高速移動したい場合はボタンを連射しながら動くことに
なると思うのですが、この際「ボタンを押してる間は低速移動」だとすると、
連射の度に一瞬一瞬移動が遅くなってストレスがたまると思います。
この様な兼用ボタンを採用しているゲームではここら辺どう対処してますか？

さしあたり思いつくのが
・ボタン押して数フレーム後から低速移動
・ボタン押すと減速開始、数フレーム後に低速移動の速度に落ち着く
なのですが、他の方法を使ってる方はいますか？

また、これらの方法を使うとしても何フレームで低速移動に落ち着かせるか迷うんですよね。
フレーム数が小さすぎると、連射の間に押すフレームより小さくなってちょこちょこ低速移動になってしまうし、
大きすぎるととっさの低速切り替えが遅れ勝ちになりそうで。

一定時間押しっぱなしだったら低速移動、で良いんじゃないかなあ。
時間（フレーム）がどのくらいかはトライ＆エラーで感覚的に丁度いい
数値を探すしかないんじゃない？

>>380
まあ、連射するゲームではないのだが・・・

ABAさんのゲーム（のソース）みてると、
ボタン押している間は、低速の値に徐々に近づき
離している間は、高速の値に徐々に近づくようになっているな
参考までに

>380
とりあえず思いついた方法を実装してみるのが先かと。

>>380
フレーム数はひたすらテストプレイして/してもらって割り出すしか。
二値じゃなきゃ駄目ってことも無いので段階的に変化させるとか。

CAVEだと
・ボタン押してmフレーム後から減速開始
・nフレーム後に低速移動の速度に落ち着く
でmとnはそれぞれ3〜60くらいかね。数値は実測してないので嘘
同ゲームでも機体によってmとnは異なる
ロケテと製品版でも違う例もあったようだ

AとCの使い分けですぐに低速に移行することもできるしね
詳細はまぁ分かるでしょ

>>380
俺が今作ってるヤツだと、前者の方式でやってる。
切り替え時間は20-30フレーム(60fpsのとき)ぐらいかな。

とっさの切り替えで隙が生まれるのは仕方がないよ。
それなりに熟練したプレーヤーなら低速に入るタイミングを
体で覚えてくれるハズ。
その辺が気になるようなら、東方みたく低速ボタンをつければいい。

俺はショットボタンと低速ボタンを分けてる。
（もちろん設定で同じボタンに割り当てることも可）
そのかわり、操作が複雑になりすぎないように極力使用ボタン数を絞ってる。（ボムも無し）

C押しながらAは低速専用ボタンと似るな。とっさに減速できて良い。

そもそも低速移動できるようにしとかなあかんのが一種の歪みなんだけどな。
1フレームに移動するドット数を考えると、
高速移動時は理論的にすり抜けられるわけがないという。

常に全力疾走だと疲れるだろ？

時には立ち止まっても、ゆっくり歩いて進んでもいいじゃないか。

歪んでるのは、落ち着きを無くしてしまったこの大都会さ。

ケイブシューも東方も普通にプレイする分には操作のコンセプトは一緒ですね

ショット撃ちっぱなしでいいなら、必要な操作は一緒だものね。

>391
かっこいいな、それ

>>391
吹いたw

>>390
精密移動で細かく避けて
高速移動でガーッと避ける
メリハリがあっていいじゃないか

俺もモードチェンジみたいなフューチャーは好きだね

ちょっと過去ログ見てたら、リプレイの話が出てたんだがちょっと質問
D3DXライブラリ使うと、内部でCPUごとに演算誤差が出てリプレイがずれる
D3DXでも演算する部分は使わないのが妥当なんだろうか？

> 内部でCPUごとに
内部でCPUごとの最適化されているために

浮動小数点つかわなければいいのでは？

固定小数点最強説

>>391
話が理解できないからってくだらないこと書き込むなよ低脳

何怒ってんの

> 1フレームに移動するドット数を考えると、
> 高速移動時は理論的にすり抜けられるわけがないという。

フリーや同人にはこれがわからずに失敗してる弾幕シュー多いね。

>>404
詳細キボン。フリーのシューティングゲーム作ってる漏れは具体的にどういうところに注意すればよいですか。

一フレームの移動量が多いときに
正しく交差判定ができずに
すり抜けるってやつだろ

よっぽどのことがないとすり抜けないよ。例えば敵弾を1ドット判定だとすると
「敵弾の1フレームの移動量−自機の1フレームの移動量＞自機の当たり判定の大きさ」
の時にすり抜ける可能性があるわけだけど、この式を満たす弾速って相当に速いｗ

緋蜂2波とかはたまにすり抜けることあるんだよね
あの場合それはそれで嘘避けもネタとして面白いからいいんだけど

すりぬけるのに関しては問題ないんじゃないのか？
昔のゲームは2フレームに1度しか判定しないものがあったと効くが

実際にプレイしてみて、バランス調整の一環として判断すればいい。
理論上どうなのかより、遊んでみて面白いかどうかなんだし。

390が言ってるのはそのすり抜けじゃないだろ？
どうでもいいけど。

低速モードが無いとすり抜けられないような弾幕作っちまうってことだろ。

なら、クイック無敵モードで弾幕をぐぐり抜ける俺のシューティングは大丈夫ですな。

…難易度低すぎって怒られそうだが。

>>412
いや、それがゲームの面白さにつながっているのなら別に問題はないっしょ。

弾幕って壊しちゃだめか？

なんでもいいよ、面白ければ。
こんなのシューティングじゃないとか言い出す奴は無視だ無視。

不文律を侵すにはそれなりの理由がいるとは思うけどな。
極端な例だけど、右入力して左に移動されたら流石に
皆なんだこりゃというだろう。

そんな例出すお前がなんだこりゃ、という感じがしないでもない。

弾幕を不文律といっちゃうのもなんだこりゃ、と。
弾幕を止めると刺激が足りないというか、物足りなく感じるのは確かだけど。

たぶんフライトシムやって上下逆のクソゲーと書き込みしてボロクソに叩かれた経験でもあるんだろ。
ぶっちゃけ右に入れたら左に動くことによって生まれる面白さがないと証明できないならそんなこというべきじゃない。

自機が簡単に無敵になれるゲームなんぞいくらでもあるし。　まあ、「無視だ無視」っつーことだわな。

416は415の「シューティングじゃないとか言い出す奴は無視」に対する
レスだったんだけど。
前に2DSTGスレでとあるゲームに対して「自機や敵弾より上にスプライトが
出るのどうよ」みたいな批判が出てたのを思い出しただけ。

多くのプレイヤーが当然と思ってることに対して、それを破るのには、
それなりの必然性がいるんじゃないかということだ。

あーすまん、俺が勝手に弾幕以外の話に飛躍させたのが悪かったんだな。
忘れてちょ。

弾消し命と言うとコンパイル系かね。
いろいろ調整が面倒だから手を出してはいないが。

そこにある弾に対して
「避ける」も「消す」も、基本的にはそのゲームにおいて
その場を生き延びて先に進もうとする行為である点では同じなんだな。
要はそのゲームが用意している「局面をさばく」手段が、どのように
具体的な面白さにつながってくるか、というところが大事なんだと思う。

弾幕を壊すゲームも、クイック無敵も、実装してみて面白ければきっと後が続く。
言い出しっぺがどんどん作ってみるべし。

>弾を壊す・・
カオスフィールド・・・
ZANACxZANACの新ZANACにも弾けしモードがあったけど弾幕とは毛色が違うゲームだしな。
共通点はどっちも微妙な点かね。

クイック無敵ってギガウイングの劣化版か

大好きな縦シューにたくさん実装されてるボムのことじゃねーの？

ボムが自分にも当たるとか・・・いや、忘れてくれ。

弾幕STGといえるか微妙だが、多量の敵弾を破壊するゲームは作ってある。

最大敵弾数は難易度で変化(75,125,200)
マウスで操作し、自弾の発射方向は自由に変えられる
敵弾は全方向から発射
HP制を採用し、自機の当たり判定を大きくする

という感じ。

破壊可能弾とはまた違うんだろうけど、それでもザナックや怒首領蜂を思い出す

>>425
ギガウィングってのを知りませんが。
当方のは二度押しで、その方向へくるりと回転移動します。
その間は弾をすり抜ける。と。


正直、簡単すぎやしないかと心配…。弾幕は無責任に強くして、ＨＰは自動回復。

1943みたいにすれば？ｗ

ギガウイング知らずに弾幕シュー作るのか。それは凄いな。

いや、B級シューなので無知は別に恥ずかしいことではないんだが
車作るのに三菱知らないようなもんだ

三菱がＢ級だと言っているのか？

今やZ級

おまえんとこみたいなメーカーがあるから
リコールは無くならないんだ！
消えろ！

ってか？ひどいなｗ

シューティング作る場合、やっぱ既出のシューティングは知らないとナァ。
じゃねーと、『おおっ、俺すげーシステム考えちゃった、みんなに自慢にしなきゃ』って
頑張って作ったのに、○○のﾊﾟｸﾘじゃんって言われる罠。

>>433
最新作が翼神であることを考えれば、的を射ているw

>>435
翼神のことかー！！(AA略

すまん、書き込みミスしたとおもっていたら成功しとったw

437超ｶｯｺｲｲな

>430
最近（でもないけど）のだと式神の城1の「？？？」の瞬間移動みたいなものか。
二度押し発動は、ちょん避けしようとすると暴発するのが辛かったんだが。

今日はあちらこちらのスレで連続爆死を見かけるな…

>>441
確かにちょん避けでダッシュ暴発はキツイな。
「ショット撃ってない時」とか条件付けたりすると良いかもね。

んー、暴発はなんとしても避けなきゃならんですか。
ならそれ発動用のボタン作ります。それ押しながら移動で回転。

どうも、助言ありがとうでした。

今まで回転避けなんてゲーム見たことないんだけど
ttp://roo.to/prefeam/　←多分ここが最初だと思う
ひょっとして、黙ってパクリですか。

>>445
未完成のゲームをパクってどうする。

>>445
似たようなものなら10年以上前からあるぞ

避けというより跳ね返しだが、スターフォックスのローリングなんかも似たようなもんか。
別に取り立ててめずらしいものでもないぞ>>445

自分の知ってるものが全てというような言い方をするとこうなるという良い例を見た

パクリかそうでないかは言ってたらキリがない。
偶然ってこともあるし、似てるゲームもそりゃある。
でもどうせパクリ（パクラレ）ならある程度ヒットしたり、
有名になってからにしてほしいよな。
ゲームのアイデアに、作品が完成してるかどうかも関係ないわけだし。

つーか、パクリという言葉は創作をしない奴のセリフとしか思えん

有名かどうかも関係ないだろ

TVでやってることを全部オレのパクリだとか言ってるヤツ周りにいないか？
パクリを言い出すとたいていそういう目で見られてますよ。

パクリ自体は悪くないと思うし、有名にならなくてもいいけど
最初からアイデアだけ真似されるの見ると、なんかムカツク。
でもある程度、有名ならいいかなとは思う。
グラディウスのパクリ、ウィザートリィのパクリ
別にムカツカないし。暗黙の了解っつーか

>>451
それはパクリ良くないと認識してるからだよ
オマージュとか二次創作なら、あんまカチンとこないでしょ。

パクリとかオマージュとか言うだけならなんとでも言える罠
その先であざとさが見えてしまったら萎える
取り入れた結果(･∀･)ｲｲ!ものが出来上がっていたら燃える

そんなもんじゃね？

シューティングなんてみんなインベーダーのパクリだしな

おもしろければ勝ち

>>454
> それはパクリ良くないと認識してるからだよ
そうそうそれがいいたかった
よくわかってくださった

まあ、アイデアなんてゲームの1%にもみたいないものだ
ゲームは、エジソンじゃないが、1%のアイデアと99%の調整。
特にシューティングだってそうだろ？
やっぱ、パターン命だよな

> まあ、アイデアなんてゲームの1%にもみたいないものだ
まあ、アイデアなんてゲームの1%にもみ満たない

失礼

昔から「すてきだな」と思った弾幕やアルゴリズムを書き留めていて、
プログラムを書くときに参考に書いたりして、結果、
人の弾幕やアルゴリズムに勝手に手を加えて発表してしまった

パクリじゃなくて盗作

コンボやカスりを入れる同人シューはたくさんあるけど
配置とか弾幕が悪くてソレを全く生かせないのが多すぎる

>>462
おれもそう思う
配置や弾幕が鍵なのにな

それが難しいから真新しいシステムに走るわけで。

なにを言ってんだろう。出来もしないうちから。
ゲームだろうがなんだろうが、
いつだって新しいものを作るほうが難しいし、はるかに意義があると思うけどね。

>>465
そいつはいかにも若者の主張っぽくて微笑ましいが
いままでにない新しいものだけが特別な意味を持つって考えはいただけない

ギガウイングはAマイナス級くらいの実力あるだろ。
ギガウイング2はC級、翼神はZ級だけどな。

>>467
もしよければ他にA級やB級に属するシューティングを教えてください。

とりあえず文句が言いたいわけね

>>467
いやB級だろ
翼神は確かにダメダメだが
あれ以下なものは他にもあるからZ級ではない

ランク付けは総合力か一芸に秀でてるか、などモノサシが曖昧なので異論出るし、>>1によるとスレ違いっぽいしな。

とりあえず形にもできていないおれはZZZ級くらいで。おやすみ〜　Zzz...

>>472
名前が強そう。

シューティングのランク付けやめないか？好みの問題も有るし不毛に見える…。

そもそもスレ違いっぽいし、部分的に良い所を話すならともかく
比較してどうこうなんて話は無意味だと思うぞ。

トライジ(ry

オデンの具材のランク付けみたいな話だな。結論なんてでるハズがねー。


ところで虫姫ラスボスの弾幕ＡＶＩを見たんだが、弾の無い部分がほとんどなかった・・・
あれは避けられるのをちゃんと前提として設計してるのか？
それともＢＯＭ前提として隙間無く弾幕敷き詰めてるのか？

ノーボム前提で組んであるはず。今回はボム撃ったときのペナルティが物凄いので。
各所のシューターのページでも、最後はミスるな、ボムるな、が基本方針のようだし。

翼神は遊んでたら電源が落ちたからＺ級未満だ

>>476
開発者たちが一回でも避けられた弾幕なら採用とかそんな感じじゃなかったっけ。

ゲーム速度を落として調整するという手もあるね。
どうせ弾幕シューの遊び手にはニュータイプがいるんだし。

>>478
俺なんか初プレイで、コイン入れたら落ちたよw
店員呼んで再起動したら、起動時にウインドウのきれっぱしが表示されてワロタ
さすが、Embeded Windowsだなw

翼神の所為でtypeXの評判がすこぶる悪いのが解せない
タクミ社員は首を吊れ、と

コスト面以外で良い所が見つからん

これに関してはWindowsの性というよりはプログラムのバグのような気もしないでもない
いわゆるPCと違ってTypeXはハードも固定されていて仮にバグがあっても回避しやすいだろうに

とおもったけど電源不足か熱暴走っぽいな

なんか翼神って店によって動きがカクカクだったり
そうじゃなかったりするね。
地元のゲーセンで普通に遊べたんだけど
秋葉のゲーセンでやったら１面からやけにカクカク動いてた。
マシンのスペックが台ごとに違ったりするんか？（んなわけないか）

スレちがいぽくてゴメン

うちのゲーセンだと1面からフレーム飛びまくりだったよ
結構、低スペックだったりするんじゃないんかね

何も知らずギガウィングっぽいのあるなと思ってやってみた。
PCでやってるような感覚でやはりカクカクしてました。

アーケードならどっちかと言うとぬめーって遅くなるんだが・・・。

処理落ちじゃなくて描画スキップ(?)になってるのは作成基準があるか、
巧が勝手にやってるんだと思う。
にしてもセレロンとはいえ２ＧＨｚオーバーのＰＣであんなにカクカクってのは、
どこに問題があるのかさっぱり判らんね。
解像度も特別高いわけでもないし。
オンボードのしょっぼいチップなのか？

数回の強制再起動(電プチ)でxpがHDDのDMA転送を外してたとか、
そんなしょうもない理由なんだろうなぁ。

エンベデッドならHDD使わないのが普通じゃないのか
ビデオ性能もネックになってるとは思えないし
怒首領蜂２みたいなものかね

基本的な部分を見ると怒首領蜂２のほうがまともなようだけどな

つーか、製品出す前に誰も止めなかったのか？

弾幕シューでフレーム落ちという暴挙をまさかアーケードでやられるとは思わなかった。
フリーソフトとかなら割合よく見かけるけど。

自機や敵弾はワープするし、リフレクトフォースが発動したのかどうか
わからなくなったりするし。

弾幕シューで、というよりも販売元の作成基準に処理落ち不可でだめならフレームを落とせ、
とあったらゲームに関係なくやらないといけない訳で。
まぁ、妄想だけど。

タイトーのtype-xのページを見に行ったら思いっきりハードディスクがくっついてる写真が合った。
スペック的には今のＰＣの普及機位だった。cel2.5G/radeon9200/128MBでＲＡＭ256が最低スペック。
Biosとドングルによるハードプロテクトがあるから案外それが原因だったりして。

ていうか、ＨａｌｆＬｉｆｅ２がType-Xで出るのか。知らんかった。

自分がそのスペックで組んでもあそこまでカクカクにならん。
と思ったのは俺だけじゃあるまい。

プレスコセレロンをあの空調がまったくない筐体に閉じ込めたいと思う自作ｅｒはおらんよ。

今ならやはりPentiumM採用していただろうか？
冬でこの状態ってことは夏場はもっとひどいってことかね？

>>491
Radeon9200だとハーフライス２の真価が全然出せない気がする
それに1時間程度で終わるゲームじゃないんだけどなぁ…セーブどうるんだろ…

ビデオカードはオプションで変更できるそうな。
RADEON 9250（128MB）／9200PRO（128MB）／9600SE（128MB）／
9600XT（128MB）／9800PRO（128MB）／X800PRO（256MB）／X800XT（256MB）
から選択。
なんか不思議な気分。

カードのスペックにバラツキがあるから処理落ちじゃなくてフレーム落ちになってるのかもね。
翼神は。
てか、9200で動くように作れば問題なさそうなんだけどな。

弾幕ものでフレームスキップというのがおかしい

HalfRice2キター！！！！！！！！！！！！！！！！！！！！！！！

VB5.0でシューティングを作成してるのですが、メインのループ処理内でWaitをかけ
処理速度を一定にしようと思い下記Wait処理を追加しました。

i=GetTickCount+30
Do Until (GetTickCount()>i)
loop

数機種の端末で動作させた所、端末のスペックにはさほど差はないにもかかわらず
動作速度に差がでて困ってます。
現状では上記"+30"の値を設定にて変更する事で、端末毎に見合った速度で調整
してるのですが、何か他に良い方法がないでしょうか？

必要でしたらそのシューティングもアプします。

googleでGetTickCountまわりを検索して
http://pc2.2ch.net/gamedev/kako/1006/10060/1006052623.html
ここの242を発見。多少参考になるんじゃないかな。VBじゃないけど。
あとはVB使ってる人に任せた。

VBは知らんけど。
+30より速く動かないようにするならそれでいいんじゃないの？
もたつく機種を何とかしたいなら別の対処が必要。

>>499
そのコードだとSleepの30とかわらんぞ
ループの速度を一定にせんと

>>500,501,502

情報ありがとう。
ちょっと>>500ののぞいて覗いてみます。

常に一定の速度で動作して欲しいというのが希望なのですが
ループ内にWait処理を入れこむと>>502がご指摘の通り
うまく一定の速度で動いてくれません。
まぁ何とかゲームにはなっていますが、何となくカクカクした
動きでイマイチです。

とりあえず、アプしてみました。
ttp://up.haiiro.info/file/456.lzh

速度30で丁度良い按配にしてあるのですが、皆様の環境では
いかがでしょうか？

つーか肝心のソースが書いてないぞ
ウエイトのからんでる部分でもいいのでまとめて処理順をかいてくれ

よくみたら確かにスリープと変わらんね。

i=GetTickCount+30
ゲームの処理
描画登録
Do Until (GetTickCount()>i)
loop

こんな感じにすれ。
機種間の違いはゲームの処理にかかる時間からくるものだから、
ゲームの処理の前の時間と処理終了後の時間でみないといかん。

混み合いすぎ・・　DLできません

>>505
そうだ。まず最初に、その指摘が必要だったんだ。GJ

>>504
おおまかにはこんな感じです。

ゲームの処理
描画登録
i=GetTickCount+30
Do Until (GetTickCount()>i)
loop
んで、>>505の指摘を見て納得しました（下に続く）

>>505
なるほど！指摘されて納得！
たしかに単なるスリープになってたんで、直前の処理が重くなればなるほど
処理落ちしてしまう現象が多々ありました。
早速作り変えてみます。

>>506
混んでいますか？今、クリックしたらダウンロードできましたけど・・。
軽いところ探してみます。

スリープはその前に指摘してたんだが気づいてもらえなかったか・・・

>>509
すみません。
あの時点では文章の意味を捉えきれてませんでした。

ちなみに今、Waitの処理を>>505と同様にしてみたのですが、
たしかに途中の処理落ちは無くなりました。
しかし速度を"1"等にすると今度はキー入力等に問題が出てきた
みたいです（キー入力を受け付けない）
とりあえず色々試行錯誤してみます。

あと端末毎に重い理由も何となく判りかけてきました。
ノートンやウイルスバスターを常駐してると重くなるっぽいです。
サービス止めたら速度が上がりました。

…でも早い時もあるんだよなぁ

>>506

ここならどうでしょうか？>>505の修正かける前のバージョンですが。

ttp://u.skr.jp/1024/files/0626.lzh

DLできました　ｽﾏｿ
カッコイイですね　エフェクトにも凝ってらっしゃる　数十分遊べました

>>511
完成度高いね

弾とか全体の絵の感じも良いね
60fps用のバージョンがあったらやりこんでしまうかもしれん

Do〜Loopの間にDoEventsがあったほうがいいんじゃない？

あと、NT系だとGetTickCountとtimeGetTime+timeSetPeriodのどっちがいいんだろ。
(9X系ならtimeGetTimeだけど）

NT系ってひとくくりにしないほうがいいぞ
NT4と２０００、XPとでだいぶ結果が違った記憶があるから
NT3系は・・・もう記憶とんでる

皆様PLAYどうもでした。
ちなみにゲームスピード調整はオプションからできます。

>>512
微妙にズレたエフェクトがあってお恥ずかしいです。
難易度はテスト版なんで結構易しくしてあります。

>>513
もともとはVB2.0時代の遺物を掘り起こして32bit化させました。
足掛けの歴史だけは古かったりします。

>>514
fpsの制御が判りませんので・・
その辺をも少し勉強するのが今後の課題ですね。
Waitかけて調整するという古い手法から早く卒業したいものです。

>>515
loopの後にDoEventsは入れてます。
Wait用のDo〜Loop間に入れる方法と、Do〜Loop終了後に入れる方法どちらも
同じと判断しました（Loop内で得に処理やってませんので）
>timeGetTime+timeSetPeriod
そのようなAPIもあるんですね？ちと調べてみます。

+30にしてるってのは30�_秒待つってことだよね
>>505の方法で、+30になってるところを+WAITにして、
const FPS = ほにゃらら
const WAIT = 1000 / FPS
としておくと、ほにゃららを決めればfps指定になりそうな予感

>518
いやそれだけだとFPSあげるとゲームスピードまで上がっちゃう
移動部分とか弾の発射間隔なんかをFPSに応じて変化させないといけないから
それなりの大改造になっちゃうと思われ

>>515
> (9X系ならtimeGetTimeだけど）
NT系でtimeBeginPeriod(1)やってないだけだろ

そこで描画と計算をスレッドで分離ですよ。
あんまりやってる人居なさそうだけど。。

それって実際どうなんだろう・・・

とりあえず俺はこのシリーズ好きなので、新作なら嬉しい。

よくできてるな

「全ての処理が終わったら次フレーム時間まで待機する」っていう考え方よりは
「1フレームの時間内に全ての処理を終わらせる」っていう風に考えたほうがいいんじゃない
結局同じことだから気分的なものだけどね…
要するに「1フレーム時間は固定」というのが大前提ということです

>>518,519
とすると、まず基準として秒間30FPSとか決め打ちしてやり、毎回全体を通した１ループで
かかった時間（�_）を拾ってくれば、1000/1ﾙｰﾌﾟ時間（�_）で処理の回数が予想できるので
30FPSより処理回数が多くなるなら差分のWaitを、少なくなるようならWait無しで対応でき
そうな感じ・・
けどそうなると重い処理の部分ではやはりバラ付きがでそうだなぁ。

>>521
描画が時間かかる場合があるんですよね。
特にStretchBltなんか激重です。
そこが処理落ちの一つの原因で改善できませぬ。

>>523
ありゃご存知でしたか
タイトルとか全部消したんですが。
前回未完成だったので気を改めて焼きなおそうかと。

>>524
そうなりますよね。
まず秒間何フレームかを決める所から考えなければ。
まとめると
・秒間の処理回数を決める（FPS）
・１フレームあたりの処理時間を取得
・１フレーム内の処理時間で処理が追いつかない場合は描画関連の処理をカット
・早く処理が完了しても２フレーム目の処理には進めないようにWait（時間は計算）
こんな感じですかね？

>>521
スレッドで分離ってことは入力からの遅延があるってことだよね？
俺は次のフレームで結果がすぐに反映されないSTGは最悪な操作性だと思ってるが

>>524
別に垂直府同期とってないこのパターンなら1フレームにかかる時間が可変長でいいんじゃね？
６０ｆｐｓのつぎが３０ｆｐｓにしたいというのならそれでいいけど
>>525のようにへんに入り組んで考えてめちゃくちゃなコードになりそうだ

F-WINGSは凄く出来がｲｲ!(･∀･)
でも３ボスの手前で突然終わってしまうのはまだ未完成だからかな。

>>526
既にコード非常に見難いです。
本当は全部作りなおしたいんですけどそこまでの気力が・・
そもそもFPSの概念をよく理解しておりません。
「FTP=１秒間の描画枚数（処理速度）」と思っていいのかな？

>>527
ありがとう。
５ボスまでは行けますよ。
６面の途中で敵が出てこなくなります。
バグ・・・かなぁ？？
あ、[ESC]押せば強制終了しますけどそれじゃないですよね。

fps = frame per second 1秒あたりのフレーム数。
アーケードも、ファミコンなど家庭用機も、シューティングは
ほぼ全てがfps60固定を前提にして作ってある。
PCだと性能が低いため15fps前提の時代もあった。
今はほぼfps60固定前提だと思う。

>>526
1フレームにかかる時間が可変長ということは、敵の移動速度などをフレーム毎に計算し直す、
ということですか？

>>528
あ、、じゃあバグだったのかな。[ESC]は押してないですよ。
３面のバキュラを過ぎて、敵小隊を倒して、ウイングを確保した直後に画面が真っ暗になりますた。
んで、しばらくしたらタイトル画面に戻った。

>>530
いや、基本は処理オチなしで回るのがいいんだけれども、
処理落ちしたときに固定フレームレート計算でいきなり半分のｆｐｓにするべきか、
それとも処理落ちした分だけずらすべきかという意味だ

垂直同期してない（できない）ウインドウモードなら後者でいいんじゃないかということね

>>526後半は、1フレームで描画しきれなかったときのような例外的な場合の話ってことだよね。

何の前触れもなくバキュラにナスカ地上絵と、
単純にパクリなのか、関連性もなければオマージュでもない。
なんだろうね･･･
あんまし好かんな、こういうのは。
あと、当たり判定がまんまキャラそのもの。ウィングないとすぐやられる。
3面ボスの高速ミサイルよけ運がわるいと即死って希ガス

>>528
＞描画が時間かかる場合があるんですよね。
＞特にStretchBltなんか激重です。
＞そこが処理落ちの一つの原因で改善できま

処理スピードに関しては、うちでは特に問題なかった。
遅くなる部分も全画面ならほぼどれでも楽に動きそうだけども。

>>529
ありがとう
有名所だとVF1の30fpsやVF2の60fpsとかですね
m25BASIC（笑）時代の人間なんで、フレーム云々とかいまいちピンと
きてませんでした。あの頃はそんなの全く気にせずによかったからなぁ。

>>530
あと[F2]キー押したら強制的にタイトルへ戻ります。
しかし突然落ちる現象ははじめて聞きました。ちとテストしてみます。

>>533
80年代のシューティングで自分が感銘を受けた要素をネタ的に取り入れました。
正直「パクリじゃん」って言ってもらうのが目的でもあります。
ゲーム名もそうですし、ボス名やウイングの種類、敵、各エフェクト、
どこかで見たものを要所々にパロディとして取りこんでいます。
一つ一つが「あ、これは何々のパクリだ」と軽く受け流して頂けたら幸いです。
自機の判定は羽と先端を除く本体部のみです。ウイングを装着すると判定は
大きくなります。
３面ボスはランダム性が強いですが、高速ミサイル射出前に破壊する事も可能
です。ウイング無ければ画面下部の隅が比較的逃げやすいかと。

>>皆様方
いろいろと話題やご意見等参考になります。
ここは良いスレですね。

>>499
音周りの終了処理おかしくない？
ゲームやったあと
winampで聞いてたmp3の曲の音がこもるようになったんだけど？

winamp再起動したら戻った
すまそ

いい雰囲気

>499
こことかどうかな？
ttp://www.ultrasync.net/yofune/?cmd=read&page=GameDev%2FLink

あと画面下に自機がめり込むとちょっと遊びづらいです。

>>539
こんなHPがあったのですね。助かります！
早速お気に入りに登録と。

>>皆様方
今夜にでも新しいバージョンアプしてみます。

・速度調整を自動で行ってみました>>525辺りのロジックを盛りこみ
・自機のレベルアップを遅くしました
・ボス戦のみのモードを追加しました
・ランダムウイングモードを実装中（間に合うかな？）

他の端末でゲームスピードが最適かどうかが知りたいです。
一応、win2k（p4）とNT40(p3)で速度の低下が無い事を確認済

とりあえず自動でWait計算してかけるバージョンに作り変えました。
画面右下に現在かかっているWaitの値を表示してますんで
これが常に25〜30ならばほぼ期待通りの処理量かと思います。

ttp://u.skr.jp/1024/files/0632.lzh

ちなみにうちのWin98で動作させると若干速い感じがします。
あと原因が判りませんが、突然遅くなったりする場合があり
少々困ってしまいました。（Waitをコメントに変えて実行して
も発生する場合があり訳わかりません）
常駐物を落とすことで割と安定するっぽいので、環境的な
ものだと無理やり納得してます（笑

おまけモードを２つ付けてますんで、お暇でしたらどうぞ。
ボス戦モードはもう滅茶苦茶です。４面が限界でした。
ランダムウイングモードは、固定のウイングが全く無いため
ちょっと新鮮な感じで遊べるかと思います。

>>526
んー、俺はそれでも1フレーム時間は固定にするべきかなー、って思う
1フレーム時間を可変時間にすると何が面倒かって、
ゲーム中のオブジェクトの時間進行速度がマチマチだからとにかくめんどくさい、
コレを実装するプログラムだけは絶対に嫌だｗ

>>525のやり方をほんの少し変えて調節すると
yaneSDKのFPS調節クラスと全く同じ機能になるよ
一応FPS45だとかそういう指定も出来るようになってる

>>542
>ゲーム中のオブジェクトの時間進行速度がマチマチだからとにかくめんどくさい、
>コレを実装するプログラムだけは絶対に嫌だｗ

これは上の30fpsに急に落ちる場合と59fpsに落ちる場合とはまったく別問題だよ
作り方がわるいのでは？

>>526の「60fpsの次が30fpsにしたいというならそれでいいけど」は、つまり
>>524のやり方だと45fpsのような指定が出来ないと考えてるんだよね？

察するに「1フレーム」という単語が
時間進行の1フレームと描画進行の1フレームの別物を指していて
単にすれ違ってるだけだと思うんだけどね

時間進行の1フレーム・・・１フレーム
描画進行の1フレーム・・・１シーン

と言う風に言ったりするよね？

しない。

しねーな

しません。

>539
そこ、リンクが記事毎に分類されててわかりやすくていーな。
これWikiだけど、おれも足したりして良いのか？

ヽ(`Д´)ﾉﾑｷｰ

>549
俺に聞かれても（；´д｀）
管理人に聞いてみてくれ。

>545
しないッス。

>>545
しないおー

>>545
したことないな

>>545
いわないな。むしろ逆なら言うかもしれんが。

VSYNCを使う場合は、1シーンの描画が1フレームに間に合わなかった時に、2フレーム使用するので
60fps→30fpsにガクッとfpsが落ちてしまうわけです。
でも1シーンの描画が間に合ったり間に合わなかったりする境界の場合には、必ずしも30fpsであると
言うことではなくて60〜30の間のどれかのfpsになる場合もあるわけです！



・・・せめてこのスレだけでも流行らないかな(つд⊂)

逆も言わない。

なんかﾜﾛﾀ

>>555
シーン、というならspsにならんの？
scene per second.
シーンといえば文字通り画面に現れている１シーンを表すものであって
時間の単位としては使われていない。
どこぞの会社の方言としては使われているかもしれないけど。

(´；ω；`)ｳｯ

昔は割り込みだったから、1intとはいったな
フレームはつかうけど、使い分けはしないな

1イントとか1インターとか呼ばれてるから interval の略かとｵﾓｯﾃﾀ。

別に昔だからって割り込みなんか使って無いと思うけど。
V-Blankを検出するまで待つだけだし。

割り込みって、音以外で何か使ったか？

ごめん、しったかしただけだから気にスンナ
昔マリオは、メインルーチンなしで割り込みだけだったとかその辺

どっちでもいいけど、ポーリングだとバス占有しちゃうし
VSYNCまちは割り込みのほうが若干応答速度は速かった希ガス

ちなみに同期の仕方として超連射でつかっているライブラリ（XSP）は
処理落ちした場合は次のを待たないという通好みな仕様が合った希ガス
この場合は割り込みつかえないとね

　　　　　　　　　　　ｼｰﾝ･･･
　　
　

　　　| ∧
　　　|ーﾟ)　ﾀﾞﾚﾓｲﾅｲ･･FPSｽﾙﾅﾗ ｲﾏﾉｳﾁ♪
　　　|⊂
　　　|
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣


　　　｜
　　　│　FPSｰ♪
　　　│　　　∧ ∧　　ﾉ
　　　│　⊂(ﾟーﾟ⊂⌒ヽつ
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣


　　　｜
　　　｜　
　　　｜　
　　　│　　　　　　　　　　　　　　　ｼｰﾝ・・・
　　　│
　　　│　
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　　　　こうしてつつがなく夜は更けていくのであった

>>567
FPSというよりスニーキングアクションって感じだな

笑え

すまん、わからんｗ

>>564
まあ、メインルーチン無しのプログラムを作る事自体は、
難しい話でもないしな。メインルーチンが有る方が良いか、
無い方が良いのかは、作成するゲームによっても変わる品。

ファミコンにもスーファミにもメガドラにもPSにもPS2にも
MSXにもX68000にもPC-9801にもFM-TOWNSにも垂直同期割り込みついてるのに、
Windowsにはないんだよな。

俺もすっかり忘れてたけど、最初はかなりボーゼンとした記憶がある。

まず、それ以前のハードと違ってWindowsでハード叩く方法がさっぱりわからなかった時点でボーゼンとした

漏れもだ。
スレッドが割り込みのかわりになると知ったのは、
そのだいぶ後の話だな。

Windowsって最初はリアルタイムゲームなんて眼中になかったからな
フリーセルやマインスイーパーができりゃ十分だと思ってたんだろう

XboxにもVSYNC割り込みないと聞いたぞ。
PCとの互換を気にしたのか、そもそもDirectX部隊にそんな発想ないのか。

今でもくれるっつーたら喜んで使うんだけど、
OSのカーネルとの兼ね合いとかいろいろ面倒なんだろう、たぶん。サリン。

むしろ、Vsync割り込みを何に使うのか聞きたい。
DC/GCなんかでは用意されていたけど使わなかったし。

今のフレームバッファ方式で垂直同期フリップが使える環境なら
さほど問題になるまい

とくにコンシューマなら環境が固定されるしね
コンシューマでティアリングがあるほうがきもちわるいわ

Winはもうどうしようもないという妥協の産物だから＞ティアリング

現状でも割り込みもらったところで垂直や水平は即時応答が必要な場合が
ほとんどだからリアルタイムOSでない辞典でこれは無理

サウンドにしても割り込みで応答していくのが本来のスタイルだが
これができないのはすぐにわかるだろう
例のOPMボードですらバッファ数での調整だけだから

　　　　〃〃∩ 　_, ,_
　　　　　⊂⌒（　`Д´）　＜　ヤダヤダ！ラスター割り込みできなきゃヤダヤダ！
　　　　　　 ｀ヽ_つ ⊂ノ
　　　　　　　　　　　　　　ジタバタ

できるかボケｗ

>>577
何に使うのかというより、VSYNC待ちがポーリングじゃなくなるから。
VSYNC待ちしただけでCPU使用率100％になる環境があるWindowsはどうかと思う次第。

>>579
ラスタ割り込みはさすがにもう要らん（ｗ

Sleep入れろ

割り込みにすると描画の負荷が高くて、今回の描画に間に合っていない場合なんかに不具合が出ませんか？
Windowsって割り込みできたっけ？

>>583
そんなことはない
Winではいわゆるまともな割り込みは使えない

ポーリングにしても確実な値が出ないものだから
垂直同期してフリップというのをハード的に用意しないとダメ

DirectXで垂直同期を待つという命令があると思うけど
それプラス垂直帰線期間中にbltでもきれいに動かない
これはマシンパワーの問題じゃなくてリアルタイムOSじゃないからであって
マシンパワーがあがることにより目立たなくさせるだけ

サウンドのバッファにしても同じ

別に割り込みとリアルタイム性が取れる環境なら8bitマシンでもあれだけ
ガンガン動いていて化けてはいないでしょ？

>>584
いや、>>583は>>581に対する返事で、
Vsync割り込み無くてもいけるでしょ、ってことなんだけど。

不具合出ませんか？ってのにたいして
それはないといったまでだが
不具合がでるならプログラムがおかしいとしか

>>586
Vsync割り込み使ってるの？
Vsync割り込みじゃないとできない処理ではないし、PS2とかなら使うのかもしれないけど、
DC/GCでは使うことは無かった。PSはそんなに深くさわってないから判らない。
てか>>581ですか？

>不具合がでるならプログラムがおかしいとしか
使ってないのでわかりませんが、確かにプログラムの問題になるね。
描画中か調べれば回避できるし。

微妙に会話がうまくいってないね。
判り難くてすまんです。

> DirectXで垂直同期を待つという命令があると思うけど
> それプラス垂直帰線期間中にbltでもきれいに動かない

bltが遅くて、垂直帰線期間中にbltが終わらないからですか？

>>587
割り込みが使える環境でいじり倒せるというのは一昔前のパソコンだが
割り込みがないと困る場合はわりとある
今みたいにバッファをたくさん持って処理というのがないとかVRAMが遅いとか
今とは作り方が違うしな

>使ってないのでわかりませんが、確かにプログラムの問題になるね。
>描画中か調べれば回避できるし。
不具合が出るといっているのはちみが最初に言い出したことなんだが
納得されてもこまるというか、なら最初からへんなこといわないでくれ


>>588
間に合わないじゃなくて間に合ったところで垂直同期を待つ関数と
bltなど描画が反映される関数と別になってる時点でリアルタイムOSではない
Windowsではきれいに描画されることを期待するのは１００％無理ってだけ
bltじゃなくてFlipでも同じだが、垂直同期をとってFlipというのがハード的に
用意されていればティアリングは防げる

>不具合が出るといっているのはちみが最初に言い出したことなんだが
>納得されてもこまるというか、なら最初からへんなこといわないでくれ
いや、すまんです。
でない？って聞いてるだけ何だけどね。

今日びのコンシューマて、ライブラリが結構強力でさ、そいつらがVSyncを使ってるから
後から割り込みをフックするユーザーのアプリじゃポーリングするのと大差ない。

そもそも、>>576前後が発端でVSync割り込みでなにすんのさ？ってことだから。
ポーリングは良くない、って人もいるみたいで、じゃVSyncでやってんの？と。
同期は必要だけど、割り込みって必要かー？と。
まぁ、大分スレの本筋と離れちゃってるからこの辺で収束したいんだけど・・・。

>>590
> 後から割り込みをフックするユーザーのアプリじゃポーリングするのと大差ない。

キミ、そもそも割り込み（VSYNC割り込みに限らず）の存在意義を理解していないのでは？

全然大差なくないよ。ポーリングのループはCPU資源の無駄だし、
そのCPUパワーは本来、バックグラウンドで思考ルーチンを回したり、
CD-ROMからファイルを読んだり、圧縮データを伸張したりと別のことに使えるはずのもの。
Presentみたいなブロック関数がCPU占有しちまうなんてアホみたいやん。

「なぜWindowsはイベントドリブンなのか」という話と同じことなんだけど
これで分からないかな。

> じゃVSyncでやってんの？

あれば使う。ファミコン時代からPSまで使ってた。
Windowsではないからちょっとむかついてる。

CPU使用率が100％になるからVSYNC待ちは良くないとか、別の論理まで登場したりして。
本当は逆で、VSYNC待ちでCPU使用率が100％になるOSが良くないのにさ。

一応理解して使ってるつもりです。
理解しきって使い尽くしているかといわれればNoになりますが。

後出しっぽくてすみませんが、大差ない、といったのは精度に関してです。
VBlank期間に入っても優先度の高いライブラリ周りを先に実行させるので、ポーリングしていても
割り込みに登録していても検出のタイミングはジャストで取れるわけじゃない、って意味で。
落ちてる場合はポーリングでは遅れますが。

>本当は逆で、VSYNC待ちでCPU使用率が100％になるOSが良くないのにさ。
OSのせいなの？OSに処理を返さないアプリのせいじゃなくて？

結局何に使いますか？
CPUフル稼働を目指すならコンテキストの切り替えですか？

>>591
＞VSYNC待ちでCPU使用率が100％になるOSが良くないのにさ
× OS
○ ドライバ

VSYNCだとかが絡むネタはいつも盛り上がるなぁ

本筋から逸脱しまくりなので、ROMに戻ります。
良スレ荒らすようになってしまって申し訳ないです。

荒れてはおらんよ

Sleep使ったらボーリングとは言わんのだよ。

http://www.google.com/search?hl=ja&lr=lang_ja&q=%E3%83%9C%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0
確かにな。

結局mtiwrzuVが何を言いたかったのかﾜｶﾝﾈ

> じゃVSyncでやってんの？
これじゃねーの？

>>592
＞OSのせいなの？OSに処理を返さないアプリのせいじゃなくて？

DirectXは垂直同期取ったらOSに処理返せないだろ。
ドライバがCPUを占有しない作りになってることを神とゲイツに祈るしかない。
だから割り込みよこせって話なんじゃん。

＞DirectXは垂直同期取ったらOSに処理返せないだろ。
　
OSに処理を返せないってのはダウトじゃん？
ただ単にPresent関数が返ってこないのだから
つまりそのスレッドに処理が返ってこないだけでしょ。
だからマルチスッドレるわけで。
　
＞ドライバがCPUを占有しない作りになってることを神とゲイツに祈るしかない。
ベンダーに祈るのが筋だろとネタにマジ突っ込み。

＞だから割り込みよこせって話なんじゃん。
マルチスレッド＆コールバック関数が代用品足りえない理由を述べよ。

マルチスレッドを知らないとか・・・

>>602
だからPresent関数がCPU占有したらマルチスレッドにしようが意味ないだろ。
「そのスレッドに処理が返ってこないだけ」じゃなくて
それだけでCPU使用率が100％になる、明らかにボーリングしてる場合一体どうしろと？

> ベンダーに祈るのが筋だろとネタにマジ突っ込み。

それはそうかも。

s/ボーリング/ポーリング/
上のヤツに釣られた。

>>602
WindowsでVSYNC取るとCPUを専有する。どうしよう、って話だから
マルチスレッドとかぜんぜん関係ないでしょ。
VSYNC割り込みがない以上、MSやドライバのベンダを呪いつつ
同期オン・オフの各モードを用意するしかないわけだが。

つーか、割り込みなくてもいまじゃ普通につくれんだろ。なんに使いたいの？

何に使いたいかは>>577から誰も答えてない。

　　　 　 　　☆　ﾁﾝ　　〃　∧＿∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　VSYNC割り込みのメリットマダ〜？
　　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　|　.温州みかん.　 |／

だから割り込みで起こしてもらえるならCPU占有しないのが確実になるだろ。
頭悪いやつが多いな。

コンシューマやアーケードのような滑らかな映像表現をするにはディスプレイとの同期が必要。
　　　↓
が、DirectXでVSYNC待ちをするとCPUを専有する場合がある。
　　　↓
同期を取ると、どんな高速なマシンだろうがCPUパワーの過半が浪費されてしまう。
その結果、他のスレッドやプロセスの動作に影響が出たり、
ノートPCではバッテリーの消費が激しくなったりファンが唸りを上げたりするので好ましくない。
実際、CPUを専有するゲームを作ると怒って開発者叩きを始めるユーザも多数いる。
　　　↓
CPUを専有せずに確実に同期を取れる方法として、VSYNC割り込みが欲しい。
そもそも>>572みたいに他のゲーム用ハードにはみんなついてるんだし。


とかまとめてみたけど。

何に使いたいの？
→同期を取りつつ、CPUが専有されない真っ当なWindowsアプリを作りたい。
　また、VSYNC待ちで浪費されているCPUパワーを活用したい。

メリットマダ〜？
→CPUが専有されません。

あと何故PCに使われてないのかデメリットもまとめにボンヌ

最近はグラボとドライバが対応してたらDirectXが勝手に同期とってくれてるんじゃないのかな？
負荷の小さいゲームはいつも滑らかに動いてるけど。

XP以降だけの機能？

その勝手に同期でCPUを占有されるのが嫌な人たちと、別にいいじゃんな人たちがいるので
微妙にもめてるような。

そろそろスレ違いでごんす

>>611
> が、DirectXでVSYNC待ちをするとCPUを専有する場合がある。
　　　↓
> 同期を取ると、どんな高速なマシンだろうがCPUパワーの過半が浪費されてしまう。

V-Sync待ちをPresent関数にお任せすると
おかしなビデオチップとドライバの組み合わせでは
CPUパワーの過半を浪費する場合もあるという話だよね？
　
でも、そういう糞環境であっても
自前でV-Sync待ちすることは可能でしょ。

俺の試した限りでは
Sleep関数の精度の問題で
ギリギリまでSleepさせられないんで
CPU占有率を20%前後は食っちゃったけどさ。

×CPU占有率を20%前後は食っちゃったけどさ。
○CPU占有率を20%以下に抑えることはできなかったけどさ。

100%占有さえしなければ、
何%だろうが他のアプリが困ることはそんなにないと思ってたけど、違うのかな？
そんなオレはいつもSleep(0)とかで待ってる。

割り込み待ちにしてCPUには休んでいてもらえば、バッテリーが節約できる

>>619
携帯機ではよくやるね。

>>619
それが有用なのってノートをイベントでデモ機に使ってるときだけじゃん

？消費電力を節約できるってことでしょ？

　　　 　 　　☆　ﾁﾝ　　〃　∧＿∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　次の話題マダ〜？
　　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　|　.温州みかん.　 |／

V-Syncの話はいつも話が発散するから秋田。

親子タスクを実装して使ってるヤツいる？

実装も何も、親を見て自分で勝手に行動決めるだけじゃ…

とりあえずロボット型の敵にレーザーの応用で作った剣を持たせてブルンブルン振らせたりしてる。

親子構造と親子タスクは違うのであり。

じゃあ説明しろよ

話題が閉塞してきたところで
イカベーダを見て欲しいのだが
スクリプト方式にしました．
コンパイラとかも付けたので
結構遊べるかも

ttp://hp.vector.co.jp/authors/VA036558/App/IBade.zip

出来はともかくその紹介の口調が凄くむかつくのだが。
どうにかならんか

ヘンに捻くれた感じになってしまいました．
スマソ

またイカベーダか！

自尊心が見え見えなのがなぁ…

やっぱ?

イカベーダの何を見てほしいんだよ

スクリプトの命令群とかどうですか?
やっぱり敵の動きとかつまらないですよね

ゲーム内容のことか。
どの程度のもん目指してんのかによるが、いまんとこやり込もうと
思うような出来ではないな。

イカベーダね、
「それなりに」できてるとは思うけど、
どうしてその程度の内容で処理ガタガタなんだい。
その点ではまた最初に戻ってるよと。一つ前のverのほうが良いね

なんというか面白いとか面白くないとかそういうレベルに到達してないな…

コンティニューの概念があるぐらいの
難易度じゃないとただの作業になっちゃうかも

どんな環境でもガタガタになるわけじゃないんだから
そういう内容書くなら君の環境も書くべきでは

レス先書くの忘れた
637へのレスね

>結構遊べるかも

コンパイル型のスクリプトとかプログラム的には
色々面白いことやってるのかもしらんが、
肝心のゲーム性が無いからSTGとしては遊べないぞ。

製作者的にどんなに面白いことをしていても
プレイヤー的には全然つまらないパターンの典型か

何とかプログラムでと思って勉強していたんだが、ゲーム作るのって独特なんだな・・・
もういっそシューティングツクールで作ってもいいか？
遊ぶ側としてどう思うかが気になる・・・手にもとってもらえないとかはないだろうか

ツクール製は微妙なの多いから印象悪いかもねえ。

ひとつ言えることは
ツクールで作ってたら
プログラムの勉強にはならん。

そっか・・・ありがとう。ツクール製だからといって、それだけで手にとってもらえないわけではないのか。
プログラムの勉強が目的じゃないんで、ツクールでちょっとがんばってみるよ。

HSPとかLGPとか使ってみたら？

RPGツクールはずっと出続けてるけど、
シューティングツクールって昔はそれなりにあったのに
もうないね・・・

根本的なジャンル人気とユーザーの年齢層の差かなあ。

弾幕ツクールなら、需要があるかもな。

敵配置データとか吐き出してくれると嬉しいんだけど。
そゆことできないのかな。

いまだとXMLあたりでシリアライズしてくれれば
環境に依存せずに使えていいね

問題はツールのほうを作るのが大変なわけだが

そこでBulletML

それはフォーマットだけしか・・・

STGに限らず、ツクール的環境を用意してみたいなと思うことは良くあるなあ。
ソース公開しとけば、もっとよく改良してくれる人が出るかも知れないとか。
で既存のツクール的ソフトに目を向けてみると、自分のやりたいような痒いところに手が届かず
ソース非公開だったり、公開でもコンパイル環境限定だったり。

思うだけなら誰でも

自分で作ればいいやん。そうすりゃ、ソース非公開にしたり環境固定にしたりしたくなると思うぞ。

まあ、ツクールでどんなことできるか調べてみて、自分で作るならどうするかとか考えてみるのも勉強。
いろいろ見てみるのも勉強。ソースも探してみて見れ。

問題は、そういったツクールを使った場合、システムが似通ってしまうんだよね。

似ないように作れ。

>>656
そういったものを公開するとき
一番覚悟をきめなきゃならないのはサポートだな。
きっとウンザリするぞｗ

オープンにしてて無償なら、サポートを最初から放棄してても問題ないかも。

サポートを放棄したツールなんて、よほどの出来でなければ誰も使わないような気がする

自分のために作ったものを公開するだけなんだから、他人が使うかどうかは関係ない
完全に使うだけの人間ならともかく、多少なりとも作り手にまわった人間にとって、気に入らない部分は
修正を待たずとも自分で直せるという環境は魅力的だし、それが無償ならなおさら

問題は自分で修正してまで使いたいと思わせるツールであるかどうかだよな・・・

ああ、そうか・・・確かにそうだ・・・ただ判断が自分でできないってとこが難しいな

＞気に入らない部分は修正を待たずとも自分で直せるという環境は魅力的だし
もうすでにそれは全然魅力的ではないよ。
それができるぐらいなら、適当にライブラリ見繕って自分で作っちゃうって。
無料で性能が良くて簡単に扱えるライブラリなんて、いまや探せば結構あるだろ？

たしかに…
修正がいるなら自前でやったほうが早そうだし、
そのまま使うにはサポートが無いんじゃちょっと…

結論：たぶんいらない

おまえら、自己流の汚いソースを公開したり、他人が公開してる汚かったり綺麗だったりするソースを見てみなさいよ。
勉強になるから。

プログラマーとしては、無償提供なんてやってられないわけですよ。

ソース検索はコレ使え

Koders - Source Code Search Engine
http://www.koders.com/

他人にソースみせないやつはダメだと先輩がいってましたがな。
読み物嫌いな人も無料なので一読しる！

http://www.pro.or.jp/~fuji/mybooks/cdiag/

ページの下の方に本の内容が公開されてるので。

自分のコードはなぜか人に見せたくないんだよな。
ムダに「企業秘密」的というか・・・。

あるソースがあったとして
それを誰でも見ることが出来たとしても
そっから価値のある情報を得られる奴って
限られてるんだよな。
それは結局公開者と同等レベルの奴だったり。
また、あるソースに固執しても仕方ない気がするんだよな。
掛算九九をマスターした者は、それを教えるのに別に躊躇したりしないだろ、
次のステージに進むだけ
こだわってる奴って何時までも九九のレベルに留まってるだけのような
気がするんだよな。

漏れは人のソースダウソして読む根性無い
参考にするのはWeb上のサンプルコードくらい

そういえば、ゲーム公開してるときにメールで「ソースくれませんか？」って聞いてくるやつがいたなぁ。
勉強熱心といえばいいのかそれとも・・・。

微妙なライン・・・

いいから嫁と。

スレタイをか？

ソース無し版をフリーウェアにして、
ソース付加版をシェアウェアにするとか。

またクソスレな流れになってきたな

669のソースまだぁ？

mada?

他人のソースなど、自分のセンスの無さを再確認して絶望するためのみに存在するのだ。
俺とは根本的に頭の出来が違うのだろうな、と。

不細工なソース　→　読む気すら起きない
スマートなソース　→　読んで自分の才能に鬱

プログラムなんか適当でーす

ひとつ読んでみたいものがあるとしたら、ZANACのソースかなぁ。

ひとつだけサンタさんがソースを届けてくれるなら。FFのソースキボンヌ

あ、FFはスレ違いかｗ　STGだとゼロガンナーのソースキボンヌ

>687
時代からして普通にアセンブラな気が

仕事で作ったものばっかりなんで・・・。そのうちテトリスもどきでも作ってアプするよ。
STGの方が本当はいいんだろうけどｗ

>>691
仕事では一体何をｔ（ｒｙ

>>690
そういや今Z80アセンブラ読める自信ねーな

あるいは超連射のCで書かれた部分か。
なんつーかさ、「高速化技術」よりも「小さく作る技術」を見たいんだよな。

>>691
クォース風にすれば問題なし

>>694
小さく作れば大抵速くなるよな

たしか超連射はほとんどCだったな
XSPで一部アセンブラだっけ

>>696
画面のことかと思った。

499です

あれから少し作りこんでみました。
しかし、当たり判定調整するの難しいですね。キャラの大きさは32x32を基本にして
中に描きこんだドット絵のサイズからマンパワーで座標を計算しており、キャラ描き直
したり新規で追加すると結構しんどいです。If〜Thenばっかのみっともない記述・・・
精進せねば。

F-WINGS(ver.1224)
ttp://u.skr.jp/1024/files/0760.lzh

難易度調整やパワーアップ関連、あとラスボス追加してみました（戦闘できませんが）
１〜５面までは遊べるかと思いますので、難易度等のご意見頂けたら幸いです。
手厳しい意見も是非お願いします。

当たり判定は、ザコは１個でいいと思う。思ったより細かくやっても意味なかったりするのだよ。

というか全く意味ないと思われ…

同じ種類のオブジェクトを画面にいくつぐらい出すのを想定しているのか考えて、
１個か２個しか出ないんだったら厳密にやってしまってもいいだろうし、
数十レベルで出す予定だったら、できるだけ簡潔にするようにすればいいね。

>699
ｲｲﾖｲｲﾖｰ　ただ俺の環境だとこうなるんだが…
ttp://upload.fam.cx/cgi-bin/img-box/sel41225072210.png

かなり期待しているんだけど、あえて言うなら敵弾の色をもうちっと見やすくしてほすぃ。
フルスクリーンモードはあると嬉しいけど、こっちで対応するから別になくてもいいや。
あ、あと半角スペースのあるフォルダに入れるとMIDI鳴らなかった。

みなさんメリクリです。
早速、ご意見ご指導ありがとうございました。

>>700,701,702
グラフィックに対して判定が大きかったりすると、見た目当たって無いのに
判定上当たったりしてたんで、敵毎に細かく判定付けました。
苦労の割には>>701が言う通りいまいち効果が判りません
今考えると大きさ毎のパターンを２〜３個用意しといて、
使いまわせば良かったですね。無駄に条件式が多くなる事も無かったし。

>>703
テストプレイありがとう。
画面が小さくなってますね。うーん。
・・たぶんOSのフォントサイズじゃなかろうかと予想。
ちと調べてみます。

>>704
ご意見どうもです。
敵弾はもう少し見やすくしてみます。
フルスクリーンというか、せめて２倍のサイズにできるようにしてみようかと
思案しています。かなり重くなりそうですが。
半角スペースのフォルダですか？こちらも調べてみます。

ところで質問です。
実ゲームの画面サイズを動的に変更するには、どのようにするのが効率が良いのでしょうか？
"StretchBlt"でメイン画面を拡大表示するのが簡単で良いのですが、これだと滅茶苦茶重い
処理になってしまいます。DirectXなら簡単にフルスクリーン化する機能もあるみたいですが、
できればお知恵を貸してくださいませ。

>>706
画面に綺麗な枠をつける。枠の外にステータス等を表示する。
まあ、昔のPCゲーでは、よく使われていた手法だ。
額縁に入れた絵だと、そこそこ見栄えが良くなるのと同じ理屈だな。

昔のPCゲーの外枠やステータスエリアは
リアルタイム描画面積を減らすための涙ぐましい努力の一環だと思うが
そんなことはどうでもいいな、うん

画面いっぱいの黒いウィンドウを表示させて、ウィンドウスタイルを変更してから解像度を変更する。
その上にメインのウィンドウをポップアップで表示させればそれなりに大きな画面としてごまかせる…よ。
プログラム内で特別に描画をいじらなくていいので楽。ちょっとアレな感じの解決策だけど…
（スタイル変更は他のウィンドウを巻き込まないため）

>>707,708
以前のバージョンでは、得点表示やその他の毎回描画が必要でないものは
画面外のフレームに収めていた時期がありました。
いささか古臭かったのと、目線がメイン画面から移るのが鬱陶しかったので
今の１画面に無理矢理収める方法になりました。
結果、毎回描画する処理が増えたので処理に負担がかかってしまいましたが
自分的にはすっきりして気に入っています。

>>709
なるほど。
OSの解像度を変更させるんですね。ソフト側での対処ばかり考えてました。
ＰＧに負担かけない方法という点では非常に有効ですね。
しかしこれだとアプリが異常終了や、タスク切替えられたときに問題でそうな予感。
ちと実験してみます。

VBのゲームで、2倍表示や3倍表示のモードを持ってたものがあった希ガス
ただ、どの方法で拡大描画してたのかはわかんない

あやふやなことは確認してから書け

まあ何というか２倍拡大だけでいいなら、倍角した画像を用意しておくとか
初期化時にどっか用意しとくかで構わないような気がする・・・
描画の座標指定だけごにょごにょすればいいんだし

DirectX使わない方向の話だよな？
昔やったのは、
・最終的にWinodowにn倍角でStretchBlt
・StretchBlt遅い環境向けに、内部でソフトウェアで拡大して
　一旦DIBにn倍角で描画、最後に当倍でウインドウにBitBlt
だな。
まー、いまごろStretchBlt遅い環境なんて考えなくていいと思うが

>いまごろStretchBlt遅い環境なんて考えなくていいと思うが
ところが作者の環境で「滅茶苦茶重い処理」らしいので・・・

「いまごろ」の環境だと、それこそDirectX使っても問題ないと思うし

素直にDirectX使った方が良いと思うな
VBで作ってるみたいだから参考文献とか少ないかもしれないけど

PenIIIでVRAM4MぐらいのノートPCだと普通に重いと思うけど。

ただいま帰宅しました。
皆様方レスどうもです。

>>713
たしかにそういう方法もありますね。
ただ修正個所が結構でてきそうなので、まずは>>709の方法で試してみて
それから検討してみたいと思います。

>>714
以前、メイン画面をStretchBltで倍化して表示させたのですが、私が使用
している端末のスペック（K6-500mhzとMMX166相当）ではかなり遅くなります。
素直にＰＣ買いかえたいのですが環境作るの面倒臭くって。
あ、ＯＳはWindows98とWindows98SEです。

>>716
DirectXには凄く興味あります。
これを完成させた次のステップとして勉強してみようかと思案中で

>>499
VB捨てれ…ってのはだめか。
いずれ描画速度問題になりそうだから、DirectX使った方がいいと思う。

さすがに、VBだからってDirectX使えないわけないでしょ！
DirectXはなんだかんだいって、ゲームには便利だから機会があったらやってみるが吉

ポリゴンよりハードウェアスプライトとBGが4面くらい使えるボードが出ないかなぁと日々考えております。

>>721
ソフトウェアでそういうライブラリ作ればいいじゃない

単なる一枚絵BGでいいなら100面くらい使えるぞ今のハードなら
半透明使わずオクルージョンカリング駆使すれば1000枚でもいける

まぁ要するに>>721は時代についていけてない可愛い子

>>718
> 端末のスペック（K6-500mhzとMMX166相当）ではかなり遅くなります。
　
StrechBltはビデオチップのアクセラレーションが絡むんで
CPUのスペックだけでは何とも言えない。

参考までに、
学生時代に（何年も前だが）実家のPC(K6-233MHz + Riva128)
で2D-STGを組んだときは
400x300x16bppでDIBにソフトウェアレンダリングして
30fps出てた。
　
で、>>499のゲームの実行結果を報告すると

CPU : Athlon(1.2GHz)
MEM : 512MB SDRAM(133MHz)
VPU : ATI Radeon 9800Pro 128MB
　
環境下で30フレーム切っている。
アプリ側コードに改善の余地があるように思われる。

>>723
誰も性能云々の話なんかしとりゃせんがな。
何をするにもいちいち面倒臭え！ってだけでさ。

>>718
なんだそりゃ。遅いどころか動かなくても文句言えない性能だな。
そんなタダでもいらんPCなんか見捨てて、面倒くさがらず新しい環境にしなさいっての。

将来的にDirectXに移行するのであれば、
今すぐのほうがいいと思う。

K6/500MHz当時のスペックならさほど遅いとはおもわないのだが
ソフトウェアレンダリングといえば超連射か
8bppだけどあれが２００MHｚで余裕で動くので作り方だろうな
速度稼ぐためにライン抜きとかも合った希ガス

>>725
だからライブラリ作ってしまえばどういうハードか意識しないですむ
ライブラリ作るほうがハードを起こすよりはらくだと思うぞ

n倍表示はVBだと元絵をピクチャボックスに読み込んだ後、
元絵のピクチャボックスをn倍の広さにしてから
同じピクチャボックスにStretchBlt()するのが良いかも。

画像転送サイズをn倍しないとならないけど、
リアルタイムでStretchBlt()をするよりはマシなはず。

ちなみに
CPU:Celeron 500Mhz
Graphics:i815(On Board)
Memory:64Mあれば
VB+GDIでもそこそこのキャラ数で60fps出せます。

どもです。
本日はOSのサイズをソフト側で変更させるロジックを組んだだけで終わりました。
進捗遅いです。

>>724
グラフィックボードはSavage4 Pro(32M）使ってます。
ソースはダラダラと書いてはいますが、多用する処理は極力If構文を使用せず
論理式等で代用しています。ただ肉付けばかりしたソースなので肥大化してしまい
無駄な処理も多いと思います。
ただ、条件式にかかる時間よりも圧倒的に描画関連（BitbltやStrechBlt）が遅いので
全体的なPGの流れを見直さなければいけない予感がしてきました。
あ、ちなみに画面下に表示される数値はFPS値ではありません（sleepの値です）

>>726
そこまで遅くは無いかと・・・
３Ｄゲームは絶望的ですがそれ以外は結構動きますよ。
しかし・・いいかげん正月にでも買いなおしましょうかねぇ。

>>728
bitbltの一発表示と、ライン飛ばし"nx1（step2）" ドットのbitblt連続描画と考えていますが”
はたして速度に変化でるのでしょうか？後者のほうが余計な処理が増えるので遅くなりそ
うな気がします。

>>729
それは結局内部処理でｎ倍した場合用の処理（例えば当たり判定や表示位置ををｎ倍する）
を用意する必要があるという事？
結構影響大きそうな感じですね（違ってたらすみません）

>>725
>>728の後半の通りだ。君は本当に可愛い思考の持ち主だな。

>>725
そんな貴兄にHSP

なにげにHSPの拡大縮小表示はかなり速いからなｗ

>>733
HSPだとそもそもフルスクリーンモードも解像度切り替えも楽にできるし
さりげなくDireｃｔXも簡単に使えるしな。。。ただ言語仕様が orz

俺HSPの性能で言語使用がC系列ライクだったら今ごろ信者になってた

あれでインタープリタじゃなかったら俺も信者になってた。

あれでオブジェクト指向も入っていたら俺も信者になってた。

あれで言語がC++だったら俺も信者になってた。

プログラミング言語がＨＳＰだけだったら俺も信者になっていた

LGPってどう？

プロパンだな

LPG

ﾜﾛﾀ

HSPってそんなに便利なのか？　C++で扱いたいなら普通にDirectXそのまま使えばいいと思うんだが。
D3DXは使いたくないけどHSPモドキは使いたいとか、そういうお年頃？

>>744
便利というよりは、最初に頭にたたき込まなければいけない知識が少なくてすみ、
お手軽にそこそこの結果が得られる、ということだと思う。

HSPはむしろ俺みたいなおっさん向け。

>>746
おっさんでも当然使えると思うが、
基本的には子供向けだと思う

１０年近く前に大学で１コマFortranをとっただけの漏れみたいな人間にはとっつきやすくていいな＞HSP

CとかC++とか名前は聞くけど、おっかなくて手を出せません。
おかげでここの書き込みも大半は意味不明だったりするけどね（苦笑）。

使ってる人が多いということは、それだけニーズに合っているのだろう

8bit時代のBASICをちょっとかじった世代にはありがたいぞ。
勉強含めて、あんまプログラムに時間かけたくないし。

ダウンロードしてから(難しいお約束事を知らなくても)数行書くだけでDirectXが使えてしまうお手軽さは強い
C++などを普通に使える人にとっては、メリットは多少薄れるだろうな

やはり簡易言語には限界があるのだろうか。

漏れはツールの限界を知る前に己の限界にたどり着いてしまうので問題なし。

HSP製ゲームですごいものがあれば説得力あるんだけど、
お手軽な分、お子様がなんも考えないで作りました、みたいなのが
大多数なのが実情なんだよなー。

>>753
天晴

突然謙虚な人が増えたのはなぜだ

みんな照れ屋なだけです。

まあ入門にはいってことね。機能理解してからDirectXに進む方が理解は早いかも。
C++とDirectXとWinのお約束事の全部が良く判らないと、まともに動かすところまで進むのも大変で。

まあサンプルあるから絵を出すくらいならC++使ってもすぐだが。

Flashなんかは、お子様級も多いけど、層が厚い分モンスター級な作者も結構潜んでいるよ
センスある作品見ると、普通に言語でちまちま何ヶ月もゲームプログラムなんか組んでる
自分が馬鹿馬鹿しく思える

Javaは意識せずに内部でDirect3D使ってるです

HSPのシューティングというと飛翔鮎とかガンデッドラインとかか

しかもDIBやDDBとかDirectXとかメモリーの確保によってすべてダイナミックにかわる
動的コンパイラだけにNT4のようにDirect３DがダメだったりSSEの有無とか
かなーりあたまはいい

.NETもだけど、静的コンパイラのほうが速度の限界がきやすいからね
内部で統計取りつつダイナミックにhotspotはつえーよ

GCのチューニングも余裕だし５．０での速度はすばらしい

>>754
個人的には飛翔鮎でHSPに対する偏見はなくなったなぁ・・・
LGPでもPsyche Metalとかあるし、このスレ的には言語は関係なさそ
目的が達成できてるなら、わざわざ途中で使用言語を変える必要もないだろうし
御幣があるかも知れないけど、「C系を使ってるほうが良い」みたいな風潮があるから
入門者が敬遠し、結果として、ものが比較的良いものにはC製が多くなってるだけだと思う

>>760
それはJavaの仕様ではなかったと思うです
でもJavaは透過GIFとか普通に使えるのが案外便利だと思うです
速度とかVMの話をしだすといろいろ湧いて出てくるのでそのへんはスルーしたいです

HSPﾖまんせー

便利ではあるがマンセーするほどのものでもないｗ

言語より配置やアルゴリズムが大変だ…。
面白いかどうかってこっちで決まるよなあ。

配置やアルゴリズムが絶妙な作品にもう少し出合ってみたいな
現状探してもいないが…
まぁ配置に凝ったものにふれても、今度はシステムや細かい挙動が不満だったりしそうだが

シューティングゲームを作ってみたいのですが、
どこから手をつけていいのか分からないのです。


当方のスペック
・大学生♂
・その昔ロゴとかいうソフトで厨房の頃シューティングを作っていたりした
・c++をほんの少しだけ知ってる（無知に等しいかも）
・ｃ++builder5professionalを持っていたりする（ほとんど使った事は無し・正規購入品）
・マシンスペックはｘｐ、ｐ4　1.8ｇ、memory756M、radeon7500

言語・開発ソフトは上記でいいのか、
お薦めの書籍・ソフト・HP、何からはじめたらいいのか
等、教えていただけないでしょうか

追記：2Dシューティングです

せっかく購入した開発環境があるんだから、それを使っていきましょや。
とりあえずはプログラミング自体に慣れたほうがいいかもね。

最初は絵を表示するとこかな。I/OのDirectX入門書とかお勧め
2Dつっても今はDirect3D使うのが主流だからDirect3Dを覚える

シューティングのプログラムの構成はWebに沢山あると思うんだが
本を上げるならシューティングアルゴリズムマニアックスとか。でもお勧めはしない
実際に作るときは他人の書いたソースでも参考にすれ

それが出来た上で面白いシューティングを作りたいならシューティングをやりこむべき

>>768
つ" http://clootie.narod.ru/cbuilder/index.html
個人的にゃDirectXよりVCLなんだが・・・・

こういうのもある。
Quadruple D for Borland C++Builder
http://www.kcat.zaq.ne.jp/takao/qd4bcb/

なにこのやさしい対応！？

同人系の人が留守だから・・・・

>768
猫又刃�dのところのドキュメントを漁るとよろし

>>768
ロゴ？タートルグラフィックスの？

>>674
そもそもコンパイルができない香具師が多いらしいな。


mameのソースは公開されているが「コンパイルの仕方教えれ」な香具師が多すぎ。

情報をくださった皆様、大変ありがとうございます
とりあえず、DirectXをかじってみようかと思います

>>771
>I/OのDirectX入門書
とは
DirectXによるゲームプログラミング I/O別冊
の事でしょうか？

>>776
そうです
接触判定が
if touchingでできたのが恐ろしく素晴らしい事だと知ったのは
その後ｃ++を学ぼうとして挫折した時の事でした

同人系だと冷たいってのかよヽ( ｀Д´)ﾉ

えーとC++でシュ−ティングを作ってます
大体の枠グミは出来たのですが（自機、敵機を動かせて弾が出る。）面とかキャラデータとかを格納する方法が分からないです。
イマまではソースにそのまま埋め込んでたんでました。
多分別ファイル化何かを使って管理するのだとは思うのですが。
教えてくださいｍ（＞＜）ｍ

その辺は好みの問題だと思う。
シューティングくらいだったら面数も多くないと思うし
ソース埋め込みでもいいんでない？
一人で作ってるんだったら外部データ化するメリットもそんなに無いだろうし。
あくまで俺の考えだけどね。

ステージデータのハードコーディングからの脱却って、一つのテーマでありFAQでもあるかな
方法は用途によっていろいろなので一発で教えるのは無理だよなー
異論もどんどん出るだろうしな。作る人によって全然スタイルが違うし、
ある方法は他の人からすれば馬鹿馬鹿しくみえたりもするだろう

バランスを取るために変更が効率よくできれば、実装方法はなんでもいいかな。

最近作ったＳＴＧで初めて面データを外に出して、マップエディタを自作した。
あまりの開発効率のアップぶりに我ながら泣けた。

個人的見解を言えば、ある程度マップデータの規模が大きくなるならソースとデータを分けた方がいいと思われ。

たいていの入門書にはシューティングゲームとかいう名前でサンプルがあったりするけど、
実はキャラや弾の移動くらいで、配置などのステージデータとかの持ち方とかそういう
データ構造について言及してるのってほとんどないよね…
あと入門書でも爆発アニメーションについて、細かく説明してあったりすると嬉しいな。
移動や当たり判定については、もうおなかいっぱいだよ。
そういう参考書ってあったりするのん？

>>785
そこでやねうらおですよ。

うらお！
うらお！
やねやね　うらお！

シューティングを作ろうとしているまた別の者です
敵弾パターンと敵パターンと移動パターンを定義して
データ上の敵は
・座標
・体力
・移動パターン
・移動パターンへの引数いくつか
・敵弾パターン
・敵弾パターンへの引数いくつか
を保持する方向ですが、なにぶん自分で思いついた方法ですので暴走してないか心配です
普通はどうやって保持して行動させるのでしょうか？

問題ないと思う．

私の場合は，座標とかの個別データの他は，
敵の種類ごとに移動や弾発射，描画とかをまとめた関数つくって
そのポインタを一個だけ持たせてる．

漏れは描画は別かな
表示コマンドだけキューアップ

>>788
細かいことだけど消滅するまでの時間とか持っておいたほうがいいかも。
例えば最終的に画面外に出て行く敵とかは
発生した瞬間に画面外に出て消滅するまでのフレーム数を求めてしまって、
画面外に出たかどうかの判定せずに、そのフレーム数を減らし続けて
0未満で消滅させる。
当たり前すぎてシューティングのサンプルとかでは書かれてないこと多い。

Luaの組み込みにチャレンジしてるけど、仕様覚えるのが大変。
でも分岐や反復が使えると面白いことが出来そう。

>>791
なるほど、情報サンクス。

age

ｵﾌﾞｼﾞｪｸﾄ（ここでは機体など）のﾃﾞｰﾀにはvectorｸﾗｽを使うのがいい？
ただ単に配列で管理するよりずっと便利だと思うんだけど。

vectorよりはlistかね

やれそうなときに両方を使ってみるのがいいかと。利点と欠点が見えてくる。

ハンドルでアクセスしたり順番にアクセスしたりできるように、
内部的にはvectorなんだけど双方向リンクリストも持った形式になってる。

vectorとlistの欠点ってなんですか？

あと利点もお願いします

いや・・・それだけだとスレ違いだろ・・・

>>801
シューティングゲームを開発する上での利点・欠点なら問題ないのでは？

>>802
じゃあよろしくｗ

>>803
いや、俺無理だから……

vectorは指定した添え字（位置）へのアクセスが高速な代わり、
要素の途中挿入や削除が遅い。
listは要素の途中挿入・削除が高速な代わりに、
指定位置へのアクセスが遅い。

シューティングのオブジェクト管理では大概
途中要素の削除が頻繁に起こる（弾が画面外に消えたり）し、
判定なんかでアクセスする際はbeginからendまで一通り回すだろうから、
決め打ちでどこかにアクセスすることは少ないような。。
と、これだけ考えればlistの方がいいんじゃないかなと思うんですが。
どうなんでしょう？

>>805
当たり判定で全オブジェクトを見なければならないので、
そうするとlistは不利なんでは？

>>806
>>805

ＨＳＰでＲＰＧ作りたいんですが、正直難しいと思います。
でもやりたいんです！！僕はＨＳＰでブロック崩し（アルカノイド）
ぐらいなら作ったことあります。
今のところ、オープニングまで作ったのですが、どなたか僕に
ＨＳＰの基礎からすべてを叩き込んでくれませんか？？
お願いします。

ＨＳＰでＲＰＧ作りたいんですが、正直難しいと思います。
でもやりたいんです！！僕はＨＳＰでブロック崩し（アルカノイド）
ぐらいなら作ったことあります。
今のところ、オープニングまで作ったのですが、どなたか僕に
ＨＳＰの基礎からすべてを叩き込んでくれませんか？？
お願いします。

iteratorで先頭から順番にアクセスするだけなら
さほど速度に違いが出ることはないかと思ったのですけど

むしろ、オブジェクト数が増えていった時、
vectorのように途中要素を追加削除した際に領域を再確保するコストに比べれば
アクセスにかかるコストは微々たるものではないでしょうか？
一番の問題はランダムアクセスをすることがあるかどうか、だと思いますが。

とはいっても実際のSTGで実証したわけではないので推測の域を出ませんが…

試せばええやん

どっちだっていいだろ。

スペック高すぎて実感できないだろうから。Ｌｉｓｔのが良いよ。>>805に書いてあるとおり。
それが理解できないってのはVectorとListの違いを理解できてないってことだよ。

作ればランダムアクセスすることはまずないってすぐわかると思うんだがね。

自分はlistでやってます。
vector使ってても、添え字からアクセスする事はあまりしないだろうし。

・vectorはゲーム開始前に必要な要素数分のメモリを確保することができる
・listは要素を追加するたびにメモリを確保する

∴要素の追加に関してはvectorのほうが有利

ここまであってる？

STL使うとやたらファイルサイズが大きくなるんですが…
俺はしょぼいリストを自作して使ってます

>>816
バカの典型

>>817
おちつけ

>>816
今時、ファイルサイズのデカさは問題にならないくらいの
HDD容量(配布するなら、通信帯域)があるから、

　ライブラリ自作する時間 ＜ ファイルサイズ

だな、効率を考えると。

>>815
> ・vectorはゲーム開始前に必要な要素数分のメモリを確保することができる
> ・listは要素を追加するたびにメモリを確保する
>
> ∴要素の追加に関してはvectorのほうが有利
　
ちょっと待て。メモリ確保の様式が固定的であると考えますか。
妙ですね。例えば、listのソースに一度でも目を通していれば
allocatorが任意に指定できることを知るはずなんですが。

結論：
てめーよー
有利とか不利とかパフォーマンスを語るならよー
ちゃんと調べろよ。ベンチ取れよ。裏取れよ。
思い込みで語んなよ。なぁ。おい。ｺﾞﾙｧ。お？

ぶっちゃけどっち使おうが最近のマシンなら大差なかったりする

>ちょっと待て。メモリ確保の様式が固定的であると考えますか。
>妙ですね。例えば、listのソースに一度でも目を通していれば
>allocatorが任意に指定できることを知るはずなんですが。

allocatorが任意に指定できようができまいが、listは要素を追加するたびにメモリを確保するのには変わりない。


結論:
お前もバカ。

>>819
>>821
多分君たち微妙にずれてる。
深呼吸してレスした相手の文章をよく読みましょう。
不用意に馬鹿とか言っちゃだめですよ、馬鹿ども。

話題転換に「弾幕はさいたま」でもどうぞ

>>820
フラグメンテーションを起こさなければね・・・

ｲﾃﾚｰﾀでアクセスするとVC++のデバッグでインスタンスのメンバを参照できないんですが
これって仕様？STL便利なんだけどバグったときに使いづらいなぁ

>>821
＞allocatorが任意に指定できようができまいが、listは要素を追加するたびにメモリを確保するのには変わりない。
　
ずれている。私は>>815に前提条件の質問をした。
＞メモリ確保の様式が固定的であると考えますか。
　　
なぜ質問したかというと、それは>>815の結論

＞∴要素の追加に関してはvectorのほうが有利

の導出過程がおかしいと感じているからだ。なぜ

＞・vectorはゲーム開始前に必要な要素数分のメモリを確保することができる
＞・listは要素を追加するたびにメモリを確保する

がパフォーマンスの優劣を語るに足る理由になるのか。
STG程度の要素数であれば全く取るに足らない話ではないのかと。

ID:PM36EONS = ID:fXtUvpbT

>>826
てめーよー
有利とか不利とかパフォーマンスを語るならよー
ちゃんと調べろよ。ベンチ取れよ。裏取れよ。
思い込みで語んなよ。なぁ。おい。ｺﾞﾙｧ。お？

端的に言って私は
ソース出せの立場である。よって免責。

自分は両方使うかな。
ゲームなんだからオブジェクト数などは有限で
開始時にvectorに入れといて、
用途に応じてそれぞれのlistに突っ込む

なにも考えない。

普通は以下のページのような各コンテナの特性を理解したうえで用途に応じて選択する。
ttp://www5a.biglobe.ne.jp/~rarin/stl/

他に参考にできそうなものは、以下のページにあるvectorの注意点というところかな。
ttp://www.nantekotta.com/stl.html

あと、
＞allocatorが任意に指定できようができまいが、listは要素を追加するたびにメモリを確保するのには変わりない。
これはちとおかしい。メモリを確保するのはallocatorだ。

ゲーム作ってるとListのが便利なんだが、パフォーマンスを考えるとそればっかりというわけにはいかないという
ところまで理解が進んでない人からみれば、Ｖｅｃｔｏｒこそが最適解となっちゃうだろうね。

メモリ確保は固定サイズで大量に確保しておいてそこから取得するようにすれば高速化は可能だが・・・。


まあ、使いもしないでどっちが良いとか言ってるヤツはプログラマとしては伸びないだろうな。

>>816
テンプレートだからね。
全てのバージョンの型サイズ分の容量は食うのかな？
自分は気にしてないけどｗ
オマケにＲＴＴＩも使ってるしｗ
その辺（コレクション管理やアロケータ、メモリプール等）も一度は
理想的なものを構築したいと考えつつも、とりあえず実害がないから後回し、、。
それよりも先に、外部ファイルから型情報を追加、みたいな事をやってみたい。

結局のところはlist有利ということになるのかな？

setって実装も見たことあるけど

>>836
どれがいいのかはっきりさせてくれよー

>>837
vector：可変長配列
list：双方向リンクリスト
set：2分木

STLportだかboostだかにハッシュもある。データ構造の特性考えて選ぶといい。

それにvector<Hoge>って直接書かずにtypedefしておいて、イテレーター経由で使うように
すれば数箇所書き換えるだけで全部試せる。

PenIIIクラスのCPUがターゲットで数千数万のオブジェクトが出てくるとかじゃない限り
そうそう違いが出るものでもないんでとりあえずどれか好きなの使っとけ。

listでもゲーム開始前に必要な要素数分のメモリを確保することができるって話はどうなった？
やり方おしえてくれ！

そーゆー命令が無かったか？

>>840
listにcapacity()はない

list::resize？

確保される最大サイズの構造体で取得される最大数の配列を容易する。
空きワークはスタックしておけばいいかな。
アロケータで確保が必要になるたびに底の配列であいてるやつを拾ってくるようにする。
これで事前にメモリ確保されてる形になると思うが。当然拾ってくるオーバーヘッドは０にはできないが。


Ｌｉｓｔがなぜ便利なのかはかなり規模の大きいものを組んで失敗してみないと理解できないと思うよ。
そしてそれは非常に有益な情報なのです。まあ、そう思うところまで作りこまないなら何でもいいとおもうが。

容易

結果として出力されるものがあまり変わらないなら、
あとで楽なほうを選びたい。

そんな優柔普段なあなたに、std::map
ランダムアクセスも途中追加/削除もやり放題。

mapの内部ハッシュの管理がvectorだったら笑えるな
その辺どう？>>846

>>847
ツリー管理だよ

>>848
シノニムじゃなくてハッシュ自体もツリーなの？

ソース見ろよ俺という感じだが。

>>849
すまん>>838に書き損ねた。map：2分木だ。mapは連想配列のインターフェイスと性能要求だけで
「ハッシュ自体」が存在しない。

大抵の実装だとキーを2分探索してるはず。仕様にはデータ構造の実装方法自体は指定されてないけど
各操作に対する計算量のオーダーの要求を満たすには木構造を使うしかなかったような。

hashや各種アルゴリズム欲しかったら標準C++じゃないけどSTLport・boost・lokiあたりを
ざっと見とくといいよ。lokiはもはやC++以外の何かに見えたりするから深入りすると戻って
来れない。

std::mapの実装は大概赤黒木だな。
つーか、それ以外の実装を見たことがない。

ハッシュベースの連想配列が使いたかったら、
STLportとかg++とかには最初からhash_mapがあるんでそちらをどうぞ。
ただし、こちらはイテレータで順次処理したときに、キーの順序に並ばないけどね。

あ。ひょっとして、>>849はstd::mapとstd::multimapを取り違えてるとかってことはない？

ゲームパッド等のコントローラ対応もいいんだけど
キーボード操作にも対応してほしいなぁという同人ゲーム結構あるよな。
まぁオレは初期型ワイドサインダー使いだから問題なしだが。

ワイドサインダー?

ﾜﾛﾀ
仮面ライダーに出てきそうだ

ジャイケル・マクソンのガイドライン
http://that3.2ch.net/test/read.cgi/gline/1068732559/

ジョン・ベンソンはいないのか？

BulletML初心者です。
<vanish>が全然うまく使えません。使い方教えてください。
他に適切な聞きにいくべき場所があれば、すみませんが教えてください。

ＢｕｌｌｅｔＭＬってＸＭＬとかの知識が無いと使えない？

基本的には、XML知らなくてもLibBulletMLが全部やってくれる。問題ない。
たしかLibBulletML組み込みガイド書いてた人のページもあったはず。

BulletMLって自機の方向をサーチとかってできる？　なんか自機の位置を
認識しない固定弾幕(ってなんだ)だけしかできないような気がするんだけど。

ていうかXMLに条件判定文って入れられたっけ？

googleで公式page探して読むと一応解説がある
ttp://www.asahi-net.or.jp/~cs8k-cyu/bulletml/
ttp://www.asahi-net.or.jp/~cs8k-cyu/bulletml/bulletml_ref.html
> スタートを押すと、自分を狙った弾が飛んでくると思います。


たしかにBulletMLには素人の導入をはばむ壁が多いとは思う
直感的にアクセスできるのはある種の言語やBulletMLに慣れた人だけのように思えるサイトデザインとか
ダウンロードして何やったらいいのかすぐわかるのは複数言語経験ずみでリファレンスの読み方に慣れた人だけとか

普及ポータルとそこへのリンクが本家から貼ってあってもおかしくないほどの良い規格だと思うんだが

OOPで　インベーダーの基本的動作作ったんだけど
OOPの観点からプログラム設計についてどう思うか、コメントください。

プログラムのみ
http://gkufme.s28.xrea.com/SpaceAction.zip

ソース付き
http://gkufme.s28.xrea.com/SpaceAction(and source).zip

ちなみにDirectX9を使用した自作ライブラリ使ってるので
DirectX9入ってないと動かないと思う。

操作は
←　and → : 移動
space : ミサイル発射

失礼しました、"素人の"は削除して読んでください
自分自身BulletMLをろくに理解してない素人だと思ってるが、だからといって
他人を素人呼ばわりしていいもんじゃない

そう思ったなら自分でそれを作ってみるべきだ。　もしそれをやるまでもないと判断したなら、当然みんなもそう思ってるということだよ。

>>863
せっかくOOPならJavaで作れよ。ﾀﾞｳｿめんどい。

>>863
CObjectから継承してるのに、なぜCTankでm_posMaxが多重定義されてるんだ？

それ以前に、OOPでゲームを作ることを考えてるなら
なぜポリモフィズムを一切利用してないのかが疑問。

これじゃ構造化プログラミングと大して変わらないじゃないか

具体的にどうしたほうがいいのかソースがないと永久に判らんのであり。
一人で１０タイトルくらい作る程度ならあんま気張ってアレコレ作ってもしょうがないし。

ＯＯＰとか役に立つのはゲームツールやライブラリ部分で、ゲーム本体側はそれほど手間かけなくてもいいんじゃないかという
気がしてきましたよ。

もうそろそろそんなこと言っていられなくなるんかなぁ。

>>867

多重定義は　単なるミスでした

また　ポリモフィズム（多様性）は、あまり活用しきれてないんですが
class CTank の MovePosとかに使ってますけど

例えばどういう感じに作ると効果的になりますか？

>>867

俺も実は　ゲームに活かすと本当によい　ということは本当なのかな？と疑問を
持つようにもなってきて。
ゲームでない場面ならば、活かせる部分がたくさんでてくるんですけどね

オブジェクト指向で作られたゲームがあまりないと思うのは
そういうことなのかな？

>>867

移動処理だったら Move
表示だったら Draw
とスーパークラスに（インターフェイスだけでも）定義して
それをオーバーライドすることで、
すべて同じ処理上で使用できるようにするってのが
いわゆる多様性ですよね

当たり判定など、他のクラスとの関連がかかわってきて
そこをどう組み込むかという部分で　うまく作れなくなって
CSpaceActionクラスに　まんま処理書いてしまった

>>870
＞オブジェクト指向で作られたゲームがあまりないと思うのは
その根拠が知りたい。

>>869

俺育成ゲーム（参加者求む）
ttp://pc5.2ch.net/test/read.cgi/gamedev/1097684655/

ここ一通り読んでみれ

>>863
俺だったらIObjectに純仮想関数でDo()を追加して使う
IObjectの双方向リストでも作って、敵とか弾とか出るたびにnewして放り込む
他のクラスと関連があるなら、参照するクラスのポインタをコンストラクタに渡す。
Run部分ではリストのノード全てをDo()してRender()とする。

つーか、カードゲーム製作スレに関係ないこと書くな！

>>870
TCG系カードゲームではオブジェクト指向便利だぜ
他のゲームでもいくらでも有効利用できるだろ

散々既出だとは思うがABA Gamesのシューティングはソースついてるし
自作STGフレームワークみたいなのの上にOOで作られてる。
TUMIKI FightersかrRootageあたりをどうぞ。
http://www.asahi-net.or.jp/~cs8k-cyu/

>>872

オブジェクト指向で作られたゲームよりも
非オブジェクト指向で作られたゲームの方が
はるかに多く見つかったから
（　純粋オブジェクト指向言語を除く　）

ゲームなんてつまるところ手続きだもんなあ

>>874
>>敵とか弾とか出るたびにnewして放り込む

IObject って仮想クラスだよね
放り込むっていうのは CTank(戦車クラス）　CEnemy(敵クラス）　に
放り込むっていうこと？

ということは、CTank　と CEnemy に 双方向リストを用意して、そこに
追加していくっていう意味でいいのかな？

とすると、弾の表示はどこのクラスが行うの？

各クラスが自分を描画を持つようにするか
描画専門のクラスを作るかでいつも迷う。
みなさんはどうよ。

IObjectのリストにCTankやCEnemyを放り込むんだろ。
まあ実際は描画順なんかを考慮しないといけないから
リストをそれぞれ分けることになるだろうけど

>>880

IObject は　純粋仮想クラスでしょ
I は　Interface じゃないのかな？

>>874
俺も割りと近いことをしてる。
ただ、描画についてはIDrawのようなインターフェイスを用意して、
IDrawを実装しているオブジェクトが各Doの中で自分自身を描画リストに登録する。
登録の際は、描画の優先度を指定するようにして、
優先度順にRenderメソッドを呼ぶようにしている。

>>881
いやまあ厳密に言えばIObject*のリストだけど、
そのぐらい分かるだろう…

>>882
描画リスト　とは　どこにあるもので、どこが実行するリストなの？

みなさん教えてくれるのはうれしいんですが、
もう少し詳しくいってくださいな

>>883

IObject* のリストって？？
俺が言いたいのは　仮想クラスだから、そのクラスを実行した
他のクラスがないといけないわけじゃん？

>>IObjectのリストにCTankやCEnemyを放り込むんだろ。

そのクラスはなんぞや？　ということです

>>885

実行した　訂正ー＞　実装した

>>863
おお！勇気ありますね。でもソース落とせない、、。

>>879
偽ガルーダやサイキではタスク系クラスが描画系クラスを参照するようにしてます。
なので、タスク系クラスには基本的に描画機能は付けませんでした。
というか、ゲームエンジンは同じものを流用してます。

>>885
…？話がかみ合わない…。
念のため聞いておくけど、

class CTank : public IObjects {};
class CEnemy : public IObjects {};

こうしていれば

IObject* objects[2];
objects[0] = new CTank;
objects[1] = new CEnemy;

これが出来るってことは知ってるよな？

訂正
IObjects→IObject

>>884
えーと、あくまで自分の実装の場合で答えますね。
外枠となるシステムクラスがあって、
IObjectインターフェイスのリストと
IDrawインターフェイスのリストを持っています。

１フレーム内の動作としては、
システムクラスはまずIObjectリストに登録されたオブジェクトのDo関数を順番に実行し、
それからIDrawリストに登録されたオブジェクトのRender関数を順番に実行します。
その後、IDrawリストに登録されたオブジェクトは全て破棄します。
（毎フレームDo関数内で登録されるため）

>>887

スペースが空いていたので、そこでリンクがとぎれてしまったみたいです
文字列をすべてコピーして　ブラウザのアドレスにはっつければDLできるんですが
一応↓にUPしておきました。
よかったらアドバイスください

http://gkufme.s28.xrea.com/SpaceAction(AndSource).zip

俺も厳密にはDxAppライブラリの方で描画をおこなっていますが、
スーパークラスのCObjectのメソッドのDrawで
DxAppライブラリの描画関数を呼ぶ用にしてます。

インベーダーで、敵がすべてばらばらに動くならば至極簡単な
構造で済んだんだけど、どのインベーダー(エイリアン)が壁にぶつかっても、
すべてのインベーダーが一段下に落ちなければいけないところがあって。
インベーダーを覆う エネミークラス　っていうのを作ってしまった。
ここら辺から仕様がむちゃくちゃになってきた気がする・・・

>>890
自分も似たような感じ。
違いは、
＞その後、IDrawリストに登録されたオブジェクトは全て破棄します。
＞（毎フレームDo関数内で登録されるため）
この部分か。
２Ｄに関しては、描画オブジェクトの種類が少ないので、静的に確保、
タスクオブジェクトは、生成時に描画オブジェクトのプールから未使用のものを
取得するようにしてる。
で、破棄するときには使用中のチェックを外す。と。
なので、３ＤＳＴＧみたいに、３Ｄモデルが多種、多数　生成、破棄されるものは
破綻するか、、。

>>888

あ〜勘違いしてました。すみません。
IObject を実装したクラスの中で CTank や CEnemy のリストを持つっていう意味で
とっていたので。
なるほどです。

>>884
なるほど〜　そうすることで、すべて一辺に
処理できますね

みなさんありがとうございました
ちょっとIObject を作ってみます

>>891
見ました。
うーん。大した事言えないけど。

もう言われてるけど、配列は使わない方が良い。
バッファオーバーランを常に監視しなくちゃいかんし。

（個人的には）ソース、ヘッダ、クラス名を可能なら一致させといた方が良い。

後、言われてるけど、virtualメゾットとか、派生全然使ってないね。
クラスとカプセル化以外はＣ。みたいな。
デストラクタは設計等が変更起きたときの事も考えて、常にvirtualで良い。

こんな感じ。

>>894

なるほど。
配列なくしてと。。

ソース名は CTank などの Cとってファイル名とするという習慣が
どこかのプログラム（マイクロソフト？）であったので
それに従ってましたが。
確かに同じ名前の方がわかりやすいですね＾＾；

確かに、自分でもオブジェクト指向っぽく見せて入るんですが、
昔とかわらないなぁ　と思っていて。
やっぱり多様性の部分が問題ですね

ありがとうございました〜

>>888
すげーまぬけな質問なんだけど、そのポインタだと仮想クラスに全部のインターフェイス突っ込まないと
ダメなんじゃー？　それでいいのかな。

あと配列はキャッシュの関係で使った方が速いという話もでてるけど、高速化と安全に配列を使う方法ってのは
このスレじゃとりあえず置いておくって感じかな？　２ＤＳＴＧで高速化必要な場面も今後はなかなかでてこないだろうし。

>>894
配列は、qsortやbsearchを使いたい場合には便利なんだけどな〜。

>>896
{};←これは実装省略してるだけで、実際には色々入ってると思われ

>>897
C++標準コンテナを使ってる限り、
STLやboostに代替アルゴリズムがあるから問題ないかと

>>894
メゾット？メソッド？

>>891
＞どのインベーダー(エイリアン)が壁にぶつかっても、
＞すべてのインベーダーが一段下に落ちなければいけないところがあって。

そういうのはメッセージ処理するといいんじゃないかな。

Observerパターンを使うとよろし

>>899
ﾜﾛﾀ

プログラムを改良しました。
一応多態性を重視したつもりですけど、どうなんでしょうか。
また評価お願いします。

敵はまだ作ってないけど。。

ソース付き
http://gkufme.s28.xrea.com/SpaceAction2.zip

DirectX9必須

操作は
←　and → : 移動
space : ミサイル発射

>>903
IObjectのデストラクタをvirtualにしておかないと、
IObjectのポインタに対してdeleteをかけた時、派生クラスのデストラクタが呼び出されないよ。

>>904

ほんとうだ・・・ありがとうございました

CSpaceAction クラス（ゲームクラス）　のメソッドの中で
CMissile インスタンスに CTank インスタンスを渡さなければいけなくて
そのために、CSpaceActionのメンバに　ObjectList の他にも CTank *pTank として
もっていますが、これは変でしょうか？

また、弾と敵との当たり判定をおこなう場合、保持されているリストが
ObjectListだけなんですが、どうやったら敵と弾のデータを当たり判定計算で
一緒に使うことができるんでしょうか。
敵のIsHItメソッドに弾メソッドを入れる方法がわかりません。
ObjectList に入っている物はすべて同じCCharacterインスタンスとして識別されてしまうので・・。

↑訳け分からない文書ですが（汗
アドバイスお願いします

>>905
　　　　　　　　　　　　　　・・・・・・
敵のIsHItメソッドに弾 メソッド　を入れる方法がわかりません。

訂正
　　　　　　　　　　　　　　・・・・・・・・・・・・・
敵のIsHItメソッドに弾 インターフェイス を入れる方法がわかりません。


CTank *pTank のように、CSpaceActionクラスのメンバにもってしまえば
できることなんですが、それだとObjectListの意味がますますわからなくなって
しまいますよね

>>906
うーん、ちょっとよく分からないんだけど、
リストが1つしかないのに、どうやってそこから弾と敵を取り出して
適切に当たり判定ができるのか　ってことかな？

それと個人的には、リストの走査でループ回すときは
イテレータ使った方がいいと思う

>>907
>リストが1つしかないのに、どうやってそこから弾と敵を取り出して
>適切に当たり判定ができるのか　ってことかな？

その通りです。
みなさんはどうやっているんだろう・・・

>イテレータ使った方がいいと思う

イテレータ使うことにします
ありがとうございました

＞リストが1つしかないのに、どうやってそこから弾と敵を取り出して
弾を含めた全てのオブジェクトに認識番号をつける
普通はオブジェクトリストと弾リストに分ける物だと思うが
弾リストも更に自弾用と敵弾用の二つ用意すれば一層便利ではないだろうか

>>909

一応認識番号をつけていますが、毎回ある処理で
自機が見つかるまでループしたりする必要がでてきて
すごく無意味な処理に感じるんですがどうなんでしょうか。

また、リストを分ける方法もありますが、これだと最初からキャラクターリストに
入れる必要がなくなり、それぞれ自機リスト、敵リスト、弾リストのようになってしまい、
多態性が活かせなくなってしまうんじゃないかと思っています。

オブジェクト指向って難しいですね

>>910
自機は別に(ポインタなど参照可能な変数で）取っておく方が便利。
>それぞれ自機リスト、敵リスト、弾リストのようになってしまい
敵と一口言ったって何種類もあるんだから多態性は十分活きると思うが。

struct TASK{
void *prev; //前のタスクのアドレス
void *next; //次のタスクのアドレス
float x,y; //座標
char buff[512]; //自由に使える
};

○head　　オブジェクトリストの先頭
●term　　オブジェクトリストの最後（番兵）
□bullet1　自弾
■bullet2　敵弾

ゲーム開始時のリストは○□■●という具合に連結していて
自＆敵キャラ、アイテム等は○□の間に挿入
自弾は□■の間に挿入、敵弾は■●の間に挿入という具合に
生成したオブジェクトのリストの挿入箇所を決めておけばいいかな

>>910
自機リスト、敵リスト、弾リストを1つにまとめるのが多態性のメリットなのか？

自機、敵、弾はキャラクタを継承したものだから
キャラクタリスト一個作って全部ぶち込めばいい。
弾のリストがみたけりゃ、ソートすればいいだろ。

>>910
そうですよね
でも、やっぱり自機、敵、弾はすべて同じキャラクタークラスから
継承しているから、なんともいやはやです。うーむ。

>>912
結構いいアイディアですね。
↓のソースは　すべてのリストはばらばらに処理していますが、
一括まとめて操作するリストも作ってみました。
ただ、処理を行う順番は
移動処理 当たり判定 描画の順とやっていかなくてはいけなくて
ちょっと面倒な部分があったので、分割しました。

>>913
もちろん、同じキャラクタークラスから継承しているので、
十分メリットになりえると思います。
ただ、当たり判定などまだ行っていない処理があって、その部分で
やっぱり一括すると難しいなと思いますね。

みなさんありがとうございました。
アドバイスを参考に、すべてリスト化して、それぞれDo処理、Draw処理をおこなうように
改良しました

ものすごくソースが汚くなったような気がするのは俺だけかなぁ・・・
ちょっと見てみてください

CSpaceAction.cpp の部分ですべての処理を行っています。

http://gkufme.s28.xrea.com/SpaceAction3.zip

ああ、スマン。話題は進んでいたのねｗ
つまり、キャラクタリストに入ってる弾と自機の当たり判定がしたいわけか？？

それならシングルトンで監視クラス（イベントリスナ）でも作れば？
ようするに早期警戒機だよ。「私（自機）の領域内（x1y1-x2y2）に弾が来たら通報ください」って
監視クラスにお願いするんだ。

監視クラスは弾の参照を独自にリスト化し、常に弾の座標を監視する。

>>916

ありがとうございます

当たり判定なんですが、今やっているのは　自機と弾ではなく
敵と弾の当たり判定です。
敵と弾は複数存在しますので、監視クラスにデータを渡す場合、
std::listのポインタを渡すのが一番いいかなと思いますが
もし、Hitしていた場合、どの敵とどの弾がヒットしていたか
ということが分からなければ意味ないですよね

イテレータを戻せば、Hit処理を抜けたあと、そのイテレータに対して
処理（削除したり、ダメージを与えたり）が行えるので
よさそうですね
ただ、複数のHitがあった場合、それを返すのがすごい
大変になりそうで、難しいですね

もし実装するにしても、やっぱりfor文の繰り返しになってしまって、
すごい処理時間がかかってしまうのが気になりますが、
これはしょうがないんですかね

また、気づいたところがあったら言ってください

>>916
その方法が一番無難だけど、心配なのはその有効性が理解できるやつがこのスレにどれほどいるだろうか・・・。
ざっと読んでみたけど、回答者はアフォばっかりだ・・・

>>917
＞もし、Hitしていた場合、どの敵とどの弾がヒットしていたか
＞ということが分からなければ意味ないですよね

依頼者は監視クラスへ自分の参照も渡せばいい。
また監視クラスはタスククラスと連動する必要がある。

例：
敵No.5がタスクとして生成されアクティブになり、インスタンスを実行する。そのインスタンス上で監視クラスへ
「すべての弾を監視し、どれか一つでもわが領域へきた場合、その弾名（弾の参照）をしらせよ」と通告する。
監視クラスは要望を受け取り、要望リストへ入れる(要望は他からも来るため）　そして要望を解析後、
タスククラスに対し、
「おたくの敵No.5から、おたくのすべての弾を監視するように言われた。おたくの弾のリストをもらえないか？」
と要求を出す。

みたいに。

脳みそがウニになりかかった・・・
有効性は理解出来るが・・・
使いこなせるだけの脳力が、まだ不足してるな・・・

>>919
ありがとうございます

つまり、監視クラスがもつ要望リストへ、値をいれ、
ある処理で、その要望リストをすべて実行するって感じでいいんでしょうか

とりあえず、以下のように簡単なプログラムに直してみました。

CMissile *pMissile = new CMissile(); // インスタンス生成

Watch.HitWatch( pMissile, this ); // 監視クラスへ当たり判定の要望をだす

Watach.Do(); // 監視クラスが要望を実行

こうすると、当たり判定処理は、すべて監視クラスの中で実行されますが
それでいいんでしょうか？
>>916の方が言っていた、早期警戒機で通報してくれるようなものではなく
当たり判定用のクラスになってしまう気もするんですが。

でも実際気になったんですが、OOPのインベーダーって存在するんでしょうか
どこを捜してもOOPのインベーダー（のソース）が見つからない・・・
あるとしたら、どうやっているんだろう

普通にほしいものでイテレータかえせばよろし

タスクすべてのリストがほしい場合と
敵弾だけ、敵だけ、自機弾だけとそれぞれ返すメソッドを作ればいいだけだ

つーか、弾と敵と自機のリストにわけちゃダメな理由が思いつかない。

理由ってのは分けないメリットということね。

だよなあ。

>>921
＞>>916の方が言っていた、早期警戒機で通報してくれるようなものではなく
＞当たり判定用のクラスになってしまう気もするんですが。

んなこたーない。マウスリスナみたいなものさ。君がもう少しイベントドリブンを理解してくれれば・・・。
俺の言ったとこはＪａｖａやC#、MFCのイベント構造を応用しただけ。

>>923
わけちゃだめな理由ではなく、一緒のリストにすることがメリットになると
俺は考えてます。理由は多態性ですね
ただ、それによってデメリットというのもでてきます
同じリストに載っていることから、個々の関係処理がしにくくなってしまう
ことですね
今までやってきて、インベーダーでは個別にリスト化したほうが
より効率的に組んでいけるということを俺は感じました

といってもいろんな問題だらけでちょっと混乱中ですが；；

とりあえず、ネットで検索しつつ本当に納得できるような仕様を
模索中です

>リストが1つしかないのに、どうやってそこから弾と敵を取り出して
>適切に当たり判定ができるのか　

── base*型のポインタがあるとき、ポインタが指しているオブジェクトが本当に
属している派生型はどれかという問いに答えなければならない。この問いに対する
基本的な答えは4つある。

1. ポインタが単一の型オブジェクトだけを指すようにする
2. 関数が参照できるように基底クラスに「型フィールド」を配置する
3. dynamic_castを使う
4. 仮想関数を使う

基底クラスへのポインタは、集合、ベクタ、リストなどのコンテナクラスの設計で
使われる。このような場合、私がとるのは、同種リスト、すなわち同じ型のオブジェクト
のリストである。2、3、4、の方法は、異種リスト、すなわちいくつかの異なる型の
オブジェクト（へのポインタ）のリストを作る時に使われる。3は、言語サポートが
ある2の変種である。4は型の安全性が保証される2の変種といえる。1と4の組み合せは、
特に面白く、強力である。ほぼどのような状況でも、1と4の組み合せは、2や3よりも
クリーンなコードを作れる。──
　　　　　　　　　　　　　　　　　　── Bjarne Stroustrup著 プログラミング言語 C++ 第3版

>>925

簡単なコードで示していただけたらわかりやすかったんですけどね
いまいちたとえ話がよくわからなかったみたいです

マウスリスナみたいなやつですか、なるほど
ちょっと考えてみます

ありがとうございます

多態性って同じように扱いたいときに利用するものでしょ。
扱いの違う「弾」やら「自機」やらをまとめても・・・。

多対多の種類別の比較が必要ならリストよりツリーのほうが効率よくない？
数百機ぐらいなら数回の探索で済むし

多態性など"ありがたOO機能"を無思考に使って悦に浸ってる脳死バカが多いスレですね

同じ基底クラスは一つのリストで管理しなければならない、などという制限は元々ない。
基底クラスは一緒にする、リストは複数とる、これで万事解決

わざわざ探索する手間をかけてまで同じコンテナに入れたい理由が・・・。

>>928
簡単な例か・・・ＪａｖａかＣ＃なら書いてやってもいいがＣ＋＋は嫌だ。

ていうかさ、Windowsってキーボードやマウスの状態を監視してて、たとえば
マウスが動いた場合WM_MOUSEMOVEが発生するでしょ？
その後コールバック関数WndProc()が呼ばれるでしょ？そして対応する処理を書くわけだけど、
これは理解してるよね？

つまり監視クラスに依頼者である敵のコールバック関数を登録して、弾がどれか当たれば
それを呼んでもらえばいいわけだ。
そのとき、当たった弾の参照を受け取ればいい。なんら難しくはないはず・・・。