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

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

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

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

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

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

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

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

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

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

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

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

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

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

良いワイプない？

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

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

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

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

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

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

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

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

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

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

ヤハリレスハナカタカー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>29
FSPって何?

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

↑↑↑　人　気　急　上　昇　↑↑↑

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

上げ

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

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

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

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

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

あげ

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

どうでもいいや。

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

>>40
ネタを振りなさい

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

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

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

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

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

初めて耳にする解釈だ

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

実際ゲーム作るときのアルファブレンドってどうしてる？
Dirext使う以外の方法。

俺はデバイスコンテキストのビットマップ取得して
自前で計算して書き込み、って感じでやってるんだけど
ビットマップの取得って遅いんだよな。

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

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

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

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

openglてどんなの？

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

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

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

描画速度とマップデータ作成の手間だよなぁ…

どっかでちらっとみたハズだけど
見失ったのでおしへてください。

中心から放射状にライン(元絵にブレンド)するのは
なんていうでしょ〜か？

おしへてください。

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

>>大和日のまるブレンド
それは、可視光線につかうやつだから違います。

僕が煎ってるのはとはちょっと違います。

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

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

>>62
ホワイトノイズとピンクノイズ
ttp://www.cr.ie.u-ryukyu.ac.jp/~jahana/study/7th/node2.html

　ぐぐったらトップに出てきたよ…。

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

保守あげ

　

あぼーん

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

あぼーん

いや、大本眞基子だろ。

あぼーん

あぼーん

あぼーん

あぼーん

現在、荒らしによってこの板の利用が困難になっているため、避難所を作成しています。
出来ればこちらに移動するのをお勧めします。

ゲ製作技術板(避難所)
http://bbs.gamdev.org/gamedev/

↓こんな感じにするのがお勧めです。
-----
9 名前：名無しさん＠ゲムデヴ[] 投稿日：2003/05/28 21:33
とりあえずOpenJaneに登録した

板一覧の上で右クリック→新規追加→板名とアドレス入れるだけ

あぼーん

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

あぼーん

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

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

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

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

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

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

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

しません

しましょう

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

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

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

いまさらGDIか

16ビットにするとか。

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

>>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とか吉里吉里見てると余裕で出してるように見えます。
手ほどきおながいします。

VGA*2か。
512*512だと、毎回メモリ転送を繰り返してもPentum3の800MHz/32ビットで
100FPS位出る（Pentium2-400MHzで50-70）みたいだね。ビット数による差
はそれほどないみたい。

http://www.sm.rim.or.jp/~shishido/vdib.html

ただ、DIB/DirectXのようなフレームバッファはビデオ環境に依存する面
が大きいから、CPU/メモリで判断するのは難しい。

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

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

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

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

やっぱ無理があるっぽいんで、FPSが低くてもごまかせるようにゲーム側を調整することにします。
みなさんレスしてくれてありがとです。

>>99
DirectXを使いたくないという、その意義がちょっとわからないな。
自分でdibsectionでやったとこで結局メモリ帯域の壁にぶち当たって終了なだけなんだけど。

全画面に対して半透明をかけるなどするのでなければ、
基本的にDirectDrawでハードウェアブリットを使用して、
適宜、システムメモリに確保したサーフェスで自分でアルファブレンド演算して
それをbltfastするだけでも十二分に問題ないよ

さらに言えば、Direct3Dでビルボード使うのが昨今の流行だよね
アルファブレンドも拡大縮小・回転・変形なんでもやりまくり

>システムメモリに確保したサーフェスで自分でアルファブレンド演算して

なんか変だな。VRAMをLockして自前で書き込む

>>97
オレもDDraw使ってた時はそうしてた。
だけど、出力先がVRAMサーフェィスだと元画像がシステムRAMサーフェイス演算処理が非常に遅くなってしまう。
で、これを解決するにはVRAMから一旦システムRAMにブリットして、そこに半透明の物を描画、
最終的にこれをVRAMに戻す。
こうすればいいんだが、透明オブジェクトごとにこれをやってると大変なことになってしまう。
雲やフェードなどで、半透明処理を画面全体に使いたいので結局ボツになってしまった。
もっと効率のよいやり方があると思うんで、教えてもらえるとうれしいです。

ちなみにDirectGraphicsのさわりを1年以上前にかじったが、受験やら何やらで記憶から飛んでしまった…
SDKとかもどっか消えちゃってるっぽいし…

