DXライブラリ総合スレッド 2008

**名前は開発中のものです。** · 2008/10/25(土) 17:37:53

Cを習得した程度のスキルでも、
GUIのゲームを比較的容易に作成する事を可能にする、
「DXライブラリ」に関するスレッドです。

DXライブラリの詳細ついては
http://homepage2.nifty.com/natupaji/DxLib/
を参照して頂きたい。

DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。

過去スレ：DXライブラリ総合スレッド
　　　　　　http://pc11.2ch.net/test/read.cgi/gamedev/1197468399/

**名前は開発中のものです。** · 2009/03/11(水) 12:48:22

>>814
対応してないとかじゃなくて、単に古くて多用されない技術だからじゃないかと無責任に予想

**名前は開発中のものです。** · 2009/03/11(水) 23:25:34

使えたら部分的なぼかしとか波紋とか屈折描画とかできて表現の幅ひろがりまくりんぐなのに・・・

**名前は開発中のものです。** · 2009/03/11(水) 23:28:32

シェーダサポートフラグですね。わかります。

**名前は開発中のものです。** · 2009/03/12(木) 00:06:32

>>816
いいなぁそういうの使ってみたい。

**名前は開発中のものです。** · 2009/03/12(木) 14:35:44

歪みはテクスチャに背景を描画→２Ｄポリゴンで挑戦中

**名前は開発中のものです。** · 2009/03/12(木) 23:20:03

>>814からの流れに関連してるかわからないけど、
ちょっと前に気になった事があるので質問させてください
LoadGraph系統以外で作成したグラフィックハンドルから
グラフィックデータのメモリを参照し、編集する事ってできないんしょうか？
SoftImage系の関数で同じような事はできるみたいだけど、
これは画像ファイルから取得したもののみですよね。。

**名前は開発中のものです。** · 2009/03/13(金) 00:27:53

>>820
MakeXXXColorSoftImageじゃあかんの？

**名前は開発中のものです。** · 2009/03/13(金) 00:43:55

Easy3D正式版きてるな

**名前は開発中のものです。** · 2009/03/13(金) 01:09:59

>>820
ありがとう、今気付いたんだけど先に用途を書くべきでした。
例えば>>816の波紋を実現しようと考えた時、
「このエフェクトをかける前までに描画された画面から
　エフェクトをかけたい矩形のグラフィックを取得して、
　これを元にピクセルを書き換える」
という処理を考えてみたんですが、GetPixelは重いようなので、
なら直接メモリを参照できないかと思った次第です。

MakeXXXColorSoftImageで作成するのはソフトグラフィックハンドルなので、
ここを描画先にしたりはできませんよね。。？

**名前は開発中のものです。** · 2009/03/13(金) 01:19:10

>>823
訂正：ソフトグラフィックハンドル->ソフトイメージハンドル
あと「描画先」と書いたのは、「DrawGraph等で描画できる描画先」という意味です。
直接グラフィックハンドルをソフトイメージハンドルに変換できる方法があればよいのですが。
そもそもこの考え方自体がアホなんでしょうか。。。

**名前は開発中のものです。** · 2009/03/13(金) 03:43:56

>>824
画面全体にエフェクトを掛けたりするのに有ると便利だが、ちょっと調べてみたが出来ないっぽいね。

