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

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

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

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

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

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

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

>>66
死んだときに後になればなるほど高得点が入るようにするとか・・・。
この場合、ボス戦で死ぬのは駄目。道中で死ぬことによって点数増加。
この点数は、ラストの残機ボーナスより(最終面で死んだ場合は)多くなるようにするとか
んで、死ぬことによって1、2段階ずつパワーダウンしていく。

ドドンパチでこれを考えると
緋蜂戦に入る前にぎりぎりまで残機を減らしたほうがいいわけだが
それだと、全一を目指そうとすると、緋蜂発狂モードに未パワーアップ＆残機数無しで相手しなければならない。

こんな感じで、安全をとるか、点数を取るか。
とかにしてみるのも面白いやも。
あとこれだと後半で死んでも捨てげーにならない、と、言う利点ができたりするわけですが・・・

どんなもんやろ？

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

そこまでしてパワーアップの必要性を作ることもないんじゃない？
そういったゲーム性はまた別の組み方があると思う。

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

死んだら敵機よろしく得点アイテムを吐くわけな。自機が。
特定のポイントで死ねなかったら捨てゲー確定ですな（意味不明かもしれん）。

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

あと、あんまり高いリスク→高得点を詰め過ぎてプレイヤーにストレスばっか
与えると、根本的につまらんゲームになりかねん。

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

残機潰したほうがスコアが稼げるというゲームは実際にあるわけだが
そして不評なわけだが

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

えーとガンネイルとか？
ちがったっけ

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

>>54
なんだろね？
雷電は結構、パワーアップ重要だったと思うけど（復活ゲーだし）
多分、ボス前のショット＞レーザーのバランスの事とか？

、、そろそろ、２ヶ月あまり停滞していたＳＴＧ作りを再開します。と自分に言い聞かせ、、。
とりあえず、安易な縦シューサンプルが動く所までを目標に、、。

58 · 04/06/20 08:19

>>59
そんなにいい方法があるのなら、ぜひ聞かせてほしいが…。

>>61
キーワードはググりました。
固定小数点使ってもある程度の誤差は免れないと思う。
俺の方法よりはマシですけど。

>下駄を履かせるとｲｲ
無駄足は踏まさせてます。
if(～)
{
before_time = time_table[count] - delta_t + now_time;

>V-SYNC待ち
完璧にV-SYNCが取得できるなら苦労しませんが。
まぁオプションで指定してもらえれば作る側は楽だが、そんなのめんどうだし。

>>63
そうですかね？浮動小数点でも有効数字の範囲なら同じに見えますが。

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

>>59
自分も聞かせてほしいです…

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

じゃあ簡単に解説

まず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日稼動をまたぐ時の処理は省略

…という方法
これでうまく動いてるんだけどどうや！

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

かってに送信された。一行追加

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; // ワンプレ前の値として記録
}

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

QueryPerformanceCounter は使ってはいかんのか？

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

別に構わんと思うけど、1回の呼び出しに1us位掛かった気もする。

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

>>74
で、bresenham' algorithm は無視かよ。

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

s/'/'s/

58 · 04/06/20 19:22

>>76
ども。
3倍して誤差をなくしてるんだな。

>>78
いいんじゃね？
俺はQPCが嫌いだから使っていないだけ。

>>80
無視しているわけではない、使っていないだけ。
まぁ76のが応用だな。

76を参考にして作ってみたが、delta_tが㌧㌦。

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())

58 · 04/06/20 19:24

追記、
今回は delta_t が使えないので誤差の蓄積は諦めた。

ちなみに>>74に書いたが、58のソースでも誤差の蓄積はしていた。

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

76だけど
あのさぁ、わざわざ3倍してんのはremainに誤差を蓄積して後フレームで取り返すためにやってんのに
その処理なくしたら何のいみもねーだろ。
そもそもv_syncとか意（ｒｙ

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

まだブレゼンハムとか言ってる人がいるのか。
タイマ周りなんて容赦なく浮動小数使えばいいのに。doubleで1＝1秒で。

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

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();
}

こんなんでも基本に。

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

