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

1 ：2008/11/06 〜 最終レス ：2012/11/29

※回答する人も、質問する人も必ず読んでください
【 回答してくださる方 】
・　できるだけ優しく質問に答えてあげてください。
・　優しく教えるのが嫌でしたら、解決するためのヒントだけでも結構です。
　「ググれ」以外の回答でおながいします。
・　神ですら理解不能な質問は無視して下さい。
【 質問する香具師 】
・　どんな事で躓いているのか明確にしる。
・　長くならないなら躓いている部分のコードを晒してみれ。
・　解決した場合、お礼を言うのは当然だが、何をどうしたら解決したかを明確に書け。

2 ：

　　　　　　　／　　／/　＼｀ー　　ヾ　＼　へｰ-､　　｀二ｰ-､
　　　　　 ／　　 /　ハ 「　　 ヽ､　　 ､　　　　 ＼ ＼へ　　｀ヽゝ
　　　　／ ノ　/　/´ 　　＼　　　＼　 ヽ　　 ヽ ､ ヽ　＼＼　 ｝ }
　 　／イ 　 /　/　/ ,|　ヽ ヘ、　　 ヽ　 } ﾍ 　 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:. :.　 　| : : ＼
／＼　: : : : : : : : : : : : : : :|　　　　　　　　　　　 ＼ ＼:. . / : : : : |

3 ：

>>1-2

4 ：

自演禁止

5 ：

簡単なアクションゲームだったら、経験から言って制御文、構造体(自己参照構造体含む。これ重要。)、
グラフィックの表示まで分かれば十分作れると思う。
まあ、本気で勉強すれば半年で、物分りの悪い人でも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;
　　　　}
　　}
}

6 ：

二次元のマップって普通１次元配列でするよね？
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クリアしてくれるから便利だよな

7 ：

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

8 ：

>>6
2次元のデータを1次元配列で管理しようとするのは、
俺みたいな昔の貧乏性のプログラマだけでいい。
斜め移動でも座標計算1回で済むとか、そんな貧乏臭い発想。
コンパイル時にサイズ不定でも、簡単なラッパ作ればいい。
2次元のものは2次元のまま扱った方が、デバッグもしやすい。

9 ：

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

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

10 ：

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

11 ：

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

12 ：

>>8
日本語わかる？

13 ：

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

14 ：

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

15 ：

主な変数説明
・BlockX、BlockY　：ブロックがｘ･ｙ軸に最大いくつ並んでいるか
・BlockFlag[][]　：ブロックが存在しているかいないか、０以外で存在
・ShellX、ShellY　：弾のｘ･ｙ座標
・ShellR　：弾の半径
・LeftEdge､UpEdge　：ブロック崩しの画面の左端、上端の位置
・ShellVX、ShellVY　：弾のｘ･ｙ速度
当たっているのが縦からなのか、横からなのかの判定がどうにもわからなかったので
当たったらｘ･ｙ速度両方反転するようにしてしまっています
よければその判定方法も教えてください
宜しくお願いします

16 ：

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

17 ：

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

18 ：

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

19 ：

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

20 ：

>>14
>>19でも指摘されてるけど、２つのブロックに同時に触れた場合は
移動方向が元に戻るから貫通するよ。
だから「ShellVY*=(-1);」の後に「break;」を入れれば
とりあえず貫通するバグは無くなる。
でもそもそも判定ロジックが間違ってるので、全部書き直さなきゃダメ。
当たった部分が縦の面か横の面かの判定をしなきゃまともに跳ね返らない。
前フレームの玉の位置と現在の位置を線で結んで、各ブロックの
４つの側面のどこと交差しているかを判定する必要がある。
横面と交差してるならＹだけ反転、縦面と交差してるならＸだけ
反転させる。
玉のスピードが速いと、複数のブロックと同時交差する場合もある。
その時は一番玉に近いブロックとの判定だけに絞り、玉の位置も
そのブロックに接触する直前のポジションまで移動させる。

21 ：

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

22 ：

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

