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

**名前は開発中のものです。** · 2007/07/11(水) 08:32:54

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

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

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

過去スレ，関連スレは >>2-3で。

**名前は開発中のものです。** · 2007/10/28(日) 03:11:20

格ゲーもだいぶ廃れたので

**名前は開発中のものです。** · 2007/10/28(日) 09:53:06

>>484
スプライトハードウェアでも、通常はVSYNC待ちの直後に画面を更新してから、
入力処理・ゲーム処理をして次のVSYNCを待つから、元々1フレームの遅延はある。
だから、ダブルバッファなら遅延は一緒。

>>487
全ての環境で同じだけ遅延があるなら、それは最初からそういうゲームシステム
なので問題ない。環境によってマチマチだと問題だが。
今でもゲームハード板とかPCアクション板あたりでは、遅延の話多いよ。

**名前は開発中のものです。** · 2007/10/28(日) 12:06:54

>>489
???
だからVSYNC待ちしたら遅延するって話じゃないの？
ただの解説？

**名前は開発中のものです。** · 2007/10/28(日) 14:31:54

しなかったらしなかったで、今度はティアリングとかで騒ぐくせに

**名前は開発中のものです。** · 2007/10/28(日) 16:58:40

垂直帰線期間内に入力とスプライト位置の更新をして残りは全部ラスタースクロールとか
そういうの作ってた人がタイムスリップしてきたんだよ

**名前は開発中のものです。** · 2007/10/28(日) 18:19:23

FPSは60固定でやりたいから仕方ない

**名前は開発中のものです。** · 2007/10/28(日) 21:07:35

>>492
べつにラスターだろうがおなじだよな？
表示期間中にバックバッファへの描画をするかフロントバッファのスクロール位置ずらすかどうかの差だし

**名前は開発中のものです。** · 2007/11/01(木) 06:08:52

えー。

[ラインバッファ]スプライト位置定義→VSYNC終わり→走査線とともに表示
ダブラ使おうがラスタかけようが変わらん。

[フレームバッファ]スプライト位置定義→VSYNC終わり→裏バッファにスプライト書かれる
→VSYNCはじまり→バッファの表裏フリップ→VSYNC終わり→走査線とともに表バッファ表示

自機の判定が小さくなったのは、フレームバッファ方式化が原因。
ラインバッファより1フレーム遅れるから、時間的に判定が雑になる。

**名前は開発中のものです。** · 2007/11/01(木) 06:16:08

もっともPCのことを頭からはずせば、
シングルバッファでも昔よりまともなハードは作れるし

いっそリフレッシュレート上げてしまうという手も

**名前は開発中のものです。** · 2007/11/01(木) 08:29:20

>>495
VSYNC終わりって言葉として変だろ。それを言うなら、VBLANK終わり。
VSYNCはVBLANKの開始を表すパルス信号、あるいはそれに同期するという意味。

それとラインバッファだろうが、遅延は一緒。
VBLANK始まり→スプライト更新(バッファFlip)→ゲーム処理→(バックバッファ更新)
→次のVBLANK待ち

ティアリングを避けるためにVBLANK中に表示を更新するなら
VSYNC→表示更新→ゲーム処理の流れは変わらない。

VBLANK中の表示更新はレジスタ等に書き込みをするだけで、キャラクタの
実体の移動はゲーム処理で行われるもの。
だから遅延はゲーム処理→それが画面に反映されるまでの時間で、
ダブルバッファとラインバッファでは一緒。

**名前は開発中のものです。** · 2007/11/01(木) 09:07:34

もうおじいさんの昔話は結構ですから奥に引っ込んでてちょうだい

**名前は開発中のものです。** · 2007/11/01(木) 09:18:24

大体スプライトの場合であっても
スプライトのアトリビュートメモリに書いてから
実際に画面に反映されるのは数フレ後なのだが(NDSとかな)

**名前は開発中のものです。** · 2007/11/01(木) 09:43:31

開発暦18年の俺が判定
正解 >484 >495
誤り >489 >494 >497

ラインバッファの場合VBlank中に全ての描画レジスタを更新するのが基本
そして直後の表示期間中に画面に反映される。

ダブルバッファの場合VBlank中にバックバッファへの描画が始まるが
これはVBlank中には終了しなくてもよく、表示期間中も描画を続けられる。
そして完成したバックバッファは次のVSyncでフロントバッファに切り替わる。