そもそもLoadGraphやMakeGraphはVRAMに転送した時点でPC環境に依った画像フォーマットに変換されちゃうから、
そこからソフトイメージハンドルを生成するとなると、コンバーター(デコーダ相当）が必要になる。
DXライブラリの作者としては手間が掛かるから、要望が無い限り実装を見送っていると予想している。
優しい作者さんなんで、要望送ってみてはどうかな？

現状で対応するとなると、どうしても遅くなるが、
画面サイズと同じ大きさにMakeGraphした裏画面領域をSetDrawScreenして、
一連の画像を転送し、GetPixcelとDrawPixcelするのがベストな選択かねぇ。

SaveDrawScreenを使ってbmp保存して、そこからSoftImageを作るという最終手段もある。(とても遅い)

**名前は開発中のものです。** · 2009/03/13(金) 03:50:25

>>823
ああ。書いてておもったが、SaveDrawScreenがあるから、デコーダ処理は既に内部には出来てるのか。
作者に要望だすと、すぐに実装してくれると思うよ。

**名前は開発中のものです。** · 2009/03/13(金) 04:00:17

解説グラフィックデータのあるメモリ領域には『ロック』をしなくてはアクセスする事が出来ません。
細かい事は抜きにしてとにかくWindows 環境ではメモリの管理が厳重なので malloc関数などで確保したメモリ領域のように簡単にはアクセスは出来ないようになっています。だから『ロック』という作業を行い直接アクセスできるようにします。
　グフィック領域に直接アクセスする利点はDrawPixel や GetPixel 関数を使用するよりも処理が速い、等があります。
　ロックの説明をはじめる前に注意なのですが、ロックを行った場合は直接アクセスが終り次第直ちにロックを解除してください。
ロックをしている最中にデバッグモードなどのブレークポイントを使ってプログラムを止めるとハングアップするので注意してください。
ロックをすると『GraphUnLock』関数を使用してロックを解除しない限り DrawLineをはじめすべての描画関数が使用不可能になるので注意してください。
　では話を元に戻します。
　ロックをするにはまずロックをしたいグラフィックハンドル、または DX_SCREEN_FRONT , DX_SCREEN_BACK 識別子を使って画面をロックする事も出来ます。
　ロックが完了すると関数は PitchBuf に指定したポインタにロックしたグラフィック領域の１ライン辺りのバイト数と、DataPointBuf で指定したポインタにロックしたグラフィックへのアドレスが代入されます。
　こうしてロックしたグラフィック領域にはめでたく直接アクセスが出来るようになります。まず希望の座標（点）にアクセスするには以下の式を用います

　　(グラフィック領域の先頭アドレス) ＋
　　(Ｘ座標値 × (グラフィックのカラービット数 ÷ ８)) ＋
　　(Ｙ座標値 × １ライン辺りのバイト数)

　　＝希望の座標のポインタ

**名前は開発中のものです。** · 2009/03/13(金) 04:02:17

　この中の『グラフィック領域の先頭アドレス』と言うのは DataPointBuf から取得できる値、『１ライン辺りのバイト数』は PitchBuf から取得できる値
『グラフィックのカラービット数は』SetGraphMode関数の引数 ColorBitNum の値（デフォルトでは１６です）となります。

　次に１ドット辺りのビット数はカラービット数と比例します、以下にカラービット数と一般のデータ型との比例関係を示します。
　　８bitカラー　　　　　char 型と同サイズ
　　１６bitカラー　　　　short 型と同サイズ
　　３２bitカラー　　　　int 型と同サイズ
　もし１６ビットカラーのグラフィックに１ドット分データのアクセスをするつもりで int 型変数で値を代入した場合は２ドット分描画してしまうので注意してください。（アドレスの算出のときも同じです）
注 … グラフィックをロックする場合は SetUse3DFlag 関数で３Ｄ機能を使わない設定にしてからLoadGraph,MakeGraph等で作られたグラフィックでないとロックは失敗します。
例　　１２８×１２８のグラフィックデータを作成し、座標( 24 , 11 )
　　の点に色コード０を代入します。（１６ビットカラー）
char *GraphData ;
short *DrawPoint ;
int Pitch , GHandle ;
// グラフィックの作成
GHandle = MakeGraph( 128 , 128 ) ;
// グラフィックのロック
GraphLock( GHandle , &Pitch , &GraphData ) ;
// 座標( 24 , 11 )のデータのアドレスを算出
DrawPoint = ( short * )( GraphData +
24 * ( 16 / 8 ) +
11 * Pitch ) ;
// 色コード０を代入します
*DrawPoint = 0 ;
// ロックを解除します
GraphUnLock( GHandle ) ;

**名前は開発中のものです。** · 2009/03/13(金) 04:05:06

サンプル表画面をロックして直接アクセスで画面にグラデーションを描きます
#include "DxLib.h"
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ){
int i , j , k ;
int Pitch ;
short *DrawPoint , Cr ;
char *GraphData ;
if( DxLib_Init() == -1 ){return -1;}
// 表画面をロックします
GraphLock( DX_SCREEN_FRONT , &Pitch , ( void ** )&GraphData ) ;
// 画面にグラデーションを描きます
for( i = 0 ; i < 480 ; i ++ )
{
for( j = 0 ; j < 640 ; j ++ )
{
// 色の値を取得
k = 255 * i / 480 ;
Cr = ( short )GetColor( k , k , k ) ;
// 描画する座標のポインタを計算
DrawPoint = ( short * )( GraphData + j * ( 16 / 8 ) + i * Pitch ) ;
// グラフィックデータへの直接アクセスで点を描画
*DrawPoint = Cr ;
}
}
// 表画面のロックを解除(『GraphUnLock』使用)
GraphUnLock( DX_SCREEN_FRONT ) ;
// キーの入力待ち
WaitKey() ;
DxLib_End() ; // ＤＸライブラリ使用の終了処理
return 0 ; // ソフトの終了
}

