花火というと東方になってしまいそうだが・・・
弾幕ばっかりになりそうだな
>>920 BulletMLを読み込み「文法を解析してその通りに動く」プログラムを自分で書くしかない。
C++やDだったら↑の括弧の部分を実装したlibBulletMLがあるがHSPには今のところ
そのようなライブラリやDLLが無いため。作れば神になれるよｗ
打ち上げ花火は見に行かなくなったなー
どうしても目が回避ルートを探してすげー疲れるから
>>921 じゃあ、玉はサイン関数でにょろにょろしてランダム時間で爆発だな。
爆発は形がいろいろあるね円形とハートなど
２種類じゃん
ナイアガラのように、怒涛の如く押し寄せる弾、弾、弾
普通
最近は星型、ニコちゃんマーク、キティちゃんとかドラえもんとかあるよ。
分裂して更に加速したり、精子みたいに泳いだり。
精子、つまりR-TYPEみたいのを作るということだな？
コンピュータシミュレーションが導入されてから
花火もすごい進化してるらしいな
935 ：
920：2006/07/30(日) 00:22:04 ID:QTYk6WOv
アドバイスありがとうございました。
当面はHSPの標準命令だけで何とかしてみようと思います。
花火大会行ってきたよー。回避ルートは全然考えなかったけど、
「あ、これ弾幕パターンにしたら面白いかも」とかは考えてしまった。
精子みたいに泳ぐヤツ、ホーミングミサイルの出だしみたいだって言ったら、
彼女に引かれた…。
精子みたい、なら引かれないのか？
卵子見たいって言ってやれよ
じゃあ、精子が卵子にたどりつくシューティングということで。
それって斑鳩だね
R-TYPEかと思った
東京は立川の花火大会いてきた。
板野サーカスみたいな花火があって吹いた。
俺はケーブルテレビでその模様を見ていた。
おれはテレビ東京
２ちゃんのオフで見に行ったｗ
946 ：
名前は開発中のものです。：2006/07/31(月) 22:17:18 ID:4A+XaW5s
いつも気になってたんだけど、このスレって技術スレだよね？
技術スレだけど、(煽りをスルーする)技術がないの。
スルーする以外の技術も無いですよ
ある程度のノリも必要だよ。
3Dで2Dシューティングを作る場合、通常の地上空中で撃ち分けが無い当たり判定ってどうやればいい？
大真面目に判定するとアンダーディフィートとかレイシリーズみたいになってしまう。
雷電IIIとかが理想なんだけど、方法が分からん・・・。orz
ん？
スクリーン座標で判定すればいいだけじゃないの？
スクリーン座標上で何をどう判定すればいいのかが分からないんだ。
オブジェクトの深度によってサイズも変わるし、カメラの角度によって判定の形も変わってくるから・・・。
グラディウスや虫姫３面みたいな
スクロール方向が可変のステージの背景マップ情報って、
どうやって表現すればいい？
一方向だったら簡単なんだけど。
アクションゲームと一緒だぞ
マップを大きめに作っておけ
>>952 サイズは計算で出せるし、形なんか矩形でいいだろ。
>>956-957 なるほど。射影変換をしないとパースが付かなくなるんだっけ？
そして矩形で計算か。なんとかなりそうな気がしてきた。ありがと。
射影変換しないっていうのは正射影でレンダするって意味？
>>959 やってる最中に気付いたよ・・・。寝ぼけてるようだ。
結果がレンダリングと合ってないと意味ナインだった。
やっぱ射影変換して矩形か球かのサイズは自力で算出しないとだめか。
>>921を見て何となく作ってみました。
http://gamdev.org/up/img/6905.zip ステージ構成のものを作りたかったんですけど、時間がかかりそうだったので、
スコアだけを競うミニゲーム的なものになりました。
気が向いたら遊んでみてください。
STG作るのは初めてで、難易度調整に苦労してるので、
遊んでくれた方はスコアを教えていただけると幸い。
ちなみに私は
Normal～16000、Hard～10000
程度しか取れません。
>>961 イイ（・∀・）！花火っぽい！ｗ
ノーマルで平均７～８０００点くらいだった。
玉が増えてくるとぱにくりますｗ
ショットで玉を上部に押しやる事ができるといいな、とか思った。
>>961 ノーマルで11469点しかいかないorz
画面端で反射するので、こっちも画面端に近い位置に張り付いてひたすらショット、
低速移動でちまちま避ける、みたいなチキンプレイ。
>>962氏の、ショットで弾を上に押しやるというアイデアが面白そう。
>>961 俺はNoemalで何とか一万点に届くぐらい。
自機ショットの速度が少し遅めなのが気になるかも。
>960
判定用に1枚板のポリゴンを用意して、それの頂点をスクリーン座標に
変換して、判定したら？
http://gamdev.org/up/img/6914.lzh 3Dで2Dシューのサンプル
ソースはなし（まぁ、HSPだしｗ）
敵のどの部分を判定に使うか
自分より奥にいる敵は3DY座標を真ん中じゃなく敵の上部を使う
自分より手前に居る敵はそのまま中心の座標を使う
敵の3D座標に大きさ分x,z（yは上で決めた座標）を足した座標を
スクリーン座標に変えて、敵の中心座標(これもYは上で決めたY座標)も
スクリーン座標にしてやってる
この二つの座標の差分を判定範囲として使う
こんな感じ
実際には回転も考慮してるから、判定は回転する矩形と点でやってる
>>962 >>玉を上部に押しやる
面白いアイディアですね。
試してみようかな。
>>963 丸玉は少しばかり自機狙いになってるので動いた方が安全かも。
>>964 今度は速くしてみます。
皆さんプレイしてくれてありがとうございました。
967 ：
950：2006/08/03(木) 22:50:15 ID:LE8eDZEp
・・・三次元空間での球をスクリーン座標上での円に変換して判定することにしたんですが、
その半径の算出方法を聞いてもいいですか？
座標変換とかの理解が曖昧でよく分かりませんでした・・・orz
>>965 なんか不思議な方法ですな。参考にさせてもらいます。
矩形が回転しているということは、判定はあの外積とか使って線の交差とか求めるやつでつか。
以前実装したら結構重かった記憶が。
>>967 バカ正直に計算
P : 球の中心座標
r : 球の半径
C : カメラ座標
U : カメラの上方向ベクトル
m : View/Projection/Screen行列
で、画面上の球（円）は
中心（pixel）：
P' = m * P
半径（pixel）：
V = P + r * normalize( cross-product( U, P - C ) )
r' = |m * V - P'|
もっといい方法がありそう…教えてエロい人(´･ω･`)
970 ：
950：2006/08/04(金) 01:38:44 ID:Pfv4JpqV
>>969 やっぱりそのままやるしかないのか・・・。
なんかビュー変換で求めた球の中心点のZ値と射影行列の一部を使えば
何とかなりそうな気がしたんだけど、、、無理？
3Dの2Dシューは技術的なこともそうだが
ステージデータの作成を考えると頭が痛くなりそうだ
そいや昔は擬似3Dって言葉があったがこっちは擬似2Dとでも呼ぼうかｗ