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

1 ：01/11/07 〜 最終レス ：11/08/16

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

2 ：

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

3 ：

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

4 ：

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

5 ：

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

6 ：

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

7 ：

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

8 ：

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

9 ：

いきなりＡＡに話がずれたあげく底にしずんじゃったネ。
なんとも２ちゃんらしいというか。
ところで昔のゲームってＡＡエディタとかつかってたの？
もしや文字コード表とにらめっこしながらつくってたとか！！

10 ：

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

11 ：

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

12 ：

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

13 ：

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

14 ：

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

15 ：

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

16 ：

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

17 ：

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

18 ：

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

19 ：

ラジオシティを真面目に計算なんてしるはずもなくごまかしでしょう。
デモでそれらしいのは見たことあるけど。
そんなものがゲーム上のソフトウェアレンダリングで動くならnVidiaなんてとっくに
死亡していると思うが。

20 ：

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

21 ：

ヤハリレスハナカタカー

22 ：

あきらめるのが早すぎますよ。
クォータービューの奥からまわす、手前からまわすというのはどう言う意味でしょう?
視点をくるくる変えさせたいのでしょうか。
とりあえず、描画オブジェクトのソートにだけ絞って書かせていただきます。
ソートをしたいだけならバブルソートで十分だと思います。
何千もの表示オブジェクトがあるなら、クイックソートとのベンチを取って
良いほうを採用すれば良いでしょう。
ソートをしたくなかったら、あらかじめ描画順序テーブルを作成して、
それを利用するのが手だと思います。
描画順序テーブルには表示オブジェクトへのインデックス、もしくはポインタを保存
しておきます。
描画するときに、テーブルの先頭から描画処理を行っていったり一番後ろから行っていったり
すれば、うまく重なって描画されると思います。
描画順序テーブルは奥行き(z値)によって長さを変えると分かりやすいのではないでしょうか。
テーブルサイズを256段階にしたら、z値が0から255までを扱える。
z値がそのままテーブルのインデックスになるというわけです。
あとは、同じz値のオブジェクトのテーブルへの格納方法などを考えればいけると
思いますが。
#これはリスト構造で何とかなるでしょう。

23 ：

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

24 ：

>>23
イマドキのハードなら、Zバッファ使うか、それがイヤなら>>22さんの
いうとおりに描画順序テーブル組んでみたら？
テーブルの解像度を32bit程度にして、影は投影される面より少し
オフセットをつけてやれば十分事足りるはず。
>毎フレームこれをやると、ちょっと速度が足りない物で、、、。
>かえって、２Ｄの方が手間ひまかかる面もあるなーと感心してます。
実装が悪いだけでは？問題点も3Dのものと本質的に変わらない
（2D特有で、3Dにはない問題ではない）みたいだし。

25 ：

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

26 ：

>>25
Ｚ値が同じ時に影が埋まって見えなくなったりするのを防ぐために
少しオフセットをつけて、描画順位が同じ時の実行順を保証してやる事。
＃あ、あと32bitもテーブルはいらないかも。これは出てくるものの数や表示したい
＃奥行きの深さにもよるね。
個人的に、今のハード（TNT, GeforceやRADEONクラス）でタクティクスオウガ
みたいな狭いマップなら、
１背景を３Ｄオブジェクトで表示。Ｚバッファを埋める。
２投影された影をポリゴンオフセットつけながら描画。描画はＺ、色値には
　書き込まず、ステンシルバッファのみ書き込み。
３ステンシルバッファ見て影部分を書き込み。（これで影が重なっても暗さが一定になる。）
４キャラ、エフェクトをビルボード描画。ここはＺソートしながら描画。
が一番絵的にも、描画速度的にも折り合いがつく気がする。
表示したいものが凄く多くて（AOEやコサックスみたいに）、足元の影だけ
描画できればいい（投影される必要が無い）なら、表示オブジェクトの足元に
書き込んでやるのが現実的かも。

27 ：

23さんはおそらく、PCをターゲットにした話でしょうから、わたしもそれに従います。
昔なら描画矩形を限定することで描画処理を軽くすることが多かったですが、
最近では全部を再描画かけるようにするのが一般的です。
もっとアプリケーションよりの話もあります。
背景をブロックの組み合わせで作成している場合、前のフレームの背景と
今回描画するフレームの背景を比べて、違うブロックだけ転送して新たな背景を
作るということもできます。
そして、作成した背景->影->人物->手前の背景->ウィンドウなど、というふうに
すれば、メモリ転送を減らせるでしょう。
23さんがどのような実装をしているか分からない以上、
明確な解決法を提示することはできません。
>影は投影される面より少しオフセット
これは、実装する人によって少しずつ意味合いが変わりますね。
z値とほぼ同義と思えば良いのではないでしょうか。
足元の影や、壁に貼りついたポスターなどを描画するときに壁や床よりも
ほんの少し、Z値を視点側にすることで影やポスターが床などにめり込まないよう
する処理です。

