09/08/23 22:24:38
キーコンフィグとかメッセージスピードとか音量とか、ユーザー設定ってどう管理すべきだろう
シングルトンにしてまいかい参照するのか、オブザーバーを使うのがいいのか
いまいちパターンの使い方がわからんス
>>814,815
レストン
結局、画像自体はフライウェイトを使って管理して、キャラには画像クラスの参照のリストをひとつのアニメーションとして持たせることにしたぜ
854:デフォルトの名無しさん
09/08/23 22:28:30
その発想こそ、シェーダー出来たってゲーム作れないに通じるな
そっくりお返しするわｗ
要は、自分勝手に、自分のレベルでしかやれない
それがクリエイター様でござい、ってでも言うつもり？ｗ
シェーダー使うと、チームで決ったら
そのシェーダー使う中での裁量はあるに決ってるだろｗ
負荷やゲーム内容に合うなら、デザインと打ち合わせして好きな表現が出来るぞ
シェーダーも使えない不自由な表現しか出来ないくせに
コーダーとか言えば、自分はシェーダー使わなくとも凄いんだぜ、とでも言いたいのか？ｗ
ほんと、低レベルな奴は言い訳ばっかだな
855:デフォルトの名無しさん
09/08/23 22:31:29
>>853
はぁ？
int main()
{
USER_DATA dat; //←ここ
初期化
while(){
内容更新
描画更新
}
終了
}
ここにあれば問題ないじゃん
ちゃんと引数で下に渡していけよ
グローバル変数なんて頭悪いもの、はじめから使う気で組むなよ
856:デフォルトの名無しさん
09/08/23 22:35:47
かくして固定パイプライン描画をゲームやデザイナに押し付ける
コーダーではないゲームプログラマが吠えるのでしたｗ
857:デフォルトの名無しさん
09/08/23 22:39:05
>>855
グローバル変数が頭悪いというのはともかく、
引数で下に渡していく場合、
static USER_DATA dat; //←ここ
int main()
{
初期化
while(){
内容更新
描画更新
}
終了
}
と、実際問題どう違うのか俺にはよくわからないんだが。
858:デフォルトの名無しさん
09/08/23 22:42:34
更に固定パイプライン描画と思っていたが、描画エンジンはフルシェーダーになっていて、
固定パイプラインと同じ結果になるシェーダーが、他のプログラマで用意されていて
関数コールするだけで理解していなかった、コーダーではないゲームプログラマはクリエイティブな仕事を続けるのでしたｗ
とかに100ゴールド
859:デフォルトの名無しさん
09/08/23 23:16:17
>>857
は？なにやってんの？
そんなことしたら
static USER_DATA dat;
int unko()
{
memset(&dat,0,sizeof(USER_DATA));
}
int main()
{
//略
}
//ヘッダ
extern int unko();
なんてやりだしたら悪夢のはじまりだろ
860:デフォルトの名無しさん
09/08/23 23:17:08
void unko()に直しておいてくれｗ
861:デフォルトの名無しさん
09/08/23 23:18:54
責任も取れない喚くだけの小物
862:デフォルトの名無しさん
09/08/23 23:52:50
>>851
あの、色収差ってアレですよ
ガラスの表裏が平行になってないと反対側の風景が青や黄色のにじみが付いたように見えますよね
アレを表現するにはどうすればいいですか？
シェーダー使うにしてもどんなアルゴリズムにすればいいのかさっぱり・・・
863:デフォルトの名無しさん
09/08/24 00:23:41
色収差を実現するためには何が必要か分かって言ってるのか？
なんか釣りっぽいが一応説明しておくと真面目にやるなら光線を追跡して
なおかつ物質の密度と屈折率を考慮に入れる必要がある
ここまで言えば嘘八百の上に成り立ってるリアルタイムレンダとは
根本的に次元が違う話だとわかるだろ
864:デフォルトの名無しさん
09/08/24 00:25:37
RGBでちょっとずつずらしたのを三枚重ねればいいだけじゃね？
865:デフォルトの名無しさん
09/08/24 00:59:05
>>863
つまり嘘八百で色収差を作ればいいってことですか？
866:デフォルトの名無しさん
09/08/24 01:18:35
なんかスレが伸びまくってると思ったら…
かわいいなお前らｗ
微笑ましい
867:デフォルトの名無しさん
09/08/24 02:17:54
オフラインレンダリングでも嘘八百な実装がほとんどだし。
フォトンマッピング使えば物理的に嘘ついてないレンダリングはできるけど
その分時間かけないと誤差は大きくなる。
868:デフォルトの名無しさん
09/08/24 07:32:12
フォトンマッピングが物理的に嘘ついてないレンダリング？
869:デフォルトの名無しさん
09/08/24 08:06:20
今のコンシューマ機って、任天堂以外シェーダを使わないと描画すらできないはずだけど…。
使う使わないという選択肢があるのはなぜ？みんなPCの話をしているのか？
870:デフォルトの名無しさん
09/08/24 08:42:30
使うのは当然。特別なことに言うアホをからかってるだけ。
あと携帯機もあるけどね。
871:デフォルトの名無しさん
09/08/24 09:48:36
iPhoneもシェーダー使えるんだっけ？
872:デフォルトの名無しさん
09/08/24 09:49:49
シェーダも知らないやつがゲーム作ろうとか笑えるｗｗｗｗ
873:デフォルトの名無しさん
09/08/24 10:35:05
処理速度の遅いマシンでも見た目ゲーム速度が変わらない作り方って
・17ｍｓごとに画面書き換え
・mainループで毎回17ｍｓ前提で座標計算
↓
①・17ｍｓごとに画面書き換え
・前回main処理が25ｍｓ掛かったので25ｍｓ前提で座標計算
②・mainが終わったら画面書き換え 最悪67ｍｓになったら画面書き換え
・前回main処理が25ｍｓ掛かったので25ｍｓ前提で座標計算
どっち？
あと倍速モード付けた時に、8ｍｓ前提でmain処理させるのか、それとも17ｍｓ前提のmain処理を2回やるか？悩む
874:デフォルトの名無しさん
09/08/24 11:43:30
誰も色収差の具体的な実装について
触れていない所が、このスレのレベルを如実に表しているな。
実際やるには、>>864の方法がいいだろう。
RGAのそれぞれについて、異なる屈折率で屈折エフェクトを掛けるもの。
nVidiaのサンプルも同じだった。
内容から、固定パイプラインでは実現は難しいだろう。
問題点としては、環境キューブマップを用いる一般的な屈折エフェクトでは
入射時の屈折のみで出る方は考えられていない。
URLﾘﾝｸ(upload.wikimedia.org)(これの出る方)
水面などにはいいだろうが、、
875:デフォルトの名無しさん
09/08/24 11:55:36
質問者おいてけぼりで回答者が殴り合いの喧嘩してるスレと聞いてやってきました
いいぞ！もっとやれ！
876:デフォルトの名無しさん
09/08/24 12:25:21
実際の速度が秒速100[px]だとしたら
速度v = 100/1000 [px/ms]
1[F]=17[ms]だから
v = 17*100/1000 [px/F]
つまり1Fごとに17*100/1000[px]移動させればいい
処理落ちしたらロジックだけ更新して描画を一回スキップ
倍速モードは二回ロジック更新
ＧＵＩのゲーム作ったことないけどたぶんこんな感じであってるだろう
877:デフォルトの名無しさん
09/08/24 14:42:46
>>873
見た目のゲーム速度が何を意味しているか不明だが、移動量だと勝手に判断する。
10～20年前のシューティングなんかは、ループ回数での処理が多かった。
例えば全体のループ1回で1度動くのを登場するオブジェクトの最高速と見なして、
自機の移動は4カウントに1回とかそんな感じ。
処理オチした場合は、大抵次のループ時間に繰り込むので、一気に速度が1/Nになったりした。
もともとVSYNC割り込みで描画したりしていたから、これが都合が良かった。
873の環境がなんだかは知らないが、今時のPC用OSでシステムをおこすのなら
ループカウント制御じゃなくて時間制御にすればいいんじゃないか？ 倍速で悩むこともないし。
これだと前回のループの開始時間から今回のループの開始時間までの経過時間分処理を行うから
遅い環境でもオブジェクトの移動量は変わらない。ただしパターンがコマ落ちする。
878:873
09/08/24 14:51:11
へー割り込みいらないんだ
②ってこと？
879:デフォルトの名無しさん
09/08/24 14:53:51
ゲームによって、処理落ちとコマ落ちを選択すべき
いきなりワープしたらゲームにならん場合もあるだろう。
880:デフォルトの名無しさん
09/08/24 15:04:35
メインループは処理落ち
描画ループはコマ落ちだろ
環境によって、ゲーム内結果が変わるのはどうか。
881:デフォルトの名無しさん
09/08/24 15:28:09
メインループが軽ければ、メインループを別スレッドにすればいい。
Quake 3/OpenArenaもそんな感じだったような...
882:デフォルトの名無しさん
09/08/24 18:07:34
でも例えば、衝突判定処理が異様に重いシューティングなんかだと、
いくら描画だけスキップしても追いつけなかったりする。
そういうときは、10回連続スキップしたら1回は描画とかの方が良い。
883:デフォルトの名無しさん
09/08/24 18:38:34
>>882
そんなレアケースの話を持ち出さなくても。
大体描画処理よりも衝突判定の方が重いシューティングなんかがあるとしたら、
設計か企画を間違っているような気がする。
ていうか、衝突判定が間に合わないシューティングってもう、
「遅いPCでもフィーリングをなるべく同じにしようとして頑張る」
とかじゃなくて「遊べないからあきらめろ」の範疇だろ。
884:デフォルトの名無しさん
09/08/24 19:33:11
弾幕STGとかはリプレイとかの為に再現性が重要だからコマ落ちさせても良い
ユーザーの視点に立つことが大事だよね。あくまでゲームなんだから
885:デフォルトの名無しさん
09/08/24 21:36:02
弾幕厨ってリア厨に多いよね
886:デフォルトの名無しさん
09/08/24 21:38:06
つーかそもそもシューティング厨がキメェ
887:デフォルトの名無しさん
09/08/24 22:44:18
アインハンダーを作ろうとしないで
自分にもできそうなところから模倣してその先へ一歩も進もうとしない奴が多いから嫌い
888:デフォルトの名無しさん
09/08/24 23:05:16
アールタイプとかグラディウスとかゼクセクスとかスカイキッドとか・・・
横シューの方がギミックが面白くて好きだ。