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

**名無しさん＠お腹いっぱい。** · 01/11/07 00:30

グラフィックに関するプログラミング、
データ作成ツール、プラグインに関するスレッド。

**名無しさん＠お腹いっぱい。** · 01/11/07 01:26

ドット絵とかアスキーアートだな

**名無しさん＠お腹いっぱい。** · 01/11/07 02:36

アスキーアート、ゲームに使うのか・・・

**名無しさん＠お腹いっぱい。** · 01/11/07 02:53

昔は文字をキャラクタに見立ててゲームを作ったもんさ

**名無しさん＠お腹いっぱい。** · 01/11/07 06:42

>>4
ああ、やったやった。
あの頃はグラフィック描画よりもテキスト出力の方が圧倒的に早いから、
スピードを要求されるゲームはテキストでやるしかなかったんだよな。
メモリも総量64kb程度しかなくて、グラフィックは容量食うしな。

スプライト機能を搭載したMSXが羨ましかったな……。

**名無しさん＠お腹いっぱい。** · 01/11/07 07:54

PC-98だったら、外字をPCGとして使ったり、低解像度画面
(テキスト画面で160*100)を使ったりしたねぇ。

**名無しさん＠お腹いっぱい。** · 01/11/07 09:05

今だとシレンとかトルネコとかになっちゃうんだな、これが。

**名無しさん＠お腹いっぱい。** · 01/11/07 22:49

小学校の頃に作ったインベーダー撃ち落しゲームで、
アスキーアートの巨大UFOを描いたなあ。
しみじみ。

**名無しさん＠お腹いっぱい。** · 01/11/08 16:58

いきなりＡＡに話がずれたあげく底にしずんじゃったネ。
なんとも２ちゃんらしいというか。

ところで昔のゲームってＡＡエディタとかつかってたの？
もしや文字コード表とにらめっこしながらつくってたとか！！

**名無しさん＠お腹いっぱい。** · 01/11/08 17:50

>>9
昔のは、キーボードから直接グラフィック文字を入力できたんすよ。
シフトキーや仮名キーみたいなカンジで。

**名無しさん＠お腹いっぱい。** · 01/11/08 20:44

>>10
そういえば昔のってキーボードにグラフィック文字書いてたような。
ベーシックマスターだったかＸ１だったかどれだったか忘れたが。

**名無しさん＠お腹いっぱい。** · 01/11/09 05:20

良いワイプない？

ツール、スクリプト系でもいいからさ。
画像処理の本にヒントさがしてるけどフォトショップのフィルタみたいなやつのことしかのってなかった

**名無しさん＠お腹いっぱい。** · 01/11/09 05:23

エロゲーで良いなら、Infantariaってゲームのワイプがいかしてた。

01/11/09 08:56

ワイプのバリエーションなんてメガデモで腐るほどあるんでねえ？
hornetでも漁って見てつかぁさい。

**名無しさん＠お腹いっぱい。** · 01/11/09 09:19

リアルタイムでラジオシティやってるゲームあったよね？
あれって、どこまで計算してたんだろ…

**名無しさん＠お腹いっぱい。** · 01/11/09 09:21

>>15
まじで？擬似じゃないの？

**名無しさん＠お腹いっぱい。** · 01/11/09 09:24

>>15
リアルタイムレイトレーシングとかもあったね。

**名無しさん＠お腹いっぱい。** · 01/11/09 12:37

>>15, >>17
まともなゲームで使ってるのってある？

**名無しさん＠お腹いっぱい。** · 01/11/09 19:28

ラジオシティを真面目に計算なんてしるはずもなくごまかしでしょう。
デモでそれらしいのは見たことあるけど。

そんなものがゲーム上のソフトウェアレンダリングで動くならnVidiaなんてとっくに
死亡していると思うが。

**ネタふり** · 01/11/10 03:15

スレ違いかなーなんて思いつつも、一応ダメもとで話を
振ってみます。
２Ｄのクオータービュー、描画において、奥から回す、
手前から回す、ソート関連、いろいろ手法があるようですが、
「コレが王道だろう！」というスタイルを語れる方、
一席もうけてくださいませんか？
私自身、シロウトではないものの、あまり明るくない分野なので、
バリバリの方のお話が聞けたら幸いです。

２０ · 01/11/10 14:26

ヤハリレスハナカタカー

**名無しさん＠お腹いっぱい。** · 01/11/10 15:30

あきらめるのが早すぎますよ。

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

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

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

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

あとは、同じz値のオブジェクトのテーブルへの格納方法などを考えればいけると
思いますが。
#これはリスト構造で何とかなるでしょう。

**名無しさん＠お腹いっぱい。** · 01/11/10 16:13

えーとですね、手前にある物から描画していくか、奥からかの意味で
（手前からの場合、描画済みのピクセルにフラグを立て、二度同じ
ピクセルには描画しない）
書きました。
恥をしのんで、具体的に当方が疑問に思っている事を書きますね。
クオータービューで、地面に影落とすのは良くありますけど、
上手い具合に、地面の平面にのみ影を落し、地面に乗っているオブジェクト
には影がかかってなかったりします。
これは、奥から順に地面の描画を全部済ませ、次に影を全キャラクター
分描画、最後にキャラクター本体の順で良いんでしょうかね？

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

**名無しさん＠お腹いっぱい。** · 01/11/10 16:29

>>23
イマドキのハードなら、Zバッファ使うか、それがイヤなら>>22さんの
いうとおりに描画順序テーブル組んでみたら？
テーブルの解像度を32bit程度にして、影は投影される面より少し
オフセットをつけてやれば十分事足りるはず。

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