23 ：

>>22
ありがとうございます
しかし読んでみたはいいのですがそれをどう組み込んでいいかがやっぱり思いつきませんでした
なのでがんばって自己流で判定組んでみたら
「○○.exe の 0x0056e0b6 でハンドルされていない例外が発生しました: 0xC0000094: Integer division by zero」
とか出されてしまいました、一体これはどういうことなんでしょうか？

24 ：

ソース
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;

25 ：

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; //次のエリアへの突入時間加算
　　　}
　　}

26 ：

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

27 ：

0除算例外
>>25>>26にある除算全てが該当するな
アルゴリズムまでは読んでないのでほかの人に任せた

28 ：

前のほうでやってるのに忘れていました
とりあえず
ShellXT<ShellYT のところを
ShellXT<ShellYT && ShellXT!=0　にしてみたら動いたは動いたのですが
ボールがあらぬ挙動をします
当たっているのに当たった動きをしなかったり、突然わけのわからないところへ移動したり
原因がさっぱりです……
一応上記の判定は、画面を35*20のエリアに分けて、今いるエリアから別のエリアに移動したら、
そこにブロックが有るか無いか判定、という形で組んでみています
(今更ですが、ブロックを35*20でやっているので、ですね)
もしかしたらこのあたり判定でなく、>>20の方法でやらなければダメなのでしょうか
でしたら、よければそのソースを教えていただけませんでしょうか？

29 ：

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

30 ：

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

31 ：

>>29
間違ってはいないよ。14の考え方は論理的には合っている。
自分で思いついた方法なら、そのまま突き進むのを俺は薦める。
とりあえず、問題がありそうな点
・XT,YTはintだと精度が足りない(AX,AY以外は全てfloatの方が望ましい)
・「左方向に突入」の部分のShellXT=35/ShellVX;は+=の間違い
・XT,YTが1フレーム分の時間を超えていたらループから抜ける必要がある

32 ：

合ってねーよバカｗ

33 ：

なんかわからんけど >>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;
　　　　}
　　　}
　　}
　}
}

34 ：

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

35 ：

回帰性があるんですね

36 ：

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

37 ：

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

38 ：

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

39 ：

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

40 ：

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

41 ：

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

42 ：

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

43 ：

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

44 ：

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

45 ：

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

46 ：

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

47 ：

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

48 ：

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

49 ：

やった事無いから適当に考えるが。
背景の中心、地面の一番奥から一番手前まで直線が引いてあるとして
一番手前の地面を左右にスクロールさせると、その直線は傾く。
けど曲線にはならない。直線のはず。
つまり正比例で座標ずらせばいいってだけじゃないのかな。
それと言っておくが
>答えられないなら無理にレスしなくて結構です
こういう事を言うやつはよくいるが、「自分の性格は悪いです」って公言してるようなもんだから
誰も回答してくれなくなるぜ。

50 ：

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

51 ：

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

52 ：

適当な数式作るにはセンスが重要だよね……
>>48
スト2のリュウステージをラスタースクロールのみで再現しようとするなら、
まず板の継ぎ目がある一点に収束するように引いておく(画面中心点が妥当)。
その点からの相対Y座標を使い、
各ラインのスクロール量X = 立ち位置ラインのスクロール量X * 各ライン相対Y / 立ち位置相対Y
でいいんじゃないかな。
ただ上記の処理だと半画面分スクロールしただけでもドットがボロボロになるので、
普通は拡大縮小処理も一緒に使うと思うよ。
この場合、板は普通に長方形で書いておき左右は均一に、上下は奥に行くほど
小さくなるような雰囲気で色を塗り、
各ラインの拡大率X = 各ライン相対Y / 立ち位置相対Y
で、画面の垂直中心線上のスクロール量が同一になるように補正する。

53 ：

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

54 ：

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

55 ：

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

56 ：

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

57 ：

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

58 ：

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

59 ：

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

60 ：

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

61 ：

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

62 ：

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

63 ：

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

64 ：

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