**名前は開発中のものです。** · 2009/03/13(金) 04:17:46

>>827
ありがとう。
GraphLock/Unlockなかなか便利だねぇ
ちょっと使ってみます
作者から非公開関数になった理由が知りたいとこだね

**名前は開発中のものです。** · 2009/03/13(金) 10:15:03

>>825-829
なるほど、そのためのGraphLock/UnLockだったのか。
あと非公開関数になっただけで使う事はできるんですね。
てっきり使用すらできなくなったものだとばかり思ってました。。。
とりあえずはこれで出来そうなので、デコード処理の要望の方は見送ろうかと思います。
お二方とも、ありがとうございました。

**名前は開発中のものです。** · 2009/03/15(日) 09:43:05

グラフィックハンドルの復元問題ってどうしています？
フルスクリーン<->ウィンドウ切り替え時にだけ発生するならいざ知らず、
フルスクリーン時にフォーカスロストでも発生するから絶対に対策が必要ですよね。

ファイルから復元できるものは別にいいのですが、
困難なのが、MakeGraphやCreateGraphFromMemで作成した画像の自前復元です。
これらハンドルが初期作成状態から書き換えがされている場合、
(GetDrawScreenGraphを使った時や描画可能な仮画面としている場合)には、
画像を元の状態に戻すのってとても困難ですよね？

SetRestoreGraphCallbackが呼ばれる時には既に失われている状態だし、
正直お手上げ状態です。
何か良い方法があったら教えてください。

**名前は開発中のものです。** · 2009/03/15(日) 11:01:39

readme.txt

「切り替えなどを行わないでください」

**名前は開発中のものです。** · 2009/03/15(日) 11:45:37

とはいってもユーザーの意図しないところでノートンなんかは自動で行っちゃうしね。

SPY++してみたら、WM_DISPLAYCHANGEもしくはWM_ACTIVATEAPPがDirect3Dオブジェクト解放前に呼び出されてるみたいだから、
このタイミングで保存処理を書いてみようと思う。上手くいくかどうか分からんけど。

**名前は開発中のものです。** · 2009/03/15(日) 12:40:49

俺は良い方法を思いつかなかったから、
グラフィック読み込む前に「これを読み込む」ってフラグを立てておき、
全てのグラフィックの中から、そのフラグが立ってるヤツだけを読み込むような処理を作っておき、
実際に読み込む時や、画面復帰した時にその処理を呼ぶようにしてる。

初期作成状態から書き換えをするような事はしてないけど、
するのならそれもフラグ管理する、くらいしか思いつかないな。

**名前は開発中のものです。** · 2009/03/15(日) 13:24:25

>>835
やっぱりなかなか良い方法が思いつかないですね。
簡単な命令(DrawLineやDrawBox)だけなら描画コマンドをバッファに記憶しておいて、
復号時に一気にコマンドを流せばいけるんですけどね。

**名前は開発中のものです。** · 2009/03/15(日) 21:04:33

どなたかDXライブラリ3Dをうｐしていただけないでしょうか

**名前は開発中のものです。** · 2009/03/16(月) 01:54:00

