トップページgamedev
158コメント52KB

ゲームのグラフィックスプログラミング

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。01/11/07 00:30ID:MUorfDi0
グラフィックに関するプログラミング、
データ作成ツール、プラグインに関するスレッド。
0002名無しさん@お腹いっぱい。01/11/07 01:26ID:???
ドット絵とかアスキーアートだな
0003名無しさん@お腹いっぱい。01/11/07 02:36ID:???
アスキーアート、ゲームに使うのか・・・
0004名無しさん@お腹いっぱい。01/11/07 02:53ID:???
昔は文字をキャラクタに見立ててゲームを作ったもんさ
0005名無しさん@お腹いっぱい。01/11/07 06:42ID:???
>>4
ああ、やったやった。
あの頃はグラフィック描画よりもテキスト出力の方が圧倒的に早いから、
スピードを要求されるゲームはテキストでやるしかなかったんだよな。
メモリも総量64kb程度しかなくて、グラフィックは容量食うしな。

スプライト機能を搭載したMSXが羨ましかったな……。
0006名無しさん@お腹いっぱい。01/11/07 07:54ID:???
PC-98だったら、外字をPCGとして使ったり、低解像度画面
(テキスト画面で160*100)を使ったりしたねぇ。
0007名無しさん@お腹いっぱい。01/11/07 09:05ID:???
今だとシレンとかトルネコとかになっちゃうんだな、これが。
0008名無しさん@お腹いっぱい。01/11/07 22:49ID:???
小学校の頃に作ったインベーダー撃ち落しゲームで、
アスキーアートの巨大UFOを描いたなあ。
しみじみ。
0009名無しさん@お腹いっぱい。01/11/08 16:58ID:???
いきなりAAに話がずれたあげく底にしずんじゃったネ。
なんとも2ちゃんらしいというか。

ところで昔のゲームってAAエディタとかつかってたの?
もしや文字コード表とにらめっこしながらつくってたとか!!
0010名無しさん@お腹いっぱい。01/11/08 17:50ID:???
>>9
昔のは、キーボードから直接グラフィック文字を入力できたんすよ。
シフトキーや仮名キーみたいなカンジで。
0011名無しさん@お腹いっぱい。01/11/08 20:44ID:???
>>10
そういえば昔のってキーボードにグラフィック文字書いてたような。
ベーシックマスターだったかX1だったかどれだったか忘れたが。
0012名無しさん@お腹いっぱい。01/11/09 05:20ID:???
良いワイプない?

ツール、スクリプト系でもいいからさ。
画像処理の本にヒントさがしてるけどフォトショップのフィルタみたいなやつのことしかのってなかった
0013名無しさん@お腹いっぱい。01/11/09 05:23ID:???
エロゲーで良いなら、Infantariaってゲームのワイプがいかしてた。
0014 01/11/09 08:56ID:???
ワイプのバリエーションなんてメガデモで腐るほどあるんでねえ?
hornetでも漁って見てつかぁさい。
0015名無しさん@お腹いっぱい。01/11/09 09:19ID:???
リアルタイムでラジオシティやってるゲームあったよね?
あれって、どこまで計算してたんだろ…
0016名無しさん@お腹いっぱい。01/11/09 09:21ID:???
>>15
まじで?擬似じゃないの?
0017名無しさん@お腹いっぱい。01/11/09 09:24ID:???
>>15
リアルタイムレイトレーシングとかもあったね。
0018名無しさん@お腹いっぱい。01/11/09 12:37ID:???
>>15, >>17
まともなゲームで使ってるのってある?
0019名無しさん@お腹いっぱい。01/11/09 19:28ID:???
ラジオシティを真面目に計算なんてしるはずもなくごまかしでしょう。
デモでそれらしいのは見たことあるけど。

そんなものがゲーム上のソフトウェアレンダリングで動くならnVidiaなんてとっくに
死亡していると思うが。
0020ネタふり01/11/10 03:15ID:???
スレ違いかなーなんて思いつつも、一応ダメもとで話を
振ってみます。
2Dのクオータービュー、描画において、奥から回す、
手前から回す、ソート関連、いろいろ手法があるようですが、
「コレが王道だろう!」というスタイルを語れる方、
一席もうけてくださいませんか?
私自身、シロウトではないものの、あまり明るくない分野なので、
バリバリの方のお話が聞けたら幸いです。
00212001/11/10 14:26ID:lDT42030
ヤハリレスハナカタカー
0022名無しさん@お腹いっぱい。01/11/10 15:30ID:Pfrth29i
あきらめるのが早すぎますよ。

クォータービューの奥からまわす、手前からまわすというのはどう言う意味でしょう?
視点をくるくる変えさせたいのでしょうか。
とりあえず、描画オブジェクトのソートにだけ絞って書かせていただきます。

ソートをしたいだけならバブルソートで十分だと思います。
何千もの表示オブジェクトがあるなら、クイックソートとのベンチを取って
良いほうを採用すれば良いでしょう。