結果ダブルバッファだとキー入力が画面に反映されるまでにラインバッファに比べ
1フレーム余計にかかる。

※ダブルバッファの場合30fpsで作ったり、移動処理と描画処理の順が
おかしかった場合、遅延は体感できるほどひどくなる場合があります。

**名前は開発中のものです。** · 2007/11/01(木) 10:03:06

それではVBlank待たないと遅延は発生しないの？

**名前は開発中のものです。** · 2007/11/01(木) 10:12:09

それではVBlank待たないと遅延は発生しないの？

**名前は開発中のものです。** · 2007/11/01(木) 10:13:37

すまｓん

**名前は開発中のものです。** · 2007/11/01(木) 12:29:04

>>500
前半2段落はあってるのになんでダブルバッファがラインバッファに比べて１フレーム遅延するんだ?
同じだろ?

**名前は開発中のものです。** · 2007/11/01(木) 14:25:29

>>500
18年もやっててそれでは才能がないと言わざるを得ない。
スプライトや背景の更新とダブルバッファのFlipが等価な処理。

ゲーム処理1→バックバッファの更新→VSync→Flip→ゲーム処理2→…
ゲーム処理1→VSync→背景＆スプライトの更新→ゲーム処理2→…

どちらもゲーム処理2の最中に1の画面の表示が始まる。

**名前は開発中のものです。** · 2007/11/01(木) 14:49:18

>>499
スルーされてるから突っ込んでおくが嘘はイカンよ。
つか、DSってポリゴンすらラインバッファなのでスプライト機と同じ感覚でポリゴンが出せる。

**名前は開発中のものです。** · 2007/11/01(木) 22:52:56

・Flipでバックバッファに描画済みの絵を切り替える
・Flipでたまった描画パケットをキックしバックバッファに描画開始

どっち？

**名前は開発中のものです。** · 2007/11/01(木) 22:58:05

>>506
んん、そうなのか？
VBlank中にVRAMへの転送とアトリビュートメモリの更新を同時にしたら
VRAMのデータは更新されてるのに位置の更新が遅れているってことがあったのだが…
何か俺が根本的に俺が間違ってたのかも。もう大分前の話で詳細は覚えてない

**名前は開発中のものです。** · 2007/11/01(木) 23:08:57

500です。

確かに>>505　のような処理もできますね。
その場合はもちろんラインバッファと同等です。

ただそれだとCPUとGPUを非同期で動かせない
（CPUの余った時間でしか描画できないし、描画中はCPUが動けない）
ので、ハードウェアをフルに活用するためには選択しないのが常識
だと思っていました。

**名前は開発中のものです。** · 2007/11/01(木) 23:36:39

>>508
キャッシュのフラッシュ忘れとかその辺じゃね？

**名前は開発中のものです。** · 2007/11/01(木) 23:42:09

>>509
キーレスポンスを追求するという考えのゲームなら選択されるんじゃないか？

で、厳密に言えばCPU処理とパケット転送をしている裏でレンダリングをしているから
非同期で動いていると思うんだが。

**名前は開発中のものです。** · 2007/11/02(金) 00:00:02

>>509
遅延をなくす場合の最優先のプログラムの話でしょ
それに２DSTGならマシンパワーが足りないなんてのは古いのを除いてまずないし・・・

スループット重視したいのならトリプルバッファオススメ

**名前は開発中のものです。** · 2007/11/02(金) 00:14:23

遅延は最優先事項としてできる限り小さくしたい

**名前は開発中のものです。** · 2007/11/02(金) 00:23:45

1とか2、3フレーム遅延しても和漢ねーよ。
そんな意味不明なこだわり見せてないでさっさと完成させろよ。

**名前は開発中のものです。** · 2007/11/02(金) 00:34:32

それだけこだわれる知識もってるくらいだから実績あるんじゃないの？

俺なんか何を言ってるのかほとんどわかんねーよ。
何をもめてるのか、が、かろうじて解る程度。

**名前は開発中のものです。** · 2007/11/02(金) 00:34:45

>>512
>それに２DSTGならマシンパワーが足りないなんてのは古いのを除いてまずないし・・・
確かにCPUパワーはすごいけど、fx5200程度だと
ピクセルシェーダ使って派手な爆発させただけで描画に16ms消費するよ。