28 ：

26,27さん、ありがとうございます。
オフセットの意味、良く分かりました。
ご推察通り、ＰＣターゲットでして、スペックがバラバラなのが
前提ですので、可能な限りサクサクと描画して、余力を残したい
というのが目標です。
現状では、かなり素直な方法で試しています。
奥からひし形のタイル地形（クオータービュー）を並べて描画し、
さらに奥にいる（移動中の現座標において）キャラから順に、
影をやはり２Ｄで描画、最後がキャラ本体です。
これですと、高低差がある地形では、手前の崖が奥の平地を
塗り潰す事は良くあるので、これは描画前に計算し、不要な
描画を取り除いきます。
結果、まだ速度が足りない（涙）ので、対処として今考えている事は
背景部分を一度組み立てておいてから、まとめて四角形で送るように
しようかと思ってます。
これですと、中央にいるキャラが動いた際、新たに視野に入る部分を
継ぎ足せば良いですよね？
四角形ですので、ひし形の「余白」の無駄も減らせるかなーと。
（ひし形ですと、単純計算で四角の倍の面積を転送せねばならないので）

29 ：

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

30 ：

>>29
マップチップが小さいとか、解像度が大きいとか、
FSP60とか、表示個数が多いとか、コードがヘボとか、
色々考えつくケド……
FSPを40ぐらいで作ってみると、楽なんでは？

31 ：

>>29
FSPって何?

32 ：

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

33 ：

↑↑↑　人　気　急　上　昇　↑↑↑

34 ：

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

35 ：

上げ

36 ：

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

37 ：

どういう描画の仕方してるの？余白って・・・
普通は余白の出来ないデータ構造にするもんだけど。
DirectDrawのBlt使って実装するなら、水平方向の対角線は完全に水平になるように
して、タイルは１マスずつ持つんじゃなくて1/4のマスと隣のマスの1/4で１つの矩形
にして、矩形単位で描画が良いかと。マスの種類の2乗のデータ量になるが。
でも、これはBGとかPCG使う場合は常套手段。というよりそうしないと実現できない。
CPUで１ドットずつ描画するなら余白の無いデータ構造にするのが吉。
１次元配列に詰め込めば問題ないかと。描画するときは配列を走査しながら、描画先
をひし形に走査するのが良いんじゃない？
あと、Zバッファみたいな仕組みはかえって帯域食うからおすすめできない。
・・・って一ヶ月前の話題にレス付けても遅いかな

38 ：

あげ

39 ：

ネタはないのか。ネタは。
私のジャギ消し方法、とか。
どうでもいいや。

40 ：

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

41 ：

>>40
ネタを振りなさい

42 ：

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

43 ：

果たしてそれはグラフィックスなのだろうか…

44 ：

>>42
角度にSinをかけて、それに対して(Cos, Sin) で座標を求めると、
しなりが表現できる。

45 ：

半透明ってどうすればいいんでしょう？
アドベンチャーゲームやノベルゲームによくあるメッセージウィンドウが半透明って
いうのをやりたいのですが。

46 ：

>>43
ピクセルエフェクトだけがグラフィックじゃないだろう。
時間軸に対する変化も「ゲーム」のグラフィックで
いいんじゃないか。

47 ：

初めて耳にする解釈だ

48 ：

>>45
アルファブレンド
R=r1*α+r2*(1-α)
G=g1*α+g2*(1-α)
B=b1*α+b2*(1-α)

49 ：

実際ゲーム作るときのアルファブレンドってどうしてる？
Dirext使う以外の方法。
俺はデバイスコンテキストのビットマップ取得して
自前で計算して書き込み、って感じでやってるんだけど
ビットマップの取得って遅いんだよな。

50 ：

別バッファ作って背景保存してる。

51 ：

>>50
別バッファへの書き込みは何を使ってるの？

52 ：

背景をファイルから２カ所のメモリにコピー。

53 ：

DIBSection確保してCPUでゴリゴリしかあるまいて。
ハードウェアに頼らないなら

54 ：