>>74
＞完璧にV-SYNCが取得できるなら苦労しませんが。

んー。DirectX7以前ならフルスクリーンでは確実に同期できますが。
（できない珍種ビデオカード環境があるなら例をあげてみなさい）
　
更に、DirectX8以降に対応したドライバならウィンドウモードでも
確実に同期できますが。大抵はスキャンライン単位で情報得られます。
　
まさか、「CRT側のリフレッシュレートと同期できない環境」で
ノイズレスかつスムーズな2Dゲームプログラムを実現できるとお考えで？
　
>>83
＞誤差の蓄積は諦めた。
　
まぁ、勉強中ということなら今回は諦めてもいいんじゃないか。
ただし、精度保証はちゃんとできるんで。数値計算の初歩本ぐらい
買うか借りるかして勉強したほうがいいと思うぞ。

>>85

いや、精度保証付きであれば何でも構わないわけだが。
話の流れ的にも整数演算のみでカタが付くことを58が
望んでる様子だからブレゼンハムって単語が飛び出たのであるし。

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

vsync同期前提で良いんじゃないかなあと俺は思ってんだけどね…。
綺麗だし。

88 · 04/06/20 22:09

あ、言葉足らなかった。
タイマはリフレッシュレートいじれない人用と考えて
そんな高精度じゃなくても良いんじゃないって話。

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

ねーねー、誤差蓄積時間って書いてあるけど、
これって単なる前回誤差時間だよね？

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

ウィンドウモードでVSyncに同期できるってのはどういうことですか？
例えば普段リフレッシュレートを85Hzに設定してる人が、
ゲームのウィンドウだけをVSyncに同期して60fpsで動かすことって不可能ですよね？

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

>>91
私はA宗です。

B宗1派の苦労もB宗2派の不幸も知らないし知りたいとも思わない。

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

A宗でしたかー。

**92=87** · 04/06/20 23:13

です。

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

数値計算屋ならなおのことB宗にしそうだけどなあ。
＃ゲームなんて超複雑な偏微分方程式みたいなもんだ

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

でだ、俺B宗なんだけど、ちとA宗の人に質問。

このことを具体的にどう実装してるのか教えてくれ。
「同じ曲線軌道を取る弾を等間隔に連打して曲線を描く弾幕を作りたい」
もちろん軌道は微分形式で表されてる奴ね。

dt可変だと、連射弾の1つ1つの軌道が変わると思うのよ。直線弾ではなくて、曲線弾だから。
結局そんなもんは誤差の範囲ってことでごまかしてるわけかな？
(実際にプレイしてればそんなに気にならないだろうし、どうせ桁外れに小さい誤差だろうけれど)

96 · 04/06/21 00:04

すまん、ちと要点がなんだかわからない文章だった。

要するにこれをA宗の実装方法でやるのに問題点は
「等時間間隔で発射すること」「全ての弾の曲線に同一軌道を持たせること」
の2つだと思うんだけど、実際どうしてるのかな、と。

**92=87** · 04/06/21 00:13

教義をよく読んだら、もすかすてA宗ってオブジェクトのパラメータ更新も
リフレッシュレートに同期させんと異端になるんか。私、原理過激派に抹殺されるかも（・∀・）

>>96
弾幕に関しては、お定まりのアニメーション再生ルーチンと同じでイケルぽ。
空間上のパラメトリック曲線上をナゾルっぺよ。Δtにあわせてスライダー上を
進むようなイメージだべよ。

**92=87** · 04/06/21 00:23

えーと、予定調和的な処理を簡素に作り上げるなら
ゲームワールドの更新に未知のΔtを使うのは嫌過ぎる。ってのは同意。
　
私は「滑らかな2Dゲーム、滑らかなスクロール」のために画面更新は
リフレッシュレートに同期させよう。というつもりでA宗だと思ってたプチ信徒ﾃﾞｨｽ。

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

>>98
アニメーション再生ルーチンってのが具体的にどういうもんだか分からないのだけれど…。
もしオブジェクトごとに非常に小さい固定dtの数値積分で求めているとしたらそれは本末転倒で、
初めからゲーム全体にクロックを与えて、そいつで駆動したほうが楽でよくない？

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