ソートをしたくなかったら、あらかじめ描画順序テーブルを作成して、
それを利用するのが手だと思います。
描画順序テーブルには表示オブジェクトへのインデックス、もしくはポインタを保存
しておきます。
描画するときに、テーブルの先頭から描画処理を行っていったり一番後ろから行っていったり
すれば、うまく重なって描画されると思います。

描画順序テーブルは奥行き(z値)によって長さを変えると分かりやすいのではないでしょうか。
テーブルサイズを256段階にしたら、z値が0から255までを扱える。
z値がそのままテーブルのインデックスになるというわけです。

あとは、同じz値のオブジェクトのテーブルへの格納方法などを考えればいけると
思いますが。
#これはリスト構造で何とかなるでしょう。
0023名無しさん@お腹いっぱい。01/11/10 16:13ID:???
えーとですね、手前にある物から描画していくか、奥からかの意味で
(手前からの場合、描画済みのピクセルにフラグを立て、二度同じ
ピクセルには描画しない)
書きました。
恥をしのんで、具体的に当方が疑問に思っている事を書きますね。
クオータービューで、地面に影落とすのは良くありますけど、
上手い具合に、地面の平面にのみ影を落し、地面に乗っているオブジェクト
には影がかかってなかったりします。
これは、奥から順に地面の描画を全部済ませ、次に影を全キャラクター
分描画、最後にキャラクター本体の順で良いんでしょうかね?

毎フレームこれをやると、ちょっと速度が足りない物で、、、。
かえって、2Dの方が手間ひまかかる面もあるなーと感心してます。
0024名無しさん@お腹いっぱい。01/11/10 16:29ID:TY+m/yMI
>>23
イマドキのハードなら、Zバッファ使うか、それがイヤなら>>22さんの
いうとおりに描画順序テーブル組んでみたら?
テーブルの解像度を32bit程度にして、影は投影される面より少し
オフセットをつけてやれば十分事足りるはず。

>毎フレームこれをやると、ちょっと速度が足りない物で、、、。
>かえって、2Dの方が手間ひまかかる面もあるなーと感心してます。

実装が悪いだけでは?問題点も3Dのものと本質的に変わらない
(2D特有で、3Dにはない問題ではない)みたいだし。
00252301/11/10 16:34ID:???
いや、まったく仰る通りでして、実装に問題があるようなので、
こうしてご指導を仰ぐべく、参上しております(笑)
>影は投影される面より少しオフセット
これはどういう意味でしょうか?
00262401/11/10 16:56ID:TY+m/yMI
>>25
Z値が同じ時に影が埋まって見えなくなったりするのを防ぐために
少しオフセットをつけて、描画順位が同じ時の実行順を保証してやる事。

#あ、あと32bitもテーブルはいらないかも。これは出てくるものの数や表示したい
#奥行きの深さにもよるね。

個人的に、今のハード(TNT, GeforceやRADEONクラス)でタクティクスオウガ
みたいな狭いマップなら、

1背景を3Dオブジェクトで表示。Zバッファを埋める。

2投影された影をポリゴンオフセットつけながら描画。描画はZ、色値には
 書き込まず、ステンシルバッファのみ書き込み。

3ステンシルバッファ見て影部分を書き込み。(これで影が重なっても暗さが一定になる。)

4キャラ、エフェクトをビルボード描画。ここはZソートしながら描画。

が一番絵的にも、描画速度的にも折り合いがつく気がする。

表示したいものが凄く多くて(AOEやコサックスみたいに)、足元の影だけ
描画できればいい(投影される必要が無い)なら、表示オブジェクトの足元に
書き込んでやるのが現実的かも。
0027名無しさん@お腹いっぱい。01/11/10 17:17ID:???
23さんはおそらく、PCをターゲットにした話でしょうから、わたしもそれに従います。
昔なら描画矩形を限定することで描画処理を軽くすることが多かったですが、
最近では全部を再描画かけるようにするのが一般的です。
もっとアプリケーションよりの話もあります。
背景をブロックの組み合わせで作成している場合、前のフレームの背景と
今回描画するフレームの背景を比べて、違うブロックだけ転送して新たな背景を
作るということもできます。
そして、作成した背景->影->人物->手前の背景->ウィンドウなど、というふうに
すれば、メモリ転送を減らせるでしょう。

23さんがどのような実装をしているか分からない以上、
明確な解決法を提示することはできません。

>影は投影される面より少しオフセット
これは、実装する人によって少しずつ意味合いが変わりますね。
z値とほぼ同義と思えば良いのではないでしょうか。
足元の影や、壁に貼りついたポスターなどを描画するときに壁や床よりも
ほんの少し、Z値を視点側にすることで影やポスターが床などにめり込まないよう
する処理です。
■ このスレッドは過去ログ倉庫に格納されています