openglてどんなの？

55 ：

SetDIBitsToDeviceを使え！
ちなみに、対応してない環境はしらん

56 ：

1/f揺らぎについて概念を説明してるサイト、ありませんか？
しょっちゅう出てくるんだけど、何のことだかサパーリわかりません

57 ：

>>28 >>37
去年のやつにレスするのもどうかと思うが、どっちが良いんだろ。
DirectX使うんで、余白は半透明にしてゴリゴリ描画させるべきか。
それとも組み合わせの全パターンを用意するべきか。
描画速度とマップデータ作成の手間だよなぁ…

58 ：

どっかでちらっとみたハズだけど
見失ったのでおしへてください。
中心から放射状にライン(元絵にブレンド)するのは
なんていうでしょ〜か？
おしへてください。

59 ：

＞＞５８
大和日の丸ブレンド

60 ：

>>大和日のまるブレンド
それは、可視光線につかうやつだから違います。
僕が煎ってるのはとはちょっと違います。

61 ：

>>56
1/f揺らぎはフラクタルノイズとかピンクノイズと呼ばれるもの。
簡単に言うと振幅が周波数に反比例するノイズ。

62 ：

>>61
とっくに忘れ去られた記事にレスつけてくれてありがとうございます
ホワイトノイズは分かるけど、ピンクノイズって言うのがさっぱりなんで
勉強してきます

63 ：

>>62
ホワイトノイズとピンクノイズ
ttp://www.cr.ie.u-ryukyu.ac.jp/~jahana/study/7th/node2.html
　ぐぐったらトップに出てきたよ…。

64 ：

>>52
このスレは忘れた頃にレス付けるのが流行りなので（大嘘
フラクタル理論ってのは正直言って使いものにならないけど、フラクタル
ノイズだけは利用価値があるから覚えておいて損はないと思う。
フラクタルノイズの生成方法は色々あるけど、中点変位法が使いやすい。
これは与えられた直線や面を複雑な形に変形させるのに向いていて、例えば
直線で構成された地図から複雑な海岸線を生成したり、Terragenみたいな
山や島を生成するのに使ったり、雲の画像を生成するのに使ったりする。
他に扱いやすいのだと、Perlinノイズとかがある。
中点変位法もPerlinノイズも有名なのでgoogleで検索して調べてチョ

65 ：

保守あげ

66 ：

　

67 ：

68 ：

>56
1/fゆらぎというのは森本レオの声のことだとテレビで
みたことあり。あれの抑揚とテンポが「いやし」なのだそうな。

69 ：

70 ：

いや、大本眞基子だろ。

71 ：

72 ：

73 ：

74 ：

75 ：

現在、荒らしによってこの板の利用が困難になっているため、避難所を作成しています。
出来ればこちらに移動するのをお勧めします。
ゲ製作技術板(避難所)
http://bbs.gamdev.org/gamedev/
↓こんな感じにするのがお勧めです。
-----
9 名前：名無しさん＠ゲムデヴ[] 投稿日：2003/05/28 21:33
とりあえずOpenJaneに登録した
板一覧の上で右クリック→新規追加→板名とアドレス入れるだけ

76 ：

77 ：

http://homepage.mac.com/hiroyuki43/hankaku02.html

78 ：

79 ：

>>64
月並だが、ランドスケープ系の地面生成にも使えそうだね。

80 ：

グラフィック用のツールでお勧めのものってありますか?
何かAdobe PhotoShopがいいって聞くけど、どうなんでつか?

81 ：

GIMPはどうだ?GPLでナイスだぞ
藻れのマシンだとタブレット使えないけど。
Linuxだと認識したな

82 ：

>>81
Redですか？Intuosですか？詳しい情報きぼんぬ。

83 ：

>>82
RedHatの8。
　タブレットはWACOMのペインタークラシックとフォトショップエレメンツが付属してる一万円ぐらいの。
　Turbo7で動いた気もするけど確信はない。
　筆圧感知は作動しなかった（別に必要としてないから構わないけど）

84 ：

漏れら極悪非道のage武田騎馬ブラザーズ！
ネタもないのにageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿ﾍ　　　　　　∧＿ﾍ
　 / ＼〇ノゝ　　　 / ＼〇ノゝ age　
　/三/´∀｀）∩　∩/´∀｀）　　age
　（つ　　丿 　　　（ 　　⊂）　age
　 （　ヽノ　　 　　　ヽ/　　）　　　age
　 し（＿）　　 　　　（＿）Ｊ