>>98
よく、知ったかのゲーマーとかがバカの一つ覚えみたいに60fpsとかいうけど、
実際は59.97Hz前後だから、VSYNCに頼ったところで正確に60fpsにゃならないんだよ。
昔のゲームは、単に高速タイマがなくて、ターゲットのリフレッシュレートは固定だから、
タイミング取るのにVSYNC割り込み使ってたという単なる慣習だ。

PCだったら、タイマとトータルのフレーム数のカウンタを併用して、1/60fps相当で
必要な処理を通すようにゲームループ回して、絵の方をつじつまあわせりゃいい。
ちらつきが嫌ならVSYNC検出して、帰線期間に絵を書き換えりゃいいし、
そうじゃないなら洋ゲーみたいにフレームレート可変って感じで。
今のシューティングゲームは、負荷でスローが掛かる表現にしたって、ソフト的に
ウェイト入れてやるだけなんだから、無理してVSYNC使う必要はないんだよ。

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

俺は敵の挙動を計算式で処理してないので
60FPS固定でやるしかない。

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

ずいぶんと脱線をしている気がする。まあ、76と86が実用になることだけわかってれば問題ないよな。
リフレッシュレート85とかのCRTでのウィンドウモードで
伝統的57～60FPSゲームを動かすのがお題目なんだし。

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

あぁ、76-77と書いておかないと万一のとき大変だ。

**92=87** · 04/06/21 01:30

>>100
補足しようと思ったらかぶってしまった。

んーと、A宗原理過激派として実装するなら
弾幕に関しては予めシナリオが作られた打ち上げ花火なので
Δtを使った数値積分で軌道を決定する必要はないです。
Δtが未知なら避けるべきです。

**92=87** · 04/06/21 01:31

私はFLASH上で編集した弾幕を自作のエクスポーターで
出力させてるんですが、私のフォーマットは
座標値を補間パラメータとする空間上のベジェ曲線で軌道を表現しています。
この制御点には時間tなども入ってます。なぞるタイミングは、制御点間でtを
3次の多項式で補間しています。

ですので、Δtが例え未知の場合であっても弾の軌道が崩れることはありません。

**92=87** · 04/06/21 01:40

>>101
＞実際は59.97Hz前後だから、VSYNCに頼ったところで正確に60fpsにゃならないんだよ。
　
おっしゃる通りです。
　
私はVSYNCに同期した画面更新なくして2Dゲームで滑らかスクロールは不可能
という立場を取りつづけますが、ゲームワールド更新に関してはその限りではありません。

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

リフレッシュレートが59.97Hz前後なら同期で60fpsにならないの？

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

アニメーションってソレね。ベジェ曲線は自由度は高いけれど実はそうでもないのよね。
要するに3次ベジェ曲線で表せるものしか表せないわけ。
俺が「微分形式で表したもの」って言ったのはちょっと表現的には間違いかも。
「微分形式でしか表せないもの」とか「積分がまんどｋ（ｒｙ」なもの。
計算屋なら数値積分がどんだけ楽か分かると思うんだけど、
それなのにA宗でパラメトリック曲線に頼るというのは、なんか変だなと思って突っ込んでみたのよ。
なんかリフレッシュレートっつーよりは数値積分のありがたみの話になっちゃったけど(笑)

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

59.97HzはカラーNTSC放送の垂直同期周波数ってだけで、
PCがそうであるかどうかとは全然関係無いと思うんだがなぁ。

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

>>110
厳密にリフレッシュレートを測定したことはないが
俺は一度、timeGetTime基準による「完全なる60Hz」で
V-SYNC完全シカト描画を行ったが、モニタ60Hz動作時
「前画面と新画面の境界線」がヌルヌルポ下がっていった。

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

>>111
ガッ
それだとリフレッシュレートは60Hzより上という事ですな･･･。

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

これからはデジタルディスプレイでいいんじゃ

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