開発終了しているのに何を期待しているんだ？
開発引き継ぐならあげるけど。。。

**832** · 2009/03/16(月) 04:54:34

WM_DISPLAYCHANGEを捕まえて、グラフィックハンドルの復元処理のコードを書いた。
同じような問題で困っている人がいたら、試してみてくれ。

検証が必要な箇所はまだあるとおもうが、とりあえず叩き台のコードをアップししとく。
http://www.dotup.org/uploda/www.dotup.org0835.zip.html
passは1234

**名前は開発中のものです。** · 2009/03/16(月) 10:24:23

>>838
引き継ぎって具体的に何すればいいのさ？
そんなに利用者いるようにも見えないが。

**名前は開発中のものです。** · 2009/03/16(月) 12:40:25

>>840
ライブラリを使う側じゃなくて作る側になってWebで公開するってこと。利用人数なんて関係ない。
現状、国内じゃまともに使える3Dライブラリが皆無だからね。

ただDXライブラリ3Dが使いたいだけならやめとけやめとけ。
変化の多い3D周りにおいて、開発終了したライブラリを今から使い始めるなんてのは得策じゃないよ。
素直にIrrlichtやORGEを使いなよ。

**名前は開発中のものです。** · 2009/03/19(木) 16:51:59

DXライブラリってDX_SCREEN_BACKとDX_SCREEN_FRONT以外にもバッファって作れないの？
画像ハンドルでもできるってことは知ってるんだけど、それだと遅くなりそうだしなんとかいい方法はないものか

**名前は開発中のものです。** · 2009/03/19(木) 18:28:29

それは何の目的でそんな事をしたいのかな？

**名前は開発中のものです。** · 2009/03/19(木) 18:36:46

画面のスクロールとかするときに、バッファ二つじゃ不便だからなぁ
俺も最近そのために物凄く無駄な苦労をした
DrawGraphとかの引数に描画先のバッファID(またはグラフィックハンドル)を指定するとか、
または予め描画先を指定する関数を呼び出しておくとか、
そういう方法で複数のバッファを使えたら楽でいいと思う
もしそれが俺の無知によるもので、本当は別に手段があるのならぜひ教えてほしい

**名前は開発中のものです。** · 2009/03/19(木) 19:07:33

いや多分無知なのは俺の方だと思うんだが、
なぜスクロールさせる事にバッファが二つじゃ足りないのか理解できない。

**名前は開発中のものです。** · 2009/03/19(木) 19:12:02

例えば、新しく作ったバッファにステージ全体の様子を描画する
表バッファには、プレイヤーを中心にした長方形を、
さっきのバッファから指定矩形部分描画を使ってコピーする

実際はもうちょっとスマートな方法だけど、簡単に言うとこういう方法

**名前は開発中のものです。** · 2009/03/19(木) 19:29:45

>>846
毎フレーム絶対同じ絵を表示するならそれでもいいけど
実際にはキャラ移動したりするしそれだと良くないんじゃない？

描画開始位置を変数で持っといて、
それを変化させながら表示すればスクロールできるんじゃ？

**名前は開発中のものです。** · 2009/03/19(木) 19:42:32

javaあたりでアクションゲームのスクロールの解説あったろ
あれみたほうがいんでね
もっと簡単にできるし

**名前は開発中のものです。** · 2009/03/19(木) 19:48:14

うん？
例えば暗闇の中で自分の周りだけ見えてる、みたいなイメージかな。

てか、裏画面にステージ全体を描画っていうけど
裏画面でも表示できる範囲以上の部分は意味なさないんじゃないのかな。
それとも画面はみ出した部分もちゃんと描画されてるの？

**名前は開発中のものです。** · 2009/03/19(木) 20:03:26

でっかいバッファにステージ全体を書いておいて、画面にはそこから一部を切り取ったものを映すってこと？

**名前は開発中のものです。** · 2009/03/19(木) 21:53:29

>>850
そういうこと

**名前は開発中のものです。** · 2009/03/19(木) 21:58:54

それって何の意味があるの？

**名前は開発中のものです。** · 2009/03/19(木) 22:00:26