85 ：

半年もレスが付いてなくてよくdat落ちしないもんだ…
GDI使った描画の話でもしませんか？

86 ：

しません

87 ：

しましょう

88 ：

GDIで描画してるんですけど、どうも速度が出ません…
640x480を2回描画する程度でも60fpsぎりぎりです(CPU1.6GHzで)
最低でもCPUが500MHzで30fpsくらいは出したいと思ってるんですが、
何か裏テクみたいのありませんか？

89 ：

DirectXを勉強しろ。いやならプログラミングは諦めろ

90 ：

>>89
DirectDrawは数年前にやった。
透明処理を自前でやるとGDIと大差ないことが分かった(システムメモリ上にサーフェイス作るわけだから)
実際GDIでも結構速度出てるの見かけるがな…

91 ：

いまさらGDIか

92 ：

16ビットにするとか。

93 ：

>>85
＞どうも速度が出ません…
　
そんな主観的表現じゃ質問の意味が通じるわけねーだろ
　
　・85が期待する「速度」とは具体的に何か
　・それは何を根拠に算出した値なのか
　
を説明しろ。根拠無いから説明不能ってんなら
使用環境とコード（描画部分）ぐらいサボらず書け。
DIBにｿﾌﾄｳｪｱﾚﾝﾀﾞﾘﾝｸﾞしてるってんなら
ｼｽﾃﾑﾒﾓﾘ周りのｽﾍﾟｯｸをちゃんと説明しろ。
ﾒﾓﾘとﾁｯﾌﾟｾｯﾄの種類ぐらいサボらず書け。

94 ：

>>92
16ビットだとアルファチャンネルいれると4bitづつしか使えないからなぁ…
>>93
速度=描画速度のことです。コードは長いので書きませんが、流れ的には、
[画像データ(DIBではない)]→[DIB]⇒[ウィンドウのDC]
(→で単純なメモリコピー、⇒でBitBlt)
この処理を640x480x32の画像で→2回、⇒1回行うとFPSが最大でも60ぐらいしか出ない。
ちなみにループの処理は、PeekMessage()でメッセージが無ければ描画をするといった感じです。
環境はOS:WinXP、CPU1.6Gz(FSB400MHz)、RAM:PC2100DDR512MB、チップセット:SiS645、ビデオボードはGeForce4MX。
オレが期待している速度は、この環境で上記の処理をFPS100以上、500MHz程度のCPUかつ非DDRメモリの環境でも、
FPS30程度を確保したい(FPSが30切るとゲームとしてはキツい)。
無謀なのかもしれないが、HSPとか吉里吉里見てると余裕で出してるように見えます。
手ほどきおながいします。

95 ：

VGA*2か。
512*512だと、毎回メモリ転送を繰り返してもPentum3の800MHz/32ビットで
100FPS位出る（Pentium2-400MHzで50-70）みたいだね。ビット数による差
はそれほどないみたい。
http://www.sm.rim.or.jp/~shishido/vdib.html
ただ、DIB/DirectXのようなフレームバッファはビデオ環境に依存する面
が大きいから、CPU/メモリで判断するのは難しい。

96 ：

640*480の32ビットカラーだと、一枚約1MBある。
これを100FPSにすると、バスに対して秒間100MBオーバー転送が発生する。
VRAMを作業領域として使わず、全てをメインメモリから転送するのは阿呆としかいいようがない。

97 ：

DirectDrawをなぜ使わない
透明処理ってカラーキーのことか？

98 ：

>>97
いちいち大げさだし、落ちた時怖いし。
テトリス程度ならBitBltでも充分過ぎる。

99 ：

>>95のヤツを640x480に改造してみたらFPS160〜200！？
値が不安定だったんで、FPSの算出の精度を上げてみたらFPS110くらいでしたorz
>>96
VRAMを使うと演算に時間がかかってしまうので。
アルファ合成などをしたいときに困る。
ただ、無演算の転送時はVRAMを使うとかは考えたんだが、
VRAMをDDraw使わずに利用する方法が分からないorz
>>97
DirectX使わずにゲーム作ってみたかったんです。
透明処理はアルファ合成やブレンド処理のことでつ。
やっぱ無理があるっぽいんで、FPSが低くてもごまかせるようにゲーム側を調整することにします。
みなさんレスしてくれてありがとです。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
■この板の名無しを考えるスレ■
■とりあえずロゴ作成スレ■
この板のみんなでゲームを作ろう！
お勉強ページ 勝手にリンク