Windowsゲームプログラミング　質問スレ

うゆ ◆vvvK3Fcqdg · 2008/11/06(木) 21:28:45

※回答する人も、質問する人も必ず読んでください

【回答してくださる方】
・　できるだけ優しく質問に答えてあげてください。
・　優しく教えるのが嫌でしたら、解決するためのヒントだけでも結構です。
　「ググれ」以外の回答でおながいします。
・　神ですら理解不能な質問は無視して下さい。

【質問する香具師】
・　どんな事で躓いているのか明確にしる。
・　長くならないなら躓いている部分のコードを晒してみれ。
・　解決した場合、お礼を言うのは当然だが、何をどうしたら解決したかを明確に書け。

**名前は開発中のものです。** · 2008/11/06(木) 21:30:16

　　　　　　　／　　／/　＼｀ー　　ヾ　＼　へｰ-､　　｀二ｰ-､
　　　　　／　　 /　ハ「　　ヽ､　　､　　　　＼＼へ　　｀ヽゝ
　　　　／ノ　/　/´ 　　＼　　　＼　ヽ　　ヽ､ヽ　＼＼　｝ }
　　／イ　 /　/　/ ,|　ヽヘ、　　ヽ　 } ﾍ　 l　ヽト､　＼イﾉ
　 ,/　/　　/　/　 l　| l　　ヽ､＼　　}_ｪl,,ｭ_l_　 l　ﾊ l　＼　｀ﾞヽ
　/　/　 / l　 l 　 l　|　l　　ﾄ､＼_ヽ´lノ　イ　｀/l _lﾍ_l_　　ヽヘ　＼
,/　 l　 /　l ｌ　ｌ　　l　| ,.k　　| ｀ｰ-ゝｿ r _,.= ._ 　ｿyﾊヽ｀Ｙ　｝ヽ､　｝､
|　　l　 l　 l l l　l　ﾍイ　ゝノ　　　　　≠"￣｀ﾞ　 |l　l人｝　l　 l　｝/丿
|　i　　 |　ﾄﾍゝﾄ､ rﾒ　r _二_　　　　　　　〃〃　|l 　l lｲ　/　/ ／
|　l　　 l　 l ＼ｊ､ゝｨ'､　≠￣｀　　丶 . - =y､　ノj}　l l | ∧{　/
ﾍﾊ　､l 　l　　/ /|ﾊ　′〃　　,　´　　　　l　　　ﾊﾉ lリ　lﾍ（
　　ﾄイl　　l　｛八l| ﾍゝ　　　く　　　　　　/　　 // / ィ l丿　Ｙ　　　>>1　乙♪
　　　 | l　　ｌ　l＼|　l "､　　　　丶._　　／　／ィｲ´ﾉノ
　　　 | 　ﾍヽハルｧl ヽヘ、　　　　￣　　／ |从/
　　　 l　　ヘＹ､ヽ_ﾙ‐-､廴_≧＝=ｪ-､-イ　　|
　　　　∨ﾍ　ト'／ ‐､: : l｀ヽ二トﾐーﾆ._二　　 |　 _＿
　　　　　＼ヘﾞ/　 : : :＼: l　　　　＼　｀ﾞ´￣~￣. :／
　　　　　　｀ﾞ/　 : : : : : : : l　　＼　　＼ .,,_.: : : : : /
　　　　　　 /´ : : : : : : : : : |　ヽ、ヽ　　　ー＝: : /｀ｰ--‐､
　　　　／／: : : : : : : : : :l　　＼　 /　　　　イ｀)＼: : : }
　　　／ﾞ／: : : : : : : /l: : : : :|　　　 ∨　　　　　　　メ､ﾍ : :|
　／　　　 : : : : : : :）: }: : : /　　　　　　　　　　 /´/ヘハ: :l
‐'´　　　　: : : : : : : : : : l: /　　　　　　　　　　　l　 lο: ＼ : {
　　　　　: : : : : : : : : : : : l　　　　　　　　 |　 |:. :.　　ﾞl: ｀l
＼　　　 : : : : : : : : : : : : :{　　　　　　　　 l　 l:. :.　　| : : ＼
／＼　: : : : : : : : : : : : : : :|　　　　　　　　　　　＼＼:. . / : : : : |

**名前は開発中のものです。** · 2008/11/06(木) 21:45:18

>>1-2

**名前は開発中のものです。** · 2008/11/07(金) 11:26:17

自演禁止

**名前は開発中のものです。** · 2008/11/08(土) 02:44:21

簡単なアクションゲームだったら、経験から言って制御文、構造体(自己参照構造体含む。これ重要。)、
グラフィックの表示まで分かれば十分作れると思う。
まあ、本気で勉強すれば半年で、物分りの悪い人でも1年やればできると思うよ。
多分、以下のソースがなにやろうとしてるか分かれば制御文については大丈夫だと思う。
(もちろん実行しないで。2分ぐらいで作ったんでscanf使っててスマソ)

#include<stdio.h>

void main(void)
{
　　int a,b,i,j
　　a=1;
　　b=0;
　　i=0;
　　scanf("%d",&j);
　　while(i<j)
　　{
　　　　switch(i%2)
　　　　{
　　　　　　case 0:
　　　　　　　　a+=b;
　　　　　　　　printf("%d\n",a);
　　　　　　　　i++;
　　　　　　　　break;
　　　　　　case 1:
　　　　　　　　b+=a;
　　　　　　　　printf("%d\n",b);
　　　　　　　　i++;
　　　　　　　　break;
　　　　}
　　}
}

**名前は開発中のものです。** · 2008/11/08(土) 02:46:36

二次元のマップって普通１次元配列でするよね？

X方向120、Y方向100のマップがあったら

$define MAPX 120
$define MAPY 100
$define MAP_SIZE MAPX*MAPY

int main(void) {

int map[MAP_SIZE];
int x=0,Y=0;

for(i=0;i<MAP_SIZE;i++) map[i]=0;
// もし X:54 Y:33 の位置に1を代入したければ
x=54; y=33;
map[x+(y*MAPX)]=1;
}

でいいんだよね？？
２次元使ったほうがいいかいな？

76 名前：名前は開発中のものです。投稿日：02/08/11 23:35 ID:YyqnVN0I
>>73
サイズが大きかったり可変長だったりすると配列ではなくalloc系で取得する
ことになるだろうし、1次元のほうがいいとおもう。

77 名前：名前は開発中のものです。投稿日：02/08/12 14:35 ID:???
>>76
callocだと0クリアしてくれるから便利だよな

**名前は開発中のものです。** · 2008/11/08(土) 02:51:52

C言語でアクションゲームが作りたい
http://pc11.2ch.net/test/read.cgi/gamedev/1020417733/
110 名前：名前は開発中のものです。投稿日：03/05/29 11:44 ID:xadUaM2+
まともだよね
Cがテーマだったりすると厨房は書きこまないのかな

**名前は開発中のものです。** · 2008/11/08(土) 02:58:07

>>6
2次元のデータを1次元配列で管理しようとするのは、
俺みたいな昔の貧乏性のプログラマだけでいい。
斜め移動でも座標計算1回で済むとか、そんな貧乏臭い発想。

コンパイル時にサイズ不定でも、簡単なラッパ作ればいい。

2次元のものは2次元のまま扱った方が、デバッグもしやすい。

**名前は開発中のものです。** · 2008/11/08(土) 09:53:33

左右がつながってるマップだと境界のこと考えなくて済むしな。

『延々と西に向かってたら、いつのまにか北極に立っていた』
な…、何をいっているのかわからねーと思うが(ry

**名前は開発中のものです。** · 2008/11/10(月) 07:44:57

>>8
１次元でも２次元でもバイナリ的には同じじゃん。
ただ表記方法が異なるだけ。
アクセススピードも同じだから、好きな方使えばいい。

**名前は開発中のものです。** · 2008/11/10(月) 18:09:32

記述的に分かりやすいのは多次元にする方だと思う。
多次元のメモリの確保、開放は少しややこしいけど、
ライブラリとして4次元ぐらいまで作っておけば便利。

**名前は開発中のものです。** · 2008/11/11(火) 07:30:30

>>8
日本語わかる？

**名前は開発中のものです。** · 2008/11/11(火) 09:46:35

ワカリマセーン、ニホンゴムツカシーネ！

**名前は開発中のものです。** · 2008/11/11(火) 22:02:10

ブロック崩しを作ろうとしているのですが、
ブロックとの当たり判定でボールがブロックとぶつかった際、本来跳ね返らなければいけないのに
時々跳ね返らず貫通して進んでしまうことが起きてしまいます、貫通弾はまだ書いてないのに……
どうしたらいいのでしょうか
言語は基本Ｃ、クラスとか途中で変数宣言とかちょっとだけＣ++入ってるかも、DxLibを使用しています

肝心の当たり判定の部分のソース
for(int i=0;i<BlockX;i++){
　for(int s=0;s<BlockY;s++){
　　if(BlockFlag[i][s]){
　　　if(ShellX>=LeftEdge+35*i-ShellR && ShellX<=LeftEdge+35*(i+1)+ShellR){ //X範囲の判定
　　　　if(ShellY>=UpEdge+20*s-ShellR && ShellY<=UpEdge+20*(s+1)+ShellR){ //Y範囲の判定
　　　　　BlockFlag[i][s]=0;
　　　　　ShellVX*=(-1);
　　　　　ShellVY*=(-1);
　　　　}
　　　}
　　}
　}
}

**名前は開発中のものです。** · 2008/11/11(火) 22:04:00

主な変数説明
・BlockX、BlockY　：ブロックがｘ･ｙ軸に最大いくつ並んでいるか
・BlockFlag[][]　：ブロックが存在しているかいないか、０以外で存在
・ShellX、ShellY　：弾のｘ･ｙ座標
・ShellR　：弾の半径
・LeftEdge､UpEdge　：ブロック崩しの画面の左端、上端の位置
・ShellVX、ShellVY　：弾のｘ･ｙ速度

当たっているのが縦からなのか、横からなのかの判定がどうにもわからなかったので
当たったらｘ･ｙ速度両方反転するようにしてしまっています
よければその判定方法も教えてください
宜しくお願いします

**名前は開発中のものです。** · 2008/11/11(火) 22:07:21

移動前と移動後の間も含めて接触判定をするだけ

**名前は開発中のものです。** · 2008/11/11(火) 23:33:50

>>16
移動前と移動後の間も含めて接触判定……って
いまいちピンと来ない、どういうことでしょうか？

**名前は開発中のものです。** · 2008/11/12(水) 01:01:19

>>17
ボールとブロックの距離が、
ボールの（1 フレームの）移動距離よりも短いとき、
ボールはブロックに衝突することなくすり抜けしまう。
対処方法として、
ボールの移動前後を結ぶ線分との交差判定を行う
ことが挙げられる。

**名前は開発中のものです。** · 2008/11/12(水) 06:00:58

>>15
> ShellVX*=(-1);
同時に2つのブロックに接触すると元に戻りそうな嫌なコードだ

**名前は開発中のものです。** · 2008/11/12(水) 10:40:33

>>14
>>19でも指摘されてるけど、２つのブロックに同時に触れた場合は
移動方向が元に戻るから貫通するよ。
だから「ShellVY*=(-1);」の後に「break;」を入れれば
とりあえず貫通するバグは無くなる。

でもそもそも判定ロジックが間違ってるので、全部書き直さなきゃダメ。

当たった部分が縦の面か横の面かの判定をしなきゃまともに跳ね返らない。
前フレームの玉の位置と現在の位置を線で結んで、各ブロックの
４つの側面のどこと交差しているかを判定する必要がある。
横面と交差してるならＹだけ反転、縦面と交差してるならＸだけ
反転させる。

玉のスピードが速いと、複数のブロックと同時交差する場合もある。
その時は一番玉に近いブロックとの判定だけに絞り、玉の位置も
そのブロックに接触する直前のポジションまで移動させる。

14 · 2008/11/12(水) 15:58:41

なるほど、理屈は理解できました
しかしどういうソースを書けばいいのかがまるで思いつかない……
いったいどういしたらいいのでしょうか？

**名前は開発中のものです。** · 2008/11/13(木) 09:45:19

>>21
ベクトルが理解できてないみたいだね。
まずは数学の勉強から始めないと。
線分交差の判定はここを参考にしてみたら？
http://www5d.biglobe.ne.jp/~tomoya03/shtml/algorithm/Intersection.htm

14 · 2008/11/14(金) 05:07:34

>>22
ありがとうございます
しかし読んでみたはいいのですがそれをどう組み込んでいいかがやっぱり思いつきませんでした

なのでがんばって自己流で判定組んでみたら
「○○.exe の 0x0056e0b6 でハンドルされていない例外が発生しました: 0xC0000094: Integer division by zero」
とか出されてしまいました、一体これはどういうことなんでしょうか？

14 · 2008/11/14(金) 05:14:12

ソース

int ShellAX, ShellAY, ShellXT, ShellYT;
//xが次のエリアに到達するまでの時間
if(ShellVX==0){ //分母が0防止
　ShellXT=0;
}else{
　if(ShellVX>0){ //右に変化中
　　ShellXT=(35-(ShellBX%35))/ShellVX;
　}else{ //左に変化中
　　ShellXT=(-1)*(ShellBX%35)/ShellVX;
　}
}
//yが次のエリアに到達するまでの時間
if(ShellVY==0){ //分母が0防止
　ShellYT=0;
}else{
　if(ShellVY>0){ //下に変化中
　　ShellYT=(20-(ShellBY%20))/ShellVY;
　}else{ //上に変化中
　　ShellYT=(-1)*(ShellBY%35)/ShellVY;
　}
}
ShellAX=ShellBX/35;
ShellAY=ShellBY/20;

14 · 2008/11/14(金) 05:14:58

while(ShellX>LeftEdge&&ShellX<LeftEdge+350&&ShellY>0&&ShellY<20*BlockY){ //ブロックが存在しうる範囲かどうか
　if(ShellXT<ShellYT){ //Xのエリアが先に変化
　　if(ShellVX>0){ //右方向に突入
　　　if(BlockFlag[ShellAX+1][ShellAY]){ //突入した先にブロックが存在
　　　　BlockFlag[ShellAX+1][ShellAY]=0;
　　　　ShellVX*=(-1);
　　　　ShellX=35*(ShellAY+1); //エリア突入時の境界線へ移動
　　　　ShellY=ShellBY+(ShellVY/ShellVX)*(35*(ShellAY+1)-ShellBY); //エリア突入時にｙが進んだ分だけ増加
　　　　break;
　　　}else{ //突入してもなかったよ
　　　　ShellAX++; //判定を次のエリアへ移行
　　　　ShellXT+=35/ShellVX; //次のエリアへの突入時間加算
　　　}
　　}else{ //左方向に突入
　　　if(BlockFlag[ShellAX-1][ShellAY]){ //突入した先にブロックが存在
　　　　BlockFlag[ShellAX-1][ShellAY]=0;
　　　　ShellVX*=(-1);
　　　　ShellX=35*ShellAX; //エリア突入時の境界線へ移動
　　　　ShellY=ShellBY+(ShellVY/ShellVX)*(35*ShellAX-ShellBX); //エリア突入時にｙが進んだ分だけ増加
　　　　break;
　　　}else{ //突入してもなかったよ
　　　　ShellAX--; //判定を次のエリアへ移行
　　　　ShellXT=35/ShellVX; //次のエリアへの突入時間加算
　　　}
　　}

14 · 2008/11/14(金) 05:15:41

　}else{ //Yのエリアが先に変化
　　if(ShellVY>0){ //下方向に突入
　　　if(BlockFlag[ShellAX][ShellAY+1]){ //突入した先にブロックが存在
　　　　BlockFlag[ShellAX][ShellAY+1]=0;
　　　　ShellVY*=(-1);
　　　　ShellY=20*(ShellAY+1); //エリア突入時の境界線へ移動
　　　　ShellX=ShellBX+(ShellVX/ShellVY)*(20*(ShellAY+1)-ShellBY); //エリア突入時にｘが進んだ分だけ増加
　　　　break;
　　　}else{ //突入してもなかったよ
　　　　ShellAY--; //判定を次のエリアへ移行
　　　　ShellYT+=20/ShellVY; //次のエリアへの突入時間加算
　　　}
　　}else{ //上方向に突入
　　　if(BlockFlag[ShellAX][ShellAY-1]){ //突入した先にブロックが存在
　　　　BlockFlag[ShellAX][ShellAY-1]=0;
　　　　ShellVY*=(-1);
　　　　ShellY=20*ShellAY; //エリア突入時の境界線へ移動
　　　　ShellX=ShellBX+(ShellVX/ShellVY)*(20*ShellAY-ShellBY); //エリア突入時にｘが進んだ分だけ増加
　　　　break;
　　　}else{ //突入してもなかったよ
　　　　ShellAY++;
　　　　ShellYT+=20/ShellVY;
　　　}
　　}
　}
　//抜け出し要素判定
　if(ShellAX==ShellX/35||ShellAY==ShellY/20){ //判定エリアが既にボールが来たことになっている場所とおなじなら
　　break;
　}
}

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

0除算例外
>>25 >>26にある除算全てが該当するな

アルゴリズムまでは読んでないのでほかの人に任せた

14 · 2008/11/15(土) 03:43:14

前のほうでやってるのに忘れていました
とりあえず
ShellXT<ShellYT のところを
ShellXT<ShellYT && ShellXT!=0　にしてみたら動いたは動いたのですが
ボールがあらぬ挙動をします
当たっているのに当たった動きをしなかったり、突然わけのわからないところへ移動したり
原因がさっぱりです……

一応上記の判定は、画面を35*20のエリアに分けて、今いるエリアから別のエリアに移動したら、
そこにブロックが有るか無いか判定、という形で組んでみています
(今更ですが、ブロックを35*20でやっているので、ですね)

もしかしたらこのあたり判定でなく、>>20の方法でやらなければダメなのでしょうか
でしたら、よければそのソースを教えていただけませんでしょうか？

**名前は開発中のものです。** · 2008/11/17(月) 07:17:05

もしかしなくても、お前の方法は完全に間違い。
先にベクトルの勉強しろって。

**名前は開発中のものです。** · 2008/11/17(月) 08:29:32

線分単位の当たり判定まではいらないにしても
少なくともどちらに跳ね返すかの判定はいるだろう
ボールの速度がブロックの厚みを超えないようにするだけでだいぶ計算量はへるし

**名前は開発中のものです。** · 2008/11/17(月) 15:27:54

>>29
間違ってはいないよ。14の考え方は論理的には合っている。
自分で思いついた方法なら、そのまま突き進むのを俺は薦める。

とりあえず、問題がありそうな点
・XT,YTはintだと精度が足りない(AX,AY以外は全てfloatの方が望ましい)
・「左方向に突入」の部分のShellXT=35/ShellVX;は+=の間違い
・XT,YTが1フレーム分の時間を超えていたらループから抜ける必要がある

**名前は開発中のものです。** · 2008/11/19(水) 06:25:45

合ってねーよバカｗ

**名前は開発中のものです。** · 2008/11/20(木) 02:14:48

なんかわからんけど >>14 と >>19 を見た感じ
これでいんじゃね？

CurShellVX = ShellVX;
CurShellVY = ShellVY;
for(int i=0;i<BlockX;i++){
　for(int s=0;s<BlockY;s++){
　　if(BlockFlag[i][s]){
　　　if(ShellX>=LeftEdge+35*i-ShellR && ShellX<=LeftEdge+35*(i+1)+ShellR){ //X範囲の判定
　　　　if(ShellY>=UpEdge+20*s-ShellR && ShellY<=UpEdge+20*(s+1)+ShellR){ //Y範囲の判定
　　　　　BlockFlag[i][s]=0;
　　　　　ShellVX = -CurShellVX;
　　　　　ShellVY = -CurShellVY;
　　　　}
　　　}
　　}
　}
}

**名前は開発中のものです。** · 2008/11/20(木) 07:27:59

↑
来た方向にそのまま戻ってくだけじゃねーかよｗ
反射させろよｗ

**名前は開発中のものです。** · 2008/11/20(木) 10:05:54

回帰性があるんですね

**名前は開発中のものです。** · 2008/11/20(木) 17:22:35

ゲーム作るならついにD言語のほうがとうとういいよ

**名前は開発中のものです。** · 2008/11/20(木) 17:55:39

ついにとうとうDの時代が来たか

**名前は開発中のものです。** · 2008/12/04(木) 15:02:10

Vista対応のゲームをつくる場合、
\Program Files以下にsavedataを作るのはまずいのでしょうか？

**名前は開発中のものです。** · 2008/12/04(木) 15:13:47

>>38
まずいよ
fopen( )だと NULL が帰ってくるから

**名前は開発中のものです。** · 2008/12/04(木) 15:15:55

まずいと思うよ。書き込めるように対策してたとしても、
プレイする人の環境によって、そのまま保存されたりVirtualStoreディレクトリに
自動的に置き換わったり、警告出たり出なかったりと、動作がまちまちになるからねえ。

**名前は開発中のものです。** · 2008/12/04(木) 19:26:59

ありがとうございます。やはりそうでしたか。

savedataどこに作るか悩みますね。。
どこに作るのが一般的なのか調査してきます。
こちらでもアドバイスいただけると幸いです。

**名前は開発中のものです。** · 2008/12/04(木) 23:28:46

マイドキュメントでも良いけど、ユーザーが直接ファイルを参照する必要がないなら
CSIDL_APPDATAのが適切かな。

**名前は開発中のものです。** · 2008/12/05(金) 09:49:13

そうだな。
他のアプリでも使う可能性がある場合はMyDocument、専用ならAppDataだな。

41 · 2008/12/05(金) 18:35:25

> 42 43
ありがとうございます。やはり結論としてはApp dataに落ち着きそうですね。

**名前は開発中のものです。** · 2008/12/05(金) 21:38:25

中学1年で数学を挫折した馬鹿な僕に教えてください
普通の3D→2Dの座標変換（x､y､z座標を持った物体の画面上の表示場所x、yを求める）
の計算方法は分かるんですが、
今分からなくて知りたいのはラスタースクロールで奥行きを出すときで、
あるY座標に来たときにXをどれだけずらせばいいかを算出する計算方法です。
具体的に言えばストリートファイター2の地面の横スクロール(立体感がついている）や、
古くはマグマックスの地上面の地表みたいな表現です。
簡単に説明できなければお薦めの参考図書を紹介してくれるのでも良いです
お願いします

**名前は開発中のものです。** · 2008/12/06(土) 02:19:07

そんなの雰囲気でおｋ
なんでもかんでも方程式で出さないと気がすまないのか？

**名前は開発中のものです。** · 2008/12/06(土) 02:28:57

スト2の地面なんて、たんにY座標に正比例してるだけじゃなかった？

**名前は開発中のものです。** · 2008/12/06(土) 07:30:02

>>46
答えられないなら無理にレスしなくて結構です
>>47
どういうことですか？
適当にやったらまったく立体的に見えなくてダメでしたので…

**名前は開発中のものです。** · 2008/12/06(土) 11:32:04

やった事無いから適当に考えるが。

背景の中心、地面の一番奥から一番手前まで直線が引いてあるとして
一番手前の地面を左右にスクロールさせると、その直線は傾く。
けど曲線にはならない。直線のはず。

つまり正比例で座標ずらせばいいってだけじゃないのかな。

それと言っておくが

>答えられないなら無理にレスしなくて結構です

こういう事を言うやつはよくいるが、「自分の性格は悪いです」って公言してるようなもんだから
誰も回答してくれなくなるぜ。

**名前は開発中のものです。** · 2008/12/06(土) 11:57:50

クオータービューで検索してね
"3DRPGプログラミング"　この本を買って読んでみなさい。

**名前は開発中のものです。** · 2008/12/06(土) 19:52:48

>>43
文句たれるバカが沸くから
結局ユーザに選ばせるしかない

**名前は開発中のものです。** · 2008/12/07(日) 08:52:11

適当な数式作るにはセンスが重要だよね……

>>48
スト2のリュウステージをラスタースクロールのみで再現しようとするなら、
まず板の継ぎ目がある一点に収束するように引いておく(画面中心点が妥当)。
その点からの相対Y座標を使い、
各ラインのスクロール量X = 立ち位置ラインのスクロール量X * 各ライン相対Y / 立ち位置相対Y
でいいんじゃないかな。

ただ上記の処理だと半画面分スクロールしただけでもドットがボロボロになるので、
普通は拡大縮小処理も一緒に使うと思うよ。
この場合、板は普通に長方形で書いておき左右は均一に、上下は奥に行くほど
小さくなるような雰囲気で色を塗り、
各ラインの拡大率X = 各ライン相対Y / 立ち位置相対Y
で、画面の垂直中心線上のスクロール量が同一になるように補正する。

**名前は開発中のものです。** · 2008/12/07(日) 09:12:51

>>52
きめ細かい解説ありがとうございます。
ストIIは実際拡大縮小もやっているのでしょうかね？

**名前は開発中のものです。** · 2008/12/07(日) 18:46:01

センスのない奴ほど数式に頼りたがるよな
それで、修正のリクエストがあったときに
物理法則がどうのこうのと力説したがる

**名前は開発中のものです。** · 2008/12/09(火) 07:07:30

数式を使わずにどうやってプログラミングするんだ。
ツクール派？

**名前は開発中のものです。** · 2008/12/09(火) 10:32:23

ジャンプを実装するのに
いちいち質量がいくつで、重力係数がいくつだから・・・・
とかやりだすことだろ

**名前は開発中のものです。** · 2008/12/09(火) 10:58:49

ジャンプなんかは適当でもいいし、
どんなに不自然なジャンプでもそれによってゲーム性にオリジナリティが出るんだからそれでいい。
だが3D表示をするにあたって計算が適当じゃあ3Dに見えないだろ
問題が全く別だよ
トンチンカンな会話すんな

**名前は開発中のものです。** · 2008/12/09(火) 11:55:35

じゃあ全く別な問題を持ち出す>>57が一番トンチンカンということになるな。

**名前は開発中のものです。** · 2008/12/09(火) 14:25:54

普通に考えてこんなのに3D計算なんかしてないだろ
単純に奥のものが手前にあるもより遅く動いてるだけ
どれくらい遅くするかは作った人間のセンス
たぶん何度も係数をいじって自分の感覚で
ベストと思われる動きでフィックスしてるはず
この感覚が万人に受け入れられない人をセンスのない人という

**名前は開発中のものです。** · 2008/12/11(木) 07:02:29

３Ｄ計算してもしなくても、最終的に数式に落とす事になるだろ。
それを聞いてるんじゃないの？
具体的な係数を聞いてるわけじゃないし、そこはＡとかＢとかでいいじゃん。

**名前は開発中のものです。** · 2008/12/18(木) 11:30:02

ライトユーザー向けのPCゲームつくりたいんだけど、
Vramの推奨スペックはいくつにすべきか？
ご意見伺いたいです。

**名前は開発中のものです。** · 2008/12/18(木) 12:25:16

何作るかによるでしょ。
3DじゃなけりゃWindowsが使えるだけあればいいよ。

**名前は開発中のものです。** · 2008/12/18(木) 12:43:11

>>61
2Dなら800*600*32ビット1画面で2Mバイト
裏画面入れて4Mバイトあればいいんじゃない

**名前は開発中のものです。** · 2008/12/19(金) 05:45:59

>>61
現に画面が表示されていれば、VRAM容量は関係ない。
画面表示用バッファは、すべてメインメモリ（DIBなど）に取れるから。

**名前は開発中のものです。** · 2008/12/19(金) 07:18:28

２Ｄゲーならシステムメモリだけでも全然快適に動くから
ＶＲＡＭゼロでもかまわないよ。

**名前は開発中のものです。** · 2008/12/19(金) 09:16:19

チェックした最低動作環境でのＶＲＡＭ容量を書いておけばいいよ

**名前は開発中のものです。** · 2008/12/19(金) 17:59:20

いまどきの安物パソコンなら専用VRAMなんか構えてないから
メインメモリ共有だし。容量だけなら128MB～512MBくらいは普通にある。

**名前は開発中のものです。** · 2008/12/19(金) 22:25:50

>>61
2Dゲーなら問題なし。
3Dなら、ユーザーが大目のMMORPGを参考にするといいと思う

**名前は開発中のものです。** · 2008/12/19(金) 22:26:25

> 大目のMMORPGを
大目の日本のMMORPGを

**名前は開発中のものです。** · 2008/12/20(土) 00:34:45

俺も2Dゲームは画像データとかシステムメモリに置いてたけどさ、
描画周りにアクセラレーション効かせるのってあんまり一般的じゃないの？

**名前は開発中のものです。** · 2008/12/20(土) 00:55:24

いつの時代からタイムスリッパしてきやがりましたか？

**名前は開発中のものです。** · 2008/12/22(月) 00:06:41

>>61
どのみちライトユーザーにVRAMとか行っても理解してもらえない。
奴等は自分のマシンのスペック分からずにで、動いたかどうかしか興味が無い。

61 · 2008/12/22(月) 12:28:11

Vramの件、みな、どうもご親切にサンクス。
レスおそくなりすいません。カキコできなくて。

何作るかによりますね。すいません。2Dゲーで
Flashで作ったアニメデータがバリバリと動く予定です。
DirectX使っていますので、Vramの確保は必須かもと思っていました。。
ライトユーザーに理解してもらえなくてもいいんですが、
作り手としてってことでしょうか。

**名前は開発中のものです。** · 2008/12/23(火) 02:14:34

>>73
72書いた者だけど、質問の意図は分かります。
ただ、どれだけ気にしてもやっぱり動かない環境は残ってしまって、
そういう環境のユーザーほどマシンスペック分からずに苦情出してくるからな～
すんません。個人的トラウマでした。
否定的な意見はやめて、

DirectXなら、使用するDirectXのバージョンがそのままマシンの世代を表しているって
考えてもいいんじゃないでしょうか？
例えば、DX7使用ならVRAM8MB、DX8ならVRAM32、とか。
あ、値は適当ですが。

**名前は開発中のものです。** · 2008/12/23(火) 20:12:05

お前「殺意を覚えるくらい馬鹿ですね」って言われたことない？

**名前は開発中のものです。** · 2008/12/23(火) 20:41:02

VRAMの大きさ（容量）を知る関数のようなもの、ありますか？

**名前は開発中のものです。** · 2008/12/24(水) 13:55:34

>>76
DirectDrawなら
IDirectDraw::GetCaps( )で
http://msdn.microsoft.com/ja-jp/library/cc353808.aspx
dwVidMemTotal
ビデオメモリの合計容量。

73 · 2008/12/26(金) 16:23:02

>74
どうもサンクス。
トラウマ…なんとなくわかります。

**名前は開発中のものです。** · 2008/12/31(水) 14:01:10

Windowsのソリティアのように
コントロールをドラグ&ドロプ、リリスしたとき、
定位置に整列する（磁石に引きつけられるように）コードの
せめて考え方、ヒントを教えて頂けないでしょうか

**名前は開発中のものです。** · 2008/12/31(水) 14:11:55

フレーム毎に目的の位置に近づけていくだけ

**名前は開発中のものです。** · 2008/12/31(水) 14:12:09

論理的思考を身につけるには、まず正しい日本語から。

**名前は開発中のものです。** · 2008/12/31(水) 14:25:51

まずは自力で線分を引けるように。
線が引ければ途中のXY座標もわりだせるだろう。

**名前は開発中のものです。** · 2008/12/31(水) 14:42:28

表示する座標 (x,y)
移動前の座標 (sx,sy)
移動後の座標 (ex,ey)

Aパターン
x+=((ex-sx)/m) ;
y+=((ey-sy)/m) ;
単純に終点へのベクトルを座標に足していく
mの値が大きければ遅く小さければ速く移動
x+=((ex-x)/m) ;
y+=((ey-y)/m) ;
とすると遠いときほど早く近いときほど遅くなり磁石っぽい

Bパターン
x=sx+(ex-sx)*m;
y=sy+(ey-sy)*m;
mを0から1.0へ増やす
mの値にsin(0)～sin(π/2)を使うと磁石っぽい
Aとの違いは始点と終点の距離にかかわらず同じ時間で終点に到達する

**名前は開発中のものです。** · 2008/12/31(水) 20:18:33

＞とすると遠いときほど早く近いときほど遅くなり磁石っぽい

磁石は距離が近くなるほど磁場が強くなるので、遠いほど遅く、近くなると速くなる。
つまり真逆。

**名前は開発中のものです。** · 2009/01/04(日) 15:53:08

DirectXとc++で2D格闘ゲームを作りたいと思うのですが、ソースってどこかにないですかね
参考にしたいのですが、ググり方が悪いのか出てきません
ソースの置いてある場所があったら教えて頂きたいのですが、ないですかね

**名前は開発中のものです。** · 2009/01/04(日) 17:35:22

逆に君は自分の自作のソースを晒したいと思ってますかね
ぐぐってパクるだけで分け与えなければどこにもなくて当たり前じゃないですかね
馬鹿ですかね

**名前は開発中のものです。** · 2009/01/05(月) 01:19:54

>>86
ガキ臭い煽り方だな
なんか嫌なことでもあったのか

**名前は開発中のものです。** · 2009/01/06(火) 13:57:16

いや、でもいいこと言っている

**名前は開発中のものです。** · 2009/01/06(火) 14:37:31

子曰く
「どうすればいいのか、どうすればいいのか、と考え悩みぬいた者でなければ
　私にもどうしようもない」

最初から他人をアテにしてるようじゃダメってことだな。

**名前は開発中のものです。** · 2009/01/06(火) 19:50:41

情弱ですか

**名前は開発中のものです。** · 2009/01/06(火) 21:55:02

>>85
格闘げーはアニメーション画像が命みたいなところがあるから、
素材の用意が大変過ぎてプログラミングの教材には向かない罠。

**名前は開発中のものです。** · 2009/01/06(火) 22:09:59

>>85
逆にいえばアニメーション、当たり判定、キー入力ができれば作れるともいえる
キー入力はちょっと特殊だけどそれ以外はインベーダーゲームの応用

**名前は開発中のものです。** · 2009/01/06(火) 22:15:01

ジョイメカファイト・・・

**名前は開発中のものです。** · 2009/01/07(水) 08:43:07

いっそ３Ｄ格ゲーにすりゃ、３Ｄアニメーションの基本をごっそり勉強できる

**名前は開発中のものです。** · 2009/01/07(水) 16:52:39

PS3のリトルビッグプラネットのCGはDirectXでも表現出来るの？

**名前は開発中のものです。** · 2009/01/07(水) 17:03:09

表示するだけならできるだろうけど
アレのすごい所って主に物理演算の部分だろ？
まったく別問題な希ガス

**名前は開発中のものです。** · 2009/01/07(水) 17:10:42

物理演算はNVIDIAならphysxが使える
あの程度なら余裕なはず

**名前は開発中のものです。** · 2009/01/07(水) 17:14:31

で具体的にどうやればあんなクオリティのCGが作れるのか知りたい
プログラムは出来るけどCGに関してはまったくの素人なんで

**名前は開発中のものです。** · 2009/01/07(水) 19:51:09

>>94
モデリングとアニメーションツールの勉強から始めなきゃならないじゃん。

プログラミングの勉強としてはすっごく遠回り。

**名前は開発中のものです。** · 2009/01/08(木) 02:23:25

>>98
とりあえずBlenderでも弄ってみたら
質は遠く及ばんなりに、基礎やクオリティ上げる定番手法は一式遊べるよ

**名前は開発中のものです。** · 2009/01/08(木) 13:45:17

多少はモデリングのことも勉強しとかんと
デザイナーと会話できないからな

**名前は開発中のものです。** · 2009/01/09(金) 00:10:10

DirectXでって言ったでしょ

**名前は開発中のものです。** · 2009/01/09(金) 00:31:42

>102
ＣＧ板で聞けば？ＣＧの話なんだし

**名前は開発中のものです。** · 2009/01/09(金) 02:32:56

>>102
つ>>96
表示だけならDirectXでもできるぞ。他の人間も指摘してるとおり
データ（モデル・モーション・マテリアル（まぁシェーダーも含むが））を用意できればの話だがな
動きについては物理シミュ用のライブラリ(bulletとかPhysX)でもひっぱってきたほうが楽だな
ただｱﾚの爆発エフェクトを真似るためには簡易なCFDのコードが必要だが、ゲーム用のフリーの
ライブラリでそういう機能を提供してるものがあるのかどうかは知らん

なければ適当に2D格子用意して格子気体法とかCIP法の劣化版みたいなコードを組めばいい
どうせシミュったって何かを厳密に再現する必要はないし、支配方程式が導出できる必要も無い
それっぽい流れ場のアニメーションができればなんでもいい

＞で具体的にどうやればあんなクオリティのCGが作れるのか知りたい

つ>>103
データを作る部分の話はCG板で聞いたほうがいいんじゃね
ティーポットとかトーラスとかシリンダに毛とか生やすだけでおｋならD3DXでいけるけどな

**名前は開発中のものです。** · 2009/01/09(金) 03:03:09

いやだからリアルフォトマティックレイとレーシングでしょ？
モデルとかそういう問題なの？
ただの無地の球体でもレイトレーシングのアルゴリズムで全然違うでしょ
レイトレーシングの仕方なんて聞いてないんだよ
同じ効果をDirectXで高速に描画出来る方法があるのかって話をしてるの

**名前は開発中のものです。** · 2009/01/09(金) 03:06:00

あと物理演算の領域はこっちの分野だから君らに教わることはないよ

**名前は開発中のものです。** · 2009/01/09(金) 03:22:44

>あと物理演算の領域はこっちの分野だから君らに教わることはないよ

おかしいな。分かるならCUDAとか使ってるだろうし
GLSLやHLSLでサクサクと俺シェーダー組めてもいいはずだが・・・

リアルタイムなCFDをやる場合って差分スキームはいつもナニ使ってるの？
後学のために教えてください

**名前は開発中のものです。** · 2009/01/09(金) 08:06:03

CUDAとシェーダーは別次元の話だな
物理演算をリアルタイム処理する人しかこの世にいないと思ってんの？

**名前は開発中のものです。** · 2009/01/09(金) 08:10:48

高速化技法をいくら語られても根幹のアルゴリズムが分からないって話をしてんの
シェーダー分かったらなんなんだ
超リアルなCGが書けるのか？書けないだろ？

**名前は開発中のものです。** · 2009/01/09(金) 08:22:52

リトルビックプラネットのCGはフォトリアルスティックレイトレーシングの結果のようなリアルな画像なの
PS3でもさすがにフルHDをレイトレーシングするような能力は無い
君の大好きなCUDAやGLSLを使ってもPCでは到底無理なの
PS３はDirectXベースに作られてるんだから当然同じことがPCでも出来るだろうと思ってるわけ
レイトレーシングはあり得ないのでどうやってんのかを知りたいの
物理演算とか誰も聞いてないから

**名前は開発中のものです。** · 2009/01/09(金) 08:49:59

自分で解答言ってないか？

**名前は開発中のものです。** · 2009/01/09(金) 12:20:56

なんでコイツ上目線で質問してんの？人格障害でもあんの？

**名前は開発中のものです。** · 2009/01/09(金) 13:18:37

２ｃｈに慣れちゃだめだぞ。:アルファルファモザイク
http://alfalfa.livedoor.biz/archives/51415753.html

**名前は開発中のものです。** · 2009/01/09(金) 18:15:29

明らかに知識が下の人が的外れな回答して偉ぶってるからｗ

**名前は開発中のものです。** · 2009/01/09(金) 20:40:58

つ鏡

**名前は開発中のものです。** · 2009/01/10(土) 03:00:31

（；・∀・）

**名前は開発中のものです。** · 2009/01/10(土) 17:35:41

ほう、PS3がDirectXとな

で、リアルタイムレイトレーシングが無理だと判ってるなら
工夫して俺シェーダー積み上げるしかないのも判ってるんでしょ
リアルに見せるフェイク処理の引き出しを地道に増やすしかあるまいて

**名前は開発中のものです。** · 2009/01/10(土) 20:43:58

PS3のグラフィックチップはGeForce7800ベースだそうだから、
ハード的にDirectXベースというのは間違いでもないよ。

LBPに関しては、何か特別なレンダリング技術を使ってるわけじゃなく、
単にアートディレクションと、質感の設定が秀逸なだけだと思うけど、
「この部分の質感が」とか「この部分のエフェクトが」とか、
具体的に言わないと誰もわかんないんでは？

**名前は開発中のものです。** · 2009/01/10(土) 21:37:42

＞PS3のグラフィックチップはGeForce7800ベースだそうだから、
＞ハード的にDirectXベースというのは間違いでもないよ。

間違いを認めず、こういう恥の上塗りをする奴って、
いったい何を考えて生きてるんだろう？

ハッキリ言うが間違い以外の何ものでもない。

**名前は開発中のものです。** · 2009/01/10(土) 21:47:52

同感。

**名前は開発中のものです。** · 2009/01/10(土) 21:59:30

さあ詭弁のガイドラインでもみてみよう

**名前は開発中のものです。** · 2009/01/10(土) 22:06:42

なんつうんだろう。
あまり人付き合いがなさそうな人に送る、座右の銘。

「土下座する、勇気」。

退く勇気は、がむしゃらに突撃する勇気よりも、大切なんだよ。

**名前は開発中のものです。** · 2009/01/10(土) 22:10:51

てか、>>113が貼られてんだから少し落ち着けとｗ

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

PS2はopenGLだったと思ったけど、PS3もOpenGLなん？

**名前は開発中のものです。** · 2009/01/11(日) 20:09:11

GLES1.0+RSX拡張
RSX叩くにはPSGLやlibgcmってライブラリを使う
シェーダ言語はCg

**名前は開発中のものです。** · 2009/01/12(月) 01:15:34

ググってみたのですが、見つからなかったので教えて下さい。
linuxについてるGlineというゲームを、
勉強がてら.netのC#で作ろうと思っているのですが、
できれば得点などのロジックをオリジナルに忠実に再現したいと思っています。
オリジナルのソースもしくは得点ロジックが出ているところってありますでしょうか。

**名前は開発中のものです。** · 2009/01/12(月) 02:32:32

>>126
gnome-gamesってソースパッケージがあるはずだから
yumなりsynapticなりで探せ
その中に含まれてる

どうしてもみつからなかったらもう一度聞いて

**名前は開発中のものです。** · 2009/01/12(月) 20:19:41

>>125
それを総合してDirectXって言うんだよ。

**名前は開発中のものです。** · 2009/01/12(月) 20:52:24

>>128
お前の言っていることは、
PCがあったら、Linuxが動いていようがFreeBSDが動いていようが、
それを統合してWindowsだと言っているほど間抜けだぞ。

**名前は開発中のものです。** · 2009/01/12(月) 21:16:19

さすがにネタっぽいな
ファーレンハイトが懐かしいぜ

**名前は開発中のものです。** · 2009/01/12(月) 21:18:31

家庭用ゲーム機は全部ファミコンで、携帯音楽プレイヤーは
全部ウォークマンですね。

**名前は開発中のものです。** · 2009/01/12(月) 21:34:42

まぁ、おれの中学時代のあだ名はウォーズマンだけどな。

**名前は開発中のものです。** · 2009/01/12(月) 21:40:02

はて・・・？
PS3の開発環境は既にDirectX対応してなかったけか、PhyreEngineで。
DirectXのAPIも実装済みで、OpenGLとDirectX、どちらでも好きな方を選べるとか。

**名前は開発中のものです。** · 2009/01/12(月) 22:38:10

組み合わせの選択幅が広過ぎるってんで鳴り物入りで紹介された奴だな
ローレベルライブラリじゃなく、フレームワークにあたるエンジンだ
PC/XBOX版で下層エンジンにDirectXも選べるという構成のようだね

**名前は開発中のものです。** · 2009/01/12(月) 22:59:42

GKはどうしてもPS3にDirectXが入っててほしくないようだな

**名前は開発中のものです。** · 2009/01/13(火) 23:52:00

フレーワークレベルでDirectXも選べるのと、ハードウェアの公式ライブラリでDirectXが動くのとは相当の違いがｗ

**名前は開発中のものです。** · 2009/01/13(火) 23:55:09

そもそもPS3ではDirectXを選択すること自体不可能だから、違い云々以前の問題。

**名前は開発中のものです。** · 2009/01/13(火) 23:55:48

しょうがないから俺も今日からDirectXで動くよ。
ああ、髪が表示されないのは、レンダリングが遅いだけだから。

**名前は開発中のものです。** · 2009/01/14(水) 00:26:48

東京証券取引所はDirectX
大阪証券取引所はOpenGLで動いているという事実

**名前は開発中のものです。** · 2009/01/14(水) 09:51:30

「WOLF RPGエディター」とは？　
・高度なRPG開発が可能な、完全無料のゲーム作成ツールです。
・製作者はなんと「モノリスフィア」やツクール2000で「シルフェイド幻想譚」などを製作した
　SmokingWOLF氏だよ。
・雰囲気はRPGツクール2000に近い。RPGツクール2000で自作システムを作りこむ際に
　不満だったところがいろいろ解消されていて、かなり自由度が高いです。ただし
　その分初心者には難しいかも。すでにツクール2000で自作システムを組むのに
　慣れた人や、ＲＰＧツクールでは物足りないけどプログラミングはちょっとという方にお勧め。
・作成したゲームは自由に配布したり、コンテストに投稿することも可能。
　また本ソフトを持たない人でもプレイ可能！ファイル暗号化も完備してるよ！
・要望、不満点、バグ報告などなど書き込みお願いします。今もどんどん進化中です。
・それとマップやキャラなどのドット素材もじゃんじゃん募集中ですので
　一度サイトにお越しくださいませ。
・このツールで作ったゲームをサイトで紹介してるから、ダウンロードしてどういう
　ゲームが作れるのか見てみてね。

2ちゃん本スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1229261856/l100

**名前は開発中のものです。** · 2009/01/16(金) 20:27:23

半年ROMれ

**名前は開発中のものです。** · 2009/01/26(月) 11:18:31

C + WinAPIでのオフスクリーンの使い方がわからんのだが。。。

HDC off,hdc;
PAINTSTRUCT ps;
hdc = BeginPaint(hWnd, &ps);//hWndは描画先のウィンドウはんどら

　off = CreateCompatibleDC(hdc);
　＜offに対してBitBltやらなんたらかんたら＞

　BitBlt(hdc, -----, off, 0, 0, SRCCOPY);
EndPaint(hWnd, &ps);

でできると思ったのにうまくいかない。。
どこが悪いか指摘求む|・｀）

**名前は開発中のものです。** · 2009/01/26(月) 11:23:21

そのoffに対して適切な大きさのbitmapはSelectしてるか？
もししてないならば、1x1ドットのモノクロビットマップになってるんじゃないか。

**142** · 2009/01/26(月) 14:32:33

>>143
ありがとう。
BitBltとかする前にCreateCompatibleBitmap(hdc, X, Y)したHBITMAPを
offにSelectObjectしたらできた。

HBITMAPは使用後Deleteしないと危ないってことも身をもって理解した。

**名前は開発中のものです。** · 2009/01/26(月) 15:12:42

WM_PAINTごとに作りっぱなしにしたのかｗ
大きさ変わらないなら、ウィンドウができた時に１つ作っておいて使いまわせる。
ウィンドウサイズが変わったら作り直して、ウィンドウ破棄の時に消す、とかね。

**142** · 2009/01/27(火) 11:20:58

>>145
WM_PAINTは無効にして、好きなときに再描画するようにしてるんだが、、まぁいいか）
再描画する関数が呼ばれるたびに作ってDeleteしなかったな。
タスクマネージャー開くとメモリ使用量のグラフがぐーんとのびてた）
１つを再利用する案、使ってみます（｀・ω・´）

**名前は開発中のものです。** · 2009/01/27(火) 11:46:12

なんでWM_PAINTだと思ったか。
BeginPaintがあったからだよ～ん

**名前は開発中のものです。** · 2009/02/06(金) 09:00:05

えっと
複数のエンジンを搭載した宇宙船をエンジンの出力調整で移動させたいのですが
物理に不自由な人間なもんでまったくどうすればよいのやらこまっております
下の図の矢印のようにエンジンがついてると仮定して
　 ←△→
　　　□
←△□△→
　　　↓

左上のエンジンと右下のエンジンの出力を上げると機体が回転するだろうなとはわかりますが
プログラムまでもってけないわけです

一応2Dでの運用を想定しております

複数の速度ベクトルを合成？するのかな
でも回転するとしたらどうすれば…
よくわかりません…orz

**名前は開発中のものです。** · 2009/02/06(金) 09:32:08

スラスターの再現をすることに何かこだわりがあるなら物理の教科書を読むんだ。

つ Amazon.co.jp：ファインマン物理学 (1): ファインマン: 本
http://www.amazon.co.jp/dp/4000077112

**名前は開発中のものです。** · 2009/02/06(金) 12:07:05

それぞれ回転する中心点の軸をずらして回転行列掛けりゃいいじゃん

**名前は開発中のものです。** · 2009/02/06(金) 14:12:04

こんなの嘘物理でよくね？
中心軸を1点にしておいて、そこを中心に
右上か左下に出力があるときは反時計まわり
左上か右下に出力があるときは時計まわり
移動はすべての出力のベクトルの和
これだけでそれっぽく動きそうな気ガス

**名前は開発中のものです。** · 2009/02/06(金) 16:59:07

中心軸は上の出力で下にずらす
下の出力で上にずらす
両方の出力だと相殺されてずれない
でどう

**名前は開発中のものです。** · 2009/02/06(金) 19:21:57

お前らそうやってゲームにニセ物理組み込んでるんだな……。俺も俺も

**名前は開発中のものです。** · 2009/02/06(金) 22:01:45

148じゃないけど
静止状態から真空無重力だと148の左上だけ出力した場合回転するんだっけ？ｗ

**名前は開発中のものです。** · 2009/02/06(金) 22:13:48

だから、そういう物理を気にしだすと
操作が直感的じゃなくなってプレイヤーのストレスになりかねないから
嘘物理でいいんじゃねって話

**名前は開発中のものです。** · 2009/02/06(金) 22:52:53

>>155
実装はそうだろうけど、知ってた方が、それを基本に考えられるから無駄にはならんと思うがｗ
148のを自分で組んでみようと思ったら154のが気になって止まったｗ
で、どうだっけ？ｗ

**148** · 2009/02/06(金) 23:19:27

>>150
ごめんなさい、回転行列がわかりませんorz
>>151 >>152
私も同じような考えにたどり着きました

必死に考え直した結果こうなりました
まちがってるかな？
ttp://www.dotup.org/uploda/www.dotup.org21184.png

中心：緑丸
エンジン：青丸
出力方向：紫矢印

エンジンの出力ベクトルを中心点とエンジンを結んだ線とその垂直線を座標としたベクトルに分割し
赤を回転用のベクトル、水色を移動用のベクトルに分ける

あとは回転と移動をそれぞれ計算すればＯＫ？

すいません日本語にも不自由しているようですorz

**名前は開発中のものです。** · 2009/02/06(金) 23:48:02

>>157
それで合ってるよ。もっと正確に言えば、中心点ではなく重心。
あと、そこについてるのがロケットエンジンなら、普通は矢印は逆向きだな。

そこから真面目に回転速度を求めるには、「慣性モーメント」という知識が必要になる。
値は適当にでっちあげでいい。

**名前は開発中のものです。** · 2009/02/10(火) 15:41:10

.NETかMFCを勉強しようと思うのですが，
ゲーム開発だとどちらが役に立ちますか？

**名前は開発中のものです。** · 2009/02/10(火) 15:52:39

どっちも微妙
言語はC++のみ？

**159** · 2009/02/10(火) 16:05:56

>>160
微妙ですか；
どの言語で学びたいというのは，特に無いですが，
C++がコード書いてる量多いです．
VBは入門書通して読んだので簡単なアプリケーションなら作れる程度で，
C＃はJavaに似てるから読めるってくらいで，書いたことはないです．

**名前は開発中のものです。** · 2009/02/10(火) 16:12:06

C++やってるなら、.NETはC#前提で考えたほうがいいかも。
MFCでゲーム部分で役に立つところは少ないと思うよ。素でAPI呼ぶのとかわらない。

どっちもウィンドウ作ったりイベントハンドラ使ったりするところは楽できるけど
そういうのを生かすゲームを作るのかどうかってとこだね。
言語とライブラリやフレームワークで選んで、それが.NETやMFCを使ってたら
それも覚えるって感じでいいんじゃないかな。

**159** · 2009/02/10(火) 18:33:00

了解しました．ゲーム開発で使うといっても，
深い部分の機能まで扱う訳じゃないんですね．

一冊買って読もうと思ってましたが，
Webで調べて動かしてみる程度にしようと思います．
ありがとうございました．

**名前は開発中のものです。** · 2009/02/10(火) 21:26:47

>>163
C++にSDKがシンプルで案外楽なんじゃないかな。
描画や音でハードなことやろうとしたらDirectXやOpenGL/OpenAL使えばいいしね。

**名前は開発中のものです。** · 2009/02/11(水) 12:06:33

>>159
ゲーム本体作るなら、C++ + DirectX
ツール作るなら、.NET(C#)だな

**名前は開発中のものです。** · 2009/02/12(木) 20:13:23

3Dゲームには垂直同期とか異方性フィルタといったフィルタ機能が多く存在しますが、
こういったものの具体的なアルゴリズムが書かれてある書籍を教えて下さい。

よろしくお願い致します。

**名前は開発中のものです。** · 2009/02/12(木) 21:16:01

君の「アルゴリズム」の定義は、おそらく一般的なそれとは異なっている。

**名前は開発中のものです。** · 2009/02/13(金) 03:30:08

異方性フィルタとか言い出す前に、
普通に素のモデルを画面に表示できるようになれって話だな。

**名前は開発中のものです。** · 2009/02/13(金) 10:16:54

>>167
どういうことですか？

**名前は開発中のものです。** · 2009/02/13(金) 14:18:20

>>169
垂直同期てなんですか
フィルタなんですか
アルゴリズムなんですか

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

C++/DirectX　でアクションゲームを作ってるのですが、色んなPCで同期をとるために経過時間を計測するのって、
一般的にどの関数使うんでしょうか？
あと、昔、DOSで作ってたころはVシンク割り込みでどうたらこうたら、ってやってたきがするんだけど、
これって今の液晶画面で計測できるもんなんでしょうか？

**名前は開発中のものです。** · 2009/02/14(土) 17:43:59

時間の計測は QueryPerformanceCounter とか。
Windowsでは垂直同期の周期は環境によって全然違うので、
基本的には垂直同期に依存しないように作る。

**名前は開発中のものです。** · 2009/02/15(日) 00:36:23

>>171
精度がミリ秒程度でよければ、timeGetTime。timeBeginPeriodで精度を上げるのを忘れずに。

高精度がいるなら、>>172

**名前は開発中のものです。** · 2009/02/15(日) 00:41:57

>>172
>>173

ありがとうございます。
多環境で同期をとるのにどの程度の精度が実際に必要かやってみないとわからないので、
教えていただいた関数をもう少し調べてやってみます。

**名前は開発中のものです。** · 2009/02/15(日) 19:09:59

垂直同期は
D3DRASTER_STATUS rs;
do{
pd3dDevice->GetRasterStatus(0, &rs);
・・・
}while(!rs.InVBlank);
とかやるといいらしい。
ループ内でスリープ入れないとCPU使用率が100%になっちゃうかな？

**名前は開発中のものです。** · 2009/02/15(日) 21:23:34

メモ代わり。
MessageBoxがなぜか表示されない。グーグル先生曰く
WM_PAINTでBeginPaintとEndPaint処理をしてないからだと。
言われたとおりにしたら見事に解決した。
描画処理を別スレッドでやっててもWM_PAINTの処理は必要らしい。
windowsの中の人はよく分からんなぁ。

**名前は開発中のものです。** · 2009/02/16(月) 00:29:54

WM_PAINTはDefWindowProcに流せば、中でBeginPaint/EndPaintを呼んでくれるはずだが。

**名前は開発中のものです。** · 2009/02/16(月) 08:35:55

そこら辺はカスタムウインドウだかしない限りは自動で出来るはずだから、参考書でも眺めたら？と3年ほどプログラミングしてない学生が入ってみる

**名前は開発中のものです。** · 2009/02/16(月) 11:54:02

BeginPaint呼ばないと無効領域のクリアができないからだよ
クリアできないといつまでたってもWM_PAINT送り続けられる。
ValidateRectで消してしまうのも手だが。

**176** · 2009/02/16(月) 19:52:31

>>179
ものすごく納得した。ｻﾝｸｽ
自作のuiライブラリの処理が甘かったなぁ。

**名前は開発中のものです。** · 2009/02/22(日) 10:56:36

オンラインで１０×１０マスのビンゴゲームをイメージして下さい。
参加者は、月１回オンラインで１００個の数字を記入したシートをUPし、
毎日５個の数の発表を待ちます。

こんな感じのプログラムを創って貰うとき、何に注意して、どこに商談すればいいですか？
お願いします。

**名前は開発中のものです。** · 2009/02/22(日) 13:07:55

なんだかすごい釣り針が…

**名前は開発中のものです。** · 2009/02/22(日) 15:53:56

>>181
そのイメージの元となったビンゴゲームの開発元に
「絵をちょこちょこっと変えたバージョンを作って売ってください」って言うのが一番確実で手っ取り早い。

**名前は開発中のものです。** · 2009/02/22(日) 17:14:10

>>183
こんなところで聞くようなｲﾀｲ業者にヒントも出すなよ。
色んな意味でろくな事にならないぞ。

**名前は開発中のものです。** · 2009/02/25(水) 15:43:56

仕様書をまとめたほうがいい
技術的には低の低

**名前は開発中のものです。** · 2009/02/26(木) 04:43:10

http://search.vector.co.jp/search?query=%83r%83%93%83S

**名前は開発中のものです。** · 2009/03/25(水) 20:42:40

ウィンドウを表示するプログラムを作っているのですがウィンドウが表示されず、
visual C++の挙動が変になります。(ずっと　プログラム名(実行中)と表示され画面の配置も変になる)
どうすればよいのでしょうか？

コードは以下に晒します
#include <windows.h>

#define APP_NAME TEXT("Sample_MainWindow")

/* ウィンドウプロシージャ */
LRESULT CALLBACK WindowProc(
HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam
){
switch(uMsg){

case WM_DESTROY:
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}

つづく

**つづき** · 2009/03/25(水) 20:43:23

int WINAPI WinMain(
HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR lpCmdLine, int nCmdShow
){
HWND hWnd;
WNDCLASS wc;
MSG msg;

wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = WindowProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)COLOR_BACKGROUND + 1;
wc.lpszMenuName = NULL;
wc.lpszClassName = APP_NAME;

hWnd = CreateWindow(
APP_NAME, TEXT("Window Title"),
WS_OVERLAPPEDWINDOW | WS_VISIBLE,
100, 100, 400, 300,
NULL, NULL, hInstance, NULL);

/* メッセージループ */
while(GetMessage(&msg, NULL, 0, 0) > 0){
DispatchMessage(&msg);
}

return msg.wParam;
}

**名前は開発中のものです。** · 2009/03/25(水) 20:58:00

showwindowが抜けてる、かも

**名前は開発中のものです。** · 2009/03/26(木) 03:35:13

WS_VISIBLEがあるからShowWindowは必要ないかな

WNDCLASS構造体に値を設定しただけでRegisterClassで登録してないのが原因だと思う

**名前は開発中のものです。** · 2009/03/26(木) 10:22:58

>>190 の通り。
RegisterClass(&wc);
をCreateWindowの前に。

**名前は開発中のものです。** · 2009/04/05(日) 21:54:31

あんまりWindowsと関係無いのですが、C++でのメモリ確保方法について質問です。

ゲームでnewとdelを繰り返し使いまくると、やってられないから、
存在フラグを持って制御するように。
と、どこかで見た覚えがあります。

それならば、もうnewでメモリを動的確保ぜずに、
普通に静的宣言でいいのではないかと思ったのですが、
動的確保のメリットって何なのでしょうか？

私は仕事がハード畑一色の人なので、頭が固いです。
どなたか教えてくださいorz

**名前は開発中のものです。** · 2009/04/05(日) 22:34:27

×ハード畑なので、頭が固い
○高卒なので、頭が悪い

**名前は開発中のものです。** · 2009/04/05(日) 22:38:51

>>192
例えばメモ帳を作るとき、読み込んだデータの長さは分からない。
こういうとき静的な確保だと、何メガバイト確保すればいいのかわからないし、
もし確保した量よりデータが大きければ扱えないし、小さければ、無駄になる

そこで、new/malocなどで動的に確保してやれば、必要な分だけ確保できる。

**名前は開発中のものです。** · 2009/04/05(日) 22:48:17

>>192
使用メモリーが決まってて、制限以内なら静的確保で問題なし。
普通は全部持つ友もリーがはみ出るから、効率いい方法を探すだけ。

**名前は開発中のものです。** · 2009/04/06(月) 20:32:34

>>192
個人的には動的確保のほうが流れが分かりやすいけどね。
>>194のような柔軟性も持たせられるし。柔軟性を持つということは
コーディングでメモリ空間の大きさをやたら意識する必要も無くなる。
メモリ確保の速度の関係で、予め確保しておいたメモリ空間を使う
ってのはちょくちょく聞く話だけど、
そういう特別な事情が無い限り動的な確保が王道じゃないかなぁとは思う。

まぁ趣味でやるなら不正アクセスが無い限り自由にやりやがれって話ですよ。

**名前は開発中のものです。** · 2009/04/10(金) 05:55:47

ゲームプログラミングの経験はあまりないのですが、
３DのMOを開発しようと思っています。

そこで開発環境についてお聞きしたいのですが、
簡単に調べて以下のようなものがあるのが分かりました。
・XNA
・Unrealなどのゲームエンジン

XNAはXbox360対応を無視して単にPC向け開発環境として見た場合、良い選択肢でしょうか？
またそういう用途で広く使われているのでしょうか？
Unrealなどのゲームエンジンは、やはりXNAに比べるとすばやく開発出来るのでしょうか？
どの程度自由度が制限されますか？

分かる方よろしくお願いします。

**名前は開発中のものです。** · 2009/04/10(金) 06:01:34

あと、フリーのゲームエンジンでメジャーなものがあれば教えてください。

**名前は開発中のものです。** · 2009/04/10(金) 07:56:06

RPGツクールでも使っとけ。
求めてるのはそういうお手軽にゲームつくれるツールだろ？

**名前は開発中のものです。** · 2009/04/10(金) 08:01:59

そんなものを求めているとは一言も書いていません。
プログラミングの知識としては、OSアーキテクチャからアプリ・サーバ・WEB開発までいけます。
メジャーな開発環境はなんなのか、どんなものがあるのか
そういったトレンドを知りたいと思っています。

Windowsゲームプログラミング 質問スレ

Windowsゲームプログラミング　質問スレ