最近の、書き込んである背景って、どう管理されてるか知ってる？
チップと一枚絵の中間という感じかな？

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

何を指して「管理」といってるのかよく分からんが
2、3人程度で趣味でやるなら難しい事考えずにチャランポランで平気だけどな。
例えば地上オブジェクト配置するときの命名規則とか。その程度だろ。

　1面.dat
　2面.dat
　3面.dat
　4面.dat

とかで、中身はレイヤー別に

　地上オブジェクトの配置情報
　地上静的構造物の配置情報
　背景ビットマップ
　
セコくやればレイヤー機能付きペイントツールさえあれば足りる。

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

s/地上オブジェクト/地上キャラ/

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

絵の話？
書き込んである＝2Dと解釈すると、ケイブだったら1画面くらいの大きさのチップ？を
並べてるんじゃないかなあ。あんまり同じ絵を並べてるようには見えないけど。

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

作画のときにチップをいろんなかたちで並べて、データに落とすときに1枚絵にしてそう。もちろん複数レイヤー

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

今はそういう力業というか、マシンパワーでごり押しみたいなのが平気で出来るように
なったからなぁ・・・。
１６×１６ドットでマップチップを作ってた時代が懐かしい。
まあそれでも、サウンドの容量に比べれば可愛いもんかも知れんが。

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

RPGのレベルアップの意味もそのうち薄まってくるんかな。

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

いやいや。

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

76のヤツって差が50以上開くまで待つんだから不等号逆じゃね？
このままだとprev_time_nul3が初期化されてなければ、
(now = n * 3) + (remain = 0) - (prev_time = 0)になって、
最初の呼び出しで永久ループだし、
ちょっと前にtimeGetTime()で初期化してたらwhile()で待たない。

58 · 04/06/21 19:11

俺の発言で誤解を招いてしまったが、俺はあくまでＢ宗一派。
>>84=76
3倍しているのは誤差蓄積の他に、俺の int time_table[] = { 16, 17, 17 }; のような
ばかテーブルを作成しないためでもあるのでは？
あと誤差蓄積を無視しているのではなく、delta_tが死んでいるので出来ないだけ。
そのうちソース修正する。
>>85=86
ソースupサンクス。参考にします。
>>87
いままでのソース読めば分かると思うがDirectXは使っていない。
> CRT側のリフレッシュレートと同期できない環境
それだからタイマ使うんじゃねーの。
実現は出来る。ある程度のマシン性能以上の環境ではな。
> 数値計算の初歩本
お薦めの本があるなら教えて欲しい。
安ければ洋書でも読む。
> 話の流れ
そういうことだが、拒みもしない。
>>88=89
> リフレッシュレートいじれない人
それが俺。
だから1000msぐらいは精度が出ないと困る。
timeGetTimeも微妙だけどな。
>>101
それはＢ宗だ。
>>111
興味深い。是非詳しく聞かせてほしい。

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

正直もっと一般的な環境を前提に、一般的な環境で開発したほうが良いんじゃ…

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

>>123
だから、なんでDirectX使わないんだ？

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

>>125
Macだからとかじゃない？

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

