DirectX総合スレ (Part4)

**名前は開発中のものです。** · 2005/11/26(土) 01:58:58

※「鬱だ氏のうスレ」と「DirectX総合スレ」は統合され、
　ゲーム製作技術スレに戻ってきました。

DirectXについて、にいさま達がマターリと
技術情報交換＆雑談するためのスレッド。
初心者用相談室では扱わないような少し高度な話題も受け持つ。

ちなみに、言語はC++がメイン。
C# / VB.NET 使いは、専用スレの方が話がスムーズに進むと思われ。

**名前は開発中のものです。** · 2006/07/13(木) 20:08:24

日本ユニセフって、ユニセフと別組織なんだよな。

**名前は開発中のものです。** · 2006/07/13(木) 21:41:50

>>638
詳しく

**名前は開発中のものです。** · 2006/07/13(木) 23:06:34

>>640
多数のビルボードを表示するような重いゲームでは、
それらの描画にかかるGPUの負荷だけでなく、
管理にかかるCPUの負担も大きくなります。

ゲームプログラミングにおける速度信仰はそう一般化して否定できるほど
バカバカしいものではないと思います。

**名前は開発中のものです。** · 2006/07/13(木) 23:16:20

まだＳＴＧ作るの？
いい加減他のゲームも作れよｗ

**名前は開発中のものです。** · 2006/07/14(金) 00:14:38

>>641
多数のビルボードって何十万枚も描画するつもりなのか？
レンダリングのコストに比べればはっきり言って馬鹿にして無視できるコストにしかならない。

**名前は開発中のものです。** · 2006/07/14(金) 00:45:10

マジレスするとGet()メソッドなんかよりDrawPrimitive()のコールの方が圧倒的に重い。
ビルボードなんて毎フレームバッファ再生成してDrawPrimitiveは数コールしかしないだろうから関係ないが。

**名前は開発中のものです。** · 2006/07/14(金) 08:39:01

いくつかの変数だけLPSTR型なのは嫌がらせでつか
新しいSDKだと変わってるのかな

**名前は開発中のものです。** · 2006/07/14(金) 13:30:34

ぶっちゃけDirectXって放ったらかしになってるメッソドとか
誰が管理してるんだかわからなくなってる機能とか
ごろごろしてるよね。
お前らどうやって勉強してやがるんですか。

**名前は開発中のものです。** · 2006/07/14(金) 19:42:10

勉強か
まーがんばって

**名前は開発中のものです。** · 2006/07/14(金) 22:14:54

>>643
エフェクトで贅沢したら普通に何万は行くぞ

**名前は開発中のものです。** · 2006/07/14(金) 23:00:01

それを別々のビルボードにバラバラに描くつもりなのか？
アホにも程がある。
そもそも贅沢しようというエフェクトをビルボードだけでやるという前提が無能の極み。

**名前は開発中のものです。** · 2006/07/14(金) 23:39:13

まぁカッカすんな。
少し頭冷やせや。

**名前は開発中のものです。** · 2006/07/15(土) 00:13:42

何をどう実装しようと勝手だけど、負荷の重い処理に挙げられてるのが
線形負荷のロジックって時点で釣り確定だな。
衝突判定の類でも持ち出してくれてれば、まだ食いつき甲斐があるものを。

**名前は開発中のものです。** · 2006/07/15(土) 00:18:23

たくさんビルボード使う場合には、描画以外の部分の
速度も重要になりうる、ということは確かなわけだな。

たくさんビルボード使う場合そのものを回避することが
できるか否かはまた別の話として。

**名前は開発中のものです。** · 2006/07/15(土) 00:47:33

線形負荷でもデータが10倍ならかかる時間も10倍ですよ

**名前は開発中のものです。** · 2006/07/15(土) 00:54:28

キャッシュの問題とかもあるから10倍じゃすまない事も多々あるけどな

**名前は開発中のものです。** · 2006/07/15(土) 02:28:56

>>652
>たくさんビルボード使う場合には、描画以外の部分の速度も重要になりうる、ということは確かなわけだな。
なにそれ。
数字だしてよ。

**名前は開発中のものです。** · 2006/07/15(土) 02:37:22

＞たくさんビルボード使う場合そのものを回避することが
＞できるか否かはまた別の話として。

この考えが間違っているんだよ。
誤差程度にしか影響のない部分を直すより、ビルボードの数を減らす事を考えた方が速度的に圧倒的に優位。
それを別の話にしようとする時点で、問題解決能力の欠如が如実に表れている。