スクロールがとても楽

**名前は開発中のものです。** · 2009/03/19(木) 23:05:40

普通に>>847じゃあかんの？

**名前は開発中のものです。** · 2009/03/20(金) 00:14:40

何が楽なんだろう……？

全画面をバッファにおいておくっつーのなら結局メモリはそれだけ必要なんだから
そのまんま画像として持っていてもあまり変わらないと思うし
それを好きな位置に表示すればそれこそ楽だろうと思うし……。

それともあれか。
お絵かきツールみたいに、画面上でいろいろ書き換えたデータを
そのまんまメモリに重ね落として、それをまた画面上に呼び出すとか
するのだろうか。

でもステージって言ってるしなぁ……？

普通ならマップチップつかって必要なとこだけ表示するだけだから楽もクソもないと思うし……。

**名前は開発中のものです。** · 2009/03/20(金) 00:57:55

新しいバッファよりもむしろマルチスレッド使えるようにならんかな

**名前は開発中のものです。** · 2009/03/20(金) 01:19:57

詳しいこと全然知らないんだけど、
DXlibではマルチスレッドは使えないの？

**名前は開発中のものです。** · 2009/03/20(金) 02:05:01

>>855
リアルタイムで背景が拡縮したり回転したり端がループする場合は
一度メモリに書き込んでおいたほうが楽なんじゃないかな

**名前は開発中のものです。** · 2009/03/20(金) 02:35:45

画像自体は既にメモリへ読み込みさせてるだろうし、計算は軽いよ
マップチップじゃなくてもSetDrawAreaで領域も最小限で済ませるし

**名前は開発中のものです。** · 2009/03/20(金) 05:32:02

ははは。ワールドマップのような広大なマップに対しても同様の手法をとるのか見ものだな

**名前は開発中のものです。** · 2009/03/20(金) 05:40:13

ちなみに、
>>842
SetDrawValidGraphCreateFlag使えば作れる。
注意点も有るが、それは自分で調べてくれ。

**名前は開発中のものです。** · 2009/03/20(金) 05:49:13

非常に亀レスだが、
>>757
>>758
俺が確認したところDXライブラリ ver2.25bには、
// フォグを有効にするかどうかを設定する( TRUE:有効 FALSE:無効 )
SetFogEnable( int Flag ) ;
// フォグモードを設定する
SetFogMode( int Mode /* DX_FOGMODE_NONE 等 */ ) ;
// フォグカラーを変更する
SetFogColor( int r, int g, int b, int a ) ;
// フォグが始まる距離と終了する距離を設定する( 0.0f ～ 1.0f )
SetFogStartEnd( float start, float end ) ;
// フォグの密度を設定する( 0.0f ～ 1.0f )
SetFogDensity( float density )
が有る。

**名前は開発中のものです。** · 2009/03/20(金) 07:38:27

DXライブラリで３DやってもカメラとかZバッファどうすんだとかいろいろ問題あるんじゃないのか

**名前は開発中のものです。** · 2009/03/20(金) 07:43:26

カメラ周りは平行透視固定みたいだね
Zバッファ周りは一通りある
詳しくはDxLib.h見れ

**名前は開発中のものです。** · 2009/03/20(金) 11:47:58

>>862
まじかー！

よーしパパobjファイル読み込んじゃうぞー

**名前は開発中のものです。** · 2009/03/20(金) 17:30:45

そーいえば昔、>849みたいなことをやろうとしたものの
結局やり方が分からなくて諦めたことがあったなあ。

どうするのがスマートだったんだろう、と
コーヒー片手にリファレンスを読みなおす。

今は雑巾を片手に。

**名前は開発中のものです。** · 2009/03/20(金) 17:42:15

ｗ

**名前は開発中のものです。** · 2009/03/20(金) 19:41:01

そこで落とす必要があるのかｗ

**名前は開発中のものです。** · 2009/03/20(金) 20:39:51

ベランダで夕日を眺めながらブランデーでも飲んでたんじゃね？

**名前は開発中のものです。** · 2009/03/20(金) 23:14:17