('∀`)

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

DirectXを使う使わないとかいう話なんか？

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

>>128

>>87の発言

　＞まさか、「CRT側のリフレッシュレートと同期できない環境」で
　＞ノイズレスかつスムーズな2Dゲームプログラムを実現できるとお考えで？

に対して、>>123は

　＞いままでのソース読めば分かると思うがDirectXは使っていない。
　＞それだからタイマ使うんじゃねーの。　
　＞実現は出来る。ある程度のマシン性能以上の環境ではな。
　
と反論しているわけだが、おまえどう思う。

58 · 04/06/21 23:16

お陰様で、だいぶよくなってきた気がする。
明日くらいには誤差修正込みの完全版ソース出せそう。
あと、俺は純粋に1/60secごとに描画したいだけだ。

>>124
「ノイズレスかつスムーズな2Dゲームプログラム」が前提だったから
特殊な環境に依存すると言ったんだが。
文句があるなら>>87にどぞ。
俺の想定環境は PenIII以降, Win9x/NT ぐらいか。
リフレッシュレートは60か75くらいしか確認できないが、それぐらいになら変更できるし大丈夫だろう。
>>125
最も本質的な話題だが、俺に答えられる範囲内ではないな。
まぁ、俺の環境と技術が不足しているから。
そもそもDirectXでリフレッシュレート同期できるんなら、こんな質問していない。
>>126
ソース見てるか？win32依存。
>>127
（´・ω・｀）
>>128
ここの方たちから見るとばかばかしいくらいの質問だからこうなる。
でも、正直WIN32APIの範囲内で答えてほしい。
…って言うとDirectXの構成の話になってしまうので、避けておく。

58 · 04/06/21 23:18

>>129
フォローありがとう。

**踊る大走査線** · 04/06/21 23:20

ぶっちゃけ内部処理300fps最強ですよ。（200fpsくらいでも十分かも）

リフレッシュレートが60Hzだろうが75Hzだろうが85Hzだろうが、
３～６ステップ適宜進行→描画→VSYNC待ちのループだけで、
60Hz完全同期との違いがわからんくらい十分ぬるぬるぽ動くよ。
今のCPUは滅法速いから、ゲームロジックの負荷が数倍になろうが問題にならないし。

Δt可変の方法はリプレイのこと考えると全滅かな。

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

>>132
ガッ
　
うえー。それは3Dゲーム限定の話でないの？いやマジで。（ﾟдﾟ）ﾎﾟｶｰﾝ
にわかに信じられないのでとりあえず確認中。
ちなみに、俺はDirectX7の頃にfpsリミッター解除でD3Dで2D横スクロールとか色々実験したが
流石に2D横スクロールでティアリング誤魔化すのは無理ぽって結論に達したぜ。

この辺は程度問題ということで、気にしなければ大した問題じゃあないという路線なら俺は引き下がる。
　
58の場合、640x480程度の解像度でシステムメモリ→ビデオメモリのBitBlt転送だろう。
ハードウェア支援があっても200fps～300fps安定して出すのは至難と思われ。

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

更新は1秒間に300回で、描画は1秒間にリフレッシュレート回ってことじゃねーの？

300回は50と60の最小公倍数だからコンシューマ用にもピッタリ

**ID:xW89oDgi** · 04/06/22 00:03

最小公倍数（・∀・）ｶﾞｯﾃﾝｶﾞｯﾃﾝｶﾞｯﾃﾝ

58 · 04/06/22 00:08

おかしい、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;
}

**ID:xW89oDgi** · 04/06/22 00:14

>>132
ｺﾞﾒﾝx256。
てーか俺って>>132の書いてること全然読んでないし。
寝ぼけてるので寝る。ごめんあさーせ。

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

素人なのでBoost::timerなんて物があると知らなかったよー
timeGetTimeが1000msまでしか測れなくて悪戦苦闘してたのが馬鹿みたいだ

**138** · 04/06/22 03:27

>>86の方法を使ってみたら、安定して60fps出るようになったのですが、しかし、
>>58のような方法を使ったときよりも、動きがカクカクします。
素人なので原因がよく分からないのですが、Boost::timerの精度が低かったりするのでしょうか？

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

timeGetTimeが1000msまで？
ms単位をDWORDで返すのにそれは無いだろう。

>>86のはSleepの精度の問題かもしれないので、timeBeginPeriod(1)
とかやって見ると良いかもね。
もしくはビジーループに変える。

他にはメッセージループの問題とか色々考えられるかな。

**138** · 04/06/22 03:59

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);

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

>>141
Windowsメッセージはビジーループに入れないで一気に処理
しておく方が良いかも。

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

ありゃ、タブが効いてない…
で、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);

**138=143** · 04/06/22 04:19

>>142
PeekMessageの部分は外に出したり中に入れたり、いろいろ試しましたが、同じ結果だったと思います

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

>>143
そのコードだとt.restart()が良くない。

1フレームの間隔だけを測っていると安定しなくて当然だよ。

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

>>143
clock 関数は、呼び出しプロセスにかかった時間を通知する。