**名前は開発中のものです。** · 2006/07/15(土) 03:02:03

>>655
ビルボードの管理で処理速度が問題になるのはどんくらいの
オーダーでの話なのかとかその処理時間とか、ちゃんと計算
してみせろ、到底問題になるとは思えんぞ、という話だな。

>>656
引用部は、単に話が二つあるってだけの意味なんだよ。
> 誤差程度にしか影響のない
かどうかが問題となってるところ(>643と>648)なんで、
その話を先にきっちり済ませたほうがいいと思うよ。
片付けないまま話をどんどん転がしてくのは悪い癖だと思う。

レッテル貼りより、「実際問題になるのかどうか数字だしてみそ」
とか、簡単な指摘をしてやった方が健全な話し合いだと思うなあ。
話が早く済むし。

**名前は開発中のものです。** · 2006/07/15(土) 06:16:53

と自分で数字を出せない>>657がのたまっております

**名前は開発中のものです。** · 2006/07/15(土) 08:06:53

>>658
なぁ。
どう考えたって関数呼び出しのコストなんてウンコみたいなもんの削減に力入れてるのなんて
馬鹿にしかみえないもんなぁ。
しかも、たった数万でこの騒ぎｗ
>>657←ウンコはお前だし、はじめに言い出したのもお前なんだから、お前が数字出して問題あるコストである証明をしてみせろよ。
でなけりゃ>>657は嘘吐き＆ホラ吹き野郎決定。

**名前は開発中のものです。** · 2006/07/15(土) 08:08:13

読んだら違う奴じゃん。

Ｘ>>657
○>>652

**名前は開発中のものです。** · 2006/07/15(土) 08:13:05

何種類か作ってみればいいじゃん。それで一番軽いの採用すれば？
実験体作るのいやだから、どんな種類がいいか人に意見聞いといて
自分と意見違うからごねるって？？なら、最初から自分の信じた道を進めばいいじゃん。

誰がどう見ても効率の悪い話なのに、それしか信じられない人なんてほっとけばいいじゃん。

プログラム書けても、中身小学生ですか？
と、フルスクリーン切り替えウィンドウが出ただけで大喜びの暇人が申しております。

**名前は開発中のものです。** · 2006/07/15(土) 11:47:56

数字なんてチップベンダのスライドで良いじゃん。

http://www.atmarkit.co.jp/fdotnet/directxworld/directxworld01/directxworld01_03.html

シーンがCPU律速なら、これの影響をモロに受けるってだけの話でしょ。

**名前は開発中のものです。** · 2006/07/15(土) 11:48:41

>>661
ゆとりの賜物

**名前は開発中のものです。** · 2006/07/15(土) 12:40:31

多対一で袋叩きにしてるときの揚げ足取り、
レッテル貼りがいつでも通用すると思ってるあたりが

**名前は開発中のものです。** · 2006/07/15(土) 12:40:51

フルスクリーン切り替えも真面目にやると、普通にDirectXのサンプルになってくね。
いやまあ、サンプルがそう作ってあるのは当然なんだし、そうじゃなきゃサンプルとして困るわけだけど、
全画面化切り替えとデバイスのロスト->復元に、あんなにいっぱいフックかまさなきゃいけないだなんて
思っても見なかったんだ。

これも勉強だと思って真面目に書いたら２日くらい使った。
もうぬるぽ。

**名前は開発中のものです。** · 2006/07/15(土) 14:25:00

>>656
重いなら減らせばいいって考えは一番低脳。
そんなことは考えるまでもなくわかってる事だし、

ビルボードのエフェクトが重いというなら
何処が実際にボトルネックになっているかをきちんと調べることが大切。

重いからポリゴン減らせばいいとかアホでもできる。

**名前は開発中のものです。** · 2006/07/15(土) 16:53:57

ポリゴン数を減らしてつつフェクトの質を落とさないように考える部分なのに、
ビルボードに限定していることとい、まともに3Dを扱えていない事が丸分かりになってるな。

**名前は開発中のものです。** · 2006/07/15(土) 17:10:48

質を落とさないように工夫して、って言ったところで結局はごまかしなんだから
ポリゴン数やビルボードの枚数減らせば不自然な状況ができるわな。

昔は爆発とかは一枚の大きなビルボードで表現されていたが、
今は複数枚重ね合わせるのが一般的。

**名前は開発中のものです。** · 2006/07/15(土) 17:48:25