マップチップの表示にメモリ・速度的にどちらも有利な磐石な方法ってのはないんだよね
毎回マップ画面を生成する必要があるのか無いのかによっても分かれるし、
生成後に加工する必要の有無によっても手法が変わってくる。

**名前は開発中のものです。** · 2009/03/21(土) 02:35:14

PCならメモリたくさんあるんだしマップチップすら作らなくてもいいような時代

**名前は開発中のものです。** · 2009/03/21(土) 02:56:48

当たり判定とかもピクセル単位でやんの？

**名前は開発中のものです。** · 2009/03/21(土) 04:12:19

できなくはないよね、10000*10000でも12.5Mbだし
セルオートマトンの砂シム作ったときそれでやったよ､まあそんときは800*800だったけど

ところでみんな2Dゲーム作るとき座標関係の変数ってint使ってるの？
自分は三角関数使ったりするから基本floatかdoubleなんだけど、今時のPCなら問題ないよね？
プログラム板のスレとか見ると「浮動小数点なんて遅すぎて使えねー」なんて書き込みが2002年にあったりする
ゲームつくり初めの頃は固定小数点とか聞きかじりでやったりしてたけどやっぱメンドいわ
そろそろ2Dゲームならどんな風に作っても快適な時代になったよね

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

2002年の段階なら当然の反応じゃねーかな。
ノートPCのことも考えると。

**名前は開発中のものです。** · 2009/03/21(土) 06:08:05

>>873
とにかくメモリーを節約したい場合以外は、floatよりdoubleの方が一般だと思う。
（今時のCPUなら早いし、精度も高いし）
あと、どのくらいその計算をさせてるかにもよると思う。
正直、２Dゲームならよほど大量のデータを演算しまくらなきゃ、
大抵は表画関連の処理時間に肉薄する事もないだろうし。
（パーティクルを超豪華に大放出です!!さらにパーティクル同士が当り判定します!
　みたいな時は分らんが、それ以外は問題無いと思う。）

**名前は開発中のものです。** · 2009/03/21(土) 09:43:50

現状、2Dゲームで浮動小数点がネックになることはほとんどない。というか無い。
そもそもDXライブラリは内部的にはサーフェスを3Dで扱ってるし、その上でいまさら固定小数点を使っても、
速度差はスズメの涙である。(ボトルネックになる部分はもっと他にある)
計算コストを見直すのであれば、当り判定を工夫したりする方がよっぽど建設的と考えるが。

**名前は開発中のものです。** · 2009/03/21(土) 09:46:34

昔は、float じゃなければ並列化が効かなかったんだよ。
doubleはどうあがいても高速化できないが、floatは腕次第でフルチューン可能だった。

そんな時代もあったのさ。

**名前は開発中のものです。** · 2009/03/23(月) 00:21:46

>>875
DXライブラリをデフォルトの状態で使うと doubeを使っても精度が float並になるよ。
つまり余計にメモリを食うだけってことに。

**名前は開発中のものです。** · 2009/03/23(月) 03:58:43

>>878
それ、なんかプログラミングが間違ってるか、何かを誤解して理解してると思うが。
引数がfloatでも、それまでに計算したdoubleの精度は精度で有効に使い続けられるわけだし。

**名前は開発中のものです。** · 2009/03/23(月) 04:14:27

ベクトルと行列演算はD3DX系命令に任せたいから俺はfloat派だ。
double精度が必要な時が出たらdouble使うと思うが今のところ無いな。

**名前は開発中のものです。** · 2009/03/23(月) 22:35:05

floatでずれが出ないなら殆ど好みでいいな

**名前は開発中のものです。** · 2009/03/24(火) 14:18:07

DXライブラリ3Dを配布してるサイトって無いのな
作者サイトも昨日までは普通にアクセスできたのに

**名前は開発中のものです。** · 2009/03/24(火) 14:20:54

>>882
3Dは DarkGDKを使え

**名前は開発中のものです。** · 2009/03/24(火) 17:18:13

>>882
3DがC言語初心者レベルで扱えるライブラリなんて設計上不可能だ。
DXライブラリ3Dが目指そうとしたのは砂上の楼閣だったのさ。
ORGEかIrrlicht使いなよ。