つまり、この用途には使えない。

58 · 04/06/22 20:53

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);// 画面更新
}
}

58 · 04/06/22 22:10

意外と簡単に直った。が、ウインドウを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;
}
上の方のソースとあんまり大差ないな。（´・ω・｀）
まぁ、バグが取れただけ良しとしますか。

**名前は開発中のものです。** · 04/06/22 23:37

ようするにおまいらシューティングゲーム製作技術について
語ってないってことでＯＫだな？

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

OK
スレ違い

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

>>2の関連スレが生きてるんだから、そちらでやったほうが良いかもしれないな。
質問と正答のやりとりで済むならここでもいいんだが。

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

>>106
＞FLASH上で編集した弾幕を自作のエクスポーター
これってどういう環境で作ったんですか？
関連サイトや書籍とかあれば教えて下さい。

後、アニメーションやキャラ配置、その他のデータ出力とかもやってるんですかね？

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

俺も気になるな、それ

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

ABAさんトコで紹介されてた
BulletML対応の弾幕生成FLASHのことじゃないかと思う俺。

86 · 04/06/23 11:35

ああ、boost::timerは機種依存なくて
手っ取り早く浮動小数で時間が返るタイマAPIだから使っただけ（ｗ
boostの中の人はANSI Cのclock関数呼んでるだけだから、精度いいとは思えんです。

**92=87** · 04/06/23 23:06

>>152
http://www.macromedia.com/devnet/subscriptions/
えーと、個人的な感想ですが、あんまオススメできません。
Flash通常版で十分イケます。SWF形式の構造は公になってますので
SWF2●●なコンバータを作るとか、そういう方向でひとつ。
http://www.openswf.org

>>154
別の方です。

**152** · 04/06/24 00:45

ギョエッ。英語かーｗ

ｻﾝｸｽです。
日本語の解説サイトないかググッてみます。
なければ諦めますｗ

プラグイン系のスレって、あんまないですね。
興味ある分野なのですが、、。
ＭＡＸプラグインとかかなり便利らしいけど、日本語解説がないみたいで挫折。

**152** · 04/06/24 01:05

一応少しありました。

多分、SWF形式ってムービーのような構造？
プロジェクトファイル（*.fla？）をコンバートORエクスポートするのがよさげかな？

やっぱ、英語が出来んと駄目か、、鬱

**92=87** · 04/06/24 01:42

>日本語解説がないみたいで挫折

というか正規ユーザーでなければプラグインのテストすら出来ないはずなので
技術的な面で挫折要素はないんですよ。正規ユーザーなら、分厚いマニュアル
入りの小箱が数個ほど届きますから、まずアレと格闘することになります。
API巨大ですがサンプルありますし。デベロッパーも多いのでフォーラムも
充実してますし。DirectXとかOpenGLとかWin32APIを乗り越えてきた人なら
そんなに心配しなくて平気です。
　
Macromediaの製品に関しても同様で、買えば“相応の”サポート情報は
得られますんで・・・（本当か？
英語は避けられないに関しては同意。まぁ、これは慣れる他ないんで。

**92=87（補足）** · 04/06/24 01:47

えーと補足。「お前、割ってるだろ」と言ってるように見えるんで訂正。
挫折するには早すぎるだろ、という趣旨です。

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

Flashの開発環境って結構たかいのね
言語の開発環境並みかよ！

**名前は開発中のものです。** · 04/06/24 23:58

例のシューティング本でてたが・・・ありゃ、シューティングというよりか、
弾本だな。

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

これのこと？
http://cgi32.plala.or.jp/higpen/shtbook/shtbook.shtml

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

それそれ。
プログラミングには詳しい人が書いた本だけど、シューティングゲーム・・・
というかゲームについてはイマイチ分かってない人が書いたっぽい内容だった。

あんな当たり判定じゃ、通り抜けしまくりじゃん！とか。

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

読んでないけど、いろんなゲームの引用してるんでそ？
知らないってことは無いんじゃ…。

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

実際に遊ばせるレベルのものは作ってない感じがする。

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

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