65 ：

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

66 ：

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

67 ：

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

68 ：

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

69 ：

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

70 ：

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

71 ：

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

72 ：

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

73 ：

Vramの件、みな、どうもご親切にサンクス。
レスおそくなりすいません。カキコできなくて。
何作るかによりますね。すいません。2Dゲーで
Flashで作ったアニメデータがバリバリと動く予定です。
DirectX使っていますので、Vramの確保は必須かもと思っていました。。
ライトユーザーに理解してもらえなくてもいいんですが、
作り手としてってことでしょうか。

74 ：

>>73
72書いた者だけど、質問の意図は分かります。
ただ、どれだけ気にしてもやっぱり動かない環境は残ってしまって、
そういう環境のユーザーほどマシンスペック分からずに苦情出してくるからな〜
すんません。個人的トラウマでした。
否定的な意見はやめて、
DirectXなら、使用するDirectXのバージョンがそのままマシンの世代を表しているって
考えてもいいんじゃないでしょうか？
例えば、DX7使用ならVRAM8MB、DX8ならVRAM32、とか。
あ、値は適当ですが。

75 ：

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

76 ：

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

77 ：

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

78 ：

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

79 ：

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

80 ：

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

81 ：

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

82 ：

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

83 ：

表示する座標 (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との違いは始点と終点の距離にかかわらず同じ時間で終点に到達する

84 ：

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

85 ：

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

86 ：

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

87 ：

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

88 ：

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

89 ：

子曰く
「どうすればいいのか、どうすればいいのか、と考え悩みぬいた者でなければ
　私にもどうしようもない」
最初から他人をアテにしてるようじゃダメってことだな。

90 ：

情弱ですか

91 ：

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

92 ：

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

93 ：

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

94 ：

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

95 ：

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

96 ：

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

97 ：

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

98 ：

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

99 ：

>>94
モデリングとアニメーションツールの勉強から始めなきゃならないじゃん。
プログラミングの勉強としてはすっごく遠回り。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【3Dゲームエンジン】Unity総合スレッド17 (527)
【3Dゲームエンジン】Unity質問スレッド3 (499)
おまえら土日でゲーム作れませんでした☆遅刻専用ｽﾚ (798)
むしろjavascriptでゲーム作ろうぜ (688)
【アイデア命#】配布型ＣＧＩゲームをつくろう (263)
ゲームにおけるデータ構造・クラス設計・パターン2 (603)
--log9.info------------------
横浜線スレ Part44 (781)
西武3ドア車総合スレ Part27 (797)
/// 京急スレッド292 /// (287)
【大阪駅・梅田駅とその界隈を語る】 Part27 (978)
阪急宝塚線・箕面線スレッド　Part44 (659)
【東京〜札幌】北海道新幹線196【4時間以内?】 (421)
JR東日本 211系転属 その3 (718)
近鉄南大阪線系統36 (872)
副都心線と東急東横線 (409)
東北新幹線青森開業は何故失敗したのか？Part4 (615)
JRW221系223系225系125系521系スレ Part.52 (798)
京王線ダイヤ考案スレ 2013.01.04 (382)
JRは中央線快速にE231投入でG車を連結しろよ (244)
東武野田線を語ろう『大宮⇔船橋』Part45 (526)
【E6】秋田新幹線・山形新幹線38【E3】 (253)
駅名しりとり【新ルール Part11】 (317)
--log55.com------------------
【ｲﾂﾏﾃﾞﾓ】アルトラパン【HA21S専用】
【NA上等】ムーヴキャンバス 11号【ターボ不要】
【スバル】R1 part31 【てんとう虫】
【ダイハツ】ウェイク part 20
【スズキ】アルト　Part81【燃費38.3km/L】
【SUZUKI】ハスラー＆ﾌﾚｱｸﾛｽｵｰﾊﾞｰ148台目【軽SUV】
【日産】 DAYZ(デイズ)/ eKワゴン part28 【三菱】
【爽快】！！カプチーノ！！ part87 【軽快】