実装が悪いだけでは？問題点も3Dのものと本質的に変わらない
（2D特有で、3Dにはない問題ではない）みたいだし。

23 · 01/11/10 16:34

いや、まったく仰る通りでして、実装に問題があるようなので、
こうしてご指導を仰ぐべく、参上しております（笑）
>影は投影される面より少しオフセット
これはどういう意味でしょうか？

24 · 01/11/10 16:56

>>25
Ｚ値が同じ時に影が埋まって見えなくなったりするのを防ぐために
少しオフセットをつけて、描画順位が同じ時の実行順を保証してやる事。

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

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

１背景を３Ｄオブジェクトで表示。Ｚバッファを埋める。

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

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

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

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

表示したいものが凄く多くて（AOEやコサックスみたいに）、足元の影だけ
描画できればいい（投影される必要が無い）なら、表示オブジェクトの足元に
書き込んでやるのが現実的かも。

**名無しさん＠お腹いっぱい。** · 01/11/10 17:17

23さんはおそらく、PCをターゲットにした話でしょうから、わたしもそれに従います。
昔なら描画矩形を限定することで描画処理を軽くすることが多かったですが、
最近では全部を再描画かけるようにするのが一般的です。
もっとアプリケーションよりの話もあります。
背景をブロックの組み合わせで作成している場合、前のフレームの背景と
今回描画するフレームの背景を比べて、違うブロックだけ転送して新たな背景を
作るということもできます。
そして、作成した背景->影->人物->手前の背景->ウィンドウなど、というふうに
すれば、メモリ転送を減らせるでしょう。

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

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

23 · 01/11/10 17:41

26,27さん、ありがとうございます。
オフセットの意味、良く分かりました。
ご推察通り、ＰＣターゲットでして、スペックがバラバラなのが
前提ですので、可能な限りサクサクと描画して、余力を残したい
というのが目標です。

現状では、かなり素直な方法で試しています。
奥からひし形のタイル地形（クオータービュー）を並べて描画し、
さらに奥にいる（移動中の現座標において）キャラから順に、
影をやはり２Ｄで描画、最後がキャラ本体です。
これですと、高低差がある地形では、手前の崖が奥の平地を
塗り潰す事は良くあるので、これは描画前に計算し、不要な
描画を取り除いきます。

結果、まだ速度が足りない（涙）ので、対処として今考えている事は
背景部分を一度組み立てておいてから、まとめて四角形で送るように
しようかと思ってます。
これですと、中央にいるキャラが動いた際、新たに視野に入る部分を
継ぎ足せば良いですよね？
四角形ですので、ひし形の「余白」の無駄も減らせるかなーと。
（ひし形ですと、単純計算で四角の倍の面積を転送せねばならないので）

**名無しさん＠お腹いっぱい。** · 01/11/16 21:38

>>23氏はRPGの移動画面かアクションゲームに
クオータービューを使おうとしているの？
そんなに遅くなるような処理とは思えないけれど…。

**名無しさん＠お腹いっぱい。** · 01/11/18 08:14

>>29
マップチップが小さいとか、解像度が大きいとか、
FSP60とか、表示個数が多いとか、コードがヘボとか、
色々考えつくケド……

FSPを40ぐらいで作ってみると、楽なんでは？

**名無しさん＠お腹いっぱい。** · 01/11/18 09:30

>>29
FSPって何?

**名無しさん＠お腹いっぱい。** · 01/11/19 15:16

>>31
fpsの間違い。１秒間の画面描画数。

**名前は開発中のものです。** · 01/12/08 04:05

↑↑↑　人　気　急　上　昇　↑↑↑

**名前は開発中のものです。** · 01/12/08 05:27

ち、アドバンスは今時のハードじゃないのかよ。

**名前は開発中のものです。** · 01/12/17 07:30

上げ

**名前は開発中のものです。** · 01/12/17 15:39

　　　∧ ∧
　　(　ﾟДﾟ）ゴルファァ
　　U　U
　／ l
　U U

**名前は開発中のものです。** · 01/12/17 16:15

どういう描画の仕方してるの？余白って・・・
普通は余白の出来ないデータ構造にするもんだけど。
DirectDrawのBlt使って実装するなら、水平方向の対角線は完全に水平になるように
して、タイルは１マスずつ持つんじゃなくて1/4のマスと隣のマスの1/4で１つの矩形
にして、矩形単位で描画が良いかと。マスの種類の2乗のデータ量になるが。
でも、これはBGとかPCG使う場合は常套手段。というよりそうしないと実現できない。

CPUで１ドットずつ描画するなら余白の無いデータ構造にするのが吉。
１次元配列に詰め込めば問題ないかと。描画するときは配列を走査しながら、描画先
をひし形に走査するのが良いんじゃない？

あと、Zバッファみたいな仕組みはかえって帯域食うからおすすめできない。

・・・って一ヶ月前の話題にレス付けても遅いかな

**名前は開発中のものです。** · 02/01/14 18:48

あげ

**名前は開発中のものです。** · 02/01/14 19:50

ネタはないのか。ネタは。
私のジャギ消し方法、とか。

どうでもいいや。

02/02/26 18:36

なんでこういうスレがあがってないんだ？？
ゲーム製作においてグラフィックプログラミングは重要なことだろ？

**名前は開発中のものです。** · 02/02/26 18:59

>>40
ネタを振りなさい

**名前は開発中のものです。** · 02/02/26 20:45

プールの飛び込み台を作るのに弾力を持たせて
上下に揺らしたいんだけど計算方法ってどんな感じ？
釣り竿みたいなしなり方するのもやってみたい。