**882** · 2009/03/24(火) 20:15:11

ファイナルパックは持ってるよ
ヘルプが完全ではないから手探りだけど

**名前は開発中のものです。** · 2009/03/24(火) 20:42:07

OpenGL用だが、3DはGLUTってのはどうだろう？

**名前は開発中のものです。** · 2009/03/25(水) 00:48:05

Siv3Dは本当に出るかわからないし
現状、DXライブラリ3Dが最強なんだが…

**名前は開発中のものです。** · 2009/03/25(水) 03:39:15

暇なんでDXライブラリ3Dみたいだけど２ｃｈネラー向きのDirectXライブラリつーのを
作ってみるわ。もちろんWindowsネイティブな。少しまちなー。

**名前は開発中のものです。** · 2009/03/25(水) 04:22:27

>>888
まずその名前はややこしいから変えて欲しい。
DirectX自体がライブラリだし、DXライブラリに名前が似てるし。
そして次、作ってみるって思ってから完成するまで膨大な時間が掛かるって事。
少し位じゃ完成しないからやるならもうちょっと長いスパンで考えた方が良いよ。

**名前は開発中のものです。** · 2009/03/25(水) 06:56:03

音ゲーみたいなの作りたいんだけど
音がズレてるような気がする。
int GetNowCount( void ) を使ってるんだけど
違うソフトとか触ったりしたら時間だけ経過されたりして描画されなくなる。

**名前は開発中のものです。** · 2009/03/25(水) 07:26:34

これって.NETのユーザーコントロールって使えないの？
擬似ボタンとかならDXライブラリの関数で作れるが
スクロールバーとか高度なものだとちと無理臭いので気になったのだが。

**名前は開発中のものです。** · 2009/03/25(水) 08:21:26

>>890
非アクティブ状態でもタイマーは進むから、その辺考慮して設計すべし。

**名前は開発中のものです。** · 2009/03/25(水) 09:12:00

>>890
int SetAlwaysRunFlag( int Flag ) ;
か
int LoadPauseGraph( char *FileName ) ;
の関数を使えば、やりたい事は解決すると思う。

>>891
できない事はない。と思うが・・・・
.NETとDirectXは基本別物（.NETからManaged DirectX は動かせるにしても）
結局深い知識が必要だから、まぁ、普通の人はやらん方が無難。
スクロールバーぐらいなら自前した方が何かといいかと思う。

**名前は開発中のものです。** · 2009/03/25(水) 09:38:24

でけた　ｔｈｘ

**名前は開発中のものです。** · 2009/03/25(水) 09:51:13

>>891
ちょっと調べたが、簡単には無理っぽいな

試したことが無いが、
SetUseGDIFlag(TRUE)すればコモンダイアログ等のGDIの画面上乗せ出来るようだ。
メインウィンドウのHWND取得して、CreateWindowEx等のAPIで自作したウィンドウハンドルを子ウィンドウとして登録。
メッセージプロシージャ等はAddMessageTakeOverWindowすればコールバックで戻ってくる模様。
.NETではないが、コモンコントロールを扱うのなら、こういう方法しかないとおもう。

ちなみに俺はスクロールバー・ボタン等については必要になった時に自作している。

**名前は開発中のものです。** · 2009/03/25(水) 12:24:54

初心者向け3Dライブラリの条件は
C++でなく、C言語に対応していること
そして、コマンド数が多い事
単純であることだろう、よって複雑な事は出来なくても良い。

DarkGDKのコマンドリストをUPする。
コマンド名を見れば動作の予測ができるでしょう
http://www.csync.net/service/file/view.cgi?id=1237950965

**名前は開発中のものです。** · 2009/03/25(水) 19:28:42

>>893 >>895
レスTHX。ListViewとかボタン（WINAPIと同じ挙動のやつ）を
作るとなるとかなり大変だからManaged DirectXの方でやることにするわ。

**名前は開発中のものです。** · 2009/03/25(水) 21:17:20

>>896
そもそも初心者が3Dに手を出すこと自体にかなり無理があると思うんだが。