ビルボードの処理で負荷かかるのは大抵CPUかPSだろう。
フィルレートが足りないなら縮小バッファを使うとか出来るし、
CPUが厳しいなら最適化できる場所があるかどうかまずは調べるだろ。

ビルボードでエフェクト出した＞重かった＞じゃぁ減らせばいいや
これじゃ進歩がない。

最近のGPUでVSが吊るなんて事はそうそうないしポリゴン数
減らして軽くなるって状況はあまりないとは思うけどね。

**名前は開発中のものです。** · 2006/07/15(土) 17:52:56

多数を重ねる必要のある処理をビルボードでやろうとする時点で選択が間違っている。
馬鹿の一つ覚えは結構だが、UVを適切に設定してまとめて描くだけで、
ビルボードでごちゃごちゃやるより遥かに速度が改善する。

**名前は開発中のものです。** · 2006/07/15(土) 18:01:08

いくらなんでもビルボード1枚描く毎にDrawPrimitiveするヤツは今さら居ないだろ。

普通はデカイ頂点バッファをDYNAMIC|WRITEONLYで作成して
DISCARDロックして一括で転送してからDrawPrimitiveするだろ。

1枚ずつDrawPrimitive呼んでたらあっちゅーまにCPUが吊る。

**名前は開発中のものです。** · 2006/07/15(土) 18:01:14

それじゃ奥行きがないから壁際で不自然になるだろ。

**名前は開発中のものです。** · 2006/07/15(土) 18:19:58

>>672
えっ？冗談？ネタ？なんで全ての深度を同じに考えるわけ？

**名前は開発中のものです。** · 2006/07/15(土) 20:08:08

ビルボード一枚ならZ値全部同じになりますよね

**名前は開発中のものです。** · 2006/07/15(土) 20:25:58

念のため訂正。ピクセルシェーダ使えば場所によってZ値変えられるな。
でもペラペラの板一枚なことにはかわりない

**名前は開発中のものです。** · 2006/07/15(土) 20:45:41

てかZ値はいくらでも変えられるだろ・・・
ビルボードだから変えられないってのもおかしかろう。

**名前は開発中のものです。** · 2006/07/15(土) 21:04:03

大爆発を小爆発の重ね合わせで表現する時に、
テクスチャに小爆発を重ね合わせたあと一枚のビルボードとして
表示って話だろ？これで一個一個の小爆発の奥行きの違いを考慮した
描画ができるっていうんなら本気で教えてほしい

**名前は開発中のものです。** · 2006/07/15(土) 21:34:31

>>677
も、も、もしかして>>671を理解できてない？そうだよね？

**名前は開発中のものです。** · 2006/07/15(土) 21:36:57

志村ー書き込み時間書き込み時間！

**名前は開発中のものです。** · 2006/07/15(土) 21:51:54

ビルボードを常に投影面と平行にしておくとか。
さすがに用途が限られすぎるか。

**名前は開発中のものです。** · 2006/07/15(土) 22:27:38

672は671へのレスだと思ってたら
6秒でレスすんのは無理あるなｗ

**名前は開発中のものです。** · 2006/07/15(土) 22:31:32

ビルボードに法線マップ適応して、凸面表現してるゲームがあったな。
ディスプレイメントマップ使えばできるんじゃないのか？

**名前は開発中のものです。** · 2006/07/15(土) 22:56:50

法線突っ込んでライト適用するだけでも
煙とかならかなりそれっぽく見えるよ。

**名前は開発中のものです。** · 2006/07/15(土) 23:09:16

ワンダがやってた奴だな。
実際に入れてみたら気持ち悪いほど立体感が出て吹いた。
爆発の中心にライトを置いたりすると、とてもいい感じ。

**名前は開発中のものです。** · 2006/07/16(日) 08:22:59

>>615
いまさらコレ読んでるけどすげーなあｗ
理屈は分かるけど俺には到底実装できねえ
と言うかマンパワーだな、擬似HDRのところとか

**名前は開発中のものです。** · 2006/07/16(日) 12:03:12

確かにシーン分けてHDRって考えは思いつかなかったな。
PS2でHDRやったときは高輝度部分をαに仕込んでポストエフェクトで実装してた。

**名前は開発中のものです。** · 2006/07/16(日) 17:14:14

普通そんなもんじゃね？
ワンダのはちゃんと明暗順応までやってんのが偉い。
効果的だったかは微妙だと思うけど…。

**603** · 2006/07/17(月) 11:02:29

>>604-606
ありがとうございます。
とりあえずこの方法でやってみます。