あと遅延に関してだけど、60フレで作った場合、ダブルバッファによって発生した遅延は
そんなに神経質になる必要はないと思う。(極々一部のプレイヤーを除く)
ちゃんと作ってあっても遅延が体感できる場合、ゲームパッドのドライバやハードウェア、ディスプレイ、
Windowsのパッド情報の更新タイミングの方が問題な気がする。＜この辺は詳しくないです。

360の無線コントローラーの遅延は体感できる。

**名前は開発中のものです。** · 2007/11/02(金) 00:36:27

どこのスレか忘れたが、住人が遅延のテストしてて1フレの差を
みんな判ったって覚えがあるんだがな。だいたい3フレ遅れたら流石にわかるだろ。

意味不明のこだわりってこたないだろ。もしかして技術的な話以外に
シューティングには大して興味ないとか？

**名前は開発中のものです。** · 2007/11/02(金) 00:46:34

結局具体的にはどう実装すればいいんでしょうか。
解る人が居る以上最善な解にしたいんですが、自分は鈍感なんで気づけないかもしれないし。

**名前は開発中のものです。** · 2007/11/02(金) 00:48:15

そら遅延だけに意識を手中させるようなテストプログラムならわかるかもな。
でも実際のゲームでは50msなんてわかんないから。

**名前は開発中のものです。** · 2007/11/02(金) 00:59:46

弾幕シュー作るなら特に遅延は気になるよ。低速で自機を凝視して目視で
避けるゲームだから。高速弾切り返し系はあまり自機見ないので実は意外と気にならない。

**名前は開発中のものです。** · 2007/11/02(金) 01:40:31

>>516
負荷のかからない描画方法を選ぶだけ
もしくは選択できるように

重視するのがグラフィックなのか遅延なのか選択は自由なんだから好きに汁

俺的には915、できれば945で大幅に性能増えたから開発者の負担はかなり下がったと思ってる
やっぱりノートPCがほとんどの現在、統合チップセットは無視できんからね
デスクトップでもかなりの割合でUMAだし

**名前は開発中のものです。** · 2007/11/02(金) 01:47:55

今のマシンで秒間60フレームならどーやっても遅れますので
古いマシンからの移植でもない限り気にすんな。

セガサターンとプレステが出た頃のネタ、
あるいはTOWNSとX68Kの間の抗争をぶり返してるだけです。

差なんてねえよって自演で言ってるのは、その後から始めた知ったか君。

**名前は開発中のものです。** · 2007/11/02(金) 09:11:02

>>520
断言するが、2、3フレームなら気にならない。

人間には環境適応能力もある。
50msの世界は気づかないか、または勝手に感覚を適応させる。

50msなんて神経の伝達速度を超えてるんだから。

**名前は開発中のものです。** · 2007/11/02(金) 09:52:50

VSync同期させない2DSTGでも気にならないプログラマと許せないプログラマがいるわけだが。

**名前は開発中のものです。** · 2007/11/02(金) 10:59:24

ティアリングもイヤだけど、VSync同期するとあからさまに遅延が判る。
回避方法あるなら教えてほし。遅延するくらいならティアリングのがましだけど…。

**名前は開発中のものです。** · 2007/11/02(金) 13:15:01

>>525
NVIDIAの場合ドライバで最大3フレーム遅延するようになっているから、
それが原因の場合はPresentの前でバックバッファをLock-Unlockする。

**名前は開発中のものです。** · 2007/11/02(金) 13:38:16

DirectX9なら、IDirect3DQuery9を使う方がいいかも。

**名前は開発中のものです。** · 2007/11/02(金) 14:59:30

実際のとこ、PCだとどこで遅延してんのか判らんから何フレ遅れてるのかも
まったく判らんね。だからプログラムでは出来る限り減らしておきたいって
ことなんだけど。

**名前は開発中のものです。** · 2007/11/02(金) 23:58:34

>517
以前このスレかな？入力遅延をさせるテストプログラムがあった気がする。
大体３フレぐらいから遅延を感じる人が出た気がするが、
１フレはほとんどわかんなかったぞ。

**名前は開発中のものです。** · 2007/11/04(日) 03:47:41

入力遅延についてはそもそもボタン類の物理的構造によっても変わるよな
ソフト的に遅延が無いといわれているものでも、実際にはみんな一瞬早めに押してるんだよ
人間ってのはそのぐらいの融通は利くようになってるんだから遅延遅延と騒ぐよりも実際にやってみんとわからんよ

