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

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

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

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

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

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

25 · 04/06/18 15:22

>>37
濃密な弾幕の中から「回廊」を見つけ出し「すり抜け計画表」を立てるのは
なかなか骨が折れると思うよ。最初の頃は明らかに行き止まりの「死の回廊」を
見つけ出して得意げに突っ込んでいくから（苦笑
探索ステップに上限を設けるので調整によってはヤケッパチ行動になりやすい。

25 · 04/06/18 15:25

ｺﾞﾒ。補足すると上記の方法論は厳密には弾除けとは別の部分です。
大局的な振る舞いを決定するためのルーチンです。ボードゲーム的で
面白いよ。

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

>>34
普通の偏差撃ち（相手が等速直線運動を続けるという前提のやつ）
でない場合の話か。その辺になると予想（博打）撃ちの世界に入っちゃうんだよね。
＃相手が回避できるエリア（円）に満遍なく撒く必殺射撃は除くｗ
俺がやったことあるのは、相手の回避方向（の癖）を記録してフィードバックする
という単純な方法。たぶん、発展させれば相手の回避曲線まで記録するカンジ
になるんだと思われ。まぁ、STGはモデルが単純化されまくってるからサンプリング
できる要素も少ないし。比較的組みやすいのでは。

>>38
＞明らかに行き止まりの「死の回廊」を
＞見つけ出して得意げに突っ込んでいく

ﾜﾛﾀ

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

縦シューつくってるんだけど、パワーアップ削ろうか悩んでる。
パワーアップあってもあんま意味ないんだよな。
死んでもその場復活でパワーアップアイテム拾ってほぼ元通りになるし…。

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

パワーアップが出ると「ﾊﾟﾊﾟﾊﾟﾊﾟﾜｰｱｯﾌﾟ」が聞ける！

それだけだけど

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

ﾊﾟﾊﾟﾊﾟﾊﾟｳｧｱｯｯ（・∀・）ｶﾞｲｼﾞﾝｻｰﾝ

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

最初からフルパワー状態で、やられてもパワーダウンしない方がいい
攻撃が激しい終盤でやられて、最弱な状態からプレイ汁というのは酷だ
フリーや同人、アーケードでパワーアップ制にしている所は猛省して欲しい

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

グラディウスとかみたいにフルパワーノーミス前提で作られてるならいいけど
最近の一般人にはノーミスクリアが難しい弾幕シューだとあんまり意味ない気がする
死んですぐにパワーアップアイテム出るならそもそもパワーダウンしなきゃいいし
あとパワーアップなしなら敵の体力の調整をしやすいって利点もあるな

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

ふと思いついた。
空中でうろついてるパワーアップアイテムが弾を防いだら面白そうだ。
何十発か当たると壊れるようにして、すぐ取るかぎりぎりまで盾にするかのジレンマが。
バランス取りは大変そうだけどな。

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

最近のケイブとかのパワーアップって単に序盤の弱い状態が強くなるという満足感を
得るための演出なんじゃない？　やられても２，３個アイテム出るし。

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

パワーアップの効果が微々たるものでも、自機の攻撃の見た目の変化がちょっとした楽しみになったりはする
弱い装備でやれることが少ない状態でプレイヤーをシステムに慣れさせ、
本来の複雑なシステムへパワーアップで段階的に発展させてゆく、という方向もある

作りたいゲームの方向によってパワーアップの要不要は大きく変わるし、作っている間でも変わるだろう

シルバーガン、斑鳩、ボーダーダウン…
単純パワーアップを廃したシステムがわかりやすいのって他に何があるかな

>>46
ギミック系にならさほどバランス気にせず取り入れられるかもね

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

式神2もパワーアップ無いよ
ケツイも無いに等しい(死んでも即時ﾊﾟﾊﾟﾊﾟﾊﾟｳｱｯだから)

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

システムがわかりやすかどうかは疑問だが、同人ならＯＯＨかな
最初から特殊兵器てんこ盛り

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

最近の縦だと、俺が知ってる範囲ではアーケードSTGでもパワーアップに
意味があるなと思えるのって無いんだよなあ…。

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

パワーアップって昔はゲームを易しく（有利に）するフィーチャーだったけど、
それだと上手い人ほど有利になってしまう、というジレンマをなんとかしようと
した結果、事実上パワーアップの意味がなくなったんだろうな。

ちょっと前は、パワーアップすると難易度が上がるので、１段階で止めとけとか。

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

チマチマとした攻撃力で雑魚のｼｮﾎﾞｲ攻撃にも恐々としながら
避けてかわして耐えに耐えてやっとこパワーアップし、
アリンコをゾウさんが踏み潰すがごとく、さっきまで必死にかわしてた
雑魚を一掃できたりするところに爽快感がある。気持ちイイのれす。
これパワーアップの醍醐味なり。
破壊力があがることで
ゲーム性は低下する。よってすくなからず難易度はあげる。これ定石。
しかし雷電はこれどうなのかね・・

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

>>53
なぜ雷電がここで出てくるのかわからんけど、少なくとも最近のゲームは
最初ヌルいのであまりそういう感じしないんだけどな…。
後半は死んでもﾊﾟﾊﾟﾊﾟﾊﾟｳｧｱｯｯだし。だからこそパワーアップシステム導入の
是非を考えてるんだけど。

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

ダライアスとか延々とパワーアップしていくやつは事実上残機無用
だったと思うけど、続編作る上で問題にはならなかったのかな？

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

初代はショットでもまだミサイル＞レーザー＞ウェーブ等とあって
パワーアップの意味があったけど、IIなんかは中盤で死んだら最後までいっても
フルパワーにならないというシステムだったな。
あんま深く考えてないと思われ。

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

死んだらパワーが思いっきり奪われるということで、
上級者に刺激を与えているのではないかと。

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

いまさらな話題だが聞いてくれ。

俺の方法はＢ宗一派に入ると思うのだが、
int time_table[] = { 16, 17, 17 };　のようなテーブルを用意して、
タイマーを調べて delta_t >= time_table[count] のときに画面を更新している。

これと同じような方法を使っている例は見たことがないのだが、
２Ｄゲーを作る場合には、この方法でもいいのか？

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

なんというかそれは非常にレベルの低い解法だな。
ぴったり60fpsにしたいというならもっと良い方法がある

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

サンクロとかボスで死ぬと思いっきり萎えたな。
最近はその辺に気を使ってるのかな。＞その場復活のアイテム

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

>>58
逝ッテヨシ。googleヲ用イテ自己解決セヨ。義務。

キーワード：

サンプリング周波数
ナイキスト周波数
aliasing-error
固定小数点演算
bresenham's algorithm
マルチスッドレ

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

嘘。逝かなくて（・∀・）ｲｲ
int time_table[] = { 16, 17, 17 };　　←下駄を履かせるとｲｲ
あとはスクロールのガタツキを改善するための工夫をすればｲｲ。

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

ぶっちゃけ浮動小数点でやってる俺はまんどくさすぎな人間

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

フルスクリーン等の環境ならほぼ確実にV-SYNC待ちが入るので
誤差蓄積は無いし、問題ないのでは。

**64訂正** · 04/06/20 00:55

V-SYNC待ちを指定する場合は誤差蓄積を容易く回避できるし。

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

>>57
上手くなってきて稼ぎとか始めた場合や、
普段死なないところでミスしたら捨てゲーすると思う…。

**名前は開発中のものです。** · 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の書いてること全然読んでないし。
寝ぼけてるので寝る。ごめんあさーせ。

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

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