【 回答してくださる方 】
・ できるだけ優しく質問に答えてあげてください。
・ 優しく教えるのが嫌でしたら、解決するためのヒントだけでも結構です。
「ググれ」以外の回答でおながいします。
・ 神ですら理解不能な質問は無視して下さい。
【 質問する香具師 】
・ どんな事で躓いているのか明確にしる。
・ 長くならないなら躓いている部分のコードを晒してみれ。
・ 解決した場合、お礼を言うのは当然だが、何をどうしたら解決したかを明確に書け。
／ / ハ 「 ヽ､ ､ ＼ ＼へ ｀ヽゝ
／ ノ / /´ ＼ ＼ ヽ ヽ ､ ヽ ＼＼ ｝ }
／イ / / / ,| ヽ ヘ、 ヽ } ﾍ 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:. :. | : : ＼
／＼ : : : : : : : : : : : : : : :| ＼ ＼:. . / : : : : |
グラフィックの表示まで分かれば十分作れると思う。
まあ、本気で勉強すれば半年で、物分りの悪い人でも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;
}
}
}
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クリアしてくれるから便利だよな
http://pc11.2ch.net/test/read.cgi/gamedev/1020417733/
110 名前：名前は開発中のものです。 投稿日：03/05/29 11:44 ID:xadUaM2+
まともだよね
Cがテーマだったりすると厨房は書きこまないのかな
2次元のデータを1次元配列で管理しようとするのは、
俺みたいな昔の貧乏性のプログラマだけでいい。
斜め移動でも座標計算1回で済むとか、そんな貧乏臭い発想。
コンパイル時にサイズ不定でも、簡単なラッパ作ればいい。
2次元のものは2次元のまま扱った方が、デバッグもしやすい。
『延々と西に向かってたら、いつのまにか北極に立っていた』
な…、何をいっているのかわからねーと思うが(ry
１次元でも２次元でもバイナリ的には同じじゃん。
ただ表記方法が異なるだけ。
アクセススピードも同じだから、好きな方使えばいい。
多次元のメモリの確保、開放は少しややこしいけど、
ライブラリとして4次元ぐらいまで作っておけば便利。
日本語わかる？
ブロックとの当たり判定でボールがブロックとぶつかった際、本来跳ね返らなければいけないのに
時々跳ね返らず貫通して進んでしまうことが起きてしまいます、貫通弾はまだ書いてないのに……
どうしたらいいのでしょうか
言語は基本Ｃ、クラスとか途中で変数宣言とかちょっとだけＣ++入ってるかも、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);
}
}
}
}
}
・BlockX、BlockY ：ブロックがｘ･ｙ軸に最大いくつ並んでいるか
・BlockFlag[][] ：ブロックが存在しているかいないか、０以外で存在
・ShellX、ShellY ：弾のｘ･ｙ座標
・ShellR ：弾の半径
・LeftEdge､UpEdge ：ブロック崩しの画面の左端、上端の位置
・ShellVX、ShellVY ：弾のｘ･ｙ速度
当たっているのが縦からなのか、横からなのかの判定がどうにもわからなかったので
当たったらｘ･ｙ速度両方反転するようにしてしまっています
よければその判定方法も教えてください
宜しくお願いします
移動前と移動後の間も含めて接触判定……って
いまいちピンと来ない、どういうことでしょうか？
ボールとブロックの距離が、
ボールの（1 フレームの）移動距離よりも短いとき、
ボールはブロックに衝突することなくすり抜けしまう。
対処方法として、
ボールの移動前後を結ぶ線分との交差判定を行う
ことが挙げられる。
> ShellVX*=(-1);
同時に2つのブロックに接触すると元に戻りそうな嫌なコードだ
>>19でも指摘されてるけど、２つのブロックに同時に触れた場合は
移動方向が元に戻るから貫通するよ。
だから「ShellVY*=(-1);」の後に「break;」を入れれば
とりあえず貫通するバグは無くなる。
でもそもそも判定ロジックが間違ってるので、全部書き直さなきゃダメ。
当たった部分が縦の面か横の面かの判定をしなきゃまともに跳ね返らない。
前フレームの玉の位置と現在の位置を線で結んで、各ブロックの
４つの側面のどこと交差しているかを判定する必要がある。
横面と交差してるならＹだけ反転、縦面と交差してるならＸだけ
反転させる。
玉のスピードが速いと、複数のブロックと同時交差する場合もある。
その時は一番玉に近いブロックとの判定だけに絞り、玉の位置も
そのブロックに接触する直前のポジションまで移動させる。
しかしどういうソースを書けばいいのかがまるで思いつかない……
いったいどういしたらいいのでしょうか？
ベクトルが理解できてないみたいだね。
まずは数学の勉強から始めないと。
線分交差の判定はここを参考にしてみたら？
http://www5d.biglobe.ne.jp/~tomoya03/shtml/algorithm/Intersection.htm
ありがとうございます
しかし読んでみたはいいのですがそれをどう組み込んでいいかがやっぱり思いつきませんでした
なのでがんばって自己流で判定組んでみたら
「○○.exe の 0x0056e0b6 でハンドルされていない例外が発生しました: 0xC0000094: Integer division by zero」
とか出されてしまいました、一体これはどういうことなんでしょうか？
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;
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; //次のエリアへの突入時間加算
}
}
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;
}
}
>>25>>26にある除算全てが該当するな
アルゴリズムまでは読んでないのでほかの人に任せた
とりあえず
ShellXT<ShellYT のところを
ShellXT<ShellYT && ShellXT!=0 にしてみたら動いたは動いたのですが
ボールがあらぬ挙動をします
当たっているのに当たった動きをしなかったり、突然わけのわからないところへ移動したり
原因がさっぱりです……
一応上記の判定は、画面を35*20のエリアに分けて、今いるエリアから別のエリアに移動したら、
そこにブロックが有るか無いか判定、という形で組んでみています
(今更ですが、ブロックを35*20でやっているので、ですね)
もしかしたらこのあたり判定でなく、>>20の方法でやらなければダメなのでしょうか
でしたら、よければそのソースを教えていただけませんでしょうか？
先にベクトルの勉強しろって。
少なくともどちらに跳ね返すかの判定はいるだろう
ボールの速度がブロックの厚みを超えないようにするだけでだいぶ計算量はへるし
間違ってはいないよ。14の考え方は論理的には合っている。
自分で思いついた方法なら、そのまま突き進むのを俺は薦める。
とりあえず、問題がありそうな点
・XT,YTはintだと精度が足りない(AX,AY以外は全てfloatの方が望ましい)
・「左方向に突入」の部分のShellXT=35/ShellVX;は+=の間違い
・XT,YTが1フレーム分の時間を超えていたらループから抜ける必要がある
これでいんじゃね？
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;
}
}
}
}
}
来た方向にそのまま戻ってくだけじゃねーかよｗ
反射させろよｗ
\Program Files以下にsavedataを作るのはまずいのでしょうか？
まずいよ
fopen( )だと NULL が帰ってくるから
プレイする人の環境によって、そのまま保存されたりVirtualStoreディレクトリに
自動的に置き換わったり、警告出たり出なかったりと、動作がまちまちになるからねえ。
savedataどこに作るか悩みますね。。
どこに作るのが一般的なのか調査してきます。
こちらでもアドバイスいただけると幸いです。
CSIDL_APPDATAのが適切かな。
他のアプリでも使う可能性がある場合はMyDocument、専用ならAppDataだな。
ありがとうございます。やはり結論としてはApp dataに落ち着きそうですね。
普通の3D→2Dの座標変換（x､y､z座標を持った物体の画面上の表示場所x、yを求める）
の計算方法は分かるんですが、
今分からなくて知りたいのはラスタースクロールで奥行きを出すときで、
あるY座標に来たときにXをどれだけずらせばいいかを算出する計算方法です。
具体的に言えばストリートファイター2の地面の横スクロール(立体感がついている）や、
古くはマグマックスの地上面の地表みたいな表現です。
簡単に説明できなければお薦めの参考図書を紹介してくれるのでも良いです
お願いします
なんでもかんでも方程式で出さないと気がすまないのか？
答えられないなら無理にレスしなくて結構です
>>47
どういうことですか？
適当にやったらまったく立体的に見えなくてダメでしたので…
背景の中心、地面の一番奥から一番手前まで直線が引いてあるとして
一番手前の地面を左右にスクロールさせると、その直線は傾く。
けど曲線にはならない。直線のはず。
つまり正比例で座標ずらせばいいってだけじゃないのかな。
それと言っておくが
>答えられないなら無理にレスしなくて結構です
こういう事を言うやつはよくいるが、「自分の性格は悪いです」って公言してるようなもんだから
誰も回答してくれなくなるぜ。
"3DRPGプログラミング" この本を買って読んでみなさい。
文句たれるバカが沸くから
結局ユーザに選ばせるしかない
>>48
スト2のリュウステージをラスタースクロールのみで再現しようとするなら、
まず板の継ぎ目がある一点に収束するように引いておく(画面中心点が妥当)。
その点からの相対Y座標を使い、
各ラインのスクロール量X = 立ち位置ラインのスクロール量X * 各ライン相対Y / 立ち位置相対Y
でいいんじゃないかな。
ただ上記の処理だと半画面分スクロールしただけでもドットがボロボロになるので、
普通は拡大縮小処理も一緒に使うと思うよ。
この場合、板は普通に長方形で書いておき左右は均一に、上下は奥に行くほど
小さくなるような雰囲気で色を塗り、
各ラインの拡大率X = 各ライン相対Y / 立ち位置相対Y
で、画面の垂直中心線上のスクロール量が同一になるように補正する。
きめ細かい解説ありがとうございます。
ストIIは実際拡大縮小もやっているのでしょうかね？
それで、修正のリクエストがあったときに
物理法則がどうのこうのと力説したがる
ツクール派？
いちいち質量がいくつで、重力係数がいくつだから・・・・
とかやりだすことだろ
どんなに不自然なジャンプでもそれによってゲーム性にオリジナリティが出るんだからそれでいい。
だが3D表示をするにあたって計算が適当じゃあ3Dに見えないだろ
問題が全く別だよ
トンJンな会話すんな
単純に奥のものが手前にあるもより遅く動いてるだけ
どれくらい遅くするかは作った人間のセンス
たぶん何度も係数をいじって自分の感覚で
ベストと思われる動きでフィックスしてるはず
この感覚が万人に受け入れられない人をセンスのない人という
それを聞いてるんじゃないの？
具体的な係数を聞いてるわけじゃないし、そこはＡとかＢとかでいいじゃん。
Vramの推奨スペックはいくつにすべきか？
ご意見伺いたいです。
3DじゃなけりゃWindowsが使えるだけあればいいよ。
2Dなら800*600*32ビット1画面で2Mバイト
裏画面入れて4Mバイトあればいいんじゃない
現に画面が表示されていれば、VRAM容量は関係ない。
画面表示用バッファは、すべてメインメモリ（DIBなど）に取れるから。
ＶＲＡＭゼロでもかまわないよ。
メインメモリ共有だし。容量だけなら128MB～512MBくらいは普通にある。
2Dゲーなら問題なし。
3Dなら、ユーザーが大目のMMORPGを参考にするといいと思う
大目の日本のMMORPGを
描画周りにアクセラレーション効かせるのってあんまり一般的じゃないの？
どのみちライトユーザーにVRAMとか行っても理解してもらえない。
奴等は自分のマシンのスペック分からずにで、動いたかどうかしか興味が無い。
レスおそくなりすいません。カキコできなくて。
何作るかによりますね。すいません。2Dゲーで
Flashで作ったアニメデータがバリバリと動く予定です。
DirectX使っていますので、Vramの確保は必須かもと思っていました。。
ライトユーザーに理解してもらえなくてもいいんですが、
作り手としてってことでしょうか。
72書いた者だけど、質問の意図は分かります。
ただ、どれだけ気にしてもやっぱり動かない環境は残ってしまって、
そういう環境のユーザーほどマシンスペック分からずに苦情出してくるからな～
すんません。個人的トラウマでした。
否定的な意見はやめて、
DirectXなら、使用するDirectXのバージョンがそのままマシンの世代を表しているって
考えてもいいんじゃないでしょうか？
例えば、DX7使用ならVRAM8MB、DX8ならVRAM32、とか。
あ、値は適当ですが。
DirectDrawなら
IDirectDraw::GetCaps( )で
http://msdn.microsoft.com/ja-jp/library/cc353808.aspx
dwVidMemTotal
ビデオ メモリの合計容量。
どうもサンクス。
トラウマ…なんとなくわかります。
コントロールをドラグ&ドロプ、リリスしたとき、
定位置に整列する（磁石に引きつけられるように）コードの
せめて考え方、ヒントを教えて頂けないでしょうか
線が引ければ途中のXY座標もわりだせるだろう。
移動前の座標 (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との違いは始点と終点の距離にかかわらず同じ時間で終点に到達する
磁石は距離が近くなるほど磁場が強くなるので、遠いほど遅く、近くなると速くなる。
つまり真逆。
参考にしたいのですが、ググり方が悪いのか出てきません
ソースの置いてある場所があったら教えて頂きたいのですが、ないですかね
ぐぐってパクるだけで分け与えなければどこにもなくて当たり前じゃないですかね
馬鹿ですかね
ガキ臭い煽り方だな
なんか嫌なことでもあったのか
「どうすればいいのか、どうすればいいのか、と考え悩みぬいた者でなければ
私にもどうしようもない」
最初から他人をアテにしてるようじゃダメってことだな。
格闘げーはアニメーション画像が命みたいなところがあるから、
素材の用意が大変過ぎてプログラミングの教材には向かない罠。
逆にいえばアニメーション、当たり判定、キー入力ができれば作れるともいえる
キー入力はちょっと特殊だけどそれ以外はインベーダーゲームの応用
アレのすごい所って主に物理演算の部分だろ？
まったく別問題な希ガス
あの程度なら余裕なはず
プログラムは出来るけどCGに関してはまったくの素人なんで
モデリングとアニメーションツールの勉強から始めなきゃならないじゃん。
プログラミングの勉強としてはすっごく遠回り。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
GameDevWikiを何とかするスレ (564)
【初心者】ステフと一緒にゲーム製作part10【歓迎】 (821)
クロックタワーの続編を作るスレ2周目 (673)
リアルタイムストラテジーの話 (639)
OpenGL (517)
FLASHでゲームをツクール (368)
--log9.info------------------
♪【音楽】ＮＦＬの試合で流れてる曲【歌】♪ (557)
NFL倶楽部 (710)
東京経済大学ファルコンズ (381)
NFL現役QBベスト5挙げてくれ (268)
【MLS】アメリカ・サッカー【アメリカ代表】Vol.2 (384)
同志社は、どうすれば立命を下せるか (445)
史上最低なクオーターバック選出 (399)
アメフトはじめたいです (534)
ダンジー監督とともに苦難を乗り越えてゆくスレ (272)
Washington Redskins 応援スレ (691)
甲子園ボウルを生中継しない毎日放送はR (216)
★ K G ファイターズ 応援スレ★ (355)
【 同志社 】 WILD ROVER (356)
【大混戦】関西学生Div.3総合【模様】 (603)
早稲田のアメフトについてⅢ (324)
なぜアメフトは野球のように世界的に普及しないの？ (244)
--log55.com------------------
★2ch.scは何故失敗したのか
★クロール批判要望スレ
★削ジェンヌに文句ある人集合
★迷惑行為報告担当 - 小さな親切募集中 2
★2ch.scへの要望スレ Part3
★かっこう観測所
★スレ立て人キャップ
★2ch.scニュース系板観測所