**名前は開発中のものです。** · 2007/11/09(金) 18:24:20

遅延をｼｽﾃﾑに活かせないかな…

**名前は開発中のものです。** · 2007/11/09(金) 18:49:07

やだよそんなの

**名前は開発中のものです。** · 2007/11/09(金) 20:02:29

遅延をシステム的に活かして成功した例といえばグラディウスのオプション

**名前は開発中のものです。** · 2007/11/09(金) 21:40:40

そら動きが結果的に同じだけで活かしたわけじゃねえし

**名前は開発中のものです。** · 2007/11/09(金) 21:54:58

ドラキュラのムチのように押してから発動するまでにタメがある攻撃なら活かしてる？
狙って撃たなきゃいけないようなシステムになるのかな
撃ちまくり爽快感の方が好きだからどうでもいいけど

**名前は開発中のものです。** · 2007/11/09(金) 22:09:38

昔のマルチFPSはクソ遅い回線の遅延もプログラムで何とかしたのに。
シューティングの奴らはいつも他人が悪い環境が悪い言ってんだな。
FPS論争のときもリフレッシュレートを60Hz以外に設定している奴が悪いって流れになるし。

**名前は開発中のものです。** · 2007/11/09(金) 22:25:03

60Hz以外が悪いとは言わんけど、
60FPS前提で作りたい場合は環境の切捨ては仕方ないな

**名前は開発中のものです。** · 2007/11/09(金) 23:02:34

昔ながらの2Dシューはプレイヤー側でも60Hzを望む人が居たりするからな
FPSとは違う要望があるジャンルだから比べてもしょうがないよ
全キャラ3Dならレート可変でもいいんだろうけど、操作感とかどうなんだろ

**名前は開発中のものです。** · 2007/11/10(土) 00:45:31

>>536
2DSTGはリフレッシュレートがゲームに与える影響がでかすぎるんだよ
FPSというか3Dゲームはリフレッシュレートが可変でもプレイに耐えるが
平面ベクトルや領域のギリギリのやりとりをする2DSTGだと可変になっただけで大惨事だ。
理屈の上では滑らかに補完できてるはずが実際動かしてみたらガタガタだったとかよくあるし。

**名前は開発中のものです。** · 2007/11/10(土) 01:15:30

そもそも絵をドット絵など2Dアニメで描いてる場合レート可変でやるには
無理がある

**名前は開発中のものです。** · 2007/11/10(土) 01:19:58

>>539
tonyu使ってる俺にとって悩みの種なんだよな
Ｃ言語に移りたいけどなかなか理解できない

**名前は開発中のものです。** · 2007/11/11(日) 02:07:28

なんか最近のPCだとタイマーが安定しないというか
環境によっていろいろ変わるようなんだが
マルチコアとかその辺の影響だろうか

**名前は開発中のものです。** · 2007/11/11(日) 02:47:42

タイマがQueryPerformanceCounterのことなら、AMDのマルチコアのシステムで
CnQ使ってたりすると問題があるよ。KB896256で修正される。

**名前は開発中のものです。** · 2007/11/11(日) 10:24:52

QueryPerformanceCounterがマルチコア環境で可笑しくなるのは仕様みたいなもんだろ。
アフィニティマスクでクロック取得先のコアを指定すればちゃんと動く。

**名前は開発中のものです。** · 2007/11/11(日) 10:45:45

仕様と思えるくらいにバグが蔓延しちゃってるのが問題なのでは

**名前は開発中のものです。** · 2007/11/11(日) 11:00:18

CPUクロックとってる場合があるんだからコアが複数あったら
どこコアから取得するか指定できないほうがまずかろ。

確かにデフォルトで1番目のコアに固定されてないのは問題だが。

**名前は開発中のものです。** · 2007/11/11(日) 13:00:55

