1 :
名前は開発中のものです。:
ゲームプログラマなら誰もが通る、もしくは、通った道。青春の香り?
それは「シューティングゲーム製作」・・・。
このスレでは、そんなシューティングゲームの製作技術や技術の検証、成功談
失敗談笑い話、難易度の設定方法論、多弾の是非などについて語り合いましょう。
もちろんBulletMLなどで弾幕を作成してみたり、自分の作ったシューティングを
晒してみたり、プロジェクトをはじめてみるなどもOK!
ただし、シューティングの未来とか既存のゲームの話題などは、関連する他の
スレでやってくれ。
■前スレ
シューティングゲーム製作技術総合 2機目
http://pc5.2ch.net/test/read.cgi/gamedev/1073736474/
3機目か……これで最後だな。
エクステンドするかもしれないだろ
シューティングマニアックスはいまいちですた
…読まないと得られない知識ってあるかね。。
いまいちでもよんどくか…
ステージの組み方とかありました?
前にスクリプト組めって言われたけどいまいちわからないので
そのあたりの解説があれば買ってみようかと
シューティングマニアックスに書いてる内容は、
プログラミング初心者の自分でもちょっと考えれば分かる事ばかりだった。
弾の動きなんてせいぜい高校数学レベルの内容だし。
そんなんじゃなくて、DirectXの基礎を理解してることを前提に、
簡単なシューティング丸々一本作り上げるような本があると嬉しいんだけどね
自分独習なので、クラス設計とかその辺の、他人のやり方が見てみたい
正直、シューティング作ってて困るのは技術的なことよりも
センスとデザインなんだよな。そもそも俺全然シューターじゃないし・・orz
あれこれ意見出してくれるシューターがスーパーバイザとして
ついてくれるのが理想なんだろうけど。
>>12 シューターじゃないってのはシューティングが上手くないって意味?
それとおもシューティングをよく知らないって意味?
後者なら、なんでわざわざシューティング作ってるのか聞きたい。
まあそれはそれとして、あれこれ意見が聞きたければこのスレで聞けば
良いんじゃない?
世界で一番厳しいアドバイザが殺伐と勢ぞろい。
シューティング苦手なら、シューティング苦手な人向けのシューティングを作ればよいと思われ。
下手にシューティング野郎が作ったシューティングより受けるシューティングになるかも知れん。
つーかシューティング多すぎ。
式神みたいなのとか?
あれって、俺の周りだとシューター仲間以外にだけ人気ある。
自分でシューティングをやらないと
どういうシューティングが面白いのか分からない
ということかと
レイストームに感動してこの道に引きずりこまれた口だが
じゃあなにをどうやったらあんな感動が得られるのが創れるか
って言われると、未だにわからんよorz
>>20 多分作品云々より、プレイヤーの精神状態とか今までやってきたゲームとかの
影響のほうが重要と思われ…
昔から言われているものの未だに決定版が出現してない
「互いに向かい合って撃ち合う」タイプの対戦型STGですが、
やはり最大のネックは敵CPUのアルゴリズムなのでしょうか。
アップルのARCHONがそれに近いw
サイドビューだけど…。
どうなんだろう。チンブレにしろTSSにしろ、決定版といえるほどの完成度はある気がする。
でも対戦格闘のほうが楽しいし、普通のSTGのほうがさらに楽しいが。
チンブレの高次面CPU相手に初心者が毎回同じ場所でやられて投げ出す問題は、
・大ダメージ攻撃の場所を憶えきれない
・どう駆け引きなのかがわからない (序盤の面は普通のSTGと同じ感覚で勝てるため駆け引きを学べない)
あたりが原因か?
最初の2行に関しては知らないが
3行目の敵キャラプログラムが最大のネックという話は疑問だな。
洋物FPSのBOTプログラムについて調べてみてはどうだろう。
キチガイじみた強さと人間臭い行動をする作例は少なくない。
浦島太郎の気分が味わえるかもしれないぞ。
26 :
25:04/06/17 13:35 ID:pdvW+yJp
洋物FPSのBOTがどんなロジックで動いてんのかは知らんが、
学習型にするというのも一つの手。
学習アルゴリズムだけでコードの7割くらいになりそう
対戦格闘なら相手にして楽しめる程度のCPU組むのも比較的楽なんだが、
STGの、おそらく大部分が弾避けに属するようなのは、
実用で作れるんだろうか。今のところ議会制弾幕回避機関が先端か?
BOTをユーザーがプログラミングできるTSSクローンがあったとして、
それのCPUをまともに組めるかどうか。
原作の嘘避け連発があまり楽しくない、というところからこの問題はスタートしてるようだが…。
対戦格闘程度のCPUで十分楽しめるような対戦STGの仕様を組んだほうがいいか?
撃ちと避けが入る以上、かなり無理っぽい気がするが。
対戦STGか
一応「ネットやろうぜ」の時にこれはというのがあったけど、
検索してもほとんど出てこん
おたがい一度に1発しか撃てない対戦STG、というシステムなら、
対戦格闘のCPUと似たような作り方ができるかもな
それが面白いかはワカンネ
ペンギンクンウォーズって対戦STG?
オフコース
何となく対戦グロブダーっぽい感じで想像してみるが、確かにうそ臭い回避だけなら比較的何とか
なりそうかもしれない。しかし、位置取りでオプション類を配置したりとか敵回避方向への
先読み弾の発射とかいった事になると、ちょっといい方法が思い浮かばない…
35 :
27:04/06/18 14:59 ID:xHeZzj8T
>>34 何手先までも読むシューターに追従するのは苦手であるが
例えば10秒間生き長らえるための安全領域探索木なら
それほど大きくはならないし、高速だよ。
36 :
25:04/06/18 15:00 ID:xHeZzj8T
あまりベタな弾避けアルゴリズム組むと、常時ドット単位・フレーム単位の神避けとかされそう。
38 :
25:04/06/18 15:22 ID:xHeZzj8T
>>37 濃密な弾幕の中から「回廊」を見つけ出し「すり抜け計画表」を立てるのは
なかなか骨が折れると思うよ。最初の頃は明らかに行き止まりの「死の回廊」を
見つけ出して得意げに突っ込んでいくから(苦笑
探索ステップに上限を設けるので調整によってはヤケッパチ行動になりやすい。
39 :
25:04/06/18 15:25 ID:xHeZzj8T
ゴメ。補足すると上記の方法論は厳密には弾除けとは別の部分です。
大局的な振る舞いを決定するためのルーチンです。ボードゲーム的で
面白いよ。
>>34 普通の偏差撃ち(相手が等速直線運動を続けるという前提のやつ)
でない場合の話か。その辺になると予想(博打)撃ちの世界に入っちゃうんだよね。
#相手が回避できるエリア(円)に満遍なく撒く必殺射撃は除くw
俺がやったことあるのは、相手の回避方向(の癖)を記録してフィードバックする
という単純な方法。たぶん、発展させれば相手の回避曲線まで記録するカンジ
になるんだと思われ。まぁ、STGはモデルが単純化されまくってるからサンプリング
できる要素も少ないし。比較的組みやすいのでは。
>>38 >明らかに行き止まりの「死の回廊」を
>見つけ出して得意げに突っ込んでいく
ワロタ
縦シューつくってるんだけど、パワーアップ削ろうか悩んでる。
パワーアップあってもあんま意味ないんだよな。
死んでもその場復活でパワーアップアイテム拾ってほぼ元通りになるし…。
パワーアップが出ると「パパパパワーアップ」が聞ける!
それだけだけど
パパパパウァアッッ(・∀・)ガイジンサーン
最初からフルパワー状態で、やられてもパワーダウンしない方がいい
攻撃が激しい終盤でやられて、最弱な状態からプレイ汁というのは酷だ
フリーや同人、アーケードでパワーアップ制にしている所は猛省して欲しい
グラディウスとかみたいにフルパワーノーミス前提で作られてるならいいけど
最近の一般人にはノーミスクリアが難しい弾幕シューだとあんまり意味ない気がする
死んですぐにパワーアップアイテム出るならそもそもパワーダウンしなきゃいいし
あとパワーアップなしなら敵の体力の調整をしやすいって利点もあるな
ふと思いついた。
空中でうろついてるパワーアップアイテムが弾を防いだら面白そうだ。
何十発か当たると壊れるようにして、すぐ取るかぎりぎりまで盾にするかのジレンマが。
バランス取りは大変そうだけどな。
最近のケイブとかのパワーアップって単に序盤の弱い状態が強くなるという満足感を
得るための演出なんじゃない? やられても2,3個アイテム出るし。
パワーアップの効果が微々たるものでも、自機の攻撃の見た目の変化がちょっとした楽しみになったりはする
弱い装備でやれることが少ない状態でプレイヤーをシステムに慣れさせ、
本来の複雑なシステムへパワーアップで段階的に発展させてゆく、という方向もある
作りたいゲームの方向によってパワーアップの要不要は大きく変わるし、作っている間でも変わるだろう
シルバーガン、斑鳩、ボーダーダウン…
単純パワーアップを廃したシステムがわかりやすいのって他に何があるかな
>>46 ギミック系にならさほどバランス気にせず取り入れられるかもね
式神2もパワーアップ無いよ
ケツイも無いに等しい(死んでも即時パパパパウアッだから)
システムがわかりやすかどうかは疑問だが、同人ならOOHかな
最初から特殊兵器てんこ盛り
最近の縦だと、俺が知ってる範囲ではアーケードSTGでもパワーアップに
意味があるなと思えるのって無いんだよなあ…。
パワーアップって昔はゲームを易しく(有利に)するフィーチャーだったけど、
それだと上手い人ほど有利になってしまう、というジレンマをなんとかしようと
した結果、事実上パワーアップの意味がなくなったんだろうな。
ちょっと前は、パワーアップすると難易度が上がるので、1段階で止めとけとか。
チマチマとした攻撃力で雑魚のショボイ攻撃にも恐々としながら
避けてかわして耐えに耐えてやっとこパワーアップし、
アリンコをゾウさんが踏み潰すがごとく、さっきまで必死にかわしてた
雑魚を一掃できたりするところに爽快感がある。気持ちイイのれす。
これパワーアップの醍醐味なり。
破壊力があがることで
ゲーム性は低下する。よってすくなからず難易度はあげる。これ定石。
しかし雷電はこれどうなのかね・・
>>53 なぜ雷電がここで出てくるのかわからんけど、少なくとも最近のゲームは
最初ヌルいのであまりそういう感じしないんだけどな…。
後半は死んでもパパパパウァアッッだし。だからこそパワーアップシステム導入の
是非を考えてるんだけど。
ダライアスとか延々とパワーアップしていくやつは事実上残機無用
だったと思うけど、続編作る上で問題にはならなかったのかな?
初代はショットでもまだミサイル>レーザー>ウェーブ等とあって
パワーアップの意味があったけど、IIなんかは中盤で死んだら最後までいっても
フルパワーにならないというシステムだったな。
あんま深く考えてないと思われ。
死んだらパワーが思いっきり奪われるということで、
上級者に刺激を与えているのではないかと。
いまさらな話題だが聞いてくれ。
俺の方法はB宗一派に入ると思うのだが、
int time_table[] = { 16, 17, 17 }; のようなテーブルを用意して、
タイマーを調べて delta_t >= time_table[count] のときに画面を更新している。
これと同じような方法を使っている例は見たことがないのだが、
2Dゲーを作る場合には、この方法でもいいのか?
なんというかそれは非常にレベルの低い解法だな。
ぴったり60fpsにしたいというならもっと良い方法がある
サンクロとかボスで死ぬと思いっきり萎えたな。
最近はその辺に気を使ってるのかな。>その場復活のアイテム
>>58 逝ッテヨシ。googleヲ用イテ自己解決セヨ。義務。
キーワード:
サンプリング周波数
ナイキスト周波数
aliasing-error
固定小数点演算
bresenham's algorithm
マルチスッドレ
嘘。逝かなくて(・∀・)イイ
int time_table[] = { 16, 17, 17 }; ←下駄を履かせるとイイ
あとはスクロールのガタツキを改善するための工夫をすればイイ。
ぶっちゃけ浮動小数点でやってる俺はまんどくさすぎな人間
フルスクリーン等の環境ならほぼ確実にV-SYNC待ちが入るので
誤差蓄積は無いし、問題ないのでは。
65 :
64訂正:04/06/20 00:55 ID:NgwUMUOo
V-SYNC待ちを指定する場合は誤差蓄積を容易く回避できるし。
>>57 上手くなってきて稼ぎとか始めた場合や、
普段死なないところでミスしたら捨てゲーすると思う…。
>>66 死んだときに後になればなるほど高得点が入るようにするとか・・・。
この場合、ボス戦で死ぬのは駄目。道中で死ぬことによって点数増加。
この点数は、ラストの残機ボーナスより(最終面で死んだ場合は)多くなるようにするとか
んで、死ぬことによって1、2段階ずつパワーダウンしていく。
ドドンパチでこれを考えると
緋蜂戦に入る前にぎりぎりまで残機を減らしたほうがいいわけだが
それだと、全一を目指そうとすると、緋蜂発狂モードに未パワーアップ&残機数無しで相手しなければならない。
こんな感じで、安全をとるか、点数を取るか。
とかにしてみるのも面白いやも。
あとこれだと後半で死んでも捨てげーにならない、と、言う利点ができたりするわけですが・・・
どんなもんやろ?
そこまでしてパワーアップの必要性を作ることもないんじゃない?
そういったゲーム性はまた別の組み方があると思う。
死んだら敵機よろしく得点アイテムを吐くわけな。自機が。
特定のポイントで死ねなかったら捨てゲー確定ですな(意味不明かもしれん)。
あと、あんまり高いリスク→高得点を詰め過ぎてプレイヤーにストレスばっか
与えると、根本的につまらんゲームになりかねん。
残機潰したほうがスコアが稼げるというゲームは実際にあるわけだが
そして不評なわけだが
えーとガンネイルとか?
ちがったっけ
>>54 なんだろね?
雷電は結構、パワーアップ重要だったと思うけど(復活ゲーだし)
多分、ボス前のショット>レーザーのバランスの事とか?
、、そろそろ、2ヶ月あまり停滞していたSTG作りを再開します。と自分に言い聞かせ、、。
とりあえず、安易な縦シューサンプルが動く所までを目標に、、。
74 :
58:04/06/20 08:19 ID:eF3refHy
>>59 そんなにいい方法があるのなら、ぜひ聞かせてほしいが…。
>>61 キーワードはググりました。
固定小数点使ってもある程度の誤差は免れないと思う。
俺の方法よりはマシですけど。
>下駄を履かせるとイイ
無駄足は踏まさせてます。
if(〜)
{
before_time = time_table[count] - delta_t + now_time;
>V-SYNC待ち
完璧にV-SYNCが取得できるなら苦労しませんが。
まぁオプションで指定してもらえれば作る側は楽だが、そんなのめんどうだし。
>>63 そうですかね?浮動小数点でも有効数字の範囲なら同じに見えますが。
じゃあ簡単に解説
まずWin32タイマー精度が1000ms分解能
ほしい精度が1000/60ms=50/3ms分解能
dword time_prev_mul3; // ワンフレ前の時間
dword time_cur_mul3; // 現在の時間
dword time_remain_mul3; // 誤差蓄積時間
void FpsTimer60::wait(){
while((time_cur_mul3 = timeGetTime()) *3 + time_remain_mul3 - time_prev_mul3 >= 50);
time_remain_mul3 = time_cur_mul3 - time_prev_mul3 - 50;
}
remainが大きくなりすぎたら一旦remainを初期化したりする処理
連続49/3日稼動をまたぐ時の処理は省略
…という方法
これでうまく動いてるんだけどどうや!
かってに送信された。一行追加
void FpsTimer60::wait(){
while((time_cur_mul3 = timeGetTime()) *3 + time_remain_mul3 - time_prev_mul3 >= 50); // 松
time_remain_mul3 = time_cur_mul3 - time_prev_mul3 - 50; // 誤差を記録
time_prev = time_cur; // ワンプレ前の値として記録
}
QueryPerformanceCounter は使ってはいかんのか?
別に構わんと思うけど、1回の呼び出しに1us位掛かった気もする。
>>74 で、bresenham' algorithm は無視かよ。
s/'/'s/
82 :
58:04/06/20 19:22 ID:eF3refHy
>>76 ども。
3倍して誤差をなくしてるんだな。
>>78 いいんじゃね?
俺はQPCが嫌いだから使っていないだけ。
>>80 無視しているわけではない、使っていないだけ。
まぁ76のが応用だな。
76を参考にして作ってみたが、delta_tがdj。
DWORD before_time = timeGetTime(), now_time, delta_t = 0;
int wait_vsync()
{
now_time = timeGetTime();
delta_t = (now_time * 3) - (before_time * 3);
if( delta_t >= 50)
{
before_time = now_time;
return 0;
}
return 1;
}
で、
while(wait_vsync())
83 :
58:04/06/20 19:24 ID:eF3refHy
追記、
今回は delta_t が使えないので誤差の蓄積は諦めた。
ちなみに
>>74に書いたが、58のソースでも誤差の蓄積はしていた。
76だけど
あのさぁ、わざわざ3倍してんのはremainに誤差を蓄積して後フレームで取り返すためにやってんのに
その処理なくしたら何のいみもねーだろ。
そもそもv_syncとか意(ry
まだブレゼンハムとか言ってる人がいるのか。
タイマ周りなんて容赦なく浮動小数使えばいいのに。doubleで1=1秒で。
const double FRAME_RATE = 60.0;
double gameTime = 0.0;
double gameDeltaTime = 1.0 / FRAME_RATE;
Boost::timer t;
while (true) {
double currentTime = t.elapsed();
if (gameTime > currentTime) {
Sleep(gameTime - currentTime);
}
gameTime += gameDeltaTime;
Update();
Render();
}
こんなんでも基本に。
>>74 >完璧にV-SYNCが取得できるなら苦労しませんが。
んー。DirectX7以前ならフルスクリーンでは確実に同期できますが。
(できない珍種ビデオカード環境があるなら例をあげてみなさい)
更に、DirectX8以降に対応したドライバならウィンドウモードでも
確実に同期できますが。大抵はスキャンライン単位で情報得られます。
まさか、「CRT側のリフレッシュレートと同期できない環境」で
ノイズレスかつスムーズな2Dゲームプログラムを実現できるとお考えで?
>>83 >誤差の蓄積は諦めた。
まぁ、勉強中ということなら今回は諦めてもいいんじゃないか。
ただし、精度保証はちゃんとできるんで。数値計算の初歩本ぐらい
買うか借りるかして勉強したほうがいいと思うぞ。
>>85 いや、精度保証付きであれば何でも構わないわけだが。
話の流れ的にも整数演算のみでカタが付くことを58が
望んでる様子だからブレゼンハムって単語が飛び出たのであるし。
vsync同期前提で良いんじゃないかなあと俺は思ってんだけどね…。
綺麗だし。
89 :
88:04/06/20 22:09 ID:zSzztZMs
あ、言葉足らなかった。
タイマはリフレッシュレートいじれない人用と考えて
そんな高精度じゃなくても良いんじゃないって話。
90 :
名前は開発中のものです。:04/06/20 22:13 ID:DOcz0XvB
ねーねー、誤差蓄積時間って書いてあるけど、
これって単なる前回誤差時間だよね?
ウィンドウモードでVSyncに同期できるってのはどういうことですか?
例えば普段リフレッシュレートを85Hzに設定してる人が、
ゲームのウィンドウだけをVSyncに同期して60fpsで動かすことって不可能ですよね?
>>91 私はA宗です。
B宗1派の苦労もB宗2派の不幸も知らないし知りたいとも思わない。
A宗でしたかー。
94 :
92=87:04/06/20 23:13 ID:wt7FAzbI
です。
数値計算屋ならなおのことB宗にしそうだけどなあ。
#ゲームなんて超複雑な偏微分方程式みたいなもんだ
でだ、俺B宗なんだけど、ちとA宗の人に質問。
このことを具体的にどう実装してるのか教えてくれ。
「同じ曲線軌道を取る弾を等間隔に連打して曲線を描く弾幕を作りたい」
もちろん軌道は微分形式で表されてる奴ね。
dt可変だと、連射弾の1つ1つの軌道が変わると思うのよ。直線弾ではなくて、曲線弾だから。
結局そんなもんは誤差の範囲ってことでごまかしてるわけかな?
(実際にプレイしてればそんなに気にならないだろうし、どうせ桁外れに小さい誤差だろうけれど)
97 :
96:04/06/21 00:04 ID:ufNKNDg5
すまん、ちと要点がなんだかわからない文章だった。
要するにこれをA宗の実装方法でやるのに問題点は
「等時間間隔で発射すること」「全ての弾の曲線に同一軌道を持たせること」
の2つだと思うんだけど、実際どうしてるのかな、と。
98 :
92=87:04/06/21 00:13 ID:LDPsXW0a
教義をよく読んだら、もすかすてA宗ってオブジェクトのパラメータ更新も
リフレッシュレートに同期させんと異端になるんか。私、原理過激派に抹殺されるかも(・∀・)
>>96 弾幕に関しては、お定まりのアニメーション再生ルーチンと同じでイケルぽ。
空間上のパラメトリック曲線上をナゾルっぺよ。Δtにあわせてスライダー上を
進むようなイメージだべよ。
99 :
92=87:04/06/21 00:23 ID:LDPsXW0a
えーと、予定調和的な処理を簡素に作り上げるなら
ゲームワールドの更新に未知のΔtを使うのは嫌過ぎる。ってのは同意。
私は「滑らかな2Dゲーム、滑らかなスクロール」のために画面更新は
リフレッシュレートに同期させよう。というつもりでA宗だと思ってたプチ信徒ディス。
>>98 アニメーション再生ルーチンってのが具体的にどういうもんだか分からないのだけれど…。
もしオブジェクトごとに非常に小さい固定dtの数値積分で求めているとしたらそれは本末転倒で、
初めからゲーム全体にクロックを与えて、そいつで駆動したほうが楽でよくない?
>>98 よく、知ったかのゲーマーとかがバカの一つ覚えみたいに60fpsとかいうけど、
実際は59.97Hz前後だから、VSYNCに頼ったところで正確に60fpsにゃならないんだよ。
昔のゲームは、単に高速タイマがなくて、ターゲットのリフレッシュレートは固定だから、
タイミング取るのにVSYNC割り込み使ってたという単なる慣習だ。
PCだったら、タイマとトータルのフレーム数のカウンタを併用して、1/60fps相当で
必要な処理を通すようにゲームループ回して、絵の方をつじつまあわせりゃいい。
ちらつきが嫌ならVSYNC検出して、帰線期間に絵を書き換えりゃいいし、
そうじゃないなら洋ゲーみたいにフレームレート可変って感じで。
今のシューティングゲームは、負荷でスローが掛かる表現にしたって、ソフト的に
ウェイト入れてやるだけなんだから、無理してVSYNC使う必要はないんだよ。
102 :
名前は開発中のものです。:04/06/21 01:05 ID:p+RaFqmS
俺は敵の挙動を計算式で処理してないので
60FPS固定でやるしかない。
ずいぶんと脱線をしている気がする。まあ、76と86が実用になることだけわかってれば問題ないよな。
リフレッシュレート85とかのCRTでのウィンドウモードで
伝統的57〜60FPSゲームを動かすのがお題目なんだし。
あぁ、76-77と書いておかないと万一のとき大変だ。
>>100 補足しようと思ったらかぶってしまった。
んーと、A宗原理過激派として実装するなら
弾幕に関しては予めシナリオが作られた打ち上げ花火なので
Δtを使った数値積分で軌道を決定する必要はないです。
Δtが未知なら避けるべきです。
私はFLASH上で編集した弾幕を自作のエクスポーターで
出力させてるんですが、私のフォーマットは
座標値を補間パラメータとする空間上のベジェ曲線で軌道を表現しています。
この制御点には時間tなども入ってます。なぞるタイミングは、制御点間でtを
3次の多項式で補間しています。
ですので、Δtが例え未知の場合であっても弾の軌道が崩れることはありません。
>>101 >実際は59.97Hz前後だから、VSYNCに頼ったところで正確に60fpsにゃならないんだよ。
おっしゃる通りです。
私はVSYNCに同期した画面更新なくして2Dゲームで滑らかスクロールは不可能
という立場を取りつづけますが、ゲームワールド更新に関してはその限りではありません。
リフレッシュレートが59.97Hz前後なら同期で60fpsにならないの?
アニメーションってソレね。ベジェ曲線は自由度は高いけれど実はそうでもないのよね。
要するに3次ベジェ曲線で表せるものしか表せないわけ。
俺が「微分形式で表したもの」って言ったのはちょっと表現的には間違いかも。
「微分形式でしか表せないもの」とか「積分がまんどk(ry」なもの。
計算屋なら数値積分がどんだけ楽か分かると思うんだけど、
それなのにA宗でパラメトリック曲線に頼るというのは、なんか変だなと思って突っ込んでみたのよ。
なんかリフレッシュレートっつーよりは数値積分のありがたみの話になっちゃったけど(笑)
59.97HzはカラーNTSC放送の垂直同期周波数ってだけで、
PCがそうであるかどうかとは全然関係無いと思うんだがなぁ。
>>110 厳密にリフレッシュレートを測定したことはないが
俺は一度、timeGetTime基準による「完全なる60Hz」で
V-SYNC完全シカト描画を行ったが、モニタ60Hz動作時
「前画面と新画面の境界線」がヌルヌルポ下がっていった。
>>111 ガッ
それだとリフレッシュレートは60Hzより上という事ですな・・・。
これからはデジタルディスプレイでいいんじゃ
最近の、書き込んである背景って、どう管理されてるか知ってる?
チップと一枚絵の中間という感じかな?
何を指して「管理」といってるのかよく分からんが
2、3人程度で趣味でやるなら難しい事考えずにチャランポランで平気だけどな。
例えば地上オブジェクト配置するときの命名規則とか。その程度だろ。
1面.dat
2面.dat
3面.dat
4面.dat
とかで、中身はレイヤー別に
地上オブジェクトの配置情報
地上静的構造物の配置情報
背景ビットマップ
セコくやればレイヤー機能付きペイントツールさえあれば足りる。
s/地上オブジェクト/地上キャラ/
絵の話?
書き込んである=2Dと解釈すると、ケイブだったら1画面くらいの大きさのチップ?を
並べてるんじゃないかなあ。あんまり同じ絵を並べてるようには見えないけど。
作画のときにチップをいろんなかたちで並べて、データに落とすときに1枚絵にしてそう。もちろん複数レイヤー
今はそういう力業というか、マシンパワーでごり押しみたいなのが平気で出来るように
なったからなぁ・・・。
16×16ドットでマップチップを作ってた時代が懐かしい。
まあそれでも、サウンドの容量に比べれば可愛いもんかも知れんが。
RPGのレベルアップの意味もそのうち薄まってくるんかな。
いやいや。
122 :
名前は開発中のものです。:04/06/21 18:19 ID:5Ni6y7O+
76のヤツって差が50以上開くまで待つんだから不等号逆じゃね?
このままだとprev_time_nul3が初期化されてなければ、
(now = n * 3) + (remain = 0) - (prev_time = 0)になって、
最初の呼び出しで永久ループだし、
ちょっと前にtimeGetTime()で初期化してたらwhile()で待たない。
123 :
58:04/06/21 19:11 ID:xf+FXc2Y
俺の発言で誤解を招いてしまったが、俺はあくまでB宗一派。
>>84=76
3倍しているのは誤差蓄積の他に、俺の int time_table[] = { 16, 17, 17 }; のような
ばかテーブルを作成しないためでもあるのでは?
あと誤差蓄積を無視しているのではなく、delta_tが死んでいるので出来ないだけ。
そのうちソース修正する。
>>85=86
ソースupサンクス。参考にします。
>>87 いままでのソース読めば分かると思うがDirectXは使っていない。
> CRT側のリフレッシュレートと同期できない環境
それだからタイマ使うんじゃねーの。
実現は出来る。ある程度のマシン性能以上の環境ではな。
> 数値計算の初歩本
お薦めの本があるなら教えて欲しい。
安ければ洋書でも読む。
> 話の流れ
そういうことだが、拒みもしない。
>>88=89
> リフレッシュレートいじれない人
それが俺。
だから1000msぐらいは精度が出ないと困る。
timeGetTimeも微妙だけどな。
>>101 それはB宗だ。
>>111 興味深い。是非詳しく聞かせてほしい。
正直もっと一般的な環境を前提に、一般的な環境で開発したほうが良いんじゃ…
>>123 だから、なんでDirectX使わないんだ?
('∀`)
DirectXを使う使わないとかいう話なんか?
>>128 >>87の発言
>まさか、「CRT側のリフレッシュレートと同期できない環境」で
>ノイズレスかつスムーズな2Dゲームプログラムを実現できるとお考えで?
に対して、
>>123は
>いままでのソース読めば分かると思うがDirectXは使っていない。
>それだからタイマ使うんじゃねーの。
>実現は出来る。ある程度のマシン性能以上の環境ではな。
と反論しているわけだが、おまえどう思う。
130 :
58:04/06/21 23:16 ID:xf+FXc2Y
お陰様で、だいぶよくなってきた気がする。
明日くらいには誤差修正込みの完全版ソース出せそう。
あと、俺は純粋に1/60secごとに描画したいだけだ。
>>124 「ノイズレスかつスムーズな2Dゲームプログラム」が前提だったから
特殊な環境に依存すると言ったんだが。
文句があるなら
>>87にどぞ。
俺の想定環境は PenIII以降, Win9x/NT ぐらいか。
リフレッシュレートは60か75くらいしか確認できないが、それぐらいになら変更できるし大丈夫だろう。
>>125 最も本質的な話題だが、俺に答えられる範囲内ではないな。
まぁ、俺の環境と技術が不足しているから。
そもそもDirectXでリフレッシュレート同期できるんなら、こんな質問していない。
>>126 ソース見てるか?win32依存。
>>127 (´・ω・`)
>>128 ここの方たちから見るとばかばかしいくらいの質問だからこうなる。
でも、正直WIN32APIの範囲内で答えてほしい。
…って言うとDirectXの構成の話になってしまうので、避けておく。
131 :
58:04/06/21 23:18 ID:xf+FXc2Y
ぶっちゃけ内部処理300fps最強ですよ。(200fpsくらいでも十分かも)
リフレッシュレートが60Hzだろうが75Hzだろうが85Hzだろうが、
3〜6ステップ適宜進行→描画→VSYNC待ちのループだけで、
60Hz完全同期との違いがわからんくらい十分ぬるぬるぽ動くよ。
今のCPUは滅法速いから、ゲームロジックの負荷が数倍になろうが問題にならないし。
Δt可変の方法はリプレイのこと考えると全滅かな。
>>132 ガッ
うえー。それは3Dゲーム限定の話でないの?いやマジで。( ゚д゚)ポカーン
にわかに信じられないのでとりあえず確認中。
ちなみに、俺はDirectX7の頃にfpsリミッター解除でD3Dで2D横スクロールとか色々実験したが
流石に2D横スクロールでティアリング誤魔化すのは無理ぽって結論に達したぜ。
この辺は程度問題ということで、気にしなければ大した問題じゃあないという路線なら俺は引き下がる。
58の場合、640x480程度の解像度でシステムメモリ→ビデオメモリのBitBlt転送だろう。
ハードウェア支援があっても200fps〜300fps安定して出すのは至難と思われ。
更新は1秒間に300回で、描画は1秒間にリフレッシュレート回ってことじゃねーの?
300回は50と60の最小公倍数だからコンシューマ用にもピッタリ
最小公倍数(・∀・)ガッテンガッテンガッテン
136 :
58:04/06/22 00:08 ID:1dwd+WcH
おかしい、whileに + remain_time した瞬間値がマイナスになってるっぽい。
あと、wait_vsync という意味わかんない関数名は気にしないでくれ、昔の名残だ。
もう寝る(´・ω・`)
DWORD before_time = timeGetTime(), now_time, remain_time = 0;
void wait_vsync(HDC hDC)
{
while(((now_time = timeGetTime()) - before_time) * 3 < 50)
;
remain_time = (now_time - before_time) * 3 - 50;
before_time = now_time;
}
>>132 ゴメンx256。
てーか俺って
>>132の書いてること全然読んでないし。
寝ぼけてるので寝る。ごめんあさーせ。
素人なのでBoost::timerなんて物があると知らなかったよー
timeGetTimeが1000msまでしか測れなくて悪戦苦闘してたのが馬鹿みたいだ
139 :
138:04/06/22 03:27 ID:LaxixKHR
>>86の方法を使ってみたら、安定して60fps出るようになったのですが、しかし、
>>58のような方法を使ったときよりも、動きがカクカクします。
素人なので原因がよく分からないのですが、Boost::timerの精度が低かったりするのでしょうか?
timeGetTimeが1000msまで?
ms単位をDWORDで返すのにそれは無いだろう。
>>86のはSleepの精度の問題かもしれないので、timeBeginPeriod(1)
とかやって見ると良いかもね。
もしくはビジーループに変える。
他にはメッセージループの問題とか色々考えられるかな。
141 :
138:04/06/22 03:59 ID:LaxixKHR
timeGetTimeは1000msじゃなくて1msか。
今は
>>58の方法に戻して保存しちゃったからソース残ってないんだけど、
自分はこんな感じで書いたからSleepの精度は関係ないと思う(自信無いけど
const double FRAME_RATE = 60.0;
double gameTime = 0.0;
double gameDeltaTime = 1.0 / FRAME_RATE;
double currentTime;
do{ //ゲームループ
do{ // VSyncに同期しない場合、ループで待機
if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE)){
TranslateMessage(&msg); DispatchMessage(&msg);
}
currentTime = t.elapsed();
}while(gameTime > currentTime);
gameTime += gameDeltaTime;
Update();
Draw();
}while(1);
>>141 Windowsメッセージはビジーループに入れないで一気に処理
しておく方が良いかも。
ありゃ、タブが効いてない…
で、boost::timerの精度が低いのかな、って思ったのは、
下みたいなコードを書いた時に32-40FPSあたりをうろうろしたからなんだけど
下のコード、何か間違ってるかな?
あと、内部でclock()を使ってる、と書いてるサイトを見かけた。
const double FRAME_RATE = 60.0;
double gameDeltaTime = 1.0 / FRAME_RATE;
do{ //ゲームループ
t.restart();
Update();
Draw();
do{ // VSyncに同期しない場合、ループで待機
if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE)){
TranslateMessage(&msg); DispatchMessage(&msg);
}
}while(gameDeltaTime > t.elapsed());
}while(1);
>>142 PeekMessageの部分は外に出したり中に入れたり、いろいろ試しましたが、同じ結果だったと思います
>>143 そのコードだとt.restart()が良くない。
1フレームの間隔だけを測っていると安定しなくて当然だよ。
>>143 clock 関数は、呼び出しプロセスにかかった時間を通知する。
つまり、この用途には使えない。
147 :
58:04/06/22 20:53 ID:1dwd+WcH
136のソースのバグが取れない…。明日に回す。
>>138 俺が使っているループです、参考になれば。
WM_PAINTで描画、WM_DESTROYでmsg_loop=0にしてる。
int msg_loop=1;
while(msg_loop)
{
if ( PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE) )
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
InvalidateRect(hWnd, NULL, FALSE);// 画面更新
}
}
148 :
58:04/06/22 22:10 ID:1dwd+WcH
意外と簡単に直った。が、ウインドウを2秒間ぐらいドラッグするとfpsが601になる。謎。
通常はだいたい60fps。
void wait_vsync(HDC hDC)
{
while(((now_time = timeGetTime()) - before_time) * 3 + remain_time < 50)
;
remain_time = (now_time - before_time) * 3 + remain_time - 50;
before_time = now_time;
}
上の方のソースとあんまり大差ないな。(´・ω・`)
まぁ、バグが取れただけ良しとしますか。
ようするにおまいらシューティングゲーム製作技術について
語ってないってことでOKだな?
150 :
名前は開発中のものです。:04/06/23 01:38 ID:mQGYafkt
OK
スレ違い
>>2の関連スレが生きてるんだから、そちらでやったほうが良いかもしれないな。
質問と正答のやりとりで済むならここでもいいんだが。
>>106 >FLASH上で編集した弾幕を自作のエクスポーター
これってどういう環境で作ったんですか?
関連サイトや書籍とかあれば教えて下さい。
後、アニメーションやキャラ配置、その他のデータ出力とかもやってるんですかね?
俺も気になるな、それ
ABAさんトコで紹介されてた
BulletML対応の弾幕生成FLASHのことじゃないかと思う俺。
155 :
86:04/06/23 11:35 ID:5nypZ6RY
ああ、boost::timerは機種依存なくて
手っ取り早く浮動小数で時間が返るタイマAPIだから使っただけ(w
boostの中の人はANSI Cのclock関数呼んでるだけだから、精度いいとは思えんです。
157 :
152 :04/06/24 00:45 ID:jhY3Irve
ギョエッ。英語かーw
サンクスです。
日本語の解説サイトないかググッてみます。
なければ諦めますw
プラグイン系のスレって、あんまないですね。
興味ある分野なのですが、、。
MAXプラグインとかかなり便利らしいけど、日本語解説がないみたいで挫折。
158 :
152:04/06/24 01:05 ID:jhY3Irve
一応少しありました。
多分、SWF形式ってムービーのような構造?
プロジェクトファイル(*.fla?)をコンバートORエクスポートするのがよさげかな?
やっぱ、英語が出来んと駄目か、、鬱
>日本語解説がないみたいで挫折
というか正規ユーザーでなければプラグインのテストすら出来ないはずなので
技術的な面で挫折要素はないんですよ。正規ユーザーなら、分厚いマニュアル
入りの小箱が数個ほど届きますから、まずアレと格闘することになります。
API巨大ですがサンプルありますし。デベロッパーも多いのでフォーラムも
充実してますし。DirectXとかOpenGLとかWin32APIを乗り越えてきた人なら
そんなに心配しなくて平気です。
Macromediaの製品に関しても同様で、買えば“相応の”サポート情報は
得られますんで・・・(本当か?
英語は避けられないに関しては同意。まぁ、これは慣れる他ないんで。
えーと補足。「お前、割ってるだろ」と言ってるように見えるんで訂正。
挫折するには早すぎるだろ、という趣旨です。
Flashの開発環境って結構たかいのね
言語の開発環境並みかよ!
例のシューティング本でてたが・・・ありゃ、シューティングというよりか、
弾本だな。
それそれ。
プログラミングには詳しい人が書いた本だけど、シューティングゲーム・・・
というかゲームについてはイマイチ分かってない人が書いたっぽい内容だった。
あんな当たり判定じゃ、通り抜けしまくりじゃん!とか。
読んでないけど、いろんなゲームの引用してるんでそ?
知らないってことは無いんじゃ…。
実際に遊ばせるレベルのものは作ってない感じがする。
ちゃんと動くゲームを作るのと遊んで面白いゲームを作るのとでは別ものの技術が必要だからな
このスレ自体は>1のとおり両方を扱うわけだが
あれ?前スレによると、その本書いた人は老舗の同人ゲームプログラマじゃないの?
169 :
名前は開発中のものです。:04/06/26 00:22 ID:b74UJZlq
まぁまぁ。このスレの半分は漏れ含めて似たようなもんだし・・・orz
面白いシューティングを作る方法って本で解法できるか?
作り方を載せるくらいしか本では出来ない気が駿河。
>>163 つーかそこのHPにあるゲームで
技術の程度が知れるな
技術的に見れば、ある程度の物ならどの同人シューティングもたいしてかわらん
あの本よんだら
「そんくらいのことは普通に・・・」
って悲しくなった。
吉田弘一御大が昔書いたノウハウのテキストとサンプル集のがある意味面白いかもね。
今、知りたいのは
シューティングゲームの美しい設計&リソース管理かな・・・
美しい設計で市販レベルの3Dシューを作るってサンプルなら
結構自分は見てみたいかもしれない。
自分じゃなにもできんのか?
もちろん自分で作ったものがすでにあるが
それでも他人のを参考にしないと向上がないということもわからんのかね
そうはいかんざき
179 :
名前は開発中のものです。:04/06/26 05:53 ID:QrK+O+L1
言わせておけば・・・いいか藻前ら!
そういう話題をこのスレで出し合うのだと思います。
見た事無いものにはややもすれば幻想を抱くものだから
別に責めたりはしないが・・・。マ○○は甘い香りがすると
思い込んでいたあの夏の思い出(教訓)は忘れないでほしい。
クッキー・・・
えーと、気休めかもしれませんが、ソースコードだけなら
洋物ゲームは大股開きで晒してるものがチラホラありますんで
そういうのを覗いてみるものアリかと。
まぁアレだ。妄想オナニーが一番楽しいんだよな。本当に。
本物がみたいみたいみたい。とか言ってる
>>177みたいな奴に限って
実際に本物を見せるとオエーと叫んで反吐ぶちまけるんだよ。
嫌ならAlienbrainを導入して脱衣シューを作ってみりゃいいのさ。(※楽しくないよ)
それで
>>177が幸せならミーハーの真髄。俺は何も言う事は無い。
s/嫌なら/妄想だけじゃ飽き足らないなら/
なんか激しく勘違いしてる人がいるが、まぁわかる人にはわかるか。
>>180 エロオヤジめ。(・∀・)オレモナー
>>183 ミーハーてのは言い得て妙ではあるが、俺も自分自身の工房時代を回顧するとやはり
激しく妄想しながらカリカリ組みながらベーマガを手垢とか色んな汁でベトベトにしてたので
ID:gUL/HHc+ の「本物が見たい」という感覚には理解を示したい。というか懐かしさを覚えた。
>>185 勘違いしてんのはオメーだっつの。タコ
「こんなの漏れにはレヴェル低すぎ!(ファビョーン」 で初心者本相手に
ブーブー文句垂れてどうすんだっつの。まだ離乳食が食い足りねーのかクズ
187 :
152:04/06/26 07:39 ID:iHNiuSnN
>>175 3Dって、スターフォックスみたいなの?
それとも、レイストーム系?
今、2Dで作ってるものが形になったら晒そうか?
内部見せるのは非常にみっともないが。
今、フリーズバグ等あるんで、もう少し掛かるけど。
>>186 初心者本に「マニアックス」ってつけちゃうのはマズいと思うよ
このスレは慈愛に包まれている。
大抵のゲープロ入門本はSHT、ACT、RPG、AVG等手広くカバーしてるのが
ほとんどだから、SHTのことしか解説してなきゃ、そりゃマニアックだ罠
192 :
名前は開発中のものです。:04/06/26 12:06 ID:QrK+O+L1
>188
でも出版社が読者層確保を狙って命名をしたっていう大人の事情かもしれんぞ。
とりあえず読んだヤシが何を期待して読みに行ったかが
このスレの話題にふさわしいのではないかと思われ。
それが出せなきゃ銀の弾を求めに行った厨房ってことでFA?
漏れはプレイヤーの追い詰め方を研究したいなー。
こういう弾で左に追い詰めて右からあるいは前から刺すとかの基礎的なところから
西京ゲーみたいに詰め将棋でプレイヤーを追い詰める方法とか。
あ、でもそうなると弾の撃たせ方と弾の特性を良く知っておく必要が出てくるのか。
SHTのことだけをしっかり説明してたらマニアックを名乗ってもいいさ。
でもあれは、弾の軌道アルゴリズムがほとんど。
タスクやオブジェクト、アニメーション、当たり判定っていうゲームのコアに
なるところはほとんど説明していないからねぇ。
あれじゃ、花火のスクリーンセーバーぐらいが関の山。
>>192 何でも大人の事情で片付けちまうのは負けを認めるようなもんだぞ、っと。
そんなのシューティングに限らない他のゲーム本にまかせりゃ十分だべさ
なんか市販レベルてことばを使ったのがまずかったのか・・・
別に本物が見たいってわけじゃないんで、やっぱかんちがいされてんなー。
そういやレイストームだったか忘れたが
あれは恐ろしくソースが汚いらしいな。
グローバル変数の嵐だとか
全然関係ないが俺が仕事で触ってるソースもそんなだよ。
しかも前々任者が書いたそのコードを前任者がオナニーで中途半端に
クラス化してるもんだからなんだかどうにも意味不明(藁
こんなソース任されてなきゃ休日出勤なんてしねえのに・・orz
198 :
152:04/06/26 15:40 ID:iHNiuSnN
>>196 では、続編は一から組み直しですかね?ありがちですが。
シューティングとは関係ないけど、DX9とMSXML(DOMでいい)の
併用してるケース知らないですか?
今、リソース管理をXMLでやろうとしてて詰まってます。
(一番嫌いなリンクエラー。LIBCMTのライブラリが競合してます。)
DX使わなければ、ビルド出来るんですが、、。
上手くいったら公開してみるので、情報あったら宜しくお願い。
やっぱさ、根本的に、管理者が移り気なのか、プログラマが移り気なのかしらんけど、
もっとできるだけ同じチーム内で長くやって、リファクタリングを続けていく文化を持たない
といかんよ。ソフト作る仕事、全般的に。
200 :
192:04/06/26 15:59 ID:QrK+O+L1
>194
あー、そうかも。
ただ坊主憎けりゃじゃないけど単なる叩きになりそうだったので水差しますた。
>193
その辺は2ちゃんのスレに全部書いてあるよ・・・(´・ω・`)
でも確かにそういうのがまとまった本があると嬉しいね。
漏れにもっと能力があればまとめページ作ってみたい気も駿河。
むりぽ。orz
201 :
198:04/06/26 16:24 ID:iHNiuSnN
>>198は、とりあえず、解決しました。忘れて下さいw
msxmlはマルチスレッド前提なのか?な?
>シューティングゲームの美しい設計&リソース管理
「シューティングの」にどれほどの特異性が残されているのかが疑問だな。
更に「美しさ」とあるから微妙にその疑問に輪がかかる。
STGのようなプリミティブな代物に関しては、汎用的・古典的ないわゆる教科書から
学ぶことでかなりの知識は流用可能だったはずだ。例えば敵・弾の制御には数値解析の初歩本。
(どうせ陽的オイラー法しか使わねんだろ?ヒャハ)。それと計算機科学の初歩本。
(チューリングマシンや有限オートマトンの概念)。メモリ管理ならOS本やDB本でイケるはずだ。
たった3冊、もしかするとGEMSなら1冊で済むかもしれない。無理か。
しかし、素晴らしい時代だとは思わんかね。
ただし、人間同士の仕事の連携には特に配慮していないので、その辺は実際に使う側の要求を
知る必要があるが、どうせ趣味で3人程度でやるんなら適当かましてもノープロブレムだろ。
泥縄でデータコンバータ用意するなり何なりプログラマがシワ寄せ食ったマゾ的方法で好きにしろ
と言いたい。
何もせん内に難しく考えて工数増やす奴は死刑。(いってやったいってやった)
203 :
補足:04/06/26 20:33 ID:yVFa7Kqi
先ほど「マニアックス本」を立ち読みした。既に指摘されてる通り
俺も「ビギナーズ」と改名するのが妥当な内容だとは思うが
まぁSTGって時点で全然売れねートコを狙ってくれてるので
俺は特にギャーギャー言わないよ。
そういえば数年前に「ゲームプログラマになる本」というトンデモ本を
立ち読みして腰を抜かした記憶があるが、アレよりはマシと思われる。
頭は大丈夫でしょうか・・・
酔ってます。寝ます。
それがいい
>>202-203 エロ釣り師
>>204 ところで、ID:gUL/HHc+ よ
『シューティングゲームの美しい設計&リソース管理』
って具体的に何を期待してるのかもちっと説明してくれ。
今ほどリソース管理が徹底していなかった旧世紀時代に作られた
シューティングゲームの方が面白いっていうのも皮肉だよね。
ギャラガや1942なんて今やっても燃えるのは確かだが、
リソース管理は面白さとは関係ないだろ。
>>209 関係ないって言えるかな?
システムや手法が複雑化したことによる弊害はない?
>>208 そもそも、新世紀時代?の今、2DのフツーのSTGは作られてない気がするんだが
>>210 ゲーム制作のシステムや手法が複雑化したことによってゲームがつまらなくなった
ということはないだろう。それは会社それぞれの管理体制に依存するものだろうし。
漏れはゲームのオリジナリティ、差別化を求めた結果面白くなくなったんだ思う。
例えるなら、昔の歌謡曲がポップス、ニューミュージック、ロックと細分化され
様々なジャンルに分かれた結果、数年で皆忘れられて後世に残らないような。
恐竜みたいなもんかね?
一見、多様化してるように見えるけど
環境の変化で全部死滅する、みたいな。
>>214 その理由も理解できる。
会社の管理体制以外には、OSとかもあると思うけど。
なんで弾一個表示するのに何百行もプログラム書かなきゃいけないんだ、
ファミコンならレジスタいじって数行じゃん!とか。
アイディアを形にするまでの労力が大きすぎて気力が薄れたり時間が不足したり。
そのためにライブラリ(フレームワーク)があるのだけれど、
発送の枠組みがライブラリに閉じ込められてしまうから新しさが出にくくなる。
誰が悪いとかじゃなくて、気が付いたらそうなっていたっていたという。
まぁ、オレはゲームプログラマって血へど吐く職業だと体感してるから
苦労は死んででもした方がいいと思うんだけど。それでも作るの好きだし。
>>215 何度でも蘇るさ。STGこそ全人類の夢だからだ。
まじめにやってみそ?
最近のSTGも結構面白いぞ。
好みもあるだろうから一概には言えないけど。
>好みもあるだろうから一概には言えないけど。
そこなんッスよね
むしろ最近のしか面白くないです。
昔のつまんない。
斑鳩、決意、大往生、
そのへん大好き
222 :
219:04/06/27 01:29 ID:kqX2Yt6f
ほう、君は若いな。
まあ俺もそのあたりは面白いと思う。
面白いのはわかるがクリアできる気がしないのは俺だけか?
昔のはクリアできるんですか?
多くは無いけどね。
なぜか昔のしか(1コイン)クリアできない。
227 :
219:04/06/27 02:42 ID:kqX2Yt6f
モチベーションの問題か今のゲームを面白く感じられないかのどちらかかな
>>221 それは昔の継承してるのばっかじゃねーか!!
いいから、式神の城、怒首領蜂2、サイバリア2、カオスフィールドとか遊んでこい。
大昔の場合、クリアという概念すら無かったんだよな。
極めればトイレに行きたくなるまで何時間でも遊べたり。
>>228 クソタイトルばっかですなw
>>229 TATUSJIN2000万やったときは、4面の中盤(しばらく安置がある)で
ギャラリーにショットボタン押しっぱなしにしてもらってトイレに
行ったりしたよ。
ガキんちょに押してもらった時、帰ってきたらなぜか死んでたけどな。
どうやったら死ねるんだあそこで…。
233 :
名前は開発中のものです。:04/06/27 14:43 ID:gtWcNANH
>233
そりゃ単にレバー動かして遊んじゃっただけだろ。
見ず知らずのガキに文句を言うなってばw
>>233 いやむしろ当時のゲーム仲間との笑い話なんだ。
あの状態だとそうそう死なないんだが器用なガキだ、とw
スレ違いスマン
最近のSTGも悪くは無い。しかし個人的には今主流のいわゆる敵弾回避型STGではなく
地形を敵弾から防ぐ壁に利用したり、フォース類を駆使して自機を防衛しつつ
進む敵弾防御型STGがやりたいのだが、こちらはどこのメーカーも作製しないね…
敵弾を動く壁だと思え
>>230 いややっとくべきだ
キャラクター重視の式神の城、
弾から弾に乗っかるアクションゲームなサイバリア2、
弾を何とかしようとしたあまり、狙って撃つ感覚がなくSTGになってないカオスフィールド
どれも今らしいゲームだ
少なくとも、色んなゲームに手を出して、
それぞれのゲームの特色、良い点、改善すべき点、
ゲームが表現したかったであろう面白さを
自分なりの考えでまとめておくのは良いことだとは思う。
>>237 怒 蜂 2 は ど こ へ 行 き ま し た か ?
>>239 その、なんだ
弾幕とはいえ狙って打つ感覚を出している本家とは、
異なるゲーム性の弾幕STGとして、
バズってゲージためてボンバー、バズって以下略な2番目の機体はやっておくべきかな、とかな
く、くるしい
>>235 背景に当たり判定があることを不条理だと感じるらしい…
最近の若い者は
243 :
名前は開発中のものです。:04/06/28 18:07 ID:0C39MrME
>235
それを君が作ればいいのでは?
ここに相談もできるだろうし。
理論でなく形で証明キボンヌ
怒蜂2って本家より面白いところがすごいと思った
ケイブがどうやっても破れない殻を、いともたやすく破ってしまったというか、
苦痛より快感を求めることに徹したゲーム性が成功したというか
まぁ、お陰でいまだに信者からバッシングされてんだけど
怒蜂、怒蜂Uどちら個性があって好きだ
怒蜂、怒蜂Uどちらも個性があって好きだ
えっと…ネタで良いのかな(アセアセ
248 :
名前は開発中のものです。:04/06/28 22:17 ID:gKK0q52w
今からシューティングゲームつくろうと思うけど
ウィンドウモードと全画面モードやるとしたらどっちがいい?
創る側からしてみれば大往生より怒蜂2の方を手本にしたいですな
CAVEシューは今ではちょっとね...
へぇ、そうなんだ。
俺は普通にケイブシューターだから大往生とかケツイとか参考にするよ
まあ好きだからそうなりがちなだけで、結局好みの問題なんだけどね
ケイブシューの是非はともかく怒蜂2がどうのってのはネタじゃないのか…
>>248 デフォルトで両方。
強いて言うなら、縦画面モードの追加(縦シューなら)
253 :
名前は開発中のものです。:04/06/28 22:48 ID:0C39MrME
>252
縦画面モードって90度回転のヤシ?
DirectXなら原点変えて頂点回すだけだから楽だね。
ついでに質問するけど横画面縦シューって大体どれくらいの解像度が遊びやすい?
ゲーセンの縦ってガレッガとか256×320だけど600×400で表示してみると小さいんだよね。
512×384モードだと対応してる機種って少なそうだし。
やぱーり640×400画面で300×400くらいにしたほうが無難?
俺の作ってるSTG、フルスクリーンでQVGAなのに縦シュー、180*240。
小さっ!!
>248
基本はフルスクリーンだと思うけど、
最近のDirectXは初期化時の選択で簡単に切り替えられるから両方。
ウインドウモードがあるとデバッグも楽。
256 :
名前は開発中のものです。:04/06/29 00:17 ID:e5i+uNWk
弾幕はもういいよ
叩かれてるゲームも、制作サイドからみれば色々得られるものはある。
そこがプレイヤー主体のアケ板とは一味違うところか
よ〜しパパ東亜プランリスペクト作っちゃうぞ〜
弾が速いので弾幕にはならんぞ〜
よ〜しパパUPLリスペクt(ry
自機の当たり判定デカイから弾幕にh(ry
横縦比4:3のモニタを90°回転させたゲーム以外は縦シューじゃないね、
それは単に縦長の縦方向スクロールゲーム。
まあヲチツケ
>>258 もっともだな。
悪い点は気づきやすいが、良いところは気づき難い。
良いところに気づく能力は大事だよな。
ゲーム制作だけじゃなく仕事でも…w
最近のSTGは保守的というか既存のシステム流用で
進歩というものが見当たらない。
どれもこれも弾を避ける手段が緊急回避ボムばっか。
もうこのシステム使うの禁止にしる。
むしろ弾禁止でいい
弾をどうこうするのはもういいよ
俺はSTGがやりたいんだ
そこで、てんこもりシューティングですよ
不満があるなら自分で作ればよろしい。
でも作ってて楽しいゲームと遊んでて楽しいゲームって全く別物だよね。
下手すると180度ぐらい違うくらいに…
誰でも今までに無いアイデアの一つや二つあるとは思うんだが、それを形に
するのはすごい労力が必要だったり、たとえそれが実現したとしても、
果たして面白いか、プレーヤに認めてもらえるか、そもそも受け入れられるか
などの問題もあってなかなか実現できないってのもあると思う。
特にコンシューマSTGなんかはプレーヤ層狭いし、どうしても既存の無難な
スタイルにしか落としどころがないと思う。
そんなに労力必要か?
3Dならともかく2DSTGで。
おまえらスレタイ嫁
作る気ないなら消えろくずども
>>273 >>1には、作ったり晒したりするのはオプションみたいな感じに書いてあるけど?
>>272 フリントとか作るとなると、やっぱそれ相応に労力が必要そうだと思う。
いや、漏れがヘタレなだけかもしれんが。
式神の式神攻撃のアイデアはいろいろなゲームから流用したものだろうけど
サブウェポンのバリエーション増やす上で結構参考になる
ZANACxZANACと結構かぶってる。
279 :
名前は開発中のものです。:04/06/30 13:00 ID:DDJ/9HBE
>276
それをこの板で研究したいところだが
「そんなこともできないのか厨」が多いから荒れちゃうかも。orz
フリントってなに?
身も蓋も無い言いかたをすると
触手が生えて、敵を追尾するようになったフォース(R-Typeの)。
XEXEXに出てくる。
フリントがなかなかボスに絡みつかないし
バカな動きばっかするので当時イライラした。
91年当時は群を抜いたグラフィックだったよね、あのゲーム。
ライザンバーのオーバーブーストは実に秀逸なシステムだった。
本体の弱さを見事補ってくれた。
R-TYPEのフォースが作れれば、フリントはその発展で行けそうだね。
・敵の生成は手軽なのですませて、自機のヘンな武器づくりに凝る
・自機はシンプルで、敵の配置に凝る
・とにかく演出に凝る
作る楽しみにもいろいろあるね。
284 :
86:04/06/30 15:19 ID:NTrQHpJR
多間接キャラという言葉に反応するヤツはオヤジ
286 :
名前は開発中のものです。:04/06/30 17:38 ID:DDJ/9HBE
>285
よくやった。感動したっ!
ゴーレムさま〜
多重スクロールに勃起した。
デカキャラにも勃起した。
拡大・縮小にも勃起した。
ラスタースクロールが出てこないね。
限界を超えた驚異のグラフィック
ナスカの地上絵にも勃起
3画面筐体に勃起
お前ら絶倫ですねw
FM6和音とSSG3和音とNoiseとADPCMが付いてるから勃起
8dot単位スクロールで萎える
テキスト面で高速化
シューティング製作技術について語れよ。
取り合えず、ガルーダっぽいのを作ってます。
アレのレイピア(レーザー)ってどうやってるんだろう?
ケイブは全部ちまちまドット打ってるような気がする
>>301 スプライトではないて事?
A。スプライトの頂点を変化させる方法
B。スプライトを沢山射出してる
Aかな?と思うんだが、
もしかして、レーザーと先端の2つに分かれてるのかも、、。
ケイブのゲームは
首領蜂以降どれもほとんど同じに見える。
自キャラ敵キャラ差し替えただけでほとんど同じだな
>>302 普通にレーザー本体と先端をそれぞれスプライトで出してるんじゃない?
ショットにくらべると、当たり判定などの面で比較的難しい点はあるかも知れない。
レーザーの当たり判定なんてタダの矩形だろ
当たり判定というか、当たったあとにレーザーオブジェクト群をどう処理するかの問題だね。
ちゃんとレイピアと同じ動作をするものを一発で作るのは割と難しいみたいだよ?
G-わんげの中の人も、最初は何に当たっても縮まないレーザーから作って
段階を経てちゃんと縮むレーザーにしたみたいだし。
縮むという表現もあまり正しくないが…。
難しく考えすぎ。
発射位置から順々に親子関係を持たせておいて、
当たったところ以下の子をバッサリ殺すだけ。
んで先端に切れ目を隠すオブジェを貼っつける。
レイピア(とか怒蜂レーザーとかも)難しくないよ。
ちょっと面倒なだけ。
凸 凸
I _ I □ I _ I
□ □
□ □
□ □
□ → □ +
□ □
□ □
M~M □ M~M
M~M M~M
根っこと先を蓋で隠す。□は繰り返しパターン。
□1つ1つは、蓋の縦サイズを超えないように分割。
おお、ちゃんとシュー技術してる。いつもこうだといいのにな。いや、そんなに沢山ネタ無いが。
>>302 君はスプライトを勘違いしてるような気がする。
312 :
300:04/07/01 23:58 ID:jteFdR11
何となく脳内解決かも。
(他の問題が山積みで、実装見送り)
>>309 Aのパターンですな。
でも、途中にちょい硬いザコが突っ込むと、レーザーが途切れますね。
なので、Bで実装する予定。
具体的には、まず、見えない判定を飛ばし、ヒット位置確認&ダメージ計算。
で、ヒット位置までレーザー本体を伸ばして表示。(判定はない)
それを毎回実行。特に難しくはない感じですた。
313 :
追伸:04/07/02 00:00 ID:Cfo7uRqr
取り合えず、実装出来たら?晒してみます。
ここってプログラムでなくてもゲーム製作の話ならOKなんだよね?
みなさんボス作る時何を考えて作ってますか?
自分は「単に避けつづけるだけだとつまらんから、ユーザーが能動的に
動作することがあるようにする」を心がけてるんですが。
具体的には、攻撃にメリハリをつけてプレイヤーがスキを見て
接近・大量撃ちこみ・大ダメージを与えることが可能とか。
他のゲームだと、怒首領蜂も似た感じでオーラ撃ちで大ダメージのチャンスがあったり、
実力に応じてパーツ破壊で点を稼げるとか、ダメージを与えられる時間(コア露出とか)
とそうでない時間が切り替わるとか色々ありますよね。
ただ弾を避けてれば誰がやっても同じような結果になるボス戦にはしたくないので、
実力があれば時間・点数などそれなりに有利に展開できる事を目指しているんですが。
315 :
名前は開発中のものです。:04/07/02 02:08 ID:Pd0aQ1VX
ゲームを作るときに、なにかライブラリを使用してますか?
DirectXなら、EL.Hとか。
DirectXというライブラリを使用しています
317 :
名前は開発中のものです。:04/07/02 02:15 ID:Pd0aQ1VX
DirectXを生ではつかってない。
DxLib使ってる。
…宣伝乙
男らしく生で行くよ。
ていうか正直DirectX 9あたりにもなるとラッパー程度のライブラリは使う意味ないと思うぞ。
>>314 動かないほうが避けやすい弾幕は基本的に作らないようにしてる。
あくまでも例外としてならあり。
俺ライブラリを構築しています。
適当にプレイしても時間がかかるが倒せるのが前提。
危険をかえりみずプレイすれば、スコアが伸びるようにする。
ってのを基本としてる
最強の人っすね
324 :
名前は開発中のものです。:04/07/02 13:07 ID:GqcCryli
>>319 ラッパーの意味無いんですか
DirectX9の本買ってみようかな。
色々ヤバイ点もありますが、一枚絵の背景を表示、スクロール、
まで実装。
現状、アルカデに載ってたガルーダ1面MAPを使ってるんだけど、
これってまずいんかな?
>>325 外部に公開しないなら問題ないんじゃない?
公開するならやめとけ。
まずいにきまってるが
大概相手にされないから大丈夫
328 :
名前は開発中のものです。:04/07/02 19:04 ID:GZewqjEA
>325
それって巨大なグラフィック?
技術いらないじゃんって思っちゃうのは漏れだけ?
でもそれ言っちゃうとWAVも一緒か。
漏れの発想がオサーンなのかも・・・orz
>>328 今どき背景をチップの組み合わせで作るほうが珍しいだろ、
特にWin向けとかだとほぼ見掛けないような気がする。
(GBA向けとかならまた話は別だが…)
そうか、最近のゲームはチップで組まないのか・・・。
単なる一枚絵なのか?圧縮したデータを展開しつつ?
今どき背景は宇宙だけ
戦車なんて出てこない
>>328 そです。
何気に最近のやり方って試してない。と。
2Dスクロールもの自体なってないし。
GBAはチップ化を想定したモードあるし。
それだけですが。
でも、テクスチャ切り替え時に一瞬止まったりします。
VRAM転送が重いのかも。容量減らすしかないですが。
どっちかというと、ツール作るのに時間掛かりました
(未完成ですがw敵の配置までやる予定)
スクロールマップなら
短冊状にして並べるのが一番楽かな。
色々な意味でのコスト的にも。
今時チップ並べるなんて必要はないからなー。
昔みたいに細々とメモリ節約するのメンドクサイよw
マップ作成はセンスが無いと辛いからなぁ
シューティングコンストラクションとかの作品で超えられない壁を思い知らされる
そういう意味ではいい時代になった希ガスる
STG用に特化したチップでマップ作れるツールなんてのを…自分で作るのがベストだろうな
マップチップ使わない理由がめんどくさいだと
遊びたくないよな。ああいう初歩的なことしない
ゲームは完成度低そうだし。
1枚絵から自動的にマップデータとタイル画像を生成するプログラム作っとくとよろし。
絵描きさんには、まあn×nグリッドのコピペを基本に好きなように描いてねと言っとく。
マップ作りは楽しいよ
ガレッガなんかプレイしてると、「ここに砲台を配置して...こっちから中型機が...」
とか制作者が色々とひねりながらマップ作ってる様子が浮かぶし
>>338 GBAのツールにそういうのあったな。
でもそうするとGBAは性質上良いけど、PCでやる場合マップチップにする意味あるか?
という疑問が出るんだが。
逆に一枚絵描く方がたいへんだから、マップチップにしてるんだけど
専属絵描きがいりゃどーでもいいことなんだろーな
言葉が足りないか。
>PCでやる場合マップチップにする意味あるか?
ってのは
>1枚絵から自動的にマップデータとタイル画像を生成するプログラム作っとくとよろし。
ここまでする暇があったら一枚絵ベッタリの方が早く完成するんじゃないかって事で。
データは小さくなるに越したことはないし
自動化によって応用が利くようになるから
マップやゲームの仕様変更に対応しやすい。
やるかどうかは状況によるけど
経験からすると、ある程度はやっといたほうがいいよ。
一枚絵べったりだと、ちょっと直したときに整合性確認するのめんどくさい。
そもそも、適当な大きさの画像をタイル状に並べて背景を作る必要はないのだが。
昔はやったけど今はそんなことはしてない。プリレンダでやってれば尚更。
チップ化したところで使いまわすような物は殆ど無い。
1枚絵で直接編集したほうが敵配置とかもダイレクトでやりやすいよ。
ふーむ。
今のマシンスペックに合わせるなら木や岩なんて
オブジェクトとして配置したほうが面白そうだね。
344の言うようにグリッド単位の配置からドット単位の配置になるっていうか。
となるとフォトショかなんかでレイヤー切って配置するのが楽?
>>345 CreatureJungleって知ってるか?
基本的なこと聞くけど一枚絵ベッタリって1ピクセル4バイト
使うと640*480ドットだと640*480*4b=約1.2Mバイト
必要で上に1画面スクロールすると1.2M*2=2.4M必要になるの?
テクスチャバッファ野中ではそうでしょ。
実際はアンチエイリアスかけて拡大して節約するだろうけど。
そこで背景は宇宙だけの出番ですよ
なんかマップチップのほうがいいな…
減色しる!
いや画像の問題じゃなくて色深度の問題か…
あと全画面使うようなシューティングだったらQVGAで良いんじゃ?
VGAじゃ細かすぎない?
そういやCG覗くとがんぶるって
>>345が言ってることまんまやってるっぽいんだよな。
背景は延々同じで要所要所に家とか看板とか風に揺れるドアとかをオブジェクトとして置いてるっぽい。
起動と終了でHDガリガリしながら1分待たせる最凶ゲーム
や1Mで収まるのに10Mの容量のゲームがあったとして
マップチップめんどいからこれでいいやと考えるなら駄目。
一枚絵でもパソコンの負担にならないならOK。
でも同人とかフリーで殆どチップ使いまわしが効かないほど大きく描かれた
背景ってのはあんまお目にかかったこと無いね。
300が言い出した一枚絵のことを具体的に知りたい。
>>346 知らんですが、なんですかそれ?MAPエディタかなにか?
358 :
345:04/07/03 18:48 ID:HdDDH8By
>357
同人のSTGなり。
もっとも漏れは遊んだことないんだけどさ。
背景にベタ絵+オブジェクトで作成されているSTG
このスレきてるくらいだから知ってるかと思っていた
ゲーム自体もかなり有名だし
ん?
マップチップで、マップエディタまで付いて来たのは大昔の奴だけ?
>Creature Jungle
今落としてみたけどマップチップでやってるね
俺も落としてみた。
力いっぱいマップチップでやってるじゃんか。
一枚絵とかありえんでしょ
スクロールしないならいいと思うけど
もしくは一枚絵が無限ループするとかかな
>363
と思うでしょ。
STGで1ステージのデータを圧縮して140M切れねぇよって香具師もこの世にいるんだよ。
HSPerだけどなw
>>365 Creature Jungleのことじゃない?
>>361,
>>362 と話が違うように見えるんで、他の作品のこと言ってるのじゃないかと >背景にベタ絵
BMPも見てみたが
背景奥=一枚絵無限ループ
背景手前=マップチップ
の模様。
つまり
>>359は半分合ってるってことじゃなかろうか。
>>364 ああ、飛翔鮎か。
exeの容量142Mって人生で初めて見たけど、アレって圧縮してたの?
ほとんどがBGMのデータで、ベタのWAVEとかいうオチじゃなくて?
ネタじゃねえの?
371 :
364:04/07/03 23:02 ID:HdDDH8By
>370
あー、そうか。WAVEが大半なのかも。orz
でも作り直ししてるやつはそうでもないとか言ってたぞ。
ゲームはZEXEEDとか言うやつ。
>>370 なんとマジ、ちなみにC65版に公式のパッチを当てた奴、ウチだと起動に1分くらいかかる。
BGMと効果音はsoundディレクトリにバラで入ってるから、残るはグラフィックとかだろう。
再分割する術はないのかね。
みんながブロードバンドなわけやなし142Mダウソさせるのもすごい
>>373 同人ソフトだからなー。
コミケや同人ショップで買うもんだしそこは問題なかろ。
分割完了?
area??.dat(??=01-05,11-15) ファイルサイズ8.06M〜15.3M、合計101.5M
bg??.bmp(?? = 01-05) ファイルサイズ2.63M〜7.91M、合計18.4M
chr??.bmp(?? = 01-07) ファイルサイズ3.00M〜4.68M、合計22.6M
demoplay.dat ファイルサイズ78.1K
start.ax ファイルサイズ34.4K
合計142.8M
ちなみに*.bmpは素では読めない。
area??.datはダンプリスト見た感じ無圧縮っぽい。
まあ、ゲーム中のレスポンスが悪くなければHSPでもVBでもいいが。
にしても、昔のFDのソフトかっつーの>起動1分
ZEXEEDって、サイトで公開とかしてるの?
ぐぐってもわからんかった・・・。
HSPでEXEにいろいろ詰め込んでるのね。
んで、ZEXEED?飛翔鮎?
どっちの話?
飛翔鮎はウチだと起動に10秒かからんが…
>>376 飛翔鮎の方。
しかしあのゲーム内容で1面のデータが8M、どういう実装してるのか凄く気になるが。
さすがにそこまでいくと逆コンパイルでもしないと……
ZEXEEDってプレステのロボットのゲームか?
試しに飛翔鮎起動したら、4秒でタイトル画面出たが。
背景をストリーム再生するなんてアレゲなことを試したやつはいるかな。
メガドラCDのシルフィード?>ストリーム再生
>>380 うちも時間は測ってないが測る必要もなくすぐでるよ
>381
背景をムービーにすれば、割と簡単に出来るかもしれない。
セガのアストロンベルトみたい概念かね
>>382 PSYGNOSISのマイクロコズムっしょ
>>363 昔、ベクターで拾ってきたVB製のシューティングが…マップがBMPだったんでビュアで
見たら…30画面分くらいの一枚絵だった…ガタガタブルブル。
>>386 懐かしいな、スカベンジャー4とか。
スペックが固定化されているコンシューマーとかTOWNSならOKだが、擬似とはいえ
マルチタスクで性能バラバラなPCだと同期ズレの問題が出てくるのではないかな。
Wave垂れ流し、一枚Bmp垂れ流し
どんどん低レベル化が進んでいくな…
WAVE垂れ流しは別に構わんだろ
スプライト専用ハードウェア 最高!
カラーキーで抜く?マスクパターンを作成する?いつの時代の話だよ。
・・・って思ってたのに、結局、DirectX(draw)は
昔やってたことに戻ってんだよなぁ。
出てくる物がしっかりしてれば技術的なレベルは
どうでも良いけど
良い意味での手抜き、手抜きで余った力を他に回せれば良いが。
大体の場合手抜きが更なる手抜きを呼び、その手抜きもまた次の(略)ってのを懸念してんじゃねえの?
裾野が広いのが良いのか、裾野は狭くても平均レベルが高いのが良いのか。
手抜きというと語弊があるかな。
そもそもやる必要のないことをやらないのは手抜きじゃないし。
で、必要かどうかって判断基準が人によってまちまちなんだろ。
wav垂れ流しが低レベルってのは流石に時代錯誤だと思うが。
でもやっぱX68soundを使ってる超連射とかをやったほうが
waveよりすげーなと。
まぁさすがにこれは時代錯誤だとしても
HDD消費のことも考えてとりあえずogg使ってほしいねぇ
同じ音がでれば凄いも何もないと思うがな。
あとHDD節約なんてケチくさいこというな!w
しかし実際そういうとこを手抜きしてるのに限ってつまらんのが多い
その逆も多いけどな
じゃぁ相関性は無しってことで。
逆なんてあるか?なんかあげてみろよ。
独自音源、ogg使ったシューでおもんないの
>>399 この逆ってのはそーいう所で手を抜いていても面白い奴は一杯って意味だったりして。
違うかもしれんけどね。
あぁ、そういう意味ではたしかにそうだな
へんなとこに拘らずに内容に拘ってるやつはやはり同じようにできが良いんだよな
どうでもいいようなとこに拘りすぎると
いつまでたっても完成できないのが問題なんだよ。
無圧縮bmp使うなんて無神経なこと俺にはできねーよ!ってやつは
作るものもそれなりのものである・・と考えたい。
敵の動きとか配置を考えるのが難しくて面倒だ…。
これじゃ物足りない…、もっと早くするか…、
これだと全て倒しきれないな…、もっと動きを複雑にするか…
配置が美しくないな…、何度も作り直して延々と時間食う。
ドラクエとか、マザーとか
?
bmpってボトムアップで格納されてるから
上にスクロールする縦STGとは相性がいいのかもしれんな
>>407 君、ゲーム作ったことないだろ。(^o^
このスレに居て楽しい?
クラスで最も嫌われるタイプ
>>405 さすがにマザーは一枚BMPは無理だね。
ファミコン画質で東京ドームぐらいの広さがあるんだっけ?
ここに馬鹿すぎてこっちが恥ずかしくなる奴が居るんだが
(407とか)何が目的なんだろ?
そんな反応することかよ
XxYマスの縦STGのマップを考えてみる。
ドット絵エディタでXxYドットの8bitBMPを作成する。
パレット番号とマップチップ(敵配置マップなら敵番号)を対応させれば
マップエディタを作成せずとも視覚的にマップを作れるかもしれない。
描くときは下から上へ、読み込むときは先頭から読めば良い。
だからなんだの域を出ないような気もするが。
あ、もちろんBMPのヘッダは読み飛ばして。
バイナリエディタ直書きに比べればきっとマシだと……思う、自信なし、所詮思いつきだし。
むっちゃ反応する人がいるなぁ
mIaBS7Ac乙
スクロールは上下左右労力同じ(移動加算値変えるだけ)で
BMPと相性がいいスクロール方向なんて無い。
というか絶対にありえない。
>>414-415 BASIC時代にマップチップを1チップ1画素で表示したのを思い出して懐かしくなった。
遊びとしてはそういうのもアリだと思うよ。
>>414 マップエディタを作るのが面倒くさい場合は有りかもしれんが
パレットとチップの対応を人力管理しなくちゃならないので
却ってそっちのが面倒くさいだろうな
大抵のドット絵エディタは256色ずつでしか管理できないので
それ以上のチップを扱うときにややこしくなるのも難点か
ボトムアップだと上下逆?そこまで難しく考えなくても良いよ。
視覚的にはBMPの絵柄と描画を同じにした方が分かりやすい。
以前からゲーム製作未経験者のような発言でもスルー
されたけど微妙に気持ち悪かったから407のような
発言に突っ込みいれたくなる気持ちも分かる。
それでもスルーしたほうが良いかもしれないけど。
その程度の細かいこと気にするんだったら、
もっと他にすべきことがあるだろう…
レイピア、スローモード、
スロー時の、撃った弾がアイテムになる処理等を入れました。
スローにすると、敵の動き(到達地点)が変化してしまうので、修正しないと、、。
後は、宝石の数、倍速モード、ボス等を入れる予定。
因みに、背景は16bitでやってます。良いツールを使えば8bitでも遜色ないでしょうが、
実験してないです。
>>423 レス番号を書いてくれ。前半4行が唐突すぎて分からん。
独り言のエクスキューズとして後半2行を加えたように見えるぞ。
流れが読めないなら、無駄なレスはやめとこうぜ。
スクロール方向なんぞ足すか引くかの違い。
上下反転? テクスチャの貼る方向を逆にすりゃええ。
DirectX8じゃない? ヽ(・∀・)ノウンコー
シューティング製作以前の問題だな
>>388 踏み絵を踏みに行くような気分だが
背景レイヤーのうちの1(遠景)を
丸々一枚絵方式でやったことはあるぞ。
システムメモリ上に圧縮データ1ステージ分。(約2MB)
ステージ進行中に圧縮データをデコードしつつ
(差分)転送。フレーム単位の転送量は1[KB]程度。
問題なく60[fps]出ていた。
そんときのメモリ上の圧縮データは
展開してもせいぜい7MB程度(256*7200*32[bpp])だったので
むしろそっちでやったほうが良かったという罠があったが。
背景レイヤーのうちの“1枚”ね。スマソ
>>428 データ圧縮&1INT内での展開ならOkじゃない?
うん。たしかに一枚絵の場合でもシステム→ビデオメモリの転送にかかるコストは
どうってことないんだよな。俺はテクスチャ上のパターンデータ(8x8テクセル)を
フレーム毎に数個づつ書き換えたりするんだけれど、そんときのデータサイズも
似たようなものだし。
結局、一枚絵の弱点はパッケージサイズの肥大化ぐらいかね。
ネットで配布するようなケースでもなければ無問題だと思うよ。
#つーか、漫画板のアゴ無しスレに誤爆した・・・鬱
一枚絵だとステージとステージの間でファイルから画像読みに行くときに
固まりそうでイヤーンな気がする。演出とか入れてごまかせばいいのかも
しれんけど、シームレスに次のステージに行きたいときは無理。
うまくやれば別スレッドで画像を読みつつスムーズにステージ切り替え
できるかもしれんけど俺はあんましやりたくないな・・
うい。お察しの通りシームレスは無理だたよ・・・。
得点算出画面を描画しながら裏でガリガリとロード。
>たしかに一枚絵の場合でもシステム→ビデオメモリの転送にかかるコストは
>どうってことないんだよな。
そうか?
かなり前にDirectDrawでシステムメモリのオフスクリーンサーフェイスから
Bltさせた時、タイル化してBltを繰り返した時と1枚絵を1発Bltした時で結構
差が出た記憶が…
オーバーヘッドを少なくする為1枚絵のBltで実装しようとしてる俺は
負け組みですかそうですか
差分だけだからたいしたことないだろ
たとえば1ピクセルのスクロールごとに処理なら1ライン分の転送だけですむわけだし
436 :
423 :04/07/06 19:03 ID:nZv9mdH7
>>426 では、そうします。
質問や相談もやりつつ、結果を報告出来ると思ったんですが。
1枚絵の背景も、CAVE系を再現したい。てので出た話題なのだし。
自分の場合は、1画面を1BMPで保持して、3画面分同時に描画。
で、1画面スクロールするごとに、一番下の画面を上に移動&テクスチャ再セットしてます。
俺は興味あるからここに報告あると嬉しいけど。
俺も。1週間に一度くらいなら気にならないし。
>>434 俺もDirectDrawでハイカラー以上でやるときは
システムメモリ上でソフトウェアレンダラーで全て
描き込んでからビデオメモリに一括Blt()するよ。
Direct3Dでやるときは
ビデオメモリ上でハードウェアレンダラーで全て
描き込んだほうが圧倒的にお得だから、組み方が
変わる。
>>434 程度(サイズ)にもよるが、
Direct3Dで背景をマップチップでやるときは
固定サイズの頂点メッシュを使ってスプライト機のBGテーブル的な
組み方が出来るんだよ。差分書き換えするのはマップチップの
インデックスではなく頂点のテクスチャUV値になるけどね。
背景の描画はDrawPrimitive2回で済む。
441 :
115:04/07/06 21:31 ID:7pzWGvje
>>423 >1枚絵の背景も、CAVE系を再現したい。てので出た話題なのだし。
はあ?
442 :
33:04/07/06 21:42 ID:69bgIzfJ
>>441 お前は一体何しにこのスレにいるのかと小一時間(ry
444 :
436:04/07/07 00:34 ID:pE7mkQZW
ではでは、たまーに、何か大きく進展したら報告するという事で。
>>440 最初はメッシュ&UV設定ツールでも作ろうかと思ってました。
しかし、だったら3Dツールでいいんじゃないかと思ったりして断念。
今のやり方は、
>>117を参考に組んでみましたが、半画面で1チップにした方が
効率が良いので、改良してみます。
当面の目的は、ツールに敵配置機能を追加する事ですが、ガルーダ等みてると、
配置と動きが連動していて、(戦車、中型機等)
現在の、敵の動きをハードコーディング部分から
見直す必要があるという問題で煮詰まり中です。
445 :
436:04/07/07 00:34 ID:pE7mkQZW
ではでは、たまーに、何か大きく進展したら報告するという事で。
>>440 最初はメッシュ&UV設定ツールでも作ろうかと思ってました。
しかし、だったら3Dツールでいいんじゃないかと思ったりして断念。
今のやり方は、
>>117を参考に組んでみましたが、半画面で1チップにした方が
効率が良いので、改良してみます。
当面の目的は、ツールに敵配置機能を追加する事ですが、ガルーダ等みてると、
配置と動きが連動していて、(戦車、中型機等)
現在の、敵の動きをハードコーディング部分から
見直す必要があるという問題で煮詰まり中です。
446 :
436:04/07/07 00:38 ID:pE7mkQZW
二重投稿すんません
ついでに
X 敵の動きをハードコーディング部分から
○ 敵の動きをハードコーディングしてる部分から、
道なりに動く戦車のコーディング、ゼビウスとかはどうやってたんだろ?
(1) 地形と全く相互作用せず、進行方向への加減速と移動方向相対変化で記述
(2) 初期ウェイトと移動方向のみ指定、あとは道に埋め込まれているオブジェクトに反応
脱線するが、怒首領蜂大往生の戦車はカーブをなめらかに曲がっているように見える。
実際は少し移動して方向転換、の繰り返しだとは思うけど。
ゼビウスか…。
あれバカでかいマップがあって、それを面によってX座標ずらして表示してるんだよな。
ドモグラムの盆踊りや伸縮移動を見るに、画面上の座標と関係なくマップ上の座標で
動かしてるんだろうが、細かいことは判らない。
たしかゼビウスは3つCPU使っててキャラクタデータ管理とかは分けられていた筈…。
基本的には移動パターンをいくつか作っておいて、カウンタの初期値を変えてるだけじゃない?
でも、ゼビウスって今以上にボーナスポイントの設定とか細かいことにこだわって作られてるんだよなぁ。
ブラスターを避けるグロブダは今でも感動する。
フリーや同人だとそこまで動きにこだわった作品は
少ないな…
超連射での加減速をうまく使った見栄えのする敵機動には見習うところがあるかも。
アケシューならザコヘリの 等速運動→減速→ホバリング→加速+旋回でUターン といった動きを
ちょっと真似してみるだけでも学べる。
まぁ最初からそこまでやる必要はないけど。
慣れてきたら等速運動や状態遷移なしの動作から先に進んでみると
敵にイイ動きをさせることができるよ、ってことで。
良い動きする敵がいると、それだけで気持ちが良いね
ゼビウスのザコの動きは制作初心者はよく研究してみるといいかも
ゾシーやタルケン等々
テラジなんかはいまだに動きの代名詞となってたり。
最近のザコは寿命が短いせいか、集団で突っ込んでくるのばかりでチトさみしい
テラジる……(ボソッ
>>447 昔そういうの作ったよ。
だけど戦車がわらわらと出てきて壊せるだけ。自機は弾に当たっても何もなし。
しかもボスがなければ、タイトルもエンディングもない。道中でスクロールが止まって終了。
ゲームとしての形になってません。こんなのでよかったらアップしますけど、やってみますか?
プレイするより技術的な話したほうが良いんじゃないの
ギャラクシアン・ギャラガ・ギャプラスの敵の動きのアルゴリズムが
よくわからんです。自機の方によりつつもループ描いたりとか。
3つ並べて書いてるがそれぞれ大分違うぞ。
ギャラガの動きに感動したガイジンは結構多いらしい
ソースをアップするのなら、技術的な話に繋げられると思うけどな。
>>459 あの滑らかな動きはテーブルでもってるのかね〜?
>>462 当時、(参照)テーブルを一切用いずに済むような
(現実的な)実装方法があったのかを考察してみ。
いきなり敵が空中回転した時は心が躍った。
今では反省している。
テーブルでいいよ
ちゃぶ台でもいいよ。
>>463 アルゴリズム的に、自機と自座標から、加速量をパラメタとして変えてくとか。
道に沿って地上物が移動する、ての簡単にやる方法模索中。
エディタ自作せんと難しいかな。
ツクールとかのデータ流用できないものか。
>>468 例えば、そのパラメータとして渡す加速度は
行動パターン毎に1セット(圧縮データ)に
なっているとする。
すると行動パターン番号から参照するための
テーブルが必要になる。
471 :
470:04/07/09 10:14 ID:l91s44YH
よく読んだら、プレイヤー座標と自座標を入力すると
加速度を出力するような関数(orロジック)を用意する
って話か。
参照テーブルを一切使わないってことは
敵キャラ1種につき関数1個といった粒度を想定しているのかな。
容量の肥大化はまず避けられないだろうが非現実的ではないな。
俺なら、ロジックの粒度を小さくして呼び出しのシーケンスを
テーブル化するような形に持って行くけどね。
>>469 透明オブジェクトとして線データをマップの上に置いといて、
それに沿って移動するような形はどうだ?
…この方法だとゼビウスみたいに分岐があった場合の処理がめんどうだな。
>>472 ああーなるほど。
透明オブジェクトに触れたら方向転換、でもいいかもね…。
やってみよ。
>>471 うん。たしかにテーブルの類を一切使わないという条件があると辛いですね。
敵キャラ加速度データのグラフは直線(矩形やノコギリや三角)を組み合わせた
不連続関数だったりするので、アルゴリズムでやるといっても中で条件分岐が
入りますね。連続関数に分解してテーブル化ってのは至極まっとうな選択だと思います。
加速度の制御だと円弧を表現しにくいので、動きパターンに応じた条件分岐も
出てくるでしょう。ここでもハードコーディングを避けるならテーブル使いますね。
>>472 マップチップでやるならラクができるよ。
自分のいるマップチップ番号を見て、三叉路や
交差点のマップチップ{┤,├, ┴, ┬, >- , -< , Y ,人,┼,×}
ならば経路決定用の関数を呼び出す。
始点
|__
___ /
\./
│
──┼
|
──┴─終点
上図の戦車の分岐シーケンスは
{右折、左折、直進、左折}
この2bitデータの配列を各戦車に
持たせるだけで済む。
パックマンと一緒か
>>476 あーそっか。マップが格子状に区切られてるから、自分のいる地形の
属性情報をBGテーブル経由で参照できたんだね。たしかに
マップチップだと色々と簡略化できるね。
道路上の戦車の移動は逐次処理だけで済むってのは納得。
けっこう複雑だと思ってたんだけど、ちょっと考えすぎだった。
>>475 円弧や正弦曲線は、ゲームデータ用に
エクスポートする際には近似曲線に
変換するといいよ。特例扱いしなくて済む。
>>476 それだと戦車に与えるパターンが少なくなる代わりに、戦車が存在しうる背景パターンは
10倍の数になるのでわ?
背景がベタな砂漠とかコンクリだけならなんとかなりそうだけど、自然な背景にしたいなら
マップエディットで力つきそうな気がする。
戦車が参照するマップと、表示用のマップが同じである
必要は無い。
マップ編集はちょっと面倒かも知れんけど。
>>480 話の発端はゼビウスとかマップエディタ流用の話なので
そういう無茶な突っ込みしないように。
・マップチップ毎にアトリビュートを付加できない
・マップチップをマルチテクスチャ化できない
・マップを多層化(複数レイヤー化)できない
低機能マップエディタを使ってリアルな背景を
追求したいなら、相応の工夫をしましょう。
確かにそうだけど、実際やってるところあるのかな?
ちなみに漏れはオブジェクト出現テーブルに移動パターンとカウンタオフセットを与える方法で
やってたけど。
戦車ってそれほどハードにくねらないから30フレくらいの頻度でパターン構成してもそれなりにみえる
でも結局、停止->前進->停止の奴が一番多かったんだけど(w
おっと被った
483は481へのレスです
>>482 道路パターンを地面に馴染ませるときは道路パターンを
アルファ付きテクスチャにして地面パターンにかぶせると
楽チンでいいな。
自然な描写を目指してくとマップエディタ自作にしたほうが
楽だと痛感した。
敵配置ツールは手付かずです。
その他のガルーダ仕様や基本的な処理(スコア、パワーアップ、アイテム効果等)は
一通り出来たので、後はボムの実装ぐらいです。
低レベル層の描画周りを見直してたら、致命的なミスを発見、
修正したら処理落ちが全くなくなりました。
(出現キャラ数は調べてませんが、アーケード版の後半ぐらいは出してる)
後はバランス調整、敵配置、ボス実装、最後に絵を直せば公開出来るんですが。
ボスの考案、絵を描くのが一番しんどい。
フィルタ掛けるとかじゃ不味いんですかね。細かい修正は色々してますが。
道路の上を進む戦車って移動はなんとなく分かったんだけど、
建物の中から出てくるときの敵の当たり判定はどうやるんだろう?
まだ建物の中にある部分は弾が当たっちゃいけないんだし・・・。
やっぱりチップで判定するのかな?
>>482 そうね。
絵的なクオリティを上げていくなら3Dカードの機能を活用しない手はないでしょ。
あとマップエディタ。最近は出来のいい汎用エディタがあるのかもしれんけど
俺が作ってたときはマップに深度値を付加したりマップを複数枚重ねられるような
エディタが見つからなかった。この手の機能が無いとマップ編集作業をやってく
うちに不満が炸裂する。
>>485 俺は、森林地帯を戦車が通り抜けるシーンを作るためだけにエディタ
自作しちまった香具師なので、むしろアフォの部類かもしれんけど
独自の拡張がどんどん出来るので、自作したほうが結果的に楽ってのは同感。
>>487 チップで判定してもいいし。チップのZ値で判定してもいいし。
戦車が何かの下にいれば弾に当たらなければいいということで。
マップチップの話だけど、
元のマップの画像は、巨大な一枚絵で描いて、
それを16×16とか適当な単位で分割して、チップをあとから作ればいいんじゃない?
HSPスレからきますた。
・・・最も速いと思われる当り判定のアルゴリズムを
伝授して欲しいんですが・・・。
CPU500MhzのPCで動かせることを考えると
どうしても処理速度と格闘せにゃならんので・・・。
飛翔鮎が500MhzのPCで軽快に動いてるのが
不思議でたまらないんですが・・・。
>>492 条件次第で変わるから、もう少し限定した条件を出してもらえると答えやすいかも。
判定する物体の形状とか、数とか。
あと、ハードウェア的な制約もあれば。メモリ量も重要だね。
MSXならスプライト同士の接触で割り込みが、とか。
494 :
492:04/07/10 00:50 ID:0VpPjZgq
すまそ、質問しといて説明不足だったんで補足
敵弾vs自機の判定は
HSPスレのほうで解決してきたんスけども、
自弾vs敵の判定で凄まじく重くなってしまって。
現在実装中の当り判定は
自弾の数だけループ(1)
自弾の移動
敵の数だけループ(2)
自弾vs敵の当り判定
ループ(2)終
ループ(1)終
ってなってます。
当り判定の基礎はコレで良いと思うんですが、
うちではコレをやると処理落ちしてしまうんスよ。
(程度の低いSTGしか出来ていないのに・・・・)
本当に当り判定の問題?
敵一個の場合とn個の場合の速度比べてみ
500MHzもあるならインタプリタでもその程度かなり余裕だろう
それ以外のところがおかしいと思われ
497 :
492:04/07/10 01:05 ID:0VpPjZgq
>>495-496 うむぅ、一番処理食ってるのが
自弾vs敵のループと
敵弾vs自機の判定
だと思うんだけど、
やっぱ別のところで無駄してるんですかねぇ?
敵1コとnコの場合、明日辺り試して見ますわぁ
まぁ、良くある方法としては、
敵や弾の移動時に、y座標単位のテーブルに登録しておいて、
自機と一定以上近い座標にあるものに対してのみ当たり判定を行うとか。
それ以前に、その重さは考えにくいから、
やっぱ当たり判定自体かループがおかしい気はするが。
499 :
492:04/07/10 01:29 ID:0VpPjZgq
>>499 この程度で遅くなるかなあ…。
描画じゃないの?回転とか使ってるし。
ビデオカードによってはそれだけで結構遅くなるよ。
501 :
ガルーダ:04/07/10 06:53 ID:pcMLfY2g
>>499 コードよくわからんけど、
貫通弾じゃない限り、ヒットしたら敵のループから抜ける
というのがなさげだけど?
あったほうがいいと思う。俺も全然やってないけど。
それ以前に、タスクのリスト総舐めしてる。
>>501 それは後のチューンナップの話しだね
初めは処理が最大の場合でも余裕があるくらいにしておかないと先が厳しい
俺の場合、まず全ての敵オブジェクトに対してBounding Circleによる簡易判定を行って、
ヒットしたもののみ引き続き厳密な判定をするようにしてる。
といっても、当たり判定ごときでそうは重くならないはず。
空間を格子状に割って格子内の物同士で判定を取る、とか低クロックのハードで
ゲームを作った際にやりました。
効果はかなりの物でしたが、500Mhzもあればそんな処理いれなくても楽勝かと。
それなりの処理、ってのは重くないはですか?
505 :
492:04/07/10 18:29 ID:0VpPjZgq
それなりの処理と書いたものの内容は
当たった瞬間だけの処理だから
重いのに影響はないと思うけど、
弾フラグ消し、
敵耐久減らし、
等の処理をします。
>>500が言ったように描画かもしれない・・・
633MhzのPCでは少し無理させても平気だった。
一番気になるのが、
俺の糞ゲーが500Mhzでガタガタになるのに、
飛翔鮎で軽快に動く、というのが・・・。
とりあえず重くなりそうな回転とか拡大縮小(使ってないかもしれないが)を減らしてみるとか
回転使うより回転パターンの絵を用意しておいて角度に対応した絵を表示した方がいいんじゃないか
そもそも描画にDirect3Dを使っていないとか。
HSPの限界じゃないのか?
その飛翔鮎とかいうのは、あたり判定ループの部分だけCで書いてるとか
HSPはそんなことがホイホイできるものなのかはよくしらんけど
efx_rotateってことはhspdxa使ってるんだよね?
ちょうど今マニュアル見てて気付いたんだけど
>>互換命令でのキャラクタ表示には、ビデオカードの2D機能を、efx命令でのefxパターン表示には3D機能を利用しています。
>>ビデオカードハードウェアがそれらをサポートしていない場合、劇的に描画速度が遅くなる事があります。
ってあるからビデオカードが原因かもしれないな
とりあえず当たり判定ルーチンをいったん外してから試したら?
それともそれまで平気だったのが、当たり判定を組み込んだら一気に処理落ちしたってことかな?
そうね。
まず何処で遅くなってるのかしっかり特定しる!
グラフィックス性能低いノートPCで
回転拡縮を使ってるとか。
513 :
492:04/07/10 20:01 ID:0VpPjZgq
なんかefx命令が原因の可能性が濃厚に思えてきた・・・。
当り判定を外す、外さないとかじゃなくて、
当り判定に使うパワーが大きいからっていう理由だけなんですわ
どこで遅くなってるかと言えば当り判定以外考えられず・・・。
とりあえず、当り判定の中に重い処理を書き過ぎた
可能性が高いので、その辺改良してからそれでも
ダメだったらまたヘルプしまつ
ご迷惑おかけしてます(='ω`)トホー
重いかどうかはあたり判定部分ごっそりコメント化してみればいいだけじゃないの?
ちゃんと問題の切り分けしたほうがいいぞ
とりあずいろいろ外してって原因を特定させるほうが先だと思うんだが…。
ぐぉ、かぶったw
まあそんなことも思いつかない奴だから
「やっぱHSPerだよな」と言われてしまうわけだ。
で、結果はどうたったんだろ…。
ほんとに原因究明しないまま改良とやらを始めてしまったのだろうか。
好きなように
やれば
いいんだよ
夏休みなんだし
みつお
もう夏休みなのか。
制服女子高生が見られない・・・
会社行くとき電車が空いてて嬉しい
だめだこいつ。
思い込みはハマりの第一歩だってのにな。
まだやん
526 :
492:04/07/11 17:08 ID:sdoT5MYW
外したの?
一度も外したと書いてなかったが、外したのか。で、外しても重たいままだったの?
描画する画面サイズがでかいだけだったとかいうオチだったりすて。
とりあえずゲームシステム的な観点で条件を書いてくれ526よ
1ループの同期時間 or v-sync
画面サイズ
ウィンドウ or フルスクリーン
転送元画像カラーbit数 and 転送先画像カラーbit数
などなど。
でもさーこれで「描画ルーチン外したら早くなった」とかだったらかなり顰蹙ものだなw
530 :
526:04/07/11 22:31 ID:sdoT5MYW
1フレーム 16ms
V-syncは待っても待たなくても特に変わらず
フルスクリーン640*480 16Bitカラー
と、とりあえず言われた通り晒したけど、
描画で遅くなってる可能性が濃厚、と感づいたレス入れたはず・・・
それを試行錯誤してるトコですわ
>>528 HSPer(?)じゃない人にはわからないと思うけど、
描画もさることながら2重ループとか
入れると重くなることなんてしょっちゅうある
2重ループの中に一部の描画命令入れてるんで
当り判定ルーチンを外す=一部描画ルーチンを外す
で、必然的に軽くなるってワケ
(この部分が悪いと指摘してくれる方が居たら
是非、と)
531 :
6:04/07/11 22:53 ID:8pataM2S
1フレーム 16msて
60FPS超えてるよね?十分なのでは・・・
なんか俺勘違いしてる?
16FPSの間違いなら携帯アプリ並だけど。
532 :
526:04/07/11 22:59 ID:sdoT5MYW
16msそのままで計算すると62.5FPSになるんだけど、
HSPの性質なのかハードウェアの性質なのか
その辺はよくわからないけど、ちょうど59.xxFPSになるのが16msなんス。
PCによっては14msでやっと60FPSに近くなるものもあるらしい
533 :
531:04/07/11 23:07 ID:8pataM2S
そっかそっか〜・・・って
59ってかなり高速と思うが
その状態でガタガタに見えるの!?
安定してないとか??
HSPの話題ですまんが、HSPDXAはウェイトだとFPS安定しないのでチューイせよ。
ん?
タイマウエイト掛けてさらに垂直同期待ってるってこと?
536 :
531:04/07/11 23:39 ID:8pataM2S
HSPDXAてなんだろとおもてちと調べてたんだけど
HSPって結構すごいことが
できちゃうんですねとかおもいますた(´Д`;)ハァハァ
ログみてたらとんでもなく空気読めてないレスだと分かりました。
ほんとゴメンナサイ。
539 :
526:04/07/12 00:07 ID:BZTWJ1i5
>>533 ウェイト16とって、それを越えたら
当然FPS40とかになるよん
そうすると、とうとうガタガタになって、
スレのみんなに質問しちゃうってことです。
うちのPCの場合は同期とっても取らなくてもあまり変わりなかった
から気づかんかったけど、みんなの話だと同期なしだと安定しないっぽいね
今のうちからコンフィグで同期の設定できるように
しておいた方がよさそうかな?
>>535 同期待ちだけだとリフレシュレート60以上のPCで困ることになるから、
16msの最低ウェイトを取る方法を採用してまつ。
何度も言うようにうちだと同期待っても待たなくても
一緒だから、テストのしようがない・・・
(最近は友人何人かに頼んでやってもらってるけど)
というかFPSとかの論争がある模様?
ほとんどのPCで同じFPSを出すのってやっぱり難しい?
いや、あんたの方法がダメダメすぎるだけ・・・
FPSをどのパソコンでも安定させる方法については
非常にすばらしい方法がありもう議論され尽くされてるから書かないが
>>539 いいじゃん、んなもんユーザに選ばせりゃ。
レスをみての推測だけど毎フレーム同じ時間だけウェイトを入れてない?
描画や当たり判定などの処理をしてあまった時間分だけウェイト入れないといけないんだけど
544 :
531:04/07/12 01:08 ID:qRwhS0h2
俺はまた実測アベレージで59FPSかとおもたよ・・
多分、HSP(HSPDXA?)には更新時間を指定する命令があるんだろう。
一般的なシューティングでCPUやらカードやらで負担かかるっつったら
衝突判定と描画くらいなもんだし。
オブジェクト指向だと生成ってのもあるだろうけど。
で、衝突判定でないと言い張るからには
HSPの仕様上、CPUに負荷のかかる画像形式とか
不要な画像処理してますとかそんなとこかね。
もしくは弾幕が異常に多い→1000発超えてますなんつてな。ヨケラレ(゚Д゚)マセン
545 :
526:04/07/12 01:11 ID:BZTWJ1i5
>>542 設定したウェイトから
処理にかかる時間を引いてるので毎回同じ
ウェイトになる(はず)
>>540 本当に論争になっていたみたいだなw
546 :
526:04/07/12 01:16 ID:BZTWJ1i5
連レスすまんネ
弾幕にするつもりはないんで
150〜200発程度でやってま。
とりあえず不要かどうかはおいといて
描画で遅くなってる可能性が90%くらいになってきた。
同じ500MhzのPC2台に協力してもらったところ、
一台ではガタガタ、もう一台では軽快に動作した
とのことで、ビデオカードのせい、
つまり、変なエフェクトかけ杉のせいっぽい。
だいたい分かってきた
なんでいまだに原因が推測なんだ?。
描画部分外して試せって言ってるのにやってないの?
ES_SET等の描画命令をコメント化すればすぐ出来るだろ?
何やってんのかぜんぜん判らんぞ。
>546
なんかドツボにハマってるような気がする。
もともと飛翔鮎が動くのに自プログラムだと・・・って話からの流れなのに、
他のPCで動いたから、んじゃービデオカードのせいだ・・・って事では、全然
問題が解決してないでは(汗
549 :
526:04/07/12 03:00 ID:BZTWJ1i5
>>548 痛いトコつかれた気がするけど思い当たる節はある
飛翔鮎ではあまりエフェクト使ってないから動くんだと思う
こっちのは回転・加算合成など使ってるから
せめて回転だけはどうにかするつもり
ビデオカードのせいというのは確定だと思ってる。
(じゃあもうこのスレ来んなと言われそうだがw)
来るなとは言わないが、質問しておいて指摘された問題点の検証を
しないならここに来る意味は無いだろう。
余裕でスルーですか(;´Д`)
人の話を聞く気が無いなら質問しないでくれ。
552 :
ガルーダ:04/07/12 05:28 ID:Z/Q7ygeU
>>544 現バージョンのガルーダ、計測してみたら最大1426キャラ出ててた;
ほぼ60FPSだけど、ハイエンドなビデオカード使ってるから参考にはならんけどね。
この前SSのシルバーガンで当たり判定表示オプションつけてみたら、
物凄い数の長方形がぐるんぐるん回っててすげぇワロタ。
ソードなら3つの正方形、アカマルやミカエルは20個ぐらいの正方形がぐるぐる
動いてて、レーザーも正方形並べただけw
幾何学的に正しい当たり判定処理をうんうん唸って考えてた俺を思い出して
さらにワロタ。
単純な判定を組み合わせるというのは高速化もあわせて8bit時代からのtipsだぞ
たとえば丸いキャラの判定をどうするか
これは縦長と横長の2つの四角をくみあわせるだけでそれっぽい判定になる
さらにちいさめの正方形をあわせて3つになればほとんどの場合問題になることはない
丸?
X方向の差の二乗とY方向の差の二乗を足した数が
半径の二乗よりも小さかったら当たり。
でよくない?
すまん。これ、相手が点の場合のみ有効な方法だった。
丸っこいキャラでも正方形一つか二つで大概事足りるね。
>>552 あれでもそんなに出てるんだ。
ガルーダは大往生と同じ基板でスペック的には
大したこと無い筈(怒首領蜂より下)なんだけどな。
所々でソフトによるウェイトでなくマジ処理落ちするけど。
552が自前で作っている「ガルーダを参考にしたSTG」の話だと思われ
アーケードガルーダのオブジェクトは558の言うとおりで、300もない程度だろう
アレンジガルーダなら1000行くかも知れないが
PS2版を知らない人のために一応フォロー。アレンジガルーダってのはPS2版のアレンジモードのこと
さすがHSPerだな…
>549
とりあえずガンガレ。
HSPは良くわからんけど、Timerが使える環境ならデバッグ用に
ゲーム開始からのフレーム数と時間の差分なんかをダンプする
簡単な関数を用意しておくと何かと便利よ。本当はちゃんとした
プロファイラを用意するのが良いんだろうけど。
563 :
558:04/07/12 18:28 ID:wXVm5haw
564 :
529:04/07/12 18:32 ID:oVg9IA8S
なんだか予想通りの展開になってるし・・・orz
晒したソースの「それなりの処理」とか個別に外して
それでも当たり判定が遅いと言っているのか思ってた。
レスされた内容を吟味してないんなら漏れも550-551と同じ意見だ。
これでエフェクト外しても遅いって言ってきたら更に顰蹙もんだぞ。
565 :
526:04/07/12 21:20 ID:BZTWJ1i5
レスは大変参考になってるし
それにしたがってテストもしてる・・・と主張したいのだが
説明も下手だし状況報告も不十分だったから無理ぽいな。
でも今さら聞いてもらえるかワカランが
問題点の検証はレスに沿ってやってる。
最初当り判定だと思い込んでいただけだし、
描画かもしれないよ、と言われたら描画関連はいじったよ。
修正・検証に時間が掛かるのはソースが汚いからだと(特に描画専門のルーチンを作っていないあたり)、
俺のレスの程度の低さから察して欲しかった。
>>551は素で完全に見えてなかった、ゴメンナサイ!w
今さらレスするとes_setは使ってない。(そういうことじゃないか)
描画は外した。もちろん速くなった。単純に弾の量は倍いける。
すまそ、つまり、
原因検証はしていたけど報告せずに
一人でソースいじって試行錯誤してた、と・・・。
叩かれて当然かもしれないけど、努力してたのは
少しくらい認めてください・・・。虫がいい話かもしれないけど。
アウトプットを出さないと何もしてないのと同じなので、同情はできないな
結局何をどうやって結果はどうなったの?
順番にやったのならどれがどうだったのかでも
報告してくれれば他の人も参考になるかもしれないのでよろしく
568 :
526:04/07/12 23:31 ID:BZTWJ1i5
@当り判定が悪いと判断しこのスレへ来る
(この時は既に当り判定を外し処理落ちしないことを確認)
A敵1のときと敵nの時の
処理速度を大まかに計測。大体比例する。
B500がここで描画とビデオカードの
ことについて述べるので
友人のPC5台ほど(古いメーカーものでビデオカードの情報は無かったな・・・
差はあれど軽快に動いたのは3台)
でテストさせてもらう。結果はまちまち。
C514-515の指摘でとりあえず色々外す
(色々すぎて何を外したかよく覚えてないが描画は外してみたはず)
処理速度が向上したことを確認。
描画、当り判定それぞれ外して処理が軽くなったので
この時点では原因は分かってない(分かってなかったと思う)
DやっぱHSPerだよなと言われてしまう。
EFPSの話題になるが問題解決につながるような
ことは無し
F友人のPCにて飛翔鮎が軽快に動き、俺のがガタガタであることから
命令処理速度ではなく描画処理速度の問題であることに気づく。
飛翔鮎ではエフェクトの使用を抑えているように見えることから。
GさすがHSPerだなと言われてしまう
Hんで現在はあらかじめ回転させた画像を作ったり
無駄な処理を削ったりしているところ。
とまぁ振り返ってみたけど
やっぱ俺のレスは内容薄かったね。。
すんません(='ω`)
まあいいけどさ…
なんか試し方がおかしい気がするんだが。
ウェイト無し、sync待ち無しにして
・デフォルト
・当たり判定ルーチンだけ外す
・描画ルーチンだけ外す
・描画ルーチンの回転拡縮、半透明処理だけ外す
それぞれでFPS計測して表示させれば、どこで大幅に処理落ちてるか判るだろ。
>>563 紛らわしかったですね。スンマセン
>>559 アレンジモードでは、1000以上出てるように見えます。
自分のは、アーケードの弾幕を参考にしてますんで。
(アレンジ再現するなら、GF3以上は必須になるかと思うので)
ただ、頻度や配置の調整が全然で、初心者考慮して弾速を遅くしたので、
画面上に溜まってるキャラが多いと。
弾の封印等を入れたら、900台まで減りましたが。
再現しようか迷ってるのが、倍率表示。
敵弾 X X100(<(0〜100)4文字)で、
今の4倍近く表示数増やさないといけなくなる。
テクスチャLOCKして書き換えるにも、数が多く、全部独立してるし。
それ以前に、点数計算方法がわからない。w
まあ、これはいらないかな?と。w派手で良い演出なんだけど。
ん?テクスチャロックって毎回テクスチャ生成するの?
「×」と「0−9」を先に作っといてくみ合わせればOKでは?
さらにインチキとしては明らかに使用頻度が多い「x100」だけは事前に
できあがった画像を準備しといたりしてもいいかも。
>>569 そうそう、そういう手順を追った測定方法をすればいいんだけど、
>>568を読むと、場当たり的で原因を突き詰める方法を理解してなさげ。
偶然うまくいったら「うまくいきました」で済ませちゃいそうな感じ。
デバック能力も必要ってことだ。
>>571 X1〜X99の部分をテクスチャを生成するは、そうなるのかな?と。
でも、生成用のテクスチャを99個持ってるんなら、初めから用意しててもかわらんねw
そもそも、そういう使い方は想定してないだろうし。
そのインチキ法は、書いてる時に思いついた。という事で、X+2桁表示でいける。
でも、そこまでして入れるもんでもないかな。
一瞬でよく見えない部分だし。
それだったら、首領蜂系のように、○HITと表示する部分を持ったり、
格ゲーのコンボみたいに10ごとにgood!等の文字にするとかしようかと。
何度もスマン。
テクスチャを生成なら、画面全体をキャプチャするべきか。
だから、空テクスチャはデカイのが1つ。と。
そもそもするつもりないからよく考えず書いてた。
後は、最低動作スペックが気がかり。
ハードウェアT&Lは必須なんで最低でも、GForce2MXぐらいは必須か。
描画周りには、殆どCPU使わない方針でやってるので、ビデオカード依存率高い。
グラフィックでちょっと無理したいならある程度のスペック要求は仕方ないね。
GForce2MXくらいなら問題ないと思うけど。
ここは、とてもやさしいスレですね
ところで、みんなは必須スペックをどの程度に見積もってる?
俺は開発環境が古め(Althon700 + GeForce2MX)なので、
それでやってる。
一応更に低い環境(Celeron500 + M-RAGE)でもテストしてる。
celeron300 + TNT
開発環境がこれなので。
いまだDirectDraw野郎な俺はSurfaceに使えるVRAMが8Mあるマシンを想定
CPUはP3-600MHzぐらい?
しかし開発環境はVRAM2.5MBしかない…orz
#Let'sNote M2な
Pentium4 1.6Ghz Geforce4440go ノートで開発
半透明処理を随所に施したゲームを開発してた時↑なら楽勝だったけど
予備のPCで動作させたら重たくなって焦った事があるよ
GeForce3/RADEON8500以上必須。
漏れはマヌアルに「〜必要」って書くのが嫌いなのでDirectXは一切未使用。
ゆえに求めるスペックはCPUのみ。
それでもPen2 400くらいあれば余裕。低スペック志向な漏れ・・orz
今だとJava2Dがかなり早くて環境に合わせた
アクセラレーションを選んでくれるので
DirectXを使用しないという人にはいいだろうね
そういう人はDIBやDDBでアプリ作ってそうだし
何げにNT4でもXPでもちゃんと動くのは面白い
500MHzクラスのマシンでスプライトが16bpp/60fpsで
1500個でたので問題ないなぁとおもた
>>578 PenIII-700〜800あたりとGeForce2くらいで処理落ちせず動けばとりあえずOKライン。
それより下でも動くようにはしたいけど執着はしない。
PenIII 800 + RADEON7500ぐらい。
(GeForceで言うと2MXぐらいなのか?)
パンピーの使うメーカー製PCも対象にしてるので、Intel Extreme Graphics 2とSiS315。
あとはGeForce4 MXとRADEON 9000あたり。
>>578 自分の開発環境は、P4(2.8),RADEON9700PROに、
ノートがPM(1.6),モバイルRADEON9000です。
どちらも快適に動きます。
で、低スペック検証用というか、ただの物欲でシャープのモバイルノート、
PC-MM50Fを購入しちゃいました。(CPU:TM8600 1.0G,モバイルRADEON)
動作させた所、最低で30FPSまで落ちる。う〜ん。きついか。普段は落ちないんだが。
更に言うと、DVD-Rに焼いたDivXムービーがコマ落ち激しい、、。
今、VC++等を入れてる所です。
>>578 どんなゲームかにもよる。スペックを超えたゲームとはいかないまでも
せめて「このゲームにしてはオーバースペックだな」
と思われないようにはしたい。
>>588 そんなに低スペックではないよな
同クロックのPenMより遅いが同クロックのPen3クラスの性能はある
ビデオがかなり貧弱であるか
もはやUMAビデオカードより低スペックだしなぁ
でもUMAの性能が確実に上がっていて、そういうマシンは
どんどん増えているからこのあたりで手を打つのは悪くない
CPUだけはどんどん上がっているのでそっちでカバー
するような作りが出来ればね
DiVの再生が思いってのは違うところがネックになってるんじゃ・・・
>>588 >DVD-Rに焼いたDivXムービーがコマ落ち激しい、、。
それは激安DVD-Rメディアを使ってるのでは。
今もってるパソコン
Pentium4 2.4G メモリ 512
ビデオ:sis651のオンボード
OS XP
が、初めて買ったパソコンだから
動作環境の定義が自力で 出来ないです orz..
ひとつ前の作品なんか、
ノーウェイトでFPS=300ぐらいだったから、
単純に2.4を5で割って500MHz とかw
かなり無責任なこと書いてました。
今回はいろいろ報告があってウレシイんですが。
自作やってる仲間が多いと、低スペックPCの1台や2台
タダですぐに組めちゃうんだけどねw
>>590 >もはやUMAビデオカードより低スペックだしなぁ
これ以外だった。RADEONというのに騙されたかな?9000以上は非常に良いっぽいけど。
モバイルで開発ってのは、まだ厳しいのかな?
VC,DirectXは動作確認したので、一応は出来るようだけど。
今VC#入れてます。
>>594 みんな もってない or 最近の企業の なんです('A`)
って、俺も自作なんて良くわからんヘタレですが。。。
っていうかHSPなんで、描画なんてライブラリ作った人まかせ。
偉そうに動作環境とか書く権利すらないような・・・。
ウインドウズの知識はおろかCPUとかの動きなんて何も知りません(´・ω・`)
CPUの動きなんて俺も知らぬw
>>595 というかUMAのチップセットがここんところ速度品質ともに進歩しすぎ
元々ネックはメモリ帯域だったんだけどDDRが標準になってきたり
PentiumMや90nmのPen4とか大容量キャッシュが当たり前になってきたりとかね
あと地味にクロックが上がっていたり(855GMEあたりは250MHzなはず)
パイプライン数が増えていたり確実な進歩しているよ
単純な速度的にはノートのは無印RADEONとほぼ同じと思っていいはず
ただ、VRAMがUMAのほうは64MBまでとれるので何かと便利
最近は同人レベルでも16MB超えるのがあったりしてるしねぇ
ただ、こういった底辺のチップセットはまだまだDirect3Dは重く、
速度的にDirectDrawに大差つけられてる
回転機能が欲しかったら3Dで実装するよりVRAM16Mくらいくってもいいから
16方向分起動時に描画してバッファに持っておくとかすれば低スペックマシンで
快適になるだろうといった考え方が必要かな
599 :
582:04/07/15 00:52 ID:RWdIjlRh
>>595 Mobility-RADEON-D(16MB)は
GF256(DDR) 〜 GF2MXの間ぐらい。
Fixed-T&L機能搭載のビデオチッフとしては
最低ラインだが、PIII-1GHz程度のCPUとの
組み合わせならば3DMark2000の点数で
3500程度は出る。
俺のサブノートがこの組み合わせなのだが
Unreal Tournamentが60FPSで動いている。
2DSTGが重たくなるのは、比較的派手な
演出をしているかコードがおかしい場合のみ。
600 :
582:04/07/15 01:03 ID:RWdIjlRh
>>598 16MBの内蔵DDRメモリにテクスチャが収まる場合
よほど間抜けなコードを組まない限り軽快に動く。
BF1942でさえ30FPS出るのだから、要は組み方の問題。
>>598,
>>599 ナルホド。参考になりました。
>派手な演出
特にないです。
回転についても、まだ保留しています。
(完全に再現するなら、パターンで持つしかないんですが)
>コードがおかしい
CPUについては、まだ全然チューニング出来てないです。
特に、メモリプール、ハッシュ等は。
まあ、追々やってきます。
>>600 2Dのほうが大幅に早いってのは855GMの話な
さすがに1フレームあたりスプライト数1000は変わるので
かなりかわるというわけさ
603 :
582:04/07/15 12:20 ID:RWdIjlRh
>>602 それは全く事実ではない。
i855GMの内蔵グラフィックス機能(Intel Extreme Graphics2)は
RivaTNTクラスに相当する。ハードウェアT&Lを搭載していないが
ラスタライズはハードウェアが行ってくれる。
このような構成のビデオチップでは、アプリケーション側のコードで
行列計算を行い、T&L済みの頂点データを流し込んでやるのが
一般的だ。2Dゲームの場合は特にパフォーマンスが改善される。
604 :
582:04/07/15 12:24 ID:RWdIjlRh
一応補足しておくけどDirect3Dで全く回転させない描画とDirectDrawの比較な
だからT&Lがどうのこうのというレベルではないよ
単純にバッチで処理するようになってるので
単体使用ではオーバーヘッドが大きいというだけさ
だからこそ低スペックPCでの話な>回転機能OFFでDirectDraw
>>603 そうですね。私はi854ユーザーですが
Quake2エンジン系のゲームちゃんと遊べます。
Direct3DのソフトウェアT&Lパイプラインは
2DSTGには非効率ですから自前でやりますね。
>>605 ベンチマーク結果の表を見ましょう。
右隅はi855GM。T&L未搭載でUMAです。
真ん中はモバラデIGP。モバラデのUMA版です。
Quake3-Arenaに注目してください。
608 :
582:04/07/15 13:58 ID:RWdIjlRh
>>606 つまり、フルスクリーン256色モードでカラーキー使った
VideoMemory(UMA)->VideoMemory(UMA)のBlt()と
Direct3Dを比較していたということか。
別にそれでも構わないが、DirectDraw VS Direct3D の
重い軽いを比較するにはやや不条理な前提であろう。
前者はVideoMemory(UMA)->VideoMemory(UMA)の矩形転送。
つまり全ての描画はハードウェアラスタライザの支援を受ける。
それと同じ処理をDirect3Dでやるということはハイカラー以上。
VideoMemory(UMA)->VideoMemory(UMA)の矩形転送では
データ転送量は最低でも倍になる。
古いビデオチップであろうと新しいビデオチップであろうと
DirectDrawにとって極めて有利な条件といえる。
俺は昔からハイカラーしかつかわんよ
riva128クラスからは256色のほうがblt遅かったし
多機能な3Dのほうに不利な条件ってのは分かってるけどね
だからこそメモリ使用量を抑えて3D描画より回転させる程度ならその分用意すればいいといったまで
省メモリと速度とのトレードオフだが、要16MBくらいなら今は許してもらえる範囲か?という話な
あとQuake3の結果はまったく当てにならん
CPUがPenM1.4GHzと高速な割に可変フレームレートで70fps程度しかでてないことから
1GHz以下を対象に2Dの固定フレームレート維持は結構厳しそうだ
前にも出た気がするけど、みんな画面の解像度いくつでやってる?
横STGなら俺は320x240でやりたいんだけど、縦で画面比3:4にこだわると
縦240ドットだとどうしても小さすぎるんだよな。
レトロコンシューマ風なら横長320x240もアリだと思うけど、アーケード風で
やりたいので…。でもアーケード風だと縦480は細かすぎる罠。
じゃあ300x400でどうよ
今なら躊躇無く640×480でいいんでない?
320*240はちゃんと表示されない環境多いし
誰でも出せる640*480だろう
自分さえよければいいという人はしらね
320*240を2倍に拡大するのがいいのかなー。
アーケード風縦画面縦STGなら横360縦480で決まり
640x480の解像度以外は遊べないプレイヤーが出てくる
画面全体を任意拡大できるSTGもいくつかあったな
個人的には、2DSTGもD3D必須となっている今、
多少VRAMを多く使うとしても、800*600に移行し始めてもいいと思うんだけどな。
今どき320*240なんてみみっちいものを選ぶ理由ってなに?
ドッターが死ぬ
619 :
610:04/07/16 02:09 ID:JGkHQqHL
レスThx。
主にアーケード2DSTG風ね。
やっぱVGAの縦をいっぱいに使った360x480に落ち着くかなあ。
ちょっと細かいんだけどね〜。
800x600にしてピクセル縦横2倍のほうが(実質300x400)雰囲気は
近いかな。速度とメモリが問題なければこれもアリか。
往年のは縦320なんだよな。
ウィンドウモード限定にして縦640または960なんてことをやると…環境によってはマズいかな?
240*320で縦シューつくって
フィルターかけずに
1240*1024の解像度に
3.0倍拡大させて描画
622 :
610:04/07/16 03:40 ID:JGkHQqHL
今更619の訂正
×>800x600にしてピクセル縦横2倍のほうが(実質300x400)
○>800x600にしてピクセル縦横2倍のほうが(実質225x300)
何やってんだ俺様orz
関係ないが、今開発のために1280x1024の液晶モニタを縦にして
2台横並べで使ってるんだけどさ、
この環境だと殆どのフルスクリーンのゲームが動かないんだよな。
当たり前だろといわれればそうなんだが…。
(Radeon9600pro使用、ドライバによる90度画面回転)
縦シューを縦画面でやりたくても、そういうのってなかなか無さそうだ。
そもそもSXGA液晶だと縦横比4:3じゃないしね。
今の俺の案
ゲームワールドは240x320(縦)で作成。
これを2倍に拡大して画面解像度1024x768の中心に。(表示域は480x640)
モニタを横倒ししてください、という同人ソフトがあってもよいと思う。
同人じゃないけど、キャリーラボのギャプラスを思い出す。
98VM以前だっけ…?
DirectDrawで縦2DSTGの雛型作ってるんだが、各描画オブジェクトを実際にDraw
する時の順番の管理に悩んでる。
つうのは各キャラクタには”高度(z)”の情報を持ってて、高度が低いキャラは小さく、
高いキャラは大きく描画する予定(レイフォースの敵雑魚を想像してくれい)なんだが、
ここで描画の順番を考慮しないと高高度を飛んでるキャラクタの上に低空を飛んでる
小さいキャラが上書きされてしまう事がありカコワルイ。
1フレーム毎に全ての雑魚を高度情報を元に描画順をソートしてると時間がかかりそうなもんだが…
なんか良い手はないんかね?
ふつうにソートしろ
200MHz以上がターゲットならば
スプライト1000くらいバブルソートでも余裕だぞ?
60MHzクラスだと少し厳しいかもしれない
>>628 そんなに時間かからない。2Dシュー程度のオブジェクト数なら、
何も考えずCのqsort()とかC++のsort()とか使って平気なくらい。今時のPCは滅法速いからな。
ソート時間実測してみて、本当に重いようならバケツソートとか基数ソートとかを検討のこと。
631 :
628:04/07/16 19:40 ID:tp+KxRbP
気にし過ぎだったかな
普通にソートしてみるよ
マンガト
ノシ
2Dの場合ソートする必要があるオブジェクトの方が少ないんでは?
少なくとも敵弾のプライオリティは他のオブジェクトよりも上だろうし
定期報告です。
敵情報設定ツール、ステージ設定ツールに敵配置機能を追加。
どちらも仮実装で、まだまだ仕様が固まってないです。
ランタイムの方は、配置データを食わせるのと、
仮タイトル画面<>ゲームの行き来を実装。
これからボスにかかります。
その後は、無断使用している素材の全書き直し、、。
自分の場合、2Dのソートはとりあえず避けました。
拡大すると不味いんだけど、取り合えず、アルファテスト使ってます。
古典的な方法なら、初めから高度別にリストを何本も用意しておくのが普通ですな。
毎回ソートしない手としては、
描画専用のリスト構造を用意して、それを常にソートされた状態にしておく、ってのがある。
挿入やZの移動が発生したときだけリストを辿ればいい。
PSのオーダリングテーブルと同じ方法でいいんじゃねーかな。
ほんとだ。調べたらそのまんま説明が出てた。
バケツソートを使うのが普通じゃなかろうか。
素材で思い出したんだが、開発途中の素材の管理も面倒じゃね?
沢山のキャラや各パターンのビットマップを最終的に1枚のビットマップに纏めてるんだけど、
>633みたいに後から差し替えるとなるとかなり手間なんだよなぁ
もっと簡単に管理したいんだが・・・
バケツはその名前しらなくても少しでもプログラムやっていれば
自然とみんな使うようになるアルゴリズムの代表だね
オレは最近は手抜きで、
バケツは使わずにC++のstd::multimap使ってる。
ぶっちゃけゲーム、とくにSTGなんて
コレクション系使いこなすための勉強にすぎない
といいたくなるくらいコレクション分かっていればどうにでもなるからな
一番技術的なレベルが低くても作れる物だけに熱くなれるというか
>>639 素材は1パターン1枚のビットマップで作る。
最終的にそれを編集して一枚のビットマップにするツールを自作。
マップチップツールの応用で結構いける。
ツールにはパターンマップを吐かせる。
後から配置換えしたくなっても、ツールでいじればいいので簡単。
場合によってはパレット管理つけるとかお好きなように。
>>644 俺なんかへんなこといったか?
STGは制作者側にとって一番敷居が低いゲームだろ
絵や音楽が優れてなくともアイディアとかバランス面でなんとかなったりするものだ
それだけにゲーム本編に力を入れることが可能だし、
職業プログラマなら気にしなくとも日曜プログラマのような趣味で作る場合
少しずつの時間の捻出でなんとでもなるというのが大きい
シューティングを作る技術=プログラム技術と思われたらかなわんな・・・。
そのアイデアやバランスのノウハウも含めてのスレタイじゃないのかい。
百歩譲ってそうだとしても、君の理屈だと(例えば)ポリゴンRPGやらADVの
プログラマーなら、STGなど朝飯前で作れるという事になるのか?
そこまで言うのなら、自らの作品を以て実証して頂きたいものだ。
真っ先にゲームプログラム開始してそれなりに形になるのがSTGだから
8bit時代にSTGから勉強下って人は多いんじゃないのか?
いっておくけど、他のジャンルと比べて簡単というのは単純に技術力だけの物じゃない
RPGやAVGなんかはボリューム出すためにだれやすく最後まで完結させることは難しい
また絵や音楽が重視される傾向にあるために一人で作るのは難しい
とりあえず最初に進むべき基本となるのが2DSTGと思っただけだ
XYとスプライト表示さえわかればどうとでもなる
それだけに基本は非常に単純であるが奥深いもので初心者から上級者まで
一緒に語りやすいいいジャンルじゃないのか
おいおい、釣られるなよ。
6歳並の絵しか描けない大学の教授だって、
絵について能書きたれたいこともあるんだよ
朝飯前で作れても
それが面白いかどうかは
また別の問題になるしな
テキトーなもんならシューティングに限らずどれも大して変わらないと思うが。
結局何が言いたいのかも不明だしな
口だけなら何とでもという典型
>>641,
>>642 コレクション系ねー。何が良いのかちゃんと研究してないな。
これが良かったとか教えてくれると嬉しいな。
現在使用してるのは、ms標準のvectorとlistだけ。
(しかもベクターモドキ使ってる。標準のだと、中身が見辛い。それだけの為にw)
ファクトリーにはmapのが良いらしいけど、何かの本にmapは遅い。と書いてあったのでこれもvector。
にしても、オーサリングツールが整ってくると、結局汎用クラス作った方が楽な気がしてきた、、、。
ファクトリにvector? 逐次探索使ってるんか?
それに比べたらmapのほうが高速だと思うが。
それともハッシュと組み合わせたらvecto
mapが遅いのはおそらく同様の
mapは内部構造が二分木だから遅いんじゃなかったっけ?
ハッシュ二分木のhash_mapってのがSTLに追加されたと思う。
そちらを使ってみては。
ああ…編集中に書き込んでしまった_| ̄|○
mapが遅いのは同様の機能を別の方法で実装したときのほうが速い
というだけであって逐次探索に比べたらよほど速い。
で、この程度のことならハッシュを使うのがいい、ってことかな。
>>653 ファクトリに、newされたポインタを返すstaticメゾットと
オブジェクト名をセットにしたクラスを登録してます。
まんまmapの分野なんですがね、、。
文字列検索はそこらじゅうで使ってます。w
ハッシュを使うのがいい。てのは判ってるんですが、
差し迫ってないので、保留してます。w
それとアロケート系がCPU負荷の殆どだと予想してます。
どちらも、数の上で重要であろうは、タスクステータス関連ですが、
アルゴリズムとメンバの分離をやるべきかと思うけど、手付かずです。
そもそも、CPUと描画の負荷をチェックする機能そのものがないですが、、。
追々やります。(最初にやるべきか?)
公開出来たら、追々ソースも晒そうかと思ってます。
酷くショボイので、勇気要りますが、、、。
SGIのSTLが元になってる系列のSTLならhash_mapは標準装備されてる(gccとかSTLportとか)。
デフォルトアロケータも一旦プールを作って使い回すような作りになってるので、
別にOSのメモリアロケート速度が遅くてもそんなに影響しないようになってると思う。
結局は思い込みでチューニングせずに、ちゃんと計測しないと却って遅くなってるかもよ?
このスレも3機目のようなので
よくわからないけどエクステンドしておきますね
(・ω・)ノ [1up]
10upくらいしちゃった(茸)
ろじっくかよ。
今週末はグラディウスVをトコトン調べつくそうぜ!
グラ5ってアケじゃないのかよ・・
もう達人シューターがギャラリーはべらせて超絶プレイを披露する
時代は終わったのか・・orz
今は達人シューターがリプレイをupして
超絶プレイを世界中に披露する時代、なのかな?
>>661 100円で10分以上遊べるゲームはもうアーケードじゃ無理。
物価が上昇したから?
100円で10分以上遊べるゲームのほうが多いと思うが…
対戦格闘とか音ゲーくらいじゃないか?すぐゲームオーバーになるのは
それはともかくうちの近くのゲーセンはシューティング含む古いゲームが1プレイ50円なんだ
1プレイ20分として、ひっきりなしにプレイする人がいると仮定して(実際はガラガラなんだが)1時間で最高150円
開店時間が10:00〜24:00までだから1台につき1日2100円しか入らない
機械のメンテナンス代、アルバイト代、エアコン代等差し引いたらどれくらい残るんだろう
どうやって経営成り立ってるのか非常に不思議だ
成り立ってないんじゃないの?
回転率のいいゲームがそれらの穴埋めをしているわけで。
バーチャや音ゲー、大型の多人数筐体()とかの
稼ぎのいいゲームしかないゲーセンってのも増えて来るわけだし。
まじで、シューティングとかは常連の為のサービスみたいなものだと思うけど。
それだと昔の1980年〜1990年頃のゲームセンターは
経営できないってことになってしまうよねぇ。
今のゲーセンの話。
もしかしてゲーセンは今も昔も変わらないと思ってる?
ゲームの寿命(製品サイクル)が短くなってるし、平均単価は上がっているし。
アケ板覗いてくると良いよ。
ゲーセン通い歴25年だから、歴史的なことはわかる。
金額やゲーム時間そのものより、アーケードゲームそのものが
衰退したことによる影響が大きかったってことかね。
シューティングゲームは今でも製品寿命が長いように感じるけど、
同じゲームをずっと設置してあるのは、なかなか償却できないから?
アーケードは衰退してないっての。
ビデオの数が減っただけで、最近は増収傾向だし。
671 :
名前は開発中のものです。:04/07/20 01:28 ID:o+IyX9h/
>>670 はぁ?
最近までアーケード店舗自体は減少傾向にあったのよ。
今年度は増収傾向だけど、それは単なる数が減ったからにすぎない。
672 :
名前は開発中のものです。:04/07/20 02:07 ID:OhWArrE+
ゲーセン減ってるよ
ほとんどパチンコ屋になってたりする
アーケードゲームは衰退してない。
ビデオと田舎のゲーセンがなくなっただけだ。
大型店舗は増えてる。
近所のローソンがなくなったからって、コンビに業界は衰退してるって
言う馬鹿はいないぞw
これ以上語るつもりなら、ゲームハード・業界板に行ってくれ!マジで頼む。
せっかくスレが良い感じになってきたからさー。
じゃ、気を取り直して、次どうぞ↓
>>673 ふぅ・・・アホはは疲れる。
近所のゲーセンがなくなったからアーケードが衰退しているというわけじゃない。
全国的に減ってるてこと。
わらた
秋葉原はゲーセンがやたらと増えました
で、思ったんだけど武器のパワー調整ってどうやってる?
武器ごとに攻撃力を持たせるのが簡単なんだけど、
昔のゲーム、例えば達人とかでレーザー取ると
次から出現する敵が固くなったりして更に調整してるみたいなんで
他にも色々な方法があれば聞いてみたい。
>>679 達人みたく敵の固さをパワーの分母にするテクニックは
整数演算時代の遺物と言えなくもない。
弾の強さに浮動小数点が気兼ねなく使える今時のPCゲーの場合は、
わざわざ敵の固さまで差し替えずに弾の威力だけで表現する方がすっきりする。
整数演算時代でも、気の利いたシステムだと威力を固定小数点で持ったりしていたね。
達人は基本的に飛翔鮫ベースの古いシステムの建て増し構造なので、
ああするしか方法がなかったとも言える。
武器攻撃力、敵の固さ、ともに固定小数点で扱うのがいいんじゃないかな。
大往生とか、一番柔らかいザコですら自機の体当たりで何十フレームも当てないと倒せないし
オプションショットも2発以上当てないと倒せなかったりする。
こういった微妙な調整のしやすさは固定小数点の利点だと思う。
あぁ、たぶん浮動でも構わない。そこはお好みで。
それだったらint32で、ショットミニマムのパワーを1000とかすればいいと思うが。
わざわざ小数で考えるメリットが分からん。
固定少数はもう旧世紀の遺物。
>680
>681
おまえら、何をどうしたら、たかが小数にそんな幻想を抱けるんだ?
まぁ、固定少数も使いどころはあるけど、大抵は浮動少数でいくでしょ。
シューティングに限らず、
>>682 みたいな使い方はよくやる。RPG、SLGやアクションとか。
関係ないけど、かなり小規模のファミコンチックなシューティングって需要あるかなぁ。
多くは無いけどある。
>>685の言う「ファミコンチック」が何を指すのかによる。
>>682 そのミニマムを256だったり65536だったりと考える、
というのが「固定小数点」の考え方の基本なんだが、
用語の意味わかって言ってるか?
わざわざシフト演算しづらい10進で内部データを扱う意味こそわからないぞ。
あ、書いてから気づいたが、
一部RISC系CPUなんかは小数点掃うために上位にバイトレベルでアクセスしたり、
ビット単位でシフトするより、割り算一回かました方が早かったりするので、
そういうことを言いたいのならスマソ。
でも、もしそうだとしたら、それは本当に一部コアなので、汎用的じゃないぞ
いや,別にシフトとかしなくてもいいってことだろ.
みんな回答ありがd
ちなみに漏れは敵の固さ固定で武器や敵の固さを0x10000を1とする固定少数でやってます。
浮動少数のほうも試してみます。
>690
共用体を使うのもご法度?
>691
敵の固さとかは座標みたいに整数へ丸める必要がないんで、
漏れはシフトとかしてないです。
>>690 普通のCPUならそこまでワード境界ペナルティがあるわけじゃないので、
そこまで気にしなくてもいいと思う。
アーケード屋で、よっぽど変わったCPU使ってるとかでない限り。
駄目箱あたりで、座標計算やダメージ判定までシェーダでやらすつもりとか、
そういうつもりでもない限り、固定小数でいいんじゃないか?
>>688 遺物、つか、固定少数点なんかPSでも低レベルな描画部分にしか使わんし
なんで固定少数点数にこだわるの?
普通に浮動小数点数使えばいいじゃん、と思うんだけど。
浮動小数点数の方が楽でしょ。
つか、小数にこだわるのが理解できん。
俺も。
「耐久力」というものに小数部を持たせる意味なんか、通常無いと思うんだが。
>>697 だったら固定小数も意味ないことになるやんけ。
ぶっちゃけバランスの微調整に小回り効いて便利でしょ。
で、どうせ小数部持つならいまどき浮動小数だな、普通。
まあ、FPUとか付いてて浮動小数点のペナが問題にならないような
ターゲットなら浮動小数点で全然いいんでね?
携帯ゲーム機とか、そのへんでは固定小数点しか選択肢がなかろうて
ターゲットシステムにおいて適材適所だあな。
で、アーケードはいまだに68K基盤使わされたりするので固定小数点マンセーだったりするのだなぁw
>ぶっちゃけバランスの微調整に小回り効いて便利でしょ。
この理屈がワカラネェ
なんで浮動少数=小回りが効くって事になるのか…
雑魚の耐久力10に対し弾一発の攻撃力10を基本にすれば?
PSは浮動少数はライブラリでのエミュレートしかないけどな。
固定少数は使用メモリが減らせれるからDCとかでもモデルデータの一部で使ってた。
耐久値とかは固定少数というか数値を大きく取ればいい訳だし、浮動少数でやってもあんまり変わらんし。
適材適所でいいんじゃないかと。
こんなことでスレを消費するのももったいないよ。
>>687 反射神経でトリッキーな動きの敵を蹴散らす、と言えばいいのかなー。
ザナックやキャラバンみたいな。
まぁ、需要がなくても作るかもしれないけど。
自己満足の世界だし。
敵弾なしのSTGってのも、遊んでみると案外楽しい
スターフォースから敵弾取ったようなもの
MSX時代にフリーでそういう作品があったんだが、
ステージが進んでランク上昇すると動きがより過激になるという要素もあった
フリーというか雑誌掲載ならガレオン
うわっ、知っている人がいたか。わざわざ正しくない「フリー」なんて言い方しなくて良かったか
>>702 > こんなことでスレを消費するのももったいないよ。
御意。
まあ、俺はザコの耐久力1.0・自機通常弾1.0を基準で作り始めるのが明快と信じる人間だが
確かにどうでもいいっちゃどうでもいい。
昔作ったWindowsのSTGでは、
ショットLv.1で攻撃力40、Lv.Maxで攻撃力60ぐらい、
雑魚は一撃で倒せるやつは体力1、そうでないのは体力100ぐらいから、
とかしてた。少数派かな?
まぁ、適当な攻略記事の数値でも見て参考にするのが良い気もするけど。
ところで、夏コミの締切に追われてる同志はどのぐらいいらっしゃいますか?
自分のつくってるゲームは、戦艦とかでかキャラ以外ほとんど硬さ1にして
そのかわりに、こちらからの攻撃を避ける等する。
確実に当てるためよく狙ったり、主ショット以外の
ロックオンミサイルをつけているところ。
>>707 > ところで、夏コミの締切に追われてる同志はどのぐらいいらっしゃいますか?
もう投げた人ならここに……。
身体壊して入院と病院通いで、今年前半ほとんど何もできなかった。
必死で落ちるの祈ってたけど通ってしまってるし。
コミケ当日も東京まで行って帰ってくる体力があるかどうか。
作者急病ですか(w
711 :
名前は開発中のものです。:04/07/21 20:54 ID:a9M7XODr
同人シューなんて東亜系や弾幕系のマイナーチェンジ
みたいなもんだから9割以上駄作だよ。
何言ってんの
弾幕薄いよ
東亜の要素をちゃんとコピーできてるSTGはもうちょっと増えて欲しいな
面白いSTGのエッセンスはいろいろとあるはずなのに、同人では忘れられている気がする
かくいう自分もそんなに東亜に詳しいわけではないが
>>714 >東亜の要素をちゃんとコピーできてるSTG
東亜の要素というのは弾幕以外で何がありますか?
道なりに動く戦車ぐらいしか思い浮かばないです。
そりゃ観察力がよわいねー
まぁプレイしてみりゃその差は歴然
一口に東亜と言っても人によってどういう部分が東亜かは異なりそうだが。
記号的な部分でなくゲームとして東亜リスペクトだったら良いと思う。
東亜ったって、
究極タイガーと達人とOUTZONEとBATSUGUNを
同列で語ってもしょうがないだろう。
>>718 BATSUGUN、ドギューン(だっけ?)、Vファイブとか好きだったな。
爪楊枝判定とか言われだしたのこの辺だっけ?
その後、ドンパチに継承されると。その辺りまではヌルイゲームだと思ってた。
達人王のデカ判定&ボム無敵なしはキツかった。
今日はグラV発売か。
では脱弾幕ということで、イメージファイトのような
縦シューでありながら横シュー的ゲーム性を持ったものを作ってみゆ
それを詰めると、レースゲームっぽくなりそう
中途形態が疾風と
縦のギミックSTG良いね。イメージファイトが代表だが、
シルバーガンも多少共通するかな?
沙羅曼蛇偶数面は横画面だが、縦画面のグラディウスも目新しいかもな。
疾風は慣れるまでは生存狙ったほうがいいのに、つい急いでしまって楽しめない、
という初心者が多かったかもなあ。策はいくつかあるが、アーケードでは難しいかも知れない。
ギャロップとか? あ、横か
東亜だとヴィマナが面白いな
マイナーどころ来ますなw。
ヴィマナは左右スクロールなかったよね。
そいや初期東亜ゲーは、二人同時プレイできるゲームはその場復活で
左右スクロールなしが基本だったな。
左右スクロールの処理って、単純にオフセット表示させてやってるのかな。
それとも相対座標で処理してるんだろうか。
そういや縦STGでの横スクの実装案でちともにょった(まだ実装してない)
一人プレイなら問題無いけど、二人同時プレイでこれやるとどうしても違和感でるんだよな
アーケードだと大往生とかケツイとか…
ガルーダも二人プレイはまともにゲームにならんしなあ。
そもそも二人同時プレイなんて必要?
アーケードなんか商売的に入れてるだけじゃないの。
二人用は…、一人用のメリットが大きい場合、犠牲にせざるをえないな。
>>724 オフセットも座標相対変化もありそう。後者はよくわからんのでオフセットにしてるが。
背景と空中オブジェクトの相対移動速度が違っててヤバい作品もあったような。
やっぱ同時プレイだとダメかなぁ>左右スクロール
鮫・鮫・鮫!!だと通常の交互プレイバージョンだと左右スクロール有りで
後に発売された2P同時プレイバージョンだと固定になってたっけな
>>726 海外ゲーセンでは、二人同時プレイの需要が意外と高かったりするんで、
海外版だけ同時プレイ、というゲームもあったりするね。
>>728 左右ありにすると、
1Pが画面左端、2Pが画面右端に行こうとしたときどうすんだ、
という問題が発生すっからねぇ
今日グラX買って2人プレイしてみたけど、結構面白かったよ。
で、その後大往生やったらどっちがどっちかわからなくなってつまらなかった。
グラXは弾の色も変えてるあたりがいいね。
おっグラVって2人プレイできるのか!
まあ俺には一緒にやってくれる人はおらんよ。。。
シューティングは一人で殺伐とやるのが良いんじゃねえか
萌えツイつまんねーよ!
横スクロールのときのベル撃ちが不可能に近い
>>726 その通り、連コイン狙いです。
片方のプレイヤーが生き残っていれば、
コイン入れてもらえるので……
ラスボス倒した瞬間連コ
みんなグラXで忙しいのかな?
とりあえず、イージーで1週。
緑ガス面、納得いかね。
ある程度装備ないと、撃ち負ける所が2箇所ほどある。
>>726 因みに偽ガルーダには実装してません。する予定もないです。
グラディウスVのレーザーってどうやったら描画できるの?
方向キーでロープみたいにぐねぐね曲げられるけど。
>>739 思い切って、1Pixel単位で描画とか。
PS2なら直線描画があるから、それでグラデーションラインを引くとか。
レーザーを点で管理して前のフレームの点と現在の点を
線で繋いでるだけのような気がする。
あとはどれくらい綺麗に保管するかって感じでは。
ポリゴンストリップでいいんじゃない?
PS2なんだし。
まあ、ストリップだろうね。
序盤しかやってないけど斑鳩のようなシルフィードのような。
雑魚の爆発が派手になってグラディウスとしては少し違和感。
面白いんだけどねー。
ぐら5って外注?
トレジャー
ケツイみたいな弾が加減速したり角度を変えるのって結構めんどいな
管理が…
そういう動きをする弾クラスを作ればいいんでない?
動き以外の処理は抽象化しちゃえばいいだろうし。
そもそも「管理」が何を指しているのかよく分からん。
750 :
748:04/07/27 00:01 ID:SoXJSX/e
間違えたので自己つっこみ。
動作処理を抽象化して具体クラスで各弾の動きを実装やね・・・。
>>746 トレジャーって、元々グラII作った人らが独立した。
であってたっけ?
>>747 俺は
>>750みたいに、全てのキャラ、弾がタスクステータスの派生クラス
という実装をしてます。
現在、ボスを実装中なんですが、
今までは、1キャラにつき、1スプライトだったんだけど、
ボスの場合は、ステータスの数自体が結構多くて、
複数のスプライトを持てるようにしようか悩み中。
出来るに越した事はないんだけど、複数タスクの場合と混乱する場合があるかも。
似たような仕様を実装する方法が幾つもあるのがちょっと気持ち悪いような、、。
>トレジャーって、元々グラII作った人らが独立した。
違うよ、コントラSFCのスタッフが独立した。
グラはファンってだけ。
>>751 経験上、1キャラ複数スプライトが必要な場面というのは
遅かれ早かれ出てくるものだと思ってる。
俺だったら、今のうちに拡張しておくけどね。
>751
そこでポリモーフィズムですよ。
リンクド・スプライトだろうが通常のスプライトだろうがポリゴンだろうがDraw()をコール。
>754
関係あるのか?
まあ751の発言の
「ステータス」や「複数のスプライトを持つ」とか
が意味するところがいまいち掴みきれないのだが。
あとDrawは名前がなんかダサい。
Drawがダサいって意味ワカラン
>>752 そうだったんだ、、。シルバーガンとかやってて、勝手に思い込んでたのかな。
>>753 まあ、そうですね。偶々今まで必要なかっただけでしょう。
特に、アクション系とかのジャンルを作る場合とかは。
>>755 やっぱわかり難かったですか。
自分の場合、1つのキャラクターにつき、TCB(タスク管理クラス)と
タスクステータスクラス(不特定多数)があり、
「ステータス」は後者、
「1つのスプライト(一応描画リソースの1つ)しかもてない」は前者です。
因みに、MSのサンプルから応用してる所為か、Drawではなく、Renderですね。
当初から描画はDirectDrawを想定して組んでたんだが、テストで500キャラ表示
させたら描画が遅くて話しにならんかった…orz
ちょっとBltで拡大させただけで一気に遅くなるよ…拡大させなきゃ1000キャラでも
問題無いのに…
DirectDrawで60fps出そうと思ったらBltは等倍しか使い物にならんの?
Direct3Dに移行しる。
頭悪くてD3Dに移行できない(;'A`)
なんか作成意欲が思いきり削がれた…
DirectX9でベタベタ書いてるけど
やってることの割にハイスペック要求せにゃならんなぁと考えて鬱になったり。
楽で良いけどね。
超連射システムっつーかライブラリの公開とかしてくれないのかしら。
単純に興味があるし。
DirectDrawの拡大bltはほとんどの場合アクセラレーション効くはずだが
そのキャラサイズとかビデオチップとかCPUとか環境かいてくれ
>>762 テスト環境(開発環境兼用)な
P3-600EでVGAはNeoMagic(Let'sNote M2R)
OSは98SEでDisplayの解像度は800x600x16bpp
作ったライブラリではキャラクタの拡大縮小も出来るけど、それは行わずに最終的な
出力画面を引き伸ばす為に1フレームあたり1回だけ拡大Bltさせたらこのザマ
もうだめぽ
まず低スペックチップなら解像度を下げることをオススメする
DACでのメモリ帯域の占有率はそれなりに高い
でも拡大を最終的に1回だけbltでそんなに重いとは思えないなぁ・・・
なんとなくNeoMagicということからvram容量たりてなくてソフト描画になってるとか
一応サーフェースは今回使ってるサーフェースはVRAMに収まってるハズなんだけどなぁ…
念の為家に帰ったら確かめてみるよ
なおこのLet'sNoteのVRAMは2.5MBという半端なもの。
んで今のテスト環境のサーフェースの内訳は以下の通り
プライマリサーフェース 800x600x2(16bpp) = 937.5KB
テンポラリ用サーフェース 480x640x2 = 600K
キャラクタ用サーフェース 640x480x2 = 600K
計2137.5KB
キャラクタは全て一旦テンポラリサーフェースに描画。
17ms毎にテンポラリサーフェースの中心部分の矩形(w = 240,h = 300)をプライマリサーフェース上の
中心に2倍(w = 480,h= 600)に拡大して描画。
拡大しなきゃ良い感じだったのに…orz
微妙だな
vramって綺麗に容量が減る訳じゃなくて
境界で減る場合もある
ところでバックバッファとってのflipとかやってないようにみえるんだが・・・
2DならD3DよりもDrawの方が早いだろう
>767
先生、アルファブレンドとか回転ぐらい使いたいです。
>766
境界については承知、あくまで理論値ね
あとflipについても当初はバックバッファ取ってたけど、765で書いたように一旦
テンポラリ用サーフェースに全部描画する事からバックバッファのメリットが無いんで廃止
つまり垂直同期しないってことか?
まぁ、この辺は人によるだろうからべつにいいが
flip使うことによってbltの回数が減るから結果高速化もされるだろう
772 :
名前は開発中のものです。:04/07/28 19:50 ID:MXXa145y
DirextX使わないのが勝ち組(自称)
最新50スレを読んだが、まだデモ程度も出来上がってないのか?
>771
何が悲しゅうて、糞遅いVRAM直アクセスなんぞせにゃならんのよ。
ジーニアス英和辞典にも「発音注意」の表記がありますた。
>>774 システムに置いてアクセスするのが普通じゃないのか?
VRAMにはプライマリのサーフェスしか置かない。
今更こんな話題出してもしかたないか。
>777
そうなると
ハードウェア能力が使えない→DirectDrawを使う意味が無い
そもそも今のマシンでDirectDraw使うメリットなんて
画面占有ぐらいしかないだろ。
>>775 まあそういう間違った発音のまま日本語に溶け込んじゃった言葉は
他にもあるけど…アベレージとか。
781 :
582:04/07/29 03:40 ID:lMfFyPXc
>>778 >ハードウェア能力が使えない→DirectDrawを使う意味が無い
いいえ、それは一概にはいえません。例えばHALデバイスで
キャラクタ単位でVideoMemory→VideoMemoryでカラーキー転送(Blt)する手法と
ソフトウェアレンダリング後SystemMemory→VideoMemoryで転送(Blt)する手法では
前者のほうが高速に決まってるじゃんとおっしゃる方がたまにいるのですが
これはアーケード的な低解像度で2DSTGを作る場合は当てはまらない場合が
多いです。ベンチを取って確認したほうがいいと思います。
前者において、HALデバイスよりHELデバイスのほうが高速になる場合
アプリケーション側コードでソフトウェアレンダリングすることが速度的に
特別不利になるようなことは稀です。
782 :
582:04/07/29 03:57 ID:lMfFyPXc
申し訳ありません。誤読していました。
システムメモリ上でソフトウェアレンダリングするならGDIでDIB作って
BitBltすんのと変わらないじゃんって話でしょうか。
一応、DirectDrawHALでSystem(AGP)→Videoの転送時に
アクセラレーション効く場合があります。
古いんだよ
マニアックス読んで、
「え、東京大学卒のゲームプログラマー!?へへ〜〜」と
ひれふし、正座して読んでたんです。ところが
290頁。。。「兆」は?
親しみがわきマスタ。
しかし亥(がい)という単位があるとは知りませんでした。
さすが。。。
私が兆を飛ばさなかったのは、億以上を思い出すとき
「万、憶、兆、京、キョーダーイーン」という特撮の主題歌を
いつも頭の中で歌うからでした。
ソフトウェアレンダリングやるときキャッシュが非常に影響でかいんだよなぁ
メモリも高速化してるとはいえCeleronとか2GHzこえてもかなりきっつい
PentiumM系がどんどん普及すればソフトウェアレンダリングは
どんどんやりたい放題になって楽しそうではある
ま、CPUとかの性能向上の割にビデオが向上してないってのが前提の話だったんだが
UMAでもDDRメモリつかうあたりからそこはネックじゃなくなってきたし
915はかなりのものらしいし、今後もどんどんよくなるだろう
3D方面は描画品質が一定ではなくて、アクセラレーションの効き具合が
メーカーによって様々すぎたことからソフトウェアレンダリングという方向が
一時期はやったのだが、今やビデオチップ開発してるところが一部のみでは
その考え方自体もあまり有効ではなくなってきてる
速度的にいえば320*240あたりの解像度ってことならたぶんハードウェア
アクセラレーション使うよりソフトウェアのほうが早いかもしれない
細かいスプライトを使う場合、どうしてもアクセラレーションを期待する方は
レスポンスが悪くなるものだ
ま、どっちにしろその解像度はネックになることはねーし、同人STGでも
640*480がここ1,2年で大幅に増えている事を考えるとどーなんだろうね
週報です。
もうちょい(数日中)で評価版?UP出来そうです。
低スペックマシンだと、テクスチャの切り替え時にフレーム落ちする。
てのは直しときたいかも。
現在は、テクスチャオブジェクトを作っといて、ポインタ切り替えてるだけなんだけど、
内部で何が起きてるかよくわからん、、。
空テクスチャ作成>サーフェイス作成>リアルタイムでサーフェイス切り替え
とかやると速くなるのかな?
D3Dの本には、そのような事が書いてあったけど、詳細はなかったので。
>>785 小学生のときなぜか無量大数まで覚えた俺。
ガキの頃ってよく変なもん暗記した。
ところでキョーダインは最後の京をケイでなくキョウと読んで
キョーダインに続いてるわけだが、誤読だろか。
IBMのCMで覚えた漏れは中年
アポロが飛ぶ奴??
MAMEのSTGって結構な速度出てるよな
あれ全部ソフトウェアで処理してるって事考えればDirectDrawは最終的な出力に
使うだけで内部的にはソフトウェアで描くのがいいのかな…
正直悩む
>>791 最近はやりのエフェクトとかにこだわらなければね。
超連射はベースが68なだけにソフトウェア描画だな
よもやDirectDrawがこんなに遅いとは思わなかった
自前Bltルーチン書くのマンドクセ('A`)
拡大縮小は諦めよう…
もうあきらめて3D使え。ヘタに自力描画するよか早いって。
796 :
名前は開発中のものです。:04/07/29 22:13 ID:Tvmb/73s
拡大版のbitmapをあらかじめ準備しる。
これなら、処理は重くならないかと。
まあ、容量は食うけどな。
ゴメソ上げちまった。
素直にDirect3D使えと何度も何度も何度も言ってるのに
まだわからんのですかオヤジどもはとか言ってみるテスト
今稼動してるPCで、2Dゲーに十分な3D性能持ってないものなんてもう極少数派ですよ。
2世代前のオンボードVGAでもGeForce2 MX未満くらいの性能はある。
少なくともDirectDrawで出来る範囲ならDirect3Dよかははやい
自前bltエンジンにしろループで回すだけだろ
拡大1回でそんな遅くなるもんか?
コードが悪いだけかと
DirectXのClip使ってるとか・・・
画面中に8x8ドットの絵(数字)を30x40=1200個Bltした時のFPSを測ってみた
等倍表示時で59FPS
2倍表示時で19〜20FPS
1フレーム17msで回してるので59FPSってのは遅延無しの状態
2倍表示しただけで3分の1まで落ちやがる
つまりコード自体には問題が無く、拡大Blt一発でガタ落ちしてると言える
もうぬるぽ orz
なおClipは使ってません
ああスマン、混乱するんで一時的にトリップ付けとく
>800に書いた結果は開発環境でもあるLet'sNote M2R(P3-600,NeoMagic)の結果ね
今ものは試しにお遊びマシン(P4-2.4C,Radeon9600np)で試したら2倍に拡大した
ままで59FPS出たわ
しかしながらこの二つの環境の差が大きすぎてイマイチ参考にならん…orz
>800
単にDDCAPS_BLTSTRETCHが無いだけ、とか言うオチは?
>>802 今Caps確認したらおっしゃる通りですた
腐れNeoMagicはDDCAPS_BLTSTRETCHは持ってなかったよ
吊ってくる
‖
‖
('A`)
( )
| |
プログラム起動時に倍角テクスチャを動的に作って等倍転送させるとかw
・・・って書くとD3Dに汁って言われそうだけど、
こんな方法どうよ? ってことで。
>804
元々、最終結果を拡大しようとしていたはずだから>765
まあこの場合、そもそも拡大する意味があまり無い気もするが。
俺はD3DじゃなくてOpenGL使ってるんだが、
他にそういう人いるかい?
今のとこ最終的なアウトプットだけ拡大してるけど、ライブラリ的にはハードウェアアクセラレーション
を当てこんでキャラクタ単位でも拡大縮小できるように書いちゃったんだよね…
なんでこんな事してるかと言うと、高速かつ少ないVRAMで動かしたかったから。
アーケードゲームの解像度も240x320(縦の場合)そこそこだから、これを基準に
してゲームワールドを構築したかったんだが…
>>806 ノシ
ここじゃ激しく異端だとは思いますが,Linux + SDL + OpenGL で作ってます
>>808 すれ違いですみませんけど、ビデオカードは何を使ってますか?
810 :
808:04/07/30 00:35 ID:pJ2x0qQh
>>809 えーと,ノートで オンボードの ATI MOBILITY RADEON 9000 使ってます.
続報
プライマリサーフェス以外のサーフェスを全てシステムメモリ上に作ったら
( ゚д゚)
(つд⊂)ゴシゴシ
(;゚д゚)
(つд⊂)ゴシゴシ
_, ._
(;:.@u@) …?!
ノートPCの方でも2倍拡大で59FPSでますた。
拡大Bltする時、どういうワケなんだかVRAM->VRAMよりもSystemMemory->VRAMの
方が速いという謎
NeoMagicって本気でクソだったんだな…
>>806 漏れもSTG作成スレでOpenGL/dev-c++/Irrlicht Engineでやってるよ。
(これも結構異端か?w)
一応Linux/Windowsソースレベルコンパチなはづw
開発環境はPen-M1.6+RADEON 9000 Mobility(奇しくも808氏と一緒やw)
現時点での最新ver.
http://gamdev.org/up/img/925.zip
813 :
809:04/07/30 00:44 ID:A0tDow7H
>>810 どうもです。いろいろ聞きたいことがあるんですが板違いになるので止めます(笑)。
814 :
806:04/07/30 02:03 ID:KCDLFlTq
みなさんどうもです。
いないかと思ったら、そこそこいるんですね。
ちなみに俺はWin/Linux/Macコンパチでやってます。
(
>>808氏と同じく、SDL使用)
LinuxのビデオカードはRADEON 9500使用です。
古いチップだと特にノート系はfillrateの問題があるな
拡大したらその分サイズが大きくなるんで
おおげさにいうと面積4倍なら速度も1/4になってもおかしくない
256色(1ドット1byte)でシステムメモリに描画
↓
システムメモリ上のオフスクリーンサーフェイスに
256色→16bit色テーブルを利用してコピー
↓
プライマリにblt
>>812 DLしてやってみたけど重過ぎて、全然動かないぞ。
つーかPCは、実際には思ってる以上に性能差があるのかも知れない。
見た目の上でも、アーケードやコンシューマと比較するのは無理があるかも。
ゲームを作る時、実際にPCで市販されているSTGの出来と、要求スペックの程度がどのくらいか
比較しながら作るようにしている(特にSTGは)
>811
そりゃ
VRAM→[CPU]→VRAMより
SysMem→[CPU]→VRAMの方が
CPUとVRAMのアクセスが少ない分速いだろ。
>817
なら自分の環境を書いてやれよ。
>>817 あらま。ちなみに環境を教えてくれると助かる。
知っている限りでは、Athlon700+Geforce2MXで40〜50FPSだったとは聞いている。
今の開発環境(前述してるので省略)では平均300fpsぐらい。
>>819 拡縮転送にハード支援が無いからCPUがエミュレートする訳なんですが。
多分半透明とか使いたくなるからsystemに持っておいた方がいいよ。
まぁ、D3Dに任せるのが一番いいけど、その環境だとね。
大人しくメインのPCで開発すれ。
逆にその程度のbltですらソフトウェアエミュレートになるなら
ますます3D方面やらせないほうが・・・
Pen4+Rade96NPのPCあるみたいだからそっちでやりなよ、ってこと。
なにも速いPCだからってスペックギリギリまで重いアプリにしなくてもいいんだし。
>>819 VRAM→GPU→VRAM と直接やりたいところが
HALで対応できないので
VRAM→(AGPバス通過)CPU→(AGPバス通過)VRAMとせざるをえない
いちばんのボトルネックを二度も通っているので
当然システムから一発で送るより遅くなる。
成程、漏れの理解が足らんかった
取り敢えずオフスクリーンサーフェスをSYSTEMMEMORY指定しても十分な速度が
出せる事が判ったんでこのまま逝ってみる
>>818,
>>820 ノートPC Athlon XP-M 2200(グラフィックはオンボード)
昨日は0FPSと表示されて何も動かなかったが、ノートPCだし他に起動
しているソフトウェアが原因と思って閉じたら、24FPSまで上がった。
その時だけどんな感じのゲームかわかったし、良かったけど
なぜかもう一度ゲームだけ起動したのに、また0〜4FPSになってしまった。
>>826 Athlonノートでオンボードって何だ?
チップセットがKMほげほげならSavage系で、SiS系ならSiS315相当、
nForceならGeForce2MX相当だけど、
nForce以外は3D使ってるゲームやるようなスペックじゃないことは確かだな。
ちなみにインテルのUMAである855GMで60〜62fps
CPUはPentiumM/1GHzな
ゲームオーバー時だけ大幅にfpsが下がるがゲーム中は安定
>>826 昼休みにDirectX版を作ってみた、良かったら試してみてくれ。
要DirectX8以上。
これで安定するとしたら、ドライバのOpenGL実装がマズーだという可能性大。
Irrlichtの問題なんだろうが、DirectX版の方が2割ぐらい速い。
妙なこだわりを捨てて、IrrlichtでのWin版はDirectXで組んだほうがいいのかorz
(define一発で済むと言えばその通りだしなぁ)
http://gamdev.org/up/img/934.zip スレ違いな気がするが見逃してくれorz
大幅にフレームレート上がったよ
160くらいでるようになった
ファイルサイズも小さいしな
ただ、ボスが出ると90くらいまで、そしてその後いっきに75くらいまで
下がった後そのあとそれくらいで安定した
どっかでへんなの掴んでるんかね
>>830 今度は他のソフト起動してても速くなったよ
ただ、今度はGAME OVERになってずっと爆発してる(バグ?)
画面構成も良いし、おもしろくなるのでは。
DirectXで75fps、OpenGLで62fps
値としてはそれなりのものがでてるかと
>>832 お、動きますたか。よかっつよかっつ。
こちらも貴重なデータをいただきますた。ty
「オンボードVGAあたりだと、
DirectXはともかくOpenGL実装はサボっているドライバあり」
というのは貴重な教訓ですわ。
ゲームオーバー後進展が無いのは単にその先未実装だからじゃw
>>831 こっちでも現象は確認した。
(昼休みにチャチャっと実装したのでそこまでは確認してなかっつ)
IrrlichtのTechdemoとかでも、DirectX使用時に限り、序盤に
「君いくらなんでもそのFPSは変じゃろ?」
という値が出ることがあるので、
ひょっとするとIrrlichtのDirectXドライバのFPS計測関数のバグかもしれん。
というわけで、スレ汚し失礼。STG作成スレに帰ります。
STGを最初からみんなで作るスレ
http://pc5.2ch.net/test/read.cgi/gamedev/1014709311/l50
836 :
名前は開発中のものです。:04/08/01 05:59 ID:oOS3lX0B
意見も何も全然完成してないじゃん。
この程度で意見求めるのはどうかと思うよ。
>836
君は835の書いたスレへ行くのが吉。
とりあえずどんなゲームになるのかくらいはページ作ろうな。
840 :
836:04/08/01 14:38 ID:7PSoUSiK
分かりました。
みなさんSEってどうしてますか?
自分はフリー素材頑張って探してるのですが見つからない
とくに弾発射と爆発音…
>>841 普通に「効果音 著作権フリー」とかでググるだけで
そこそこ見付かると思うけどなぁ。
そんなんじゃゲーム作る気がないとお(ry
あのー・・・
基本的なことで申し訳ないのですが
現在のリフレッシュレートってどうやって取得するん?
ヘルプ見ても
「ウィンドウ モードの場合0」だとか
「デフォルトの場合0」とかしか書いてない・・・
計測するしかないんかなぁ
>>845 HRESULT IDirect3D9::GetAdapterDisplayMode( UINT Adapter, D3DDISPLAYMODE *pMode );
で取れたけど。
845が使ってるDirectXのバージョンは?
848 :
845:04/08/02 17:03 ID:5/vDCotE
どもども。
>>847 9でつ。
GetAdapterDisplayModeだと0とか帰ってきたりするでつ・・・
諦めて自分で計測しまつ
すまん。もしかしたら勘違いしているのかもしれん。
ウチの環境ではそれでリフレッシュレートの値取れるんだけど、
ヘルプに「RefreshRate。この値が 0 の場合、アダプタ デフォルトを示す。」って書いてあったんだ。
もしかして、これはディスプレイモード指定時時にアダプタデフォルトを示すには0を指定する、って意味で
GetAdapterDisplayModeを使った時はリフレッシュレートの値がちゃんと帰ってくることが保障されてたりするの?
ノートなんかだとリフレッシュレートが取得できない場合が多い。
俺のも必ず0が返ってくる。
>>850 (´・ω・`)そか・・・
やっぱ0が返ってくることもあるのね
しかたないので、取得計測両方して、差が大きかったら計測値を採用、でやってみまつ。
ありがとん。
基本的にデジタルディスプレイはダメでは
9xもダメかも
OSによって取れたり取れなかったりしたような
98では0が返ってくるけどXPや2000では取得できたような
>>854 確かそうだよな
リフレッシュレートでは俺も以前フレームレート絡みで色々と試行錯誤したが、
結局Windows環境である限りどうにもならんと諦めた記憶が
実測モードを付けておけば万全…かな?
結局実測して取得値と比較しますた。
取得値60で実測値が61だったら 60を採用
取得値0で実測値が61だったら 61を採用
みたいな感じで。
>>132の言ってる内部FPS300と組み合わせたら(・∀・)e!感じ
おまいらにもおすすめですよ
>>132を見て思ったことだが、リプレイの実装についても話し合ってみたい。
俺はまだその段階までたどりついてないけどね。
リプレイは早期に搭載して「ちゃんと再生される」段階まで確認できてると、あとが楽かも
内部300FPSでも、従来どおり乱数シードとキー入力だけで問題ないよな
バッファが埋まってしまったら、追加バッファをアロケートするわけだよね。
プレイヤーが何もしないとどんどん使用メモリが増えていくのが不安なので、
今作ってるのは制限時間を設けてフレーム数に限度を付けてるんだけど・・・。
制限が無いゲーム作ってる人はあまりそういうことは気にならないのかな。
・ステージごとにリプレイデータを書き出してバッファ掃除
・ステージは強制スクロールで、ボスも自爆
・なので、バッファは固定長
というゲームしか想定したことがないなあ
時間無制限の場合は、何らかの形で休憩ポイントみたいなのを設けて
その間に一時ファイルとかに書き出しちゃったほうが良いような。
STGだとループゲーでない限り、気にするほどでもないと思うが。
・何も考えず直にファイル書き出し
>>861 まてまて。バッファ固定長?
それってフレーム毎のボタン入力情報を保持しとくってことか?
それだとデータ量凄いことになるべ。内部300FPSでは大変大変。
あれですよ。
大体1フレ毎にボタンのON/OFF切り替わるわけじゃないんだから、
フレーム毎のボタン入力情報じゃなくて、
ボタン毎の押されたフレーム数情報を保持したほうがいいですよ。
例えば、Aボタンが300フレーム押されなくて、次に20フレーム押されたときは
A { {OFF,300} , {ON,20} }
みたいな形で保持した方がメモリ食わんですよ。
ほじ(ホヂ)【保持】
―する
〔そうする△意義(必要)のあるものについて〕そのままの状態を持ち続けること。
・・・漏れは日本語がヘタのようだ。
みんなは保持しないで保存してくれよな。
シューティングならPlayer当たり8bitもあれば十分だよね。
300FPSでも1時間記録して1MB程度なので余計な事しないほうが
いいんでわw
漏れはファイルに逐一書くほうが楽だと思うけど。
リアルタイムでランレングス圧縮かけてる。
>>868 乙。
やってみた。動作に問題はなさげ。
以下疑問質問。
・キー入力に対して自機の反応がかなり遅いんだけど何故?
・左右スクロールは無し?
・自機はセセリたんですか(*゚∀゚)=3
こっちの環境書いとくね。
AthlonXP2400+、RADEON9600pro、WinXPpro、DirectX9。
いじょ。ガンバレ。
>>868 キー入力されてから実際の動きに反映されるまでの遅延が凄すぎ
おかげで弾幕が全く避けられん
確かにUSBジョイスティックの入力をDirectInputが拾うまでの遅延はあるのは
知ってるが、それ以上に遅い気がする
当方環境
P4-2.4C Radeon9600np Win2k DirectX9
>868 すげーヽ( ・∀・)ノ
AthlonXP2500+/PC2700 1280MB/RADEON 9800Pro/Win2k/DX9cR
ほぼ60fpsを維持。他二方が言ってた入力遅延は起こらなかった。
パッドは、psxpadドライバを使ったSFCコントローラ(パラレルポート経由)
872 :
871:04/08/04 11:54 ID:RB8JqBU+
連続書き込みsry
USB接続のゲームパッド持ってることを思い出したんで、そっちでやってみた。
結果は変わらず、遅延は感じられなかった。なんでだろ?
AthlonXP2000+、GeForce FX 5200、Win2k、DirectX9b、サンワのUSBパッド
1ボスが爆発で40程度に落ちる以外は概ね60程度を維持してる。
入力の遅延は全く感じず。
偽ガルーダ
設定にXML使うのはいいんだけどSOAPってあたりが激しく疑問だ
PentiumM1GHz/855GM
爆発時以外常時60fps安定
USBパッド遅延無し
P1.6GHz XP Geforce4440ノートPC DirectX9
60fps維持、ボスキャラ爆発で57fps前後
ジョイパットないのでキーボード操作、全く問題なし
ボスキャラ作って断末魔「お嬢様ー」と叫ばせて欲しい
Cerelon400相当/TNT2
タイトルから先が動かなかった…。
後日別マシンで動かしてみよう。
P4-2GHz/Radeon9200/dx9
タイトルから進まず。desktopのリフレッシュレート85Hzが、titleでそのまま使われてる。
dxdiagで60Hz強制上書きにすると、ちゃんと60Hzになる。そこからZ押しで強制終了。
>>868 PenIII / 886MHz
Mil.G550
SVGA 60Hz
Win2K
起動してもLoading Please Waitが出たまま反応せず。
>>868 Pen-M1.6G/RADEON9000Mobility/Mem1G/WinXP
DirectX9b+OMEGA DRIVER
FPS300〜400前後でフレームリミッタ効かず
ご協力感謝します。参考にします。
粘着してた甲斐がありましたw
>・キー入力に対して自機の反応がかなり遅いんだけど何故?
自分の所で、症状が出ているのか、判断出来ない状態です。
明らかに判るレベルでしょうか?調査します。
>・左右スクロールは無し?
取り合えずは、なしです。(手抜きです
>・自機はセセリたんですか(*゚∀゚)=3
その反応を期待してそうしましたw
>その他、動作しない
調査してみます。
入力には、DirectInputを使用してます。
DirectXは9.0bを使用しています。
今の所、テクスチャは512*512,400*480の2種類を使用してます。
XMLパーサーには、Microsoft XML 4.0 Parser を使用してます。IE5.0以上?が入ってればOKだったかも、、。
ビデオカードは、ハードウェアT&Lを前提として組んでます。(Direct3Dです)
882 :
869:04/08/04 23:54 ID:SqmvQOiX
セカンドPCでやってみたが、こっちはそれほど遅延はなかった。
けど全く無いわけじゃないと思う。869で書いたPCは誰でもわかるほどの遅延。
今回テスト環境
AthlonThunderbird1.0GHz、GeForce2MX、W2k、DirectX9。
ちなみに今回はUSBキーボード。869はPS/2キーボード。
いや、XMLパーサとSOAPは関係ない
あきらかにちがってる
たぶん参考にしている書籍かなんかがSOAPだったんだろうなぁと
どっちみち紛らわしいしやめとけ
俺みたいに仕事してればひっかかるから
>>874,881
何故にSOAPてのはですね、、。
ツール側のシリアライズ、デシリアライズに使われていてですね(C#で組んでます)、
それを未加工で使わせてもらってます。
そのデータから、必要なメンバだけを使用しているわけです。
間にコンバータ挟むと、修正の際も含めて、工程が倍になるかなー?という所での実験です、、。
>>869 サンクスです。そですかー。
では、こちらの環境では、再現出来てないです、、。
今、取り合えず、デバッグモードでトレースしてます。
いや、C#だろうがSOAPヘッダつける必要はないだろう
>869
やってみた
細かいことだけどキャラが画面端にいくとぷるぷるしてるのが気になった
後全体的に弾速がかなり遅いね赤状態でちょうどいいぐらい
入力の反応が遅いんで微妙なところかと
偽ガルーダやってみました。
他の方も言ってますが、キャラの移動がもっさりしてるような気がします。
あと、斜め移動が縦横移動より速い気がします。ルート2倍かな?(知ってて放置してるのだったらすみません。
まだ荒削りの段階なのでしょうが、よく出来てるなーと思いました
そいやグラVは斜め移動速度はルート2倍だね。
縦STGでは最近あんま見ないな。
>>886,888
はい。単なる手抜きです。
追々直す、、かもです。
892 :
877:04/08/05 12:15 ID:1ery+xof
同じく、タイトルでゲーム強制終了。
一応、他のアプリのウィンドウ位置が復元されない(破壊される)ことをもって強制終了と判断してる。
893 :
869:04/08/05 12:44 ID:07QHXvNg
そいや前のバージョン終了するときエラー音出てたな。
今度のは平気っぽいです。
偽ガルーダ見ても自分で書いてるコードでテストしても、こうも入力の遅延が
大きいのを見せつけられると暗澹たる気分になってくる
STG、特に2D弾幕系を作る環境じゃねえよ
ぶっちゃけ製作のモチベーション下がる…
うちではそんなに遅延してないと思うが…
入力の遅延は正確な計測ができないから(プレイヤーの感覚しかない)、難しいな
ジョイパッドの方向キーをほんの一瞬”チョン”ってな感じで押してみるとわかるよ。
アーケード基板やファミコンでもキー入力された瞬間にキャラクタの動きが即座に
反映されるが、偽ガルーダに限らずDirectInputで同じ事やるとキー入力(↓)
されてそれが離れた(↑)後でやっとキャラクタの動きに反映される。
897 :
名前は開発中のものです。:04/08/05 19:05 ID:twiZbl6g
ジョイパッド持ってないのでわからないけど
>>896 キーボード操作でもそうなります?
遅延って仕様なの?
どうしようもないのか?
>>896 まぁDirectInputだけの問題でもない
環境依存かと
ちみのマシンはかなり遅延でているようだが
極論いえばリアルタイムOSじゃない時点でお察しください
リフレッシュレートをDirectXで確実に変える方法もないし
ゲームに適した環境でないのは確か
偽ガルーダ、うちの環境では開発用のメイン機が一番遅延大きかったんだよな。
自分で作ってるゲームはこんなに遅延出なかったんだが…。
遅延ってOSとかDirectXが原因ってのもあるけど、パッドが一番悪いんでないの?
I/FSEGAだと遅延を感じたことはないし、USBだとはっきりわかる
>880
ところで、テクスチャサイズ400*480なんてけったいなサイズは、
ちゃんと2の累乗まで水増しして作ってるのか?
905 :
902:04/08/05 20:41 ID:bfVqoQCp
遅延といっても原因はひとつだけじゃないからな。
1)パッド→PC
2)入力の内部処理
3)ゲーム進行の演算内部処理
4)描画処理
5)ビデオカード→モニタ
画面に出るだけでこれだけ段階があるんだから
どこか噛み合わなければ遅延が出る。
2〜4は出来る限りアプリ側で解消したほうがいいけど。
MS SideWinder Joypad(レガシーな方)だがやはり遅延を感じるな
入力から3フレくらい遅れて感じる
なんかもっさりしてるね。
自分が今作ってるプログラムだと遅延はほとんど無いんだがなぁ・・・
ちなみに SMART JOY PAD 3 でプレステ2のパッドを使用してる。
なんか加速度付いてる感じ?
止まる時にタイムラグを感じるわけでもないような気も。
>>906 既に問題が絞れた上での議論なんだが…
それの1か2、特に1番目の入力の取り込み遅延が問題なワケで
今回のに関して既に絞れてるとは言えないと思うが…。
見てないので適当に書くけど、Win32のjoyGetPosではどうなん?
DirectInputって微妙に信用ならんし設計も気に入らんので使ってない俺。
「画面端でぷるぷる、に入力遅延の謎を解く鍵が!?」
などと、てきと〜な事を言ってみる。
∧ ∧∧ ∧
(゚Д゚≡゚Д゚) プルプル
|し |つ
⊂__ |
し'
(( ∩ )) プルプルプル
γ'⌒ヽ∧ ∧
し'ゝつ( ゚Д゚)つ
画面端ぷるぷるは単に座標のリミットを移動後に処理してるからじゃない?
亜覇破!
結局Windows環境では弾幕シューは不可って事でFA?
やるせねえな
さあ…
しかし俺は自分のゲームでは偽がルーダのような遅延出てないんだが…。
Windowsの同人ゲーで弾幕シューだらけの状況を見て何を寝惚けたことを。
プログラムが悪いんだろ。環境のせいにすんな
(1) ヘンな変換器など環境依存な条件で遅延が起きる
(2) 環境は問題ないが、プログラムの都合で遅延する。プログラム次第で遅延なしにできる
大部分のWindows用STGは遅延しない。(1)と(2)の遅延の内容は別。
今回の問題は(2)なんじゃない?
うちではタイトルでボタン押すと落ちるので確認できてないが。
そりゃ、メモリー破壊起こしてる可能性が大だな。
Windowsのメモリー保護が強化されたとはいっても、
実行中の他アプリの動作に影響を与えなくなっただけで、
実行しているアプリ自信のメモリーデータに対しては、
保護しないからな。まあ、保護できるとも思えんけど。
というか、アプリがアプリ自信を破壊するのは
さすがに保護できるとは思えん。
しかしこの、メモリー破壊という言葉はどうにかならんか?
メモリーが物理的に壊れたと、勘違いするヤシが多いと思うが。
弾幕シューは不可なWindows環境もあるって事じゃないの?
プログラムに問題のある可能性が大きいな。
まさかと思うが、Windowsにまったく処理を戻さずに、
プログラムを動作させてないか?
メモリリーク、と一般的に言われてないですか?
遅延はPSパッドのUSB変換機の類だと遅延が起きるものがあるらしい。
今回はキーボードでも起きているらしいからコードの問題かもね。
遅延が起きてないケースもあるから微妙だけどなー。
偽ガルーダやってみたけど
遅延している原因は画面の更新をV-syncでやっているからかもしれない。
描写が汚くなるけど、Timerでやれば遅延はなくなると思う。
>>929 メモリ破壊とメモリリークは違いますよ。
メモリーリークはメモリーの削除忘れにより、
メモリーを食いまくる現象。メモリー破壊は、
メモリー上の書き込んではいけない領域に、
書き込みを行った結果として、発生する現象。
まあ、メモリーリークを繰り返した結果、
メモリーを取得出来なくなって、
メモリー破壊を起こす可能性はある。
ただ、今回のコレの場合は、メモリーの
フラグメンテーションの可能性もあるんだよな。
メモリーの取得や削除をバラバラに行った結果、
メモリーの取得状況が虫食い現象を起こし、
メモリーを取得出来なくなる現象。reallocを
多用して、あちこちで動的にメモリーを使用
している場合にも起きる。
そんなタコなドライバがあってたまるか
いや、プログラムの側が、そうした事を
してる可能性を示唆しているだけなんだが。
>>923 バッファオーバーランの事ですかね?
気を使ってはいますが、、。
>>933 初回タイトルから発生なら、少し考え難いですが、それも踏まえて、
現在、エラー処理として、テキストログを書き出すようにしたんで、
細かいエラー、アサート、D3D初期化失敗原因も特定し易くなる予定です。
遅延については、まだ、手付かずです。スンマセン。
バッファオーバーランは、メモリー破壊の原因の一つではあるわな。
某東方でも入力の遅延は問題になったことがあったね。
それでユーザーから報告があって、コンフィグに
「DirectInputを使用しない」の項目が追加された経緯があった。
うちでは遅延というほどではないが自機が滑る現象があったがその処理で軽減されたり。
東方は知らんのだが、そのDirectInputを使わない設定で現象が軽減された事例があるんだろうか?
だとすれば速攻DirectInput捨てるんだが
WinXPあたりだとWin32のほうが安定しないこともあったような
>932
そういうのは、普通
「アクセスバイオレーション」って言わないか?
>>940 >だとすれば速攻DirectInput捨てるんだが
それは流石にやめとけ
>>942 その用語の用途は、破壊される前に検出したっていう意味では?
>>945 violation ... 違反,違背,妨害,侵害,侵入,暴行,強姦
最初の訳を取って、「アクセス違反」だよね?
アクセスの和訳は勘弁してな。
フッ だからあれほどJavaを使えとぬるぽ
なんかめちゃめちゃな流れのようだが、とりあえず以後アセンブラわからんやつ発言禁止
947かっこいいな
てめえの頭の悪さをJavaのせいにすんなよ
Java2DはWinの実装だとDIB、DDB、DirectXをつかうからな
もちろん、綺麗にカプセル化していてvramの復元とかも
すべてインテリジェントにやってくれる
NTでもLinuxでもきれいに動くしUMAのノートで垂直同期とって
スプライト2000個が60fps余裕ででたので
やっぱり
>>950がぬるぽなだけだ
まぁHSPと比べたら確実に速いしな。
別にJavaでもええんじゃないかぇ?
言語論争は宗教論争にしかならないから、やーめーろーよー
シューティング制作の話、しようぜ?
キーコンフィグ画面作るのめんどくせー
さて、そろそろ次スレの季節なわけですが。
皆さん、いかがお過ごしでしょうか?
テンプレは何にします?
低スペックのPCで快適に遊べるのを作れよな
>>952 んなわけない。
最新のPCでも、Javaで60fpsのスプライト2000個なんて無理。
嘘をついちゃいかんよ。
>>958 ペンIII-800、GF2MXくらいならOKよ。
>>958 PenII233MHz VRAM1MB を目標にしてまつ
>>959 あふぉがいた
Javaの動きしってるのか?
もしかしてJavaは96年あたりで止まってる人?
>>961 そこまで下げる必要あんの?
他に問題起こりそうだ。
Javaがえらいんじゃない、JITとDirectXが頑張ってるだけだ。
(´-`).。oO(今は、どれぐらいが底スペックなんだろ)
その実装ががんばってるというところだろう
そしてその実装含めてSunとJavaだろう
だって1.4からvramアクセスや垂直同期フリップはいったしだし
VolatileImage同士の転送が柔軟になっていればもっと速度でそうだけど
サーフェースの消失管理とか全自動なんでこれはこれですごいけどな
VBとかHSPでゲームできているうちはそれよりはるかに高速なJavaなら余裕だろう
Hotspot殺してインタプリタモードでも1000個はでるっぽいから
言語や環境は問題じゃないだろうな
>>959みたいな死滅スレの出張はわからんが
俺の基準では1GHz未満が低スペック。
判りやすいっしょ。
シューティングの面白さは、スプライトの数ではなく、
敵や段幕の動作や配置にある、と言ってみるテスト。
そもそも普遍的な面白さの定義など存在しないと言ってみるテスツ
☆ チン マチクタビレタ〜
マチクタビレタ〜
☆ チン 〃 Λ_Λ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
ヽ ___\(\・∀・) < 次スレまだ〜?
\_/⊂ ⊂_ ) \_____________
/ ̄ ̄ ̄ ̄ ̄ ̄ /|
| ̄ ̄ ̄ ̄ ̄ ̄ ̄| |
| 愛媛みかん |/
最初にPCスペックが低い高いじゃないんでしょ。
どんな「ゲーム」がどの程度の「スペック」で動くか
その要求スペックが低いか高いかってことで、
ゲームとPCが揃って初めて言えることでは。
つったってある程度以下は最初から切り捨てるでしょ。
その「程度」の話じゃないの?
974 :
961:04/08/09 01:21 ID:+0qMqF1r
漏れはフツーのシューティングを作るつもりだから、
変に高いスペックなど要求したら馬鹿にされそうでつ。
つったって今時PenII233MHzはないだろうw
低スペックマンセーネタは釣りだといい加減気づけよお前ら…
いつも大漁だな。
_人人人人人人人人人人人人人人_
> な なんだってー!! <
 ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
_,,.-‐-..,,_ _,,..--v--..,_
/ `''.v'ν Σ´ `、_,.-'""`´""ヽ
i' / ̄""''--i 7 | ,.イi,i,i,、 、,、 Σ ヽ
. !ヘ /‐- 、u. |' |ノ-、 ' ` `,_` | /i'i^iヘ、 ,、、 |
|'' !゙ i.oニ'ー'〈ュニ! iiヽ~oj.`'<_o.7 !'.__ ' ' ``_,,....、 .|
. ,`| u ..ゝ! ‖ .j (} 'o〉 `''o'ヽ |',`i
_,,..-<:::::\ (二> / ! _`-っ / | 7  ̄ u |i'/
. |、 \:::::\ '' / \ '' /〃.ヽ `''⊃ , 'v>、
!、\ \. , ̄ γ/| ̄ 〃 \二-‐' //`
:::ミ:/ ,,..__ ゙ ~~´ ゙ミミ! '"';:' ;'::'゙:゙::;゙ fミ ノノノ/ili!ヽ::;, /`ヾ .: :.:..:: ミ、
:ミ:/ u `ヽ、 ゙ , ;, ,; u u゙ミi ,. ,. ,, ., ., .:i -..,ゞ、ノツソ ,.ヾ;i ,., ,..,,.,. ミ
:/ u ,.-一‐ヾ 、_;,.;,.,; _,,,;;-'''i/メ、ノノil!))ヾ、 .i ゙;._f5゙`ー;:,.'e-゙:!,.ゞ、_ソツノ;,ヾ;;ヾ゙
'´ (・) `ー=t"r.` ./;'"r。゙ーt ,;-='´iu""._ u ゙ゞ゙ー' i.._G_,゙;:/t'a`i/i
u ゙ー--一,,.:: トー--'::! ゙-一u i、,゚,,ノ.i,j ./" `ヽ. ン u.i、u__ノ´, ゞ、.ィ'
u ゙'ヽ ゙`i u ,.:‐-、 ;.ノ i .i'.._ ゙ー-/ .ノ ./- 、゙7 u 丿
u ,.-‐- 、.._ τ/ u ! f--...___7 u丿.i、.:__ヽ / /ヽ. i、___,ソ ./
/__ `゙ー, u ノ、 i、 ゙ ゙̄/ ./ ヾー--',ィ'._ `┬‐'´; ゙ヽ
つってもアーケードの基板なんて68000-16MHzなんてのもザラなワケでだな…
DirectX9で高性能VGAとか要求しといてコンテンツレベルでショボかったらそりゃバカにされるわな
ゲーム向けのOSがあれば…w
今のWindowsは
PSとサターンとPS2とDCと64とGCとXBOXが
同じOSで動いてるようなもんだからな
ハードの性能なんてせいぜい半分ぐらいしか出ねーんだよ
低スペックで動くかどうかなんて低スペックPC持ってる奴じゃないと
わかんないから別にどうでもいいのでは…
自分所で持ってる範囲外までサポートしろ
っていうのは確かにむちゃな話だな。
英語を使えない人に英語に対応しろ、というようなモノか。
まあ、翻訳ソフトとかあるケド。
個人レベルならそれでいいだろうがな
厨房にセレロン300で動かないんですけど等言われないように
最低環境書いとけばOK。
2GHz機が3〜4万円で買える時代にスペック云々言ってモナー。
PentiumIII-500MhzのPC、貰い手がいなくて捨てたばかりだし
☆ チン マチクタビレタ〜
マチクタビレタ〜
☆ チン 〃 Λ_Λ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
ヽ ___\(\・∀・) < 次スレまだ〜?
\_/⊂ ⊂_ ) \_____________
/ ̄ ̄ ̄ ̄ ̄ ̄ /|
| ̄ ̄ ̄ ̄ ̄ ̄ ̄| |
| 愛媛みかん |/
ええい、このスレにエクステンドはないのか!
3機目死亡でGAMEOVERです
必要性を感じないヤシはそう頻繁にマシンの買い替えんよ。
3Dアクセラレーションが使えんノートの稼働率なんか結構高いと思われ。
埋め立て開始!
やっぱし触手は出さないとマズイでしょ。
誘導弾の地位はもうちょい高くても良いと思うな。
995 :
名前は開発中のものです。:04/08/09 20:05 ID:9hA/J4qX
埋め
最近、レーザーの地位が弱くなった気がしないか?
漏れとしては極太レーザーがお気に入りなんだが。
997
敵が誘導弾を撃つと文句を言う人がいるみたい。
某アーケードシュースレでいくつか見かけた。
CAVEが誘導弾使わないからか?
変なカーブはするのにな。 > CAVEシュー
1up
1001 :
1001:
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。