>>99
MMXとか使うと良いよー
http://www.cyborg.ne.jp/~xelf/developer/MemoryCopy.html
これはメモリコピーの例だけど、アルファブレンドも高速化できるよ

>>103
ありが�d！
MMXはアルファブレンドで既に使ってるけど、メモリコピーでは使ってないんで試してみるわ。

>>102
画面全体に使いたいなら、答えは解像度を落とすか、Direct3Dを使うしかない。
D3Dでの2D描画はお勧め。最初、とっつき悪いけど。

GDIでゲーム作るってのはバスでレースに出るようなもんだ。

たとえｽﾋﾟｰﾄﾞが出なくても、
ﾊﾞｽで安全運転したいんじゃなかろうか？

街乗りにレース仕様を求める輩は(ry

>>94
吉里吉里は鬼のような更新エリア管理（変化があったところしか描画しない）で
あの速度を出していると聞いたことがある。ADVのような画面変化の少ない
ゲームにはすごく有効なんだろうな。常時画面が動いてるようなSTGとかでは
ほとんど意味がないだろうけど。

縦STGなら、画面幅狭くして誤魔化せる♪

>109
>たとえば完全に不透明なレイヤの奥にあるレイヤは描画しないくてよいとか、
>CPUキャッシュを効率的に使用するために画像をキャッシュに収まるぐらいの
>分量で演算して順次画面に転送したりとか、変更のない領域は演算しないとか、
>いろいろあります。
サクーシャの日記より

エメドラとかでやってた差分更新スクロールを思い出しちゃった

タムリン回復してくれ！
いやレーザー出してないで回復してくれ。
おいハスラムお前は下がってろ、死ぬぞ。
だからダムリン、レーザーじゃなくて回復だって。
おいハスラム下がれよ。
あ、死んだ。

>>112
それをいうならテグザー。って歳がばれるな。。。orz

だいぶ下がってるみたいだが、誰もいないのか？
誰かいたらageてくれ

おらおら

オラオラ

>>88
フレーム管理の処理は入れたか？

>>118
88だが、そのやつはウェイト無しでやったからフレーム管理はしてない。
実際に使う時は、MMタイマー使ってＦＰＳを保つけど。

>>115出てこいや

DirectXに逃げずに未だにＧＤＩでふんばってる香具師ってどのくらいいるんだ？

テーブルゲームとかパズルゲームの作者なら
ふんばってるかも。

GDIに逃げずにDirectXに移行してる香具師ってどのくらいいるんだ？

誰か画像の任意角回転方法教えてください！

>>124
2Dか？
3D機能を使うのか？
ピクセルをゴリゴリしたいのか？

ピクセルゴリゴリキボンヌ

擬似コードで書くとこんな漢字だろ？
for (int y=-16;y<17;++y) {
　for (int x=-16;x<17;++x) {
　　int xx=x*cos(r);
　　int yy=y*sin(r);
　　PutPixel( Surface1, x,y, GetPixel(Surface2,xx,yy) );
　}
}
コードをお最適化したいならネットで調べてくれ

>>127
そのくらいは既に作ってあるんだけど、画像がデカくなると鈍くてぬるぽ。
もちろんsinやcosは最初の一回だけ演算で、固定小数で座標変換するくらいの工夫はしてるが。

今時のＣＰＵなら余裕だろ
つーか計算以外のところが重いんじゃないの？

今時でないＣＰＵならこの辺が参考になるかも
ttp://homepage3.nifty.com/taka7646/taka/

よく見れば
>>127
ってなんか間違ってる気が…
>>129
回転マトリクス使うわけだが、この乗算を640x480でやったら結構大変だと思うが…

ttp://www.yashok.com/~yashok/oth/pro/win/win_eff01.shtml
要はrotozoomerだろ？
コモドールとかamigaでOldschoolメガデモでタイルぐるぐる回すやつ。
DirectXのラッパか何か使ってるの？
俺はmallocで確保した背景（回転エフェクト）用の領域をQWORD整合して、
描画した後、プライオリティ考慮しながらoffscreenに流し込む方法とってる。
800*600とかでも十分に速度出る。1024*768はさすがにやばいけど。
あとはURLで紹介されているけど、sincosをテーブルにするとか、
テクスチャのサイズを2のべき乗にして剰余演算をANDで置き換える等々。

移転に気づいて久しぶりに来てみたらレス付いてたわ…

>>131
とりあえずmallocでメモリ確保してGDIで出力してる。
演算は固定点小数でやってるが、タイル状のものを回転させてたいわけじゃないんで、
範囲内か外かの判定もドット毎にやってる。
それとαチャンネルも考慮してるせいか、320*240以上の回転だと無理を感じる。

あげ

>>範囲内か外かの判定もドット毎にやってる。
エッジスキャンとか使えばちょっとは楽になるはず。

過疎ってるなみんな順調なのか

　　　　　 　？？？　　←買い犬
　 ？　　？？？〓▲？　　　　　　　　　　　 　　？ ？　？？？？？■？？〓？？ ？ ？ … ．
　？　▼ 　　　　？？▼　　 　　　　　．？？■？ ？ ？　？¨ ∵？ ？ ・
　 ？？　？？ 　 　　？ ？？　　　？？　？？？？　¨？？？？？？？■■〓？？？？
　 　 ？　 ？　？■ 　 　　？　？ ？？？？？？？？？■〓？？ ？？ ∴ ？ ．
　　？　　　？　　　？？　？？？？？？？？？？？ ？ ∴ …．？　？　 ？？
　　 ？？？　 ？？？？？？？？？？？？？？？？　 ？ ？？？？？？
　　　　　？？？？？？？　　　？　 ¨ ？？？■？？？ ？ ？ ∴‥

あげます

アニメーションデータをコンバートするフリーツールってないですか？

>>138
形式が何から何にかぐらい書けよ…

あ、すいません。
2Dのアニメーションコンバートツールをさがしています。
flashとかを通して変換するのでもいいですが、
素材はphotoshopなんで座標の動きなどの抽出ができれば
特に形式はといません。てか、2Dの形式はあんま知らないんですよね。。
データに落とし込めれば何でもいいです。
調べながらやろうという感じですが、あんま検索してもでてこないんですよね。。

>>140
俺の場合、画像データの変換(コンバート)と言えば
拡張子○○のファイルを拡張子○○に変換するというのを思い浮かべるんだけれど、そういう意味では無いのか。

3Dの分野はよくわからないや。
それこそ、Photoshopならたいていの形式に変換して保存できると思うんだけど。
アニメーションならgif形式が一般的。(俺の中では)

>>140 に書いてあることが俺にはさっぱり理解できない。
素材がフォトショップなの？座標の動きが抽出できる２Dフォーマット？

エスパーを呼べ。

ひょっとして、2Dアニメってピクセルの色が固定で
そのピクセル座標を移動してるとおもってる？
3Dのシェーダーでいうバンプマップや、旗、水面の表現みたいに。

すまん、よくわからん説明かいた。
飲み過ぎて、よくわからんはしょりかたしているかも。

>141
どうもサンクス。お話はよくわかります。ただ、2Dっす。

>142

photoshopのデータをflashやAEに持ってきて、
アニメーションを作成。
そのデータをコンバートして
テキストなりバイナリなりのデータに落とし込みたい。
そのコンバートツールをさがしている。
まだアニメーションはつけていない。

これでエスパー呼ばなくても大丈夫かしら？

>143
ピクセルアニメじゃないっす。わかりづらくてすいませんね。

>>144

AEやフラッシュからキーフレームの情報を書き出すツールは知らないな。
そういうアニメーションの汎用フォーマットがあることも聞いたことがない。

うちでも２Dのアニメーションの作成＆再生ってやってるけど、
専用のオーサリングツールを作ってそれでやってる。
そんなに大変じゃないから作った方が早いかも。
PC で再生するんだったら、PS とかも使えるしね。

テキストの汎用フォーマットというとSVGか？

>>144
あらゆるマルチメディアファイルを相互変換するフリーソフト SUPER C
http://gigazine.net/index.php?/news/20060901_super_c/

なんか凄く嘘臭いけど
使ったことある人いる？

>>147
ちょっとは>>144の内容を読んでやれよｗ

145-148
サンクスです。
結論としては、145のいうとおり、
自分で作った方がよさそうじゃないか、になりました。
でも、知らないこともあったので、参考になりました。

英語圏とかに知らんもんがあるかもしれないので、
もしなんか知っている方いましたら書いといてくれるとありがたいです。。
そのうち様子見にくるかもしれませんので。では。

；；；

hoshu

test

test

test

INTEL

あ

http://toro.2ch.net/test/read.cgi/gamedev/1330137413/

　　∧＿∧
　 （　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ｀Д´）/ ←>>128
　（＿フ彡　　　　　 　　/