13/04/21 15:41:16.06
エロゲしか作ったことないけど
なんでも聞いてちょ
【前スレ】
ゲームプログラムなら俺に聞け27
ｽﾚﾘﾝｸ(tech板)
次スレは>>950が立てること。
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
2:デフォルトの名無しさん
13/04/21 15:44:45.54
モルピグ
3: 忍法帖【Lv=40,xxxPT】(1+0：5)
13/04/21 18:17:09.19
tes
4:デフォルトの名無しさん
13/04/21 21:09:47.24
ここって>>1以外にテンプレないの？
28スレ目ともなればあっても良さそうだが
5:デフォルトの名無しさん
13/04/22 21:12:32.77
テンプレも作られないような存在価値皆無のスレです
ごめんなさい
6:デフォルトの名無しさん
13/04/22 22:42:37.85
モルピグ厨の巣窟
7:デフォルトの名無しさん
13/04/24 21:29:35.73
mainのループの呼び名は
メインループでいいですか？
8:デフォルトの名無しさん
13/04/25 09:34:08.78
別にmainに無くてもいいけど
9:デフォルトの名無しさん
13/04/25 15:49:40.89
>>7
知らないけど俺はそう呼んでる
10:デフォルトの名無しさん
13/04/26 00:34:35.98
>>7
C++とかは知らんけど、iOSとかのObjective-Cはイベントループと呼ぶ
11:デフォルトの名無しさん
13/04/27 01:07:34.43
まあメインループとか描画ループとか呼んでたな。
12:デフォルトの名無しさん
13/04/27 02:59:35.03
DirectXSDKって2006年だか2008年だかのが最新！？
はっきり覚えてないけど、この間SDKを最新版にしようと思って探したらそれくらい古いのしか見つからなかった
13:デフォルトの名無しさん
13/04/27 13:52:59.36
DirectX SDK Version 一覧
URLﾘﾝｸ(dench.flatlib.jp)
14:デフォルトの名無しさん
13/04/27 14:43:36.45
DirectXもXNAもオワコン
15:デフォルトの名無しさん
13/04/27 16:42:18.76
質問です。
モルピクの通信データの圧縮ってどうすればいいのでしょうか？
現在、プレイヤーの数が増えてきたため、プロバイダの帯域制限に引っかかりそうでヒヤヒヤしています。
アップデートして無駄なところは極力減らした(後に拡張することがあってもいいように用意していたヘッダを8バイトから4バイトに減らすなど)のですが、
そろそろ限界です。
プロバイダは変えるつもりですが、まだどこにするかも決まっていないので、変えるまでに3か月くらいはかかると思います。
それまで何とか乗り切りたいのです。
16:デフォルトの名無しさん
13/04/27 18:03:35.18
またモルピグさんかｗ
そんな一般性ゼロの単語誰もわかんねーよ。
17:片山博文MZパンク ◆0lBZNi.Q7evd
13/04/27 19:09:17.98
>>15
zlib
18:デフォルトの名無しさん
13/04/27 19:34:18.19
>>15
どういうプロトコルかにもよるけど
1バイト単位で調べて同じ値が連続してたらまとめるとか
そういうのしかないしんじゃない
19:デフォルトの名無しさん
13/04/27 20:22:38.81
>>15
どうせまだ他にも無駄があるんだろ
20:デフォルトの名無しさん
13/04/27 20:40:44.19
モルピグって用語使ってると特定されて嫌がらせ受けると思う
21:デフォルトの名無しさん
13/04/27 21:55:59.03
既に動いているのにそんな抽象的な質問しても
的はずれな回答にしかならん
22:デフォルトの名無しさん
13/04/27 23:05:47.69
流行ってたころならともかく、ソーシャル全盛の今の時代に
そこそのMMO運用してるならとっくに特定されてもおかしくないはず
というわけで実際はモルピグ名乗るのもおこがましいほどのカスか脳内の話だろう
23:15
13/04/27 23:40:00.37
>>18
ありがとうございます。
それでどの程度圧縮できるか分かりませんがやってみます。
>>19
無駄な部分はかなり修正したのでほとんどないはずですが・・・もう少し調べてみます。
24:デフォルトの名無しさん
13/04/27 23:50:34.49
ゲームの強いセーブデータを配布したりできないように暗号化したいんだがいい方法ない？
25:片山博文MZパンク ◆0lBZNi.Q7evd
13/04/27 23:53:56.90
>>24
他のPCで使えないようにしてしまう。例えばPC固有のデータを確認するとか
26:デフォルトの名無しさん
13/04/27 23:57:30.92
NICのMACアドレスあたりを埋め込んでおくのが手軽かな
今時NIC無しのパソコンなんか無いだろうし
27:デフォルトの名無しさん
13/04/28 01:13:17.78
イーサ設定なんかいくらでも偽装できる
28:デフォルトの名無しさん
13/04/28 01:28:12.77
配布する側はともかく、そんなのを落としてくる人がいちいち偽装するかな
29:デフォルトの名無しさん
13/04/28 02:44:38.00
それを言ったら
セーブデータを落としてくるほど価値があるクリア特典のあるゲームor金が絡むMMO→偽装に対しても頑健である必要がある
それ以外→別にセーブデータ出回ってもいいし。自分の労力に見合う苦労させたいっていう開発側のオナニーじゃない？
コスパ的にも楽してストーリーだけ楽しみたいってユーザーのプレイスタイルを縛り付ける意味はないと思う
30:デフォルトの名無しさん
13/04/28 04:31:52.66
>26-28
MACアドレスって調べてみたけどこれでいいわ
NICのMACアドレスを埋め込んであるかどうかすら知らなかったら
MACアドレス偽装もしようがないだろ
そこまで調べあげて偽装するような奴には破られてもいいわ
31:デフォルトの名無しさん
13/04/28 06:09:25.49
セーブデータがロードできないバグに悩まされる未来が見える･･･
32:デフォルトの名無しさん
13/04/28 09:48:19.49
お手軽な方法としては否定するわけじゃないけど
o 正規ユーザーに「個人用途においても他のPCにセーブデータの移行はできない」と明記する必要がある
o PCの修理で基盤交換するとロードできなくなる
o MAC検証を回避するexeパッチが出回った時点でカジュアルユーザーにも無力になる
…ぐらいは想定した上で導入しなよ
33:デフォルトの名無しさん
13/04/28 12:10:38.01
>>30
そこまで調べあげて偽装するような奴は、破った後に、
誰でも簡単に破れて簡単に改造できるスクリプトやツールをばらまくよ
34:デフォルトの名無しさん
13/04/28 12:19:17.94
こんなスレで聞くくらいだし、フリーソフトでちょっとズルをやりにくくするくらいの意味合いじゃないのかな？
改造ツールがバラまかれる規模ならもうちょっと別の対策を考えた方がいいかもね
35:デフォルトの名無しさん
13/04/28 12:32:20.70
>>33
>>15 のような奴もこんなスレで訊いている現状、
求めている質については回答者の方からは何とも言えんので、
一応そういうことも想定できるよと、可能性を述べました
今回はそこまで求めてなくても、「なるほど、そういうこともあるのか」と
頭の片隅にでも入れておいてくれたら、それでいいよ
36:35
13/04/28 12:33:01.63
ごめん、アンカーミス
>>34
37:デフォルトの名無しさん
13/04/28 12:42:26.57
MACを埋め込むんじゃなくて、MACをキーに暗号化すれば検証回避とかは出来ないんじゃね？
38:デフォルトの名無しさん
13/04/28 13:20:51.62
いや、だからさ
39:デフォルトの名無しさん
13/04/28 21:41:07.04
早く乳揺れ見せて
40:デフォルトの名無しさん
13/04/28 22:17:02.58
何言ってんだお前
41:デフォルトの名無しさん
13/04/29 03:32:01.91
なんか作ろうぜ
42:デフォルトの名無しさん
13/04/29 17:21:51.04
最近のパソコンなら家電量販店に売ってるやつでもシェーダが使えると思ってていいの？
訳：ここ2年以内に発売されたパソコン(デスクトップ・ノートを含むが、タブレット・ネットブックを除く)であれば、
家電量販店で販売されているものの80%以上でシェーダ5.0を利用可能ですか？
43:デフォルトの名無しさん
13/04/29 19:09:47.09
>>42
IvyBridge SM5.0 (2012/04～)
SandyBridge SM4.1
CPUがSandyBridgeでビデオカード積んでないPCがどれくらいの割合か分からん。
44:デフォルトの名無しさん
13/04/30 21:36:44.45
Win32APIのみで3Dゲームのライブラリって作れる？
45:デフォルトの名無しさん
13/04/30 21:53:39.05
DirectX を使わないとかいう訳のわからない主張でない限り、Yes
46:デフォルトの名無しさん
13/05/01 00:21:47.48
わけわからなくないよ底辺の俺でさえDIBで3Dレンダリングをスクラッチから組んだことあるし
47:デフォルトの名無しさん
13/05/01 00:30:18.31
それは3Dゲームではない別の何か
48:デフォルトの名無しさん
13/05/01 21:25:55.89
>>44
テクスチャ無しでよければ、
頂点色有りのトライアングルが描画できる関数があったはずだからそれ使えば？
たしか、GDI+か何かの関数だったと思う。
49:デフォルトの名無しさん
13/05/01 21:48:40.52
頂点色によるグラデーション付き塗りつぶしも、
3D空間で真面目にやるならパースペクティブコレクトが必要なんだがね
50:デフォルトの名無しさん
13/05/01 22:07:22.51
まったくだな
3Dもそうだけどライブラリに頼り切ってアルゴリズムの書けない連中だらけになった
51:44
13/05/01 22:30:41.78
DirectXを使わないと現実的じゃないってことでOK？
52:デフォルトの名無しさん
13/05/01 22:32:17.58
>>51
OpenGLを使うという選択肢もある
53:デフォルトの名無しさん
13/05/04 00:21:57.88
お前らはゴールデンウィーク中にどんなゲーム作る？
54:デフォルトの名無しさん
13/05/04 09:57:46.23
ゲームじゃないが水の物理シミュ
55:デフォルトの名無しさん
13/05/04 10:52:16.74
SPH法難しい
56:デフォルトの名無しさん
13/05/04 12:22:43.31
みんなそれなりに充実しているようだね
俺もなんかしないとなぁ
57:デフォルトの名無しさん
13/05/05 02:35:42.49
エリアレベルでの半透明のリアルタイムレンダリングってどうやるの？
RPGの戦闘でコマンドを選ぶところで、
「魔法」を選んだら、次は魔法の種類を選んで、最後に対象の敵を選ぶ
古典的な入力方法。
但し、「魔法」コマンドを選んで次の魔法一覧が出ても、
「魔法」コマンドを含むエリアが消えずに半透明グラデーションで残したい。
攻撃 ファイア
魔法 サンダー
アイス
↑これが、「魔法」コマンドを選んだ後の魔法の種類を選択するときの状態。
「攻撃」「魔法」と書かれてるエリアは消えずに、
そのエリアは文字も含めて右から左へ半透明でフェードアウトした状態で描画したい。
そこからサンダーとか適当に魔法を選んだら今度は、
ファイア 盗賊A
サンダー 盗賊B
アイス
↑みたいに対象の敵を選択できる状態になるけど、
このときも「ファイア」「サンダー」「アイス」を含むエリアは完全には消えずに
右から左にフェードアウトした状態にしたい。
しかも各選択時にはパッと変わるのではなくて、スライドするように変えたい。
58:デフォルトの名無しさん
13/05/05 02:37:12.03
環境はWindows7でDirectXは9で開発してる。
つーか説明が分かりにくいから画像にするわ。
59:デフォルトの名無しさん
13/05/05 03:29:22.18
画像にした。
とりあえずこんな感じで攻撃とか魔法とか出てて、
URLﾘﾝｸ(age2.tv)
魔法を選択するとコマンドがスライドしていって・・・
URLﾘﾝｸ(age2.tv)
次のコマンドが表示されたときはこの状態になる。
URLﾘﾝｸ(age2.tv)
そこからさらにコマンド選択するとこういう状態になる(スライド過程は省略)
URLﾘﾝｸ(age2.tv)
このコマンドの半透明をリアルタイムレンダリングしたい。
エリアだけなら半透明グラデーションかけた画像を用意すればすむんだが、
文字なんかは、例えば魔法の習得順序がプレイヤー全員同じでないから、
画像として準備するのが難しいし、
文字をこのグラデーションの画像として準備するとかなりの量になる。
だからリアルタイムでやりたいんだけど、これをDirectXで実現するにはどうしたらいいんだ？
60:デフォルトの名無しさん
13/05/05 03:52:41.12
１．シェーダを書きます
終了
61:デフォルトの名無しさん
13/05/05 10:28:48.86
>>57
リアルタイムでオフスクリーンに文字をレンダリングして、
それをテクスチャにしてビルボードをバックバッファにレンダリング。
その際に頂点カラーとしてアルファ値を設定し、アルファブレンディングを有効化しておく。
シェーダーがまともに使える以前は、たとえばこんな風にして実現していた。
62:uy@右翼
13/05/05 11:01:37.53
最近世界情勢の事調べてんだけどさあ
そこから推察すると日本のITが全体的に失墜し始めた理由は
韓国と台湾と中国にそれぞれ日本の技術と市場を売ったからだな
韓国にはソフトウェア技術
台湾には基盤技術
中国にはその両方ってところか
売った理由は戦後賠償
日本経済が伸びすぎたから米国から待ったをかけられて
｢市場｣そのものを売るといいか明け渡すように要求されたものと思われる
日本の技術はたしかに最高峰なんだけど、中小が、だから通りで虚業化してるんだ
そしてアニメ関係がかろうじて生き残った
理由は簡単
日本人以外には出来ないから
真似が出来ない。神風と同じだね
日本は、日本以外でも出来る産業はいくらでも奪われるような立ち位置なんよ
中韓からの撤退につきこれから東南アジアにもおそらく｢市場｣そのものを売りにいく
だからさ、他国に真似されない産業を作っていかないと生きていけない
イプシロンロケットや10式戦車くらいになると
技術を奪われるにしてもイギリスとアメリカ相手くらいでそっちでも極秘扱いになるはずだからまだいいとしても
発展途上国に対し金だけじゃなくいろんなものを売ることを要求される日本は
ありきたりな産業で生きてる中小企業は政治家の指先ひとつでどんどん生存厳しくなっていく
これが俺様の推察した、日本のIT不況の根幹にあるものだ
63:デフォルトの名無しさん
13/05/05 11:03:41.25
読んでないけど遠目にもスレチとわかるのでやめてください
64:デフォルトの名無しさん
13/05/05 15:10:51.88
>>60-61
ありがとう。
シェーダってそんなに便利なものなのか。
ちょい勉強してみる。
65:デフォルトの名無しさん
13/05/06 11:33:13.71
キャラの回転移動伸縮の指定は絶対指定と相対指定どっちでやってる？
絶対指定だと回転移動伸縮指定の指定順序を記憶しないと
回転だけリセットとか難しいよね（例：回転して移動して正面を向かせる）
かといって相対指定だと蓄積誤差とかが気になる
みんなどんなやりかたしてる？
66:デフォルトの名無しさん
13/05/06 14:59:27.58
蓄積誤差は気にせずにやってる
67:デフォルトの名無しさん
13/05/06 16:12:07.60
じゃあなんも考えずに変換行列にどんどんかけちゃって行けばいいかな
68:デフォルトの名無しさん
13/05/06 20:38:43.71
気になるとか、そういう感情はとりあえず脇に置いておいて（まぁ時には直感も大事だが）、
どのようなシーンで、どの程度の誤差が蓄積して、どのような問題が起きたか、
という視点で考えたほうがいいと思う。
実際に問題が起きるのなら、その誤差を減らす方法か、シーンを変えることを考える必要がある。
問題が起きない程度の誤差なら、誤差が蓄積している事だけ覚えておいて、あとは無視できる。
趣味でゲームを作る場合、作る前に悩んでも仕方がないし、意味がない。
これから起こるかもしれないことに対して対策を考えても、
その対策が有功か検討するのに結局作ってみなければならないのだから、
それなら作ってみて問題が起きてから、それに対する対策を考える方が建設的だ。
69:デフォルトの名無しさん
13/05/06 21:46:59.73
>>68
ライブラリの設計なので後で変更するのがきついんすわ
最終的にはテストコード書いて検証する必要あるけど
とっかかりとして、普通どっちでやってるのかなと
70:デフォルトの名無しさん
13/05/06 22:25:02.33
>>69
そんなのキャラの動かし方やシーンによって変わるよ。
3Dのフィールド上に立っているキャラをプレーヤーのコントロールで歩かせる場合は、
相対値で十分だし、その方が自然だ（基準値をどこかに設けるほうが不自然）。
たとえば 5秒前進した後で5秒後退し、画面上の見た目で最初と数ドットずれていたとして、
プレーヤーはそれに対して怒ったりはしないし、気づかない人が大半だ。
（そのズレがゲーム性に関わるのなら問題だが。例えば横スクロールアクションとか）
でも、キャラを中心に一定の半径をもってエネルギー流が回転するシーンの場合、
回転するごとに誤差のせいでその半径がどんどん広がっていったらおかしい。
こちらは、基準値となる座標や角度を設けて、相対的ではなく絶対的な回転角度から計算すべき。
だから、ライブラリなら両方使えるようにしておくのがいい。
一方でもう一方を実現するなんて不自然なことをプログラマにさせたくないのなら、ね。
71:デフォルトの名無しさん
13/05/06 23:31:44.04
両方かーめんどうだな
回転移動伸縮回転移動伸縮…したあとで移動だけ絶対指定した場合
現在の変換行列に移動を打ち消す行列かけてから新しい移動行列かけるわけだよな
相対指定の履歴を全部で保存しておいて逆順に逆行列掛けてくのがいい？
72:デフォルトの名無しさん
13/05/07 18:54:17.25
>>71
すまんが、言いたいことがよく分からん。
相対指定も絶対指定も指定するために必要なものは変わらんと思うが。
今回施す変換行列と、変換の基準となる行列、この2つを指定すればいい。
相対指定なら、基準となる行列とは前回まで積み重ねた結果の変換行列のこと、
絶対指定なら、基準となる行列とはなにか適当な変換行列のこと（キャラの中心とか、ワールド座標系とか）。
> 回転移動伸縮回転移動伸縮…したあとで移動だけ絶対指定した場合
そのような要望をするのは、そのライブラリを使うプログラマ側だよな。
なにを絶対指定の基準とするかはそのプログラマにしか分からん。
であれば、基準となる変換行列はプログラマ側に指定させるしかない。
> 現在の変換行列に移動を打ち消す行列かけてから新しい移動行列かけるわけだよな
それは絶対指定にならないのでは？ 打ち消す行列をかけた時点で誤差が蓄積する。
> 相対指定の履歴を全部で保存しておいて逆順に逆行列掛けてくのがいい？
絶対指定（を以後続けること）において、記憶させておかなければならないことは、
今までの変換の履歴ではなくて、基準となる変換行列の方だと思うが。
並進変換（平行移動）だけ絶対指定して、回転変換などは相対指定したいのなら、
並進変換の基準となる変換行列だけプログラマに保存してもらえばいい。
逆に相対指定の場合は、基準となる変換行列は今までの変換の積み重ねだが、これはライブラリ側で把握可能だ。
今までの積み重ね全てではなく、前回の最終計算結果だけ保存しておけばいい。
インターフェースとしては、基準となる変換行列を null 値で指定されたら、
相対指定されたとみなして、最終計算結果を基準となる変換行列として計算すればいい。
そうすれば、相対指定と絶対指定でインターフェースを分ける必要がなくなる。
73:デフォルトの名無しさん
13/05/07 23:12:49.33
>>72
認識が食い違ってる
基準となる変換行列は常に単位行列で
・平行移動絶対指定⇒回転・拡縮状況はそのままにキャラを"変換行列が単位行列のときの位置"に平行移動しそこから絶対指定された量平行移動させる必要がある
・回転絶対指定⇒平行移動・拡縮状況はそのままにキャラを"変換行列が単位行列のときの姿勢"に回転しそこから絶対指定された量回転させる必要がある
・拡縮絶対指定⇒平行移動・回転状況はそのままにキャラを"変換行列が単位行列のときの大きさ"に拡縮しそこから絶対指定された量拡縮させる必要がある
それとプログラマ側には行列演算を意識させたくないので
glTranslateみたいなIFだけ用意してる
74:デフォルトの名無しさん
13/05/07 23:16:02.75
>>72
追記
[移動|回転|拡縮]相対指定を繰り返したあと[移動|回転|拡縮]絶対指定することもある
75:デフォルトの名無しさん
13/05/08 00:27:45.34
絶対指定って座標じゃないんだ
76:デフォルトの名無しさん
13/05/08 12:51:33.70
>>73
なんとなく意味がわかってきた。
それなら、スケーリング変換行列と回転変換行列と並進変換行列、
それぞれを保存するバッファを用意すればいい。
Msb : スケーリング変換行列を保存するバッファ
Mrb : 回転変換行列を保存するバッファ
Mtb : 並進変換行列を保存するバッファ
今回施すそれぞれの変換を次のものとする。
Ms : 今回施すスケーリング変換行列
Mr : 今回施す回転変換行列
Mt : 今回施す並進変換行列
全ての変換で「相対指定」するのなら、新しいベクトル V' を
ベースとなるベクトル V から次のように計算する。
Msb = Ms * Msb
Mrb = Mr * Mrb
Mtb = Mt * Mtb
V' = Msb * Mrb * Mtb * V
もし、回転換のみ「絶対指定」するのなら次のように計算する。
Msb = Ms * Msb
Mrb = Mr
Mtb = Mt * Mtb
V' = Msb * Mrb * Mtb * V
つまり、相対指定するなら、バッファに新たな行列をかけて計算を積み重ねる。
絶対指定するなら、バッファに新たな行列を代入する。
（これが、変換を打ち消す行列をかけることと同義だ）
77:76
13/05/08 12:54:12.60
>>73
すまん、>>76 の掛け算の順が逆だった。
スケーリング変換行列からかけないと結果が無茶苦茶になるな。
正しくは、
全ての変換で「相対指定」するのなら、新しいベクトル V' を
ベースとなるベクトル V から次のように計算する。
Msb = Ms * Msb
Mrb = Mr * Mrb
Mtb = Mt * Mtb
V' = Mtb * Mrb * Msb * V
もし、回転換のみ「絶対指定」するのなら次のように計算する。
Msb = Ms * Msb
Mrb = Mr
Mtb = Mt * Mtb
V' = Mtb * Mrb * Msb * V
78:デフォルトの名無しさん
13/05/08 14:21:42.73
いきなりライブラリ作ろうとするからだろ
「この程度の蓄積誤差なら問題ないな」とか
「このくらいになってくるとヤバいな」とか
もうちょっとノウハウを蓄積させてからのがいいって
79:デフォルトの名無しさん
13/05/08 17:25:59.45
参考までに俺がゲーム用ライブラリを作るときの手順は、
1.まずその分野のゲームを作る
2.将来ライブラリ化する予定の部分は別ファイルにして#includeするだけで使えるようにして作っていく
3.マジックナンバーを削ってマジックナンバーだった部分は初期化などで設定できるようにする
4.それをincludeするだけで使えるか確認するために同じ分野の別ゲーを作る
5.前回では見えなかった特定のゲーム依存の部分を汎用できるようにブラッシュアップ
6.ライブラリ化
7.その頃にはその分野のゲームを作るのに飽きている
素人でもこの手順でやれば作れる
もちろんプロは設計から入るからこんな手順踏まないけど
80:デフォルトの名無しさん
13/05/08 20:00:44.24
プロはしっかり設計してしっかりテストして
思いつきの仕様変更にしっかり振り回されて
大人の都合でプラットフォーム変更されてしっかり泣く
81:デフォルトの名無しさん
13/05/08 21:14:41.30
>>77
ありがとう。
そんな感じで書きはじめてみた。
82:デフォルトの名無しさん
13/05/09 05:08:49.79
DirectXのZバッファが思い通りに効いてくれません。
以下のようにA～Eのテクスチャをスプライト->Drawで描画しています。
A 0.8f
B 0.4f
C 0.4f
D 0.2f
E 0.1f
基本的にZバッファは効いてくれているのですが、ところどころ問題が起きます。
〇Bを描画するとCが最全面にきます。
〇Cをコメントアウトすると、Eが描画されなくなります。
〇CにAより深い値を設定してもAの背面にはならず、Dの背面にはなります。
AutoDepthStencilFormatはD16と、D24S8の両方で試しましたが同じでした。
Draw直前で引数に与える位置座標(D3DXVECTOR3)のz成分は上記のままだったので問題ありませんでした。
毎フレーム描画前のデバイス->Clearには2番目の引数でZバッファをクリアする旨、クリアは1.0fまでする旨書いてあります。
DirectXは9使ってます、OSは7、言語はC/C++です。
83:デフォルトの名無しさん
13/05/09 14:54:46.59
さらに不可解な現象が発生しました。
問題の切り分けをさらに細かくしようとして変数を宣言していたところ、
DとEの間でD3DXVECTOR3 test;と宣言するとDとEが描画されない事案が発生。
Dより前に宣言しても同様でした。
描画自体は別のクラスに投げていて、そのクラスにはそのtestは渡していません。
宣言するだけでEが描画されなくなります。
グローバルにtest変数があるわけでもなく、testを他の絶対に使用していない名前に変えても同様の現象になります。
これも上記の不具合に関係ありそうです。
■D、Eが問題なく描画される場合
D3DXVECTOR3 test;//グローバル・ローカルに関わらずプログラム中で1回も使ってない名前
Draw_DE();
BOOL Draw_DE(){
D描画
E描画
return TRUE;
}
■D、Eが描画されなくなる場合
Draw_DE(){
D3DXVECTOR3 test;//グローバル・ローカルに関わらずプログラム中で1回も使ってない名前
D描画
E描画
return TRUE;
)
84:デフォルトの名無しさん
13/05/09 15:55:49.24
解決しました・・・が、ってか、え？？？？？？
解決後の検証結果、スプライト->Draw()に渡しているRECTやD3DXVECTOR3変数が、スプライト->End()、もしくは、デバイス->EndScene()以前に破棄されると>>82-82の問題が発生するようです。
スプライト->Draw()に渡していたそれらの変数がローカル変数で、スプライト->End()、デバイス->EndScene()の前に破棄されていたため発生した問題のようです。
■問題が発生する場合
デバイス->Clear(引数省略);
デバイス->BeginScene();
スプライト->Begin();
Draw_Test();
スプライト->End();
デバイス->EndScene();
デバイス->Present(引数省略);
BOOL Draw_Test(){
D3DXVECTOR3 pos , cen;
RECT rc;
(変数に値を設定)
スプライト->Draw( テクスチャ , &rc , &cen , &pos , 0xFFFFFFFF );
return TRUE;
}
■問題が発生しない場合
D3DXVECTOR3 pos , cen;
RECT rc;
デバイス->Clear(引数省略);
デバイス->BeginScene();
スプライト->Begin();
(変数に値を設定)
スプライト->Draw( テクスチャ , &rc , &cen , &pos , 0xFFFFFFFF );
スプライト->End();
デバイス->EndScene();
デバイス->Present(引数省略);
85:デフォルトの名無しさん
13/05/09 15:57:58.10
■問題が発生しない場合２
D3DXVECTOR3 pos , cen;
RECT rc;
デバイス->Clear(引数省略);
デバイス->BeginScene();
スプライト->Begin();
Draw_Test( &rc , &pos , &cen );
スプライト->End();
デバイス->EndScene();
デバイス->Present(引数省略);
BOOL Draw_Test( RECT *rc , D3DXVECTOR3 *pos , D3DXVECTOR3 *cen ){
(変数に値を設定)
スプライト->Draw( テクスチャ , rc , cen , pos , 0xFFFFFFFF );
return TRUE;
}
この2通りの問題が発生しない場合から考えて、最初に述べた結論で間違いなさそうです。
というか、こんな縛りがあるなんて驚きです。
これってプログラムでは普通なんですかね。
※(引数省略)・・・問題の本質に関係ないため、この投稿で省略したという意味です。
86:デフォルトの名無しさん
13/05/09 16:13:32.81
ブレークポイントをあちこちに仕込んだり変数の中身を表示したりとかなり手こずりました。
解決したもののかなり運に近かったような気がします。
rcもposも使い回してるので内容も変わりまくってるはずで、
その変数がスプライト->Draw()する瞬間以外にも参照されているということになりますよね。
不可解です。
なにはともあれ、解決して良かったです。
これもみなさんに回答や助言を頂いたお蔭です。
みなさんのお力添えがなければもっと悩んでいたと思います。
やっと眠りにつくことができます。
おやすみなさい。
87:デフォルトの名無しさん
13/05/09 17:51:18.12
どういたしまして
88:デフォルトの名無しさん
13/05/09 20:06:36.98
検証はしないが
もし本当なら有り得ない欠陥
89:デフォルトの名無しさん
13/05/09 22:56:15.34
誰か検証してよ
90:デフォルトの名無しさん
13/05/11 16:34:27.32
ゲーム作るならjavaとcのどっちがいいんだ？
91:デフォルトの名無しさん
13/05/11 16:49:52.83
きちんとデバッグできてDirectXとか使いたいならC
お手軽に作ってデバッグもCより楽にやりたいならJava
92:デフォルトの名無しさん
13/05/11 17:00:35.28
適当にサイコロ振ってどっちか選んで、とりあえず全力で完成させてみろよ。
本当はどっちが作り易かったのか考えるのはその後でいい。
93:デフォルトの名無しさん
13/05/11 17:04:55.69
javaにする
とんくす
94:デフォルトの名無しさん
13/05/11 17:42:05.22
お手軽だとは思うが
丸投げで聞いてくるレベルでは情報が少なすぎてツライかも
95:デフォルトの名無しさん
13/05/11 17:58:24.32
>>79
そのまとめたライブラリは
クラスにまとめてる？
それかextrunを使って分かりやすくグローバルにしてる？
96:デフォルトの名無しさん
13/05/11 18:04:19.22
「描画ループって何ですか？」というレベルでは何を使っても
ゲームは完成しない。
97:デフォルトの名無しさん
13/05/11 18:47:35.38
描画ループって、どういうループ構造の事を指してるんだ？
メインループとか、Windowsアプリのメッセージループとかなら、
while (...) { ... } という構造でループしてるなってすぐ分かるが。
描画ループは、描画処理の部分だけでひとつの輪っかを成しているのか？
ってことは、メインループとかとは別スレッドか・・・
98:デフォルトの名無しさん
13/05/11 19:34:41.96
>>97
当たり前だろ
このご時世シングルスレッドで作るゲームって数当てゲームくらい
99:デフォルトの名無しさん
13/05/11 20:03:57.11
Now loadingの画面でアニメーションさせられるのは
HDDからの読み込みとアニメーションが別スレッドで動いてるからですか？
100:デフォルトの名無しさん
13/05/11 20:08:06.11
>>98
そういうことなら、描画ループを知らないレベルでもゲームは完成させられるはず。
なぜなら、以前まではそのレベルで、数当てゲーム以上のクオリティのゲームを完成させていたから。
何を使ってもゲームは完成しない根拠をもう少し詳しく説明してほしい。
101:デフォルトの名無しさん
13/05/11 20:14:56.04
はい
102:デフォルトの名無しさん
13/05/11 20:57:57.96
どうでもよさ過ぎて鼻水でた
103:デフォルトの名無しさん
13/05/11 21:32:18.27
RestoreHanamizuToNoseOf(102);
104:デフォルトの名無しさん
13/05/12 18:40:49.91
ゲームの技術じゃなくて今のスマホの流行ってどうなってんの？
例えば3Dとかはスマホでは完全に定着してるのですか？
105:デフォルトの名無しさん
13/05/12 18:48:12.16
>>104
3Dどころか、プログラマブルシェーディングも完全に定着しています。
106:デフォルトの名無しさん
13/05/12 18:57:32.46
スマホ内部の組み込みプログラミングのレベルでは3Dでも
普通に使われてるけどAndroidのアプリはJavaだから無理。
107:デフォルトの名無しさん
13/05/12 19:13:33.78
でスマホのゲームってほとんどが無料じゃん？どうやって稼いでるの？
作り損？
108:デフォルトの名無しさん
13/05/12 19:51:23.82
そういうのはゲーム会社に就職できたらわかるかるから
がんばって就職してね。その気がないなら気にしたって
しょうがないでしょ。ビジネスモデルは自分で調べる。
109:デフォルトの名無しさん
13/05/12 21:01:21.61
>>106
内部組み込みとか意味不明。
AndroidはC++でプログラムは作れるんだが、
ndkも知らないのに知ったかするな。
jniは組み込みじゃないからな。
ついでにいうとJava単独でもシェーダぐらい呼び出せる。
110:デフォルトの名無しさん
13/05/13 09:58:37.77
>>107
趣味か、広告で稼いでるか
ガチャなどで一部の人から搾取して稼いでる
111:デフォルトの名無しさん
13/05/13 12:29:09.34
ビジネスはスレチ
112:デフォルトの名無しさん
13/05/14 19:42:57.82
C++のアクションゲームで
プレイヤーや敵キャラのクラスは
いろんなステージで使うからstaticにしてるのだけど
どんどんstaticが増えてきて困ってる
本来はどうやってまとめるものなの？
113:デフォルトの名無しさん
13/05/14 20:14:43.57
面の状態を記憶する領域をシングルトンとして提供するか持ち回すかして
プレイヤー情報や敵キャラの情報は全部その中に持ったり都度生成したりする
114:デフォルトの名無しさん
13/05/15 02:28:07.47
>>112
ステージってことは面クリ型？
俺が作るとしたらって考えたんだけど敵の何をstaticにするのかよく分からない
ステージクラスの中に敵クラスのポインタを宣言しといて、
ステージがロードされるたびに、前のステージの敵クラスは全解放して、また新しいステージの敵の数だけ敵クラス用メモリ確保→敵データ読み込みとかどうよ
プレイヤーのクラスはグローバルにしとく
115:デフォルトの名無しさん
13/05/15 20:07:56.66
>>113>>114
ありがと
>>114方式でやってみるよ
116:デフォルトの名無しさん
13/05/15 20:16:04.30
URLﾘﾝｸ(dixq.net)
このサイトを参考にマリオみたいなゲームを作っているのですが
ジャンプなどをしてブロックの角にぶつかると
滑るようにブロックを登ってしまいます
どのようにすれば良いでしょうか？
117:デフォルトの名無しさん
13/05/15 20:20:10.92
どうなってほしいの？
118:116
13/05/15 21:09:26.28
>>117
ブロックの反発を使って不自然な動きをしないようにしたいです
119:デフォルトの名無しさん
13/05/15 21:36:47.75
>>116
お前のプログラムだと、なんで滑るようにブロックを登ってしまうんだ？
何が原因なんだ？
120:デフォルトの名無しさん
13/05/15 23:14:42.15
不自然じゃない動きってどういう動き？
121:116
13/05/15 23:46:26.21
ジャンプしてブロックの斜め上にぶつかった場合
ブロックの上部にプレイヤーの座標がくるとめり込まないようにY軸がマイナスされる
それで不自然に浮いたような動きになる
当然、ifの順番を変えてもどこかの角が不自然な動きになってしまう
122:片山博文MZパンク ◆0lBZNi.Q7evd
13/05/15 23:58:45.81
縦方向のめり込みより先に横方向のめり込みを考慮する
123:デフォルトの名無しさん
13/05/16 00:54:23.03
>>122
そうすると
ブロックの下からジャンプして頭ぶつけたときに横に滑る
124:片山博文MZパンク ◆0lBZNi.Q7evd
13/05/16 01:07:06.69
ぶつかるブロックとマリオの位置関係を定義
125:デフォルトの名無しさん
13/05/16 01:39:05.71
>>124
どういうこと？
126:デフォルトの名無しさん
13/05/16 01:40:07.40
>>124
実際、マリオとかロックマンってどうなっているんだ？
127:片山博文MZパンク ◆0lBZNi.Q7evd
13/05/16 01:44:09.85
>>125
マリオとブロックの相対位置と、マリオの速度に応じて、「マリオがブロックと接する面」を定義し、
接する面より向こう側に移動できないようにする
128:デフォルトの名無しさん
13/05/16 01:59:15.46
小さい頃ブロック崩し作ったなあ
手抜き実装：
現在の縦座標はブロック外→縦にぶつかったので縦ベクトルを反転
(elseで判定を繋がない)
現在の横座標はブロック外→横にぶつかったので横ベクトルを反転
（縦も横もブロック外なら角にぶつかったので両方とも反転）
反射先がブロックかどうか見ていないので
例えばブロック密集地に高速で突っ込むと高確率でバグる
129:デフォルトの名無しさん
13/05/16 07:16:58.14
>>123
いや、横には滑らさなければいいだろ
130:デフォルトの名無しさん
13/05/16 08:54:34.90
>>123
横を優先したら横に滑っちゃうよ
131:デフォルトの名無しさん
13/05/16 12:41:11.34
>>127
どういうこと？
説明したサイトなどない？
132:デフォルトの名無しさん
13/05/16 13:14:26.02
>>131
いや、分かるだろ
133:デフォルトの名無しさん
13/05/16 16:45:23.49
何だ、片山はWin32APIスレ潰したら今度はここをターゲットにしたのか
134:デフォルトの名無しさん
13/05/16 16:49:38.40
市販のRPGの多くがマップと戦闘を分けてるのは
そのゲームの演出的な意味なの？
それともメモリ容量の関係？
プログラムの生産性や分割しやすさとかそういったもの？
135:デフォルトの名無しさん
13/05/16 17:04:36.70
そこまでわかってて何を聞きたいのか
136:デフォルトの名無しさん
13/05/16 18:50:20.09
いや、どれか分からないから聞いてるんだけど
137:デフォルトの名無しさん
13/05/16 18:58:31.35
いちばんの理由はドラクエ以来のテンプレとして
プレイヤー・開発者ともに受け入れられたからだと思うけどｗ
138:デフォルトの名無しさん
13/05/16 19:41:04.35
>>132
わかんねーよぉぉぉぉぉぉぉぉぉぉぉ
くそがぁぁぁぁぁぁぁぁぁぁぁ
139:デフォルトの名無しさん
13/05/16 19:51:46.48
>>138
ざこおつ
140:デフォルトの名無しさん
13/05/16 20:01:46.26
マリオ程度なら適当にゲーム開発講座サイト探したら載ってそうだけどな
141:138
13/05/16 22:23:27.61
>>139
うるせぇぇぇぇぇぇぇ
雑魚だから質問してんだよぉぉぉぉぉぉぉぉぉぉ
教えてくれよぉ(´;ω;｀)
142:片山博文MZパンク ◆0lBZNi.Q7evd
13/05/16 22:39:01.74
マリオの右にいくつかブロックがあるとしよう。マリオの頭から足までの範囲のすぐ右にブロックがあったら、そのブロックの左端より右に歩いて行けない。
この時、マリオはそのブロックに「接している」と言うことができる。
マリオが落下しているとき、マリオの左端から右端の範囲のすぐ下にブロックがあったら、そのブロックに着地してそれより下に落下しない。この場合も下のブロックに「接している」と言える。
143:デフォルトの名無しさん
13/05/16 22:45:23.66
>>142
うむ
それでブロックにめり込んだ分だけ
反発してブロック手前まで戻すのが今のプログラムだろ
そこからどうするにょ？
144:デフォルトの名無しさん
13/05/16 22:56:29.22
真面目に答えて欲しいのなら、真面目に質問して欲しいにょ
145:デフォルトの名無しさん
13/05/16 22:59:34.17
>>144
ごめんなさい
それをどう変えれば良いの？
146:デフォルトの名無しさん
13/05/16 23:04:06.60
>>145
どの辺に対して、どの方向から接して（めり込んで）いるのかを考慮する
横方向から接しているのに、縦方向から接しているのと同じ対処をしてもダメ
147:デフォルトの名無しさん
13/05/17 02:00:32.78
バグっていても伝わらなくてもしらん無責任な書き込み
マリオの移動処理{
キー入力を読む; //略
マリオの速度を暫定的に更新; //略 重力も考慮してしまう
マリオの左右処理; //後述
マリオの上下処理; //後述}
マリオの左右処理{
if(いまのマリオの位置に横速度を足すとブロックに当たる){
マリオの横座標をブロックと接する位置に;
マリオの横速度を0に;
}else{
マリオの横座標に横速度を加える;}}
マリオの上下処理{
if(いまのマリオの位置に縦速度を足すとブロックに当たる){
if(縦速度が下向き){
マリオの縦座標をブロックに接する位置に;
マリオの縦速度を0に;
}else{
switch(突き上げたブロックの種類が){
case:ただの石なら
音を出す;
マリオの縦速度を反転;
case:破壊可能ブロックなら
音を出す;
ブロックの破壊処理;
マリオの縦速度を超低速上昇に設定;
case:……}
マリオの縦座標に縦速度を加える;}}}
148:デフォルトの名無しさん
13/05/17 09:11:11.60
「マリオが・・・」を軸に考え始めると、マリオに係る処理が膨大になって
そのうち破たんすると思うよ
もっと、マリオも全体の一部的なを考えをしないと
149:デフォルトの名無しさん
13/05/17 19:36:04.48
マリオもブロックもひとつとみて、コントローラー(クラス)にやらせるのがいいのかね
150:デフォルトの名無しさん
13/05/18 13:20:54.32
>>145
いっそマリオを長方形に見立てて、四隅の角の座標を取る
例えばマリオ右上の座標が、右側にあるブロックの左下座標より上、なおかつ左にあったら横からの衝突処理
同ブロック左下よりも右、なおかつ下にあったら下からの衝突処理
同右、なおかつ上にあってめり込み状態だったら、ブロック左下とマリオ右上の座標差x,yのうち小さいほうを優先して処理
みたいなのしか思い浮かばん……
151:デフォルトの名無しさん
13/05/19 00:41:59.38
マリオ作りたいって言ってるけど、
それ以前にブロックも段差もない平坦な2Dアクションは作れたわけ？
152:デフォルトの名無しさん
13/05/19 01:52:57.84
>>151
質問者は、キャラがブロックの角にぶつかるとキャラがそのブロックを滑るように登る、と言っている。
この問題の解決と、ブロックも段差もない平坦な2Dアクションが作れるかどうかと、どう関係するんだ？
ブロックも段差もない平坦な2Dアクションが作れることは、この問題の解決の必要条件なのか？
そもそも「ブロックも段差もない平坦な2Dアクション」とは何を指している？
地面の上をただジャンプするだけのものをプログラムできるかどうかと質問者に尋ねているのか？
153:デフォルトの名無しさん
13/05/21 12:48:00.74
だいたい一度にどの程度の数のオブジェクトをどう管理したら重くなるかとか
そういうのは経験積むしかないよね？
154:デフォルトの名無しさん
13/05/21 13:51:38.03
>>153
それもだし、環境と制限による
155:デフォルトの名無しさん
13/05/22 10:04:23.87
>>152
関係するし必要条件だと私は思うのですが
どう考えたら関係ないと思えるんでしょうか？
156:デフォルトの名無しさん
13/05/22 19:40:26.96
>>155
質問者が抱えている問題は下記の2つ。
これらが意図したようにプログラムされていないために問題が現れている。
・当たったかどうかをどのように判定しているか
・当たっていた（めり込んでいた）場合、どのように解消するか
これらはなにもアクションゲームに特有の問題ではい。
シューティングでもRPGでもパズルでも、いろいろなゲームで根幹の問題だ。
初心者が「地面の上をただジャンプするだけのもの」を作る場合、
キャラが画面の縦軸座標のある値よりも下には行かないようにプログラムする。
このようなキャラと地面との当たり判定とその解消方法は、
ジャンプした時のキャラとブロックとのそれらとは根本的に異なる。
（経験と知識を積めば、一般化して、地面に対しても同じ処理で解決しようとするだろうが、
それはブロックとの当たりについて知識や経験を得た後だ）
方法が異なるので、「地面の上をただジャンプするだけのもの」を作ることで得た知識や経験は、
質問者が今現在抱えている問題を解決しない。
よって、「地面の上をただジャンプするだけのもの」が作れるかどうかを問うことに大した意味はない。
それと、そもそも質問者はジャンプなどをすることはプログラムできているはずだ。
ジャンプしてブロックに当たった時の処理で問題が起きているのだから。
ジャンプするからには、普通は地面が用意されていると思う。
「地面の上をただジャンプするだけのもの」は既にプログラムできていると思わないか？
157:デフォルトの名無しさん
13/05/22 22:04:43.02
そこまでダラダラ長々書く必要があるのか
158:デフォルトの名無しさん
13/05/22 22:14:28.04
>>157
この長さが必要だったかどうかは、私にはわからん。
もっと短くても >>155 が私の考え方がどういうものか理解してくれたのなら（納得はしないだろうが）、
この長さは不必要だったかもしれん。
もしかしたら、>>155 が理解するにはこの長さが適切だったかもしれん。
私は >>155 の返答から、やや丁寧に書いた方が良いだろうと判断した。
本当にこの長さが必要だったかどうかは >>156 に聞いてくれ。
159:デフォルトの名無しさん
13/05/22 22:15:42.72
>>158
自分に聞いてどうするよ・・・orz
本当にこの長さが必要だったかどうかは >>155 に聞いてくれ。
160:デフォルトの名無しさん
13/05/22 23:50:38.60
はい。
161:デフォルトの名無しさん
13/05/23 09:22:32.29
>>156
>方法が異なるので、「地面の上をただジャンプするだけのもの」を作ることで得た知識や経験は、
>質問者が今現在抱えている問題を解決しない。
本当にそうでしょうか？
>「地面の上をただジャンプするだけのもの」は既にプログラムできていると思わないか？
思わないです。
162:デフォルトの名無しさん
13/05/23 12:49:52.69
>>161
> 本当にそうでしょうか？
本当にそうです。
それでは解決しません。
解決すると言うのなら、それをはっきりと質問者 >>116 に言うべきです。
「地面の上をただジャンプするだけのもの」を作る時に＊＊という処理を使うが、
それを～～のように改良すれば今回の問題は解決する、など。
> 思わないです。
矛盾しています。
あなたは >>151 で作れたかどうかを訊いている。
プログラムできていないと思っているのなら、>>151 の質問は無駄です。
質問者にわかりきった無駄な逆質問をするより、上記のようなアドバイスを
はっきりと示した方が質問者にとって良いこととは思いませんか。
163:デフォルトの名無しさん
13/05/23 13:03:54.21
>>162
>本当にそうです。
>それでは解決しません。
必要条件と必要十分条件を取り違えていませんか？
それ「だけ」では解決しないのは私も分かっています。
>矛盾しています。
何が矛盾なのですか？
必要条件である「ブロックも段差もない平坦な2Dアクション作れる」
を満たしているかどうかを確認するのは絶対に無駄なのでしょうか？
164:デフォルトの名無しさん
13/05/23 15:54:19.19
無駄
165:デフォルトの名無しさん
13/05/23 16:24:39.56
長いわ
166:デフォルトの名無しさん
13/05/23 17:41:50.93
ば、ばかな
何ひとつとして有用な情報がないｗ
167:デフォルトの名無しさん
13/05/23 17:52:45.96
妄想プログラマが多いからな
168:デフォルトの名無しさん
13/05/23 18:01:28.69
>>163
「地面の上をただジャンプするだけのもの」を作れなくても、
たとえばシューティングゲームで当たり判定の処理をプログラムしたことがあれば十分。
シューティングゲームを作ったことなくても、他のものでもいい。
ゲームでなくても、GUIのツールを作る過程で本質的に同様の処理をする場合もある。
よって、>>116 を解決するのに「地面の上をただジャンプするだけのものが作れる」は
必ずしも必要ではない。
>を満たしているかどうかを確認するのは絶対に無駄なのでしょうか？
あなたは「地面の上をただジャンプするだけのもの」は既にプログラムできているとは思わないと
>>161 で言っている。
まだプログラムできていないと思っているのなら、確認の必要はない。
これは既にプログラムできているという前提で、
さっさと「地面の上をただジャンプするだけのもの」を作ることで
問題がどう解決するのかを提示すべき。
既にプログラムできているかどうかあなたの中で判断できないのなら、確認には意味がある。
169:デフォルトの名無しさん
13/05/23 19:36:44.73
粘着しとんなあ
170:デフォルトの名無しさん
13/05/23 20:19:37.65
俺は既に >>146 で自分なりのアドバイスをしている。
その周辺の他の人のアドバイスと合わせれば、解決の糸口が見えて来るのではないかと思っている。
しかし、>>151 が「地面の上をただジャンプするだけのもの」を作れることが
解決に繋がると考えているのなら、それをもっと詳細に説明してあげた方が良いと俺は思うぞ。
俺は、質問者は既に「地面の上をただジャンプするだけのもの」はプログラムできていると思っている。
それが解決に繋がるのなら、質問者はぜひ知りたいと思っているのではないかな。
>>169
そう思われるのは心外なので、>>151 に対するレスはもうしない。
171:デフォルトの名無しさん
13/05/23 20:27:48.94
何でもいいけど、当たり判定のプログラムのどこでそんなに困るのか。
そもそもマリオでブロックの角に当たったら滑って登るって普通だったろ。
172:デフォルトの名無しさん
13/05/23 20:31:27.27
自力で出来ないなら市販の物理エンジン使えよ
バカには無理なんだから金でもつかわんとなんも出来んぞ
173:デフォルトの名無しさん
13/05/23 20:41:31.43
>>170
質問者の>>116がただサイトからコピペしただけで
「ブロックも段差もない平坦な2Dアクション」の部分すら理解してない
という可能性を>>151は示唆してるというだけなんじゃないの？
174:デフォルトの名無しさん
13/05/23 20:51:27.93
当たり判定くらいから算数の力が必要になってくる
学校のテストで点をとるためだけに勉強してた奴はこの辺りで引っかかりはじめる
3D行くと三角関数使うようになるし
数学苦手な奴にはもう無理
175:デフォルトの名無しさん
13/05/23 21:01:07.39
＞キャラが画面の縦軸座標のある値よりも下には行かないようにプログラムする
これがもし本当にできるのであれば
キャラが画面の縦軸座標のある値よりも上には行かないようにプログラムすれば天井ができ
キャラが画面の横軸座標のある値よりも右には行かないようにプログラムすれば壁ができ
キャラが画面のある座標には行かないようにプログラムすればブロックできるじゃんやったな
176:デフォルトの名無しさん
13/05/23 21:12:38.79
>>175
一度は実際に検証してみてからレスした方がいいと思う
177:デフォルトの名無しさん
13/05/23 21:20:03.21
>>176
いや、だからそういうところから質問者が自分で試してみろってことだよ
何で下は上手く行くのに上がダメなのか考えればいつか自ずと答えが出るだろ
それが理解するってことだろ、答えだけ知ろうとするなよ
って俺は思うんですけど厳しいですかねｗｗｗｗｗ
178:デフォルトの名無しさん
13/05/23 21:42:20.52
>>177
> 質問者が自分で試してみろ
いや、そういう考えなら、俺も同感だ。
別に笑うことでもない。
でも、そういう事を「最初に」はっきりと質問者に向かって言わないと、
遠回しな言い方では伝わらないよ。
ただ、それは回答者の方も一度は検証してからレスした方が良いというのと別問題だとは思う。
179:デフォルトの名無しさん
13/05/23 21:45:29.39
つーかムキになって反論すんなよ
いくら考えて上等な反論並べたところで
誰も認めやしねーよ。うざいガキと思われるだけ。
180:デフォルトの名無しさん
13/05/23 21:49:42.21
>>179
お前は誰と戦ってるんだよ
181:デフォルトの名無しさん
13/05/23 22:08:29.73
>>178
つまり貴方様は既に検証済みということですよね？
参考にそのプログラムを見せていただけませんか？
182:デフォルトの名無しさん
13/05/24 02:01:56.77
>>116はもうこのスレを覗きに来てない気がするんだよな…
いや、いいけどさ過疎だし
183:デフォルトの名無しさん
13/05/24 07:52:18.24
>>181
入社して研修を受けてた頃からさんざんやってるから、いろんなことを検証してきた。
俺のアドバイス >>146 の「接する方向を考慮すること」もすぐにやらされるから検証済み。
君だってアクションゲームを作ったことがあるのなら、同じ事を一度はやってるはずだ。
それに例えば「アクションゲーム 当たり判定 ブロック」などでググれば、
俺（や、その周辺の人）のアドバイスの実例や、もっと詳細な解説はいくらでも見つかる。
あらためて俺が自分のプログラムを公開する必要性がない（面倒だし）。
俺のプログラムでなければ参考にならない、なんてことはないだろう。
それに、これくらいのキーワードは誰にでもすぐに思いつくはずだ。
君だって思いついただろう（この程度も思いつかないなんて言うなよ）。
なのに何故ググろうとしない？
>>175 のように、「これより右には行けない」、「これより下にはいけない」、
「これより右にはいけない」、「これより左にはいけない」と処理することで
ひとつのブロックを表現しようとすることも研修中にやっている。
そして、これではうまく処理できないこと経験している。
キャラの移動速度の関係でブロックにめり込んでしまった（しまう）場合、
そのキャラをどこに移動させればいいのか判断できないからだ。
ブロックの上側に強制的に移動させればいいのか？
それとも左側に強制的に移動させればいいのか？
結局、接する方向を考慮する必要がある。
「これより下にはいけない」これひとつだけなら問題ない、上側に移動させればいい。
>>175 は「できる」と言っているが、俺は研修中できなかった。
まぁ >>175 も「できた」とは言っていないが。
184:デフォルトの名無しさん
13/05/24 08:43:46.08
また同じ粘着か
実りないしよそでやれよ
185:デフォルトの名無しさん
13/05/24 09:52:26.39
>>183
要約すると
「昔に検証したことだから今は手元にソースない」
ってことですね分かりました
186:デフォルトの名無しさん
13/05/24 10:30:23.29
>>183
>入社して研修を受けて
入社を始点に物事語ってる時点でお前様の程度が知れる
お前様を採用して会社も（お前を育てるのに）さぞ苦労したろうな
187:デフォルトの名無しさん
13/05/24 12:36:28.35
>>185
そう。
現時点で示せるコードは何一つ手元にないし、これから >>181 のために書くのも面倒だ。
学びたいのなら、ネット上にもっと良いコード片や資料はいくらである。
そちらを参考にしてくれ。
>>186
研修云々を話してしまったのは俺のミスだ。
このスレにはどうでもいい関係ないことだった、申し訳ない。
忘れてくれ。
188:デフォルトの名無しさん
13/05/24 13:55:25.18
どうでもいい関係ないことに拘って延々と粘着するスレだろ
何言ってんの
189:デフォルトの名無しさん
13/05/24 15:06:31.34
初心者相手に自己顕示欲を満たすためにその当たり判定を実現したものを作ろうかと思ったけど当たり判定だけのためにアプリ作るのもだるい
190:デフォルトの名無しさん
13/05/24 17:01:29.71
ここはひどいインターネッツですね
191:デフォルトの名無しさん
13/05/24 18:54:53.83
>>186
全然関係ないけど、人を育てるのはどの会社、どの分野でもそうとう大変だよ
今ちょうど俺が新入社員相手に四苦八苦してるところ
ゲーム全く関係なくて、エクステリア関係の小さな問屋だけど
192:デフォルトの名無しさん
13/05/24 19:08:56.15
新人がうまく育たない会社は大抵先輩の指導がカスなんだよな
193:デフォルトの名無しさん
13/05/24 19:12:11.60
(´；ω；`)ｳｩｩ
ごめんなさい、がんばる
194:デフォルトの名無しさん
13/05/24 19:19:53.46
中途ならともかく新卒で即戦力とかいう求人結構きくしな・・・
195:デフォルトの名無しさん
13/05/24 19:26:48.18
そんなんもれなくブラックじゃん
つか学生上がったばかりで即戦力の実力あるなら起業するし
196:デフォルトの名無しさん
13/05/24 19:33:50.90
だよな、俺とか
197:デフォルトの名無しさん
13/05/24 20:45:42.66
すげーなお前
正直うらやましい
198:デフォルトの名無しさん
13/05/24 21:54:36.72
企業は嘘じゃないけど、泣きそうなくらいセルフブラックです
見栄張ってごめんなさい