QueryPerformanceCounter使ってないな
CPUクロックはなんだか安定感がなさそうなふいんき（なぜか変換(ry で

**名前は開発中のものです。** · 2007/11/11(日) 15:19:34

昔のゲームはマルチコアだとおかしくなる
HTでもわりとおかしくなってたけど
・超連射とか

最近出たソフトならまず対応してるだろ
してないのなら作者が悪いだけ
デュアルコアの確認はしていませんとかせめて開発環境を公開するべきだ

**542** · 2007/11/11(日) 15:59:09

レスどうもっす。やっぱいろいろあるのね。
俺はメイン絵描きでプログラムはHSPしか出来ないんで
制御はどうにもプラグイン頼みになっちまうのですが、
やっぱ内部的に何やってるかぐらい知らんとダメですな…。
皆さんいろいろありがとう。

ちなみに超連射はうちのクアッド機では平気な感じでした。
会社のHT機ではおかしくなったけどｗ

**名前は開発中のものです。** · 2007/11/11(日) 20:12:18

超連射はPen4HTとIntelCoreでおかしくなってるのを確認
プロセス探してCPU固定割付すると大丈夫

まぁサウンドだけおかしいんだけどね
68soundがまったくマルチスレッドを考慮していない

**名前は開発中のものです。** · 2007/11/11(日) 20:15:04

>>550
あーそれ互換モードで直るんじゃないかな

**名前は開発中のものです。** · 2007/11/11(日) 20:18:17

自レス
要するにマルチスレッドに対応してないOSの互換モードに
してやればいいって事か。

**名前は開発中のものです。** · 2007/11/11(日) 20:24:12

>>551
全ての互換モード試したけどなおらんかったよ
2000のときはたしか発病しなかった気がする

**名前は開発中のものです。** · 2007/11/11(日) 20:27:06

あれスマン。ダメだったか。
うちのQ6600だと非互換モードとw2kモード以外は正常に鳴るんだけど…。

**名前は開発中のものです。** · 2007/11/12(月) 15:04:19

Vistaのサウンドドライバがクソとかそういう話なん名じゃねーの？

**名前は開発中のものです。** · 2007/11/13(火) 00:38:01

すべてXPだし、オンボードのサウンドだよ
あとAudigyも同じなのも確認済

理由はXSoundDLLの仕組み

実際2世代古い超連射はどのOSでも問題ない
最新版がやばいというのはよくでてくるし常識かと

**名前は開発中のものです。** · 2007/11/15(木) 00:45:54

そろそろモニタをCRTから液晶に換えようと思うんだが
24インチワイドとか使ってる人いる？
ちょっと調べてみたところ
大きいのは応答速度が遅いらしいんだが・・・

**名前は開発中のものです。** · 2007/11/15(木) 00:50:22

http://pc.watch.impress.co.jp/docs/2007/1114/mitsubishi.htm

**名前は開発中のものです。** · 2007/11/15(木) 01:30:40

最近のワイドパネルは動画性能重視なんでそこそこ応答性は悪くないんじゃない。
韓国製VAパネルが多くてチカチカギラギラして目が疲れやすいけど…。
ただ応答性悪くないといってもCRTに対してはまったく勝負にならない。

個人的にワイドでお勧めはNECのLCD2690WUXiなんだけどゲロ高い。
ttp://www.nec-display.com/products/display/model/lcd2690wuxi/index.htm

**名前は開発中のものです。** · 2007/11/15(木) 01:32:28

すまんなぜかアドレスの最後が削れた。
ttp://www.nec-display.com/products/display/model/lcd2690wuxi/index.html

**名前は開発中のものです。** · 2007/11/15(木) 21:50:46

20マソ使ってイイなら
ワコムのでっかい液タブ買っちまいそう

**名前は開発中のものです。** · 2007/11/15(木) 22:51:57

タブレットはA5くらいがちょうどよくね

**名前は開発中のものです。** · 2007/11/15(木) 22:55:54

三角関数のテーブル化って本当に高速化されるのか？
弾が1000以上出る弾幕系2DSTG作ってて今は65535分割テーブル使ってるが
標準関数に戻しても殆ど差が無かった
標準関数で統一しようかなぁ

**名前は開発中のものです。** · 2007/11/15(木) 22:58:01

今はメモリアクセスを以下に減らすかが勝負だから
やり方次第で計算したほうが速い

**名前は開発中のものです。** · 2007/11/15(木) 23:29:20

最近のCPUなら1000程度の三角関数の計算など
どちらでやっても誤差程度ではないのか？

**名前は開発中のものです。** · 2007/11/15(木) 23:35:55

テーブルはsin/cosが遅かった時代の技術。
今でも携帯機とかで使えない場合には持つこともあるけど。

VCなら組み込み関数にしちゃうと速度的なペナルティはほぼないね。

**名前は開発中のものです。** · 2007/11/15(木) 23:36:15

でもゲーム会社にたまに生き残ってるだろ。固定少数や三角関数テーブルに血道をあげてる厄介な奴。
男の生き様なんだよ。

**名前は開発中のものです。** · 2007/11/15(木) 23:42:57

π==3.14にするためにテーブルにした
逆関数はしらん

**名前は開発中のものです。** · 2007/11/16(金) 00:50:25

テイラー展開の三角関数つくっておいてゲームが破綻しない精度まで
じょじょに項数へらしていくってのはどうよ

**名前は開発中のものです。** · 2007/11/16(金) 01:17:21

テーブルだろうがなんだろうがCPUでやろうとして悩むのがそもそもアホなんじゃねえの。
多くの弾は直進なんだから毎フレーム三角関数で求める必要ないし
スプライトの回転はシェーダですりゃいい。　
XYZが回転中心。法線のXYが頂点へのオフセットでZが回転のようなフォーマットなら
弾1000個 6000頂点をDrawPrimitive1回でできる。

**名前は開発中のものです。** · 2007/11/16(金) 07:25:58

>>569
前にそれやってる人みかけたなー
テーブルより遅いが、Sin関数など呼ぶより速いという
^C氏の記事でもあった気がする・・・

**名前は開発中のものです。** · 2007/11/16(金) 15:40:45

>テイラー展開
どうよと思って調べてみたけどこりゃだめだね
なんというか項を重ねるごとに-∞から∞までの波全体の形が整っていくのかと思ったら
原点から左右に紡いでくみたいに形ができていくのね
近似自体はn=2までで十分な品質になるけど-PI/2からPI/2までの範囲だけ
θをその編み上がってる狭い範囲にもってくるmodにコストがかかっちゃう

**名前は開発中のものです。** · 2007/11/16(金) 16:09:24

よくわからんけど知らなくてもよさそうだ

**名前は開発中のものです。** · 2007/11/16(金) 21:42:13

いまどき固定小数でシュー作ってるとこってケイブくらいなモンだろ

**名前は開発中のものです。** · 2007/11/16(金) 22:00:03

ケイブがやってんならそれで良いんじゃね
とか思ってしまうわけで

**名前は開発中のものです。** · 2007/11/16(金) 23:19:14

一線をリタイアしたロートルプログラマが携帯でそういうのをやってんじゃないの

**名前は開発中のものです。** · 2007/11/16(金) 23:44:37

別に何を使おうがちゃんとしてるならいいんじゃないの？

**名前は開発中のものです。** · 2007/11/17(土) 14:40:50

俺は整数でやってるんだが・・・

**名前は開発中のものです。** · 2007/11/17(土) 16:17:02

俺は素数でやってるぜ！

**名前は開発中のものです。** · 2007/11/17(土) 17:06:34

3Dでマトリックス演算とか全部整数なのか？

**名前は開発中のものです。** · 2007/11/17(土) 17:38:58

出来なくもないだろうけどやる必要もないと思うよ

**名前は開発中のものです。** · 2007/11/17(土) 17:50:59

まぁ必須ではないな
2DSTGならなおさら

**名前は開発中のものです。** · 2007/11/17(土) 18:57:25

DSとかPSPなら固定少数は主流だったりする？

**名前は開発中のものです。** · 2007/11/17(土) 19:14:52

DSはしらんがPSPはfloat普通に使う。

**名前は開発中のものです。** · 2007/11/17(土) 20:58:46

角度がアナログなら計算しちまったほうがいいかもだけど
グラディウスの敵弾みたいに16方向とか32方向とかの限られた方向しか使わない仕様だと
三角関数テーブル（と言っても行数はごく少ない）が良さげ？

**名前は開発中のものです。** · 2007/11/17(土) 21:35:55

どっちを選んでも実際のゲームで変化が見えないなら趣味の問題。

最適化に凝る同僚に面倒な規約を強要されるが、これ無意味なんじゃねーのと
うんざりする経験の有無で、汎用性や分かりやすさを重視するかどうか
分かれるかもしれない。

**名前は開発中のものです。** · 2007/11/17(土) 21:59:33

ゲームを作ることにおいて、技術的な追求を重視するかどうかってことかもな