**名前は開発中のものです。** · 2006/07/17(月) 11:38:59

本当にありがとうございます。

**名前は開発中のものです。** · 2006/07/17(月) 13:31:52

warning LNK4089: 'd3dx9_30.dll' へのすべての参照は /OPT:REF によって廃棄されます。
と警告がでました。どうすれば消せますか？

**名前は開発中のものです。** · 2006/07/17(月) 13:43:01

ほっといておｋ

**名前は開発中のものです。** · 2006/07/17(月) 21:01:12

xファイルを，テキスト，バイナリ，圧縮それぞれ相互変換させるプログラムを作成してます．
DirectXのAPI使ってます．

テキスト，バイナリファイルの書き出しは可能なのですが，圧縮ファイルの書き出しがうまくいきませぬ．
APIリファレンスによると，
CreateSaveObject(LPCSTR szFileName,DXFILEFORMAT dwFileFormat,LPDIRECTXFILESAVEOBJECT* ppSaveObj)
関数を使用して，第２引数をァイルフォーマットの値を論理和，つまり，テキスト圧縮なら3, バイナリ圧縮なら2を与えているのですが，
通常のテキストファイル，バイナリファイルが書き出されてしまいます．原因がまったくわかりません．

**名前は開発中のものです。** · 2006/07/17(月) 21:10:11

D3DXF_FILEFORMAT_COMPRESSED | D3DXF_FILEFORMAT_TEXT
ってやってみたら？

**692** · 2006/07/17(月) 21:17:10

D3DXF_FILEFORMAT_COMPRESSED | D3DXF_FILEFORMAT_TEXT
これでも，無理です．

**名前は開発中のものです。** · 2006/07/17(月) 21:19:12

http://pc8.2ch.net/test/read.cgi/tech/1144878498/827

**名前は開発中のものです。** · 2006/07/17(月) 21:19:59

原因は知っているが、マルチが酷いので教えない。

**名前は開発中のものです。** · 2006/07/17(月) 21:21:38

http://bbx.hp.infoseek.co.jp/cgi-bin/bbx.cgi?log=50&vew=29

**名前は開発中のものです。** · 2006/07/17(月) 21:30:28

今すごいマルチを見た。

**694** · 2006/07/17(月) 21:46:15

すんません．普通にせっぱつまって‥‥
マルチの意味調べました．ほんとうにすんません．

**sage** · 2006/07/18(火) 13:26:22

いいよ。俺が許す。君が許さないなら俺が許すさ。

**699** · 2006/07/18(火) 18:26:53

どうもです・・・

**名前は開発中のものです。** · 2006/07/19(水) 07:09:04

Aero Glassって…orz

**名前は開発中のものです。** · 2006/07/20(木) 00:02:15

struct COLOR_POINT
{
D3DXVECTOR3 vecCoord;
DWORD dwColor;
};
COLOR_POINT ColorPoint[2]=
{
D3DXVECTOR3(-0.5,0.3,0),D3DCOLOR_ARGB(255,255,0,0),
D3DXVECTOR3(0.5,0.2,0),D3DCOLOR_ARGB(255,0,255,0)
};
g_CGraphic.GetD3DDevice()->SetFVF(D3DFVF_XYZ | D3DFVF_DIFFUSE );
g_CGraphic.GetD3DDevice()->DrawPrimitiveUP(D3DPT_LINELIST,1, ColorPoint, sizeof(COLOR_POINT));

で色つきのラインを描画しようとしています。
ですが黒色のラインがでてしまいｍす、原因をして何が考えられますでしょうか？
深度バッファとかをしようしていますが特に関係ないですよね。

**名前は開発中のものです。** · 2006/07/20(木) 00:12:24

>>703
とりあえずライティングオフにしてみなさいよ。

**名前は開発中のものです。** · 2006/07/20(木) 00:15:10

なおた、ありがと

**名前は開発のものです** · 2006/07/23(日) 16:22:09

ふぅ、やっとこさID3DXMeshを使って表示できました。
「よし次は、当り判定だぁぁ」と思ったのですが、ちと行き詰りました。

頂点バッファに格納されている局所座標の座標値が、ワールド座標へ
座標変換された値は、どうやってとりだすのだぁぁとなってしまいました。

もふかして、頂点バッファから頂点データを取り出し、自前で、
ワールド座標座標変換を行う必要がいるのでしょうか？

お手数ですが、何卒ご教授して頂きたくお願い致します。

**名前は開発中のものです。** · 2006/07/23(日) 17:14:48