**名前は開発中のものです。** · 2009/03/25(水) 22:14:20

Easy3Dは初心者に対しては本当に良く出来てる
HSPで3Dってのが個人的にはありえなかった

**名前は開発中のものです。** · 2009/03/26(木) 00:21:46

そもそも初心者はゲームの作り方自体がわかんないと思うけどなあ

**名前は開発中のものです。** · 2009/03/26(木) 00:33:28

DXライブラリのおかげでなんとかゲームらしきものが作れてるレベルの俺としては
３Ｄものなんて夢のまた夢。

**名前は開発中のものです。** · 2009/03/26(木) 02:33:02

3Dもそこまでハードルが高いとは思わないんだけどさ、
2Dと違って素材集めやモデリングが難しいんだよね。そして興味ない。
さらに3Dで作るゲームにアイデアがない。
最後に、3Dゲーって2Dゲーと違ってしょぼさが如実にあらわれるんだよね。

**名前は開発中のものです。** · 2009/03/26(木) 02:55:38

ハードルなんてあるのか？軸が１個増えた程度にしか･･･。

**名前は開発中のものです。** · 2009/03/26(木) 03:28:44

あたり判定やらモーションが難しいし面倒
衝突した場合、３Ｄの場合は食い込んで表示されて不自然だし
回転とかしたときのモデルの先端の座標やらがイメージしにくい

**名前は開発中のものです。** · 2009/03/26(木) 04:42:32

>>903は次世代コンシューマでメインPGで何作も作ってる程の凄腕のプログラマーに違いない。

**名前は開発中のものです。** · 2009/03/26(木) 06:38:45

カメラを意識しないようなゲームなら、ホントに軸が１個増えただけだと思うよ
計算が複雑になったり、グラフィックに掛ける手間が増えるから
初心者は2Dでゲーム製作に慣れてからの方がいいとは思うけど

**名前は開発中のものです。** · 2009/03/26(木) 06:44:13

PRG作るときのキャラ表示って２次元のグラフィックを三次元空間に配置したほうが楽？
二次元のキャラが２マスのサイズあるので、
NPCの前に立つのと、後ろに立つので被さり表示順序を変えなきゃならん。

３Dならこんなのないだろうになぁ

**名前は開発中のものです。** · 2009/03/26(木) 07:38:35

>>907
3Dでも基本的に同じだよ
奥行きの値で表示順をソートする必要がある

**名前は開発中のものです。** · 2009/03/26(木) 08:50:05

>>907
俺は描画オブジェクトにZ値を持たせ、描画順をstd::listで記憶して表示順序変えてるよ。
Z値が同じ値なら、Y値の設置底面(top+heihtした値)で比較し、ソートする。

たぶんこれが一番楽で一番確実。
毎フレームソートするのはバカらしいから、極力必要最低限の回数にするようにしてね。

**名前は開発中のものです。** · 2009/03/26(木) 09:47:36

>>909
thx.
std::listってc++か・・

**名前は開発中のものです。** · 2009/03/26(木) 09:59:19

そうそう。これを機にSTL覚えなよ。
STLも万能ではないが、知っておくに越したこと無いね。
ちなみに、こういう並び替えが頻繁に行われるものはvectorやmapでもなく、list使うのが良い

**名前は開発中のものです。** · 2009/03/27(金) 07:03:04

オブジェクト指向のｃ＋＋のが、
何人いるかわからないNPCにとっては有効？

**名前は開発中のものです。** · 2009/03/27(金) 08:48:18

有効。C++じゃなくても書けるが、Cで書くよりははるかに柔軟に書ける。
スプライトを扱う基底クラスを継承してNPCクラス作ればいい。

厳密に言うと何人居るかわからないのはSTLのvectorが基本。(俺ならlist使うけどな)
NPC挙動はデザインパターンでいうところのStateかとStrategy

**名前は開発中のものです。** · 2009/03/27(金) 22:11:00

3D版で、衝突したポリゴンから法線ベクトルの取得ってできる？

DXライブラリ 総合スレッド 2008

DXライブラリ総合スレッド 2008