>>706
メッシュとメッシュで当り判定しようとしてんの？
普通は当り判定用の球（中心と半径）とか箱（縦横高）とかを
モデルとは別に用意、もしくはモデルから算出して、それ同士でヒットチェックを行う。

**名前は開発中のものです。** · 2006/07/23(日) 17:34:03

ポリゴン単位の判定では局所でデータを持っているはずだから、
当たり判定の座標データを局所に変換してやればいい。

局所→ワールドに変換する行列があるはずだ。
それの逆行列を求める関数もある用意されているはずだ。

あとは当たり判定の座標データを、
逆行列を用いてワールド→局所に変換すればいい。

当たり判定で決定される座標データは局所だから、
必要に応じてワールドに変換する。

ベクトルは直には変換できないから、専用の変換をするか、
始点終点を変換してからベクトルを求めるといい。

**名前は開発のものです** · 2006/07/23(日) 18:06:47

707,708様、回答ありがとうございます。
ふむふむ、バウンディングでの当り判定は、別値として持って演算し、判定するのですね。

つぎに、ポリゴン同士の当り判定になった場合は、一方の構成している局所座標から
局所座標への座標変換を考えればいいのですね。

と、なると、
一方の局所座標へ変換を行うのであれば、構成している頂点データ全て座標変換処理が必要になるのですね。

ふむふむ、少し光が見えてきましたぁぁ。（これは、ＤｉｒｅｃｔＸ側で
処理する関数は、ないんでしょうか？）

**名前は開発中のものです。** · 2006/07/23(日) 18:09:53

Ｘファイルから立方体を読み込み、頂点の数、位置を取得したところ
頂点の数は24個だったのですが、これだと1面あたり頂点の数は
4個ということになりますよね。
しかし、三角形のポリゴンで立方体を作ると頂点の数は36個、
1面あたりの頂点の数は6個になりますよね。こうなるように
頂点の情報を取得したいのです。

要は、Ｘファイルの頂点の情報を三角形のポリゴン単位で取得したいのですが
どのようにすればいいでしょうか？

ご教授お願いします。

**名前は開発中のものです。** · 2006/07/23(日) 18:44:31

インデックスバッファをきちんと理解すれば分かると思う

**名前は開発中のものです。** · 2006/07/23(日) 19:11:32

>>709
>ポリゴン同士の当り判定になった場合は
そううまくいかねーぞ。
ポリ同士の当り判定はかなり無駄に時間がかかる。
ポリ同士の当り判定だったとしても簡易モデルを用意するんじゃなかろうか？

さらにヒットした後にどんな情報がほしいかでもデータ構造を代える必要が出てくるかもしれんし。
描画に使う頂点データを当り判定でもそのまま使うこと自体稀な話だ。

ちなみにポリ同士の場合、ヒットした後にヒットした箇所を割り出すのはヒットする物にもよるがかなり困難だと思う。
例え、ライブラリにポリ同士の当り判定がサポートされていたとしても俺はゲームでは使ったことが無いな。

それとお前、話に自分用語を入れるくせがあるようだけど、プログラマとして正直うまくねーぞ。
だれにでもわかる言葉で、今、抱えてる問題を表現できる能力がなきゃ未来はねーぞ。
それと「ふむふむ」とか理解できてるのかできないとかよくわからねーけど、正直、不愉快だ。やめろ。普段でもでてきちまうぞ。

**名前は開発中のものです。** · 2006/07/23(日) 19:19:41

「ふむ」は一回で十分。OK?

**名前は開発中のものです。** · 2006/07/23(日) 19:35:03

うむ

**名前は開発中のものです。** · 2006/07/23(日) 19:41:35

よもやゲームでポリゴンvsポリゴンで当たり判定するとは思わなかったｗ
（せいぜい地形やターゲットとベクトルの判定を予想
非常に負荷が高い事が予想される処理だが、
格闘ゲーとか、１フレームに数回とかならなんとかなるんじゃね？
３DSTGなら、そもそもポリゴンvsポリゴンの判定する前に決着つくし。

まぁ俺は「なんとかなる」レベルの処理なんて、なるべくやりたくないし、
幸い今のところやらずにすんでいる。興味はあるけどね。

というわけで、>>709は実装完了したらレポートよろｗ

＞ふむふむ、少し光が見えてきましたぁぁ。（これは、ＤｉｒｅｃｔＸ側で
＞処理する関数は、ないんでしょうか？）
どの処理の事はよくわからんが、
逆行列を求めるならD3DXMatrixInverseでいいんじゃないか？

**名前は開発中のものです。** · 2006/07/23(日) 19:52:50

>>715
>格闘ゲーとか
逆に使わないっしょ。
このアクション中は当りがこんだけとか調節したいだろうし、
モデルでやっちゃうとデザイナの見た目でゲーム性が変わっちゃうじゃん。

**名前は開発中のものです。** · 2006/07/23(日) 20:42:35

フムッフムフム、フムッ!!

**名前は開発中のものです。** · 2006/07/23(日) 20:44:17

ふむ？

**名前は開発中のものです。** · 2006/07/23(日) 20:56:43

>>706
つヒント:IDirect3DDevice9::ProcessVertices

**名前は開発のものです** · 2006/07/24(月) 02:42:00

ふむふふむ、の言葉が不愉快に思われたのは、ごめんさない。
うんと、うんと、これも、不愉快？うークセかなー
皆様ご教授ありがとう、ございます。
いま、ヒントとしてあげて頂いた事、一生懸命、自分なりに考えております。
皆様、ご教授ありがとうございます。

**名前は開発中のものです。** · 2006/07/24(月) 06:40:44

>>720
そういうくだらん態度をとることにメリットを感じるならプログラマには向いてないだろう。

**名前は開発中のものです。** · 2006/07/24(月) 07:00:29

んな目くじらたてるようなことかねｗ

**名前は開発中のものです。** · 2006/07/24(月) 09:22:52

不思議系スーパープログラマーってのはアリだなぁ
ほえ～とか言ってんのに何故か爆速コード書けるの

**名前は開発中のものです。** · 2006/07/24(月) 12:38:48

スーパープログラマという名称には悪いイメージしか残されていない。

**名前は開発中のものです。** · 2006/07/24(月) 16:52:40

クリエイトのカードでどんなプログラムも作っちゃうよ

**名前は開発中のものです。** · 2006/07/25(火) 15:00:37

Xファイルを使わずに独自形式を読み込んでDrawPrimitiveで
描画しているのですが、やめたほうがいいのでしょうか？

**名前は開発中のものです。** · 2006/07/25(火) 15:01:24

>>726
んなこたぁない。

**名前は開発中のものです。** · 2006/07/25(火) 15:09:02

>>726
俺もそうしてる。

**名前は開発中のものです。** · 2006/07/25(火) 16:24:25

>>726
賢い

**名前は開発中のものです。** · 2006/07/25(火) 17:35:32

ポリゴンが描画されるときの順番って、
アドレスの小さい方のトライアングルから、
って保証されてないよね？

**名前は開発中のものです。** · 2006/07/25(火) 17:44:30

DrawPrimitiveならそれはされてる。
というかされてないと話にならない。

DrawIndexedPrimitiveはIndexBuffer次第。

**名前は開発中のものです。** · 2006/07/25(火) 17:56:37

>>731
あ、そうなんだ。サンクス。
ちょっと謎が氷解。

**名前は開発中のものです。** · 2006/07/25(火) 19:35:00

>>726
他のフォーマットからの変換ツールやらエクスポーターとか
用意できてX形式でできることがだいたいできてるなら
むしろそっちのほうが理想。

**名前は開発中のものです。** · 2006/07/26(水) 01:42:06

Xが特別洗練されてるわけじゃないしなー。
方言も多いし、安い3Dソフトだと吐き出すのが大変だったりもするし。

**726** · 2006/07/26(水) 18:52:27

返答ありがとうございます。
Ｘファイルで出来ることを完全に把握していないので理想かは判りませんがこのまま直進します。

また、初心者な質問をすることもあると思いますがその時もよろしくお願いします。

**名前は開発中のものです。** · 2006/07/26(水) 19:22:42

VRML

**名前は開発中のものです。** · 2006/07/29(土) 10:26:51

ファイルから読み込んだ1文字をLPD3DXFONTのDrawText()で表示させるにはどうすればいいでしょうか？
ぐぐっても
DrawText( ... , "hogehoge", ... , ... , ... , ...);
のように文字を直接与えてるサンプルばかりなので。
私の場合、まずchar c;　と定義して　c　に　「h」という一文字を入れ
DrawText(... , &c, ...);
としても文字化けしてしまうようです。

要するに、第二引数の与え方がよくわからんとです。
どなたかご教授お願いします。

**名前は開発中のものです。** · 2006/07/29(土) 10:39:38

Cの勉強からしなおしたほうがいいような･･･
char str[2];
str[0] = c;
str[1] = '\0';