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/08(日) 15:28:40

東方の新作が発表される度に自作のゲームとシステムが被っててヘコむ……

**名前は開発中のものです。** · 2009/03/08(日) 15:35:38

>771
それを気にしてたら、世の中作品なんて生まれない。
大丈夫、何ら問題ない。思う存分やれ。キミは盗作じゃない。

……自分のやりたいことを、他の人が作ったのでそれで満足しちゃったなら知らんｗ
（こっちもよくある話だけどな！）

**名前は開発中のものです。** · 2009/03/08(日) 17:25:05

弾幕シューは東方だけじゃないしね

**761** · 2009/03/08(日) 18:12:09

>>770
俺も>>767のように憂鬱本で読んで信じてきたんだけど、後学のために教えて欲しい。
まず憂鬱本にはこんな風に書いてある。
・コンストラクタやデストラクタはあまり難しい処理をするのは考え物。
　1・返り値を持つことが出来ない。
　2・インスタンスが完全な状態ではない。
　3・外部変数としてクラスインスタンスがある場合、コンストラクタやデストラクタはmain()の走る前、後になる。

>>770さんが言っているのは3の場合で、この本によると
「ポインタとして宣言しておきmain()が走った後でその中でnewする」
という解決策が書いてある。
で、問題の2にははっきりと
「コンストラクタ、デストラクタが走っているときは、インスタンスは完全な状態ではない」
と書いてあり、
「実は内部的にはそのインスタンスの使用するメモリの取得/解放とそれに伴う複雑な作業も行っている」
「インスタンス自体がまだ生成途中であり、内部的にはまだ不安定な状態」
と書いてあります。
問題点は、
「このような状態で他のクラスのインスタンスのメンバ関数を読んだりすると巡り巡ってまだ生成途中の自分自身のメンバ関数が呼ばれるかもしれないから」
との事です。
C#なんかではコンストラクタでのメソッドの呼び出しなども保障されてますが、C++では言語使用的には保障されていない、と解釈したのですがここらへんどうなんでしょうか？

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

この際、本家DXライブラリにDXライブラリ3Dを機能統合してしまっても良いんじゃないか？
今どき2Dだけじゃなぁ

**名前は開発中のものです。** · 2009/03/08(日) 19:25:34

>>775
いや、意味が分らん。
碌にDirectXすら使えない人間が３Dに手をだしてどうしたいんだ？

むしろ、本家は本家であの程度でまとまってるからこそ良いライブラリだろ。
もっと色々とやりたかったら海外の３Dライブラリをあさればいい。高機能の多いぞ。
（まぁ、普通に日本語対応がメンドイけど。）

**名前は開発中のものです。** · 2009/03/08(日) 19:52:53

っていうか、DXライブラリ3Dの開発を継続してほしいJEXさん

**名前は開発中のものです。** · 2009/03/08(日) 23:53:47

>>772,773
弾幕毎に名前付けてるから、気を付けないとまんまになっちゃうんだよね

もう開き直っちゃおうかな……

**名前は開発中のものです。** · 2009/03/09(月) 00:24:37

どうせやるなら「白い弾幕くん」くらい自由度上げてみたらどうだ

**名前は開発中のものです。** · 2009/03/09(月) 05:38:20

縦弾幕だったらどうやったって東方っぽいって言われるのがオチだから、
変なこと気にせず好きにやっちゃえYO！

**名前は開発中のものです。** · 2009/03/09(月) 13:06:42

東方のオマージュである、と明記しちゃえば変な因縁はつけられなくなると思う

**名前は開発中のものです。** · 2009/03/09(月) 13:28:18

自分で考えて実装した者に対して
なんという屈辱を。

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

パクってないんなら堂々としてればいいじゃない
ここで愚痴る前にちゃっちゃと完成させて
もう東方に先を越されないようにすればいいじゃない

**名前は開発中のものです。** · 2009/03/09(月) 15:06:44

先を越されたから愚痴ってるんだと思うがのｗ

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

新しいの出るごとに被るというと
低速移動時に敵を貫通するとかボム使うとパワーが減るとかその辺りか？

**名前は開発中のものです。** · 2009/03/09(月) 15:54:45

別に愚痴のつもりじゃありませんでした
こうやって悩むのもゲーム制作の楽しさの一つなので……
気分を害されたのならすいません

>>785
点レートアイテムとか、特殊アイテムを取るとボーナス敵が出る点が……

**名前は開発中のものです。** · 2009/03/09(月) 17:01:47

どんなシューティングでもお前。。。

**名前は開発中のものです。** · 2009/03/09(月) 18:04:17

Q.○○のパクリですか？

A1.はい、参考にしました。
　→盗作ｲｸﾅｲ！俺の好きな○○を汚すな！ ○○の公式サイトのBBSに通報(?)書き込み

A2.いいえ、オリジナルです。似ているのは偶然でしょう。
　→嘘を言うな、正直に言えよ

A3.いいえ、○○ではなく△△のパクりです。
　→そんなん知らねーよ！ △△も○○のパクりだな！

実際にあるから困る。

**名前は開発中のものです。** · 2009/03/09(月) 18:28:11

結論：気にせず作れ
作ることにも価値がある

**名前は開発中のものです。** · 2009/03/09(月) 18:40:02

>>788　どっちかと言うと、この手の奴で、実際にパックたりしてなかったら、
何も答えないのがベスト。ただただ、事務的返しで流すべし。

あと、>>786みたいのは　東方以前からあるのばっかじゃねぇかよwww
それこそ、ファミコン全盛の時代（のアーケード）から・・・・
「今更それを先を越されたとかwww」
と言われるのが落ちじゃね？

**名前は開発中のものです。** · 2009/03/09(月) 18:51:35

んー、今更だけど自分で気にしすぎだった気がしてきた
前作が東方をリスペクトしたものだったので、今回も素直に断り書きを入れてみます

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

パロディにまで昇華させてしまうという手もあるな。

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

http://siv.creation.googlepages.com/home
知ってるとは思うがこれにはずっと期待してる

**名前は開発中のものです。** · 2009/03/09(月) 22:34:04

押しっぱをできなくするようにしたいけど
char a[256]
GetHitKeyStateAll(char *a)
つかうとうまくできねぇ。。

ポインタをctrcmpやるのはおかしいの？
それとも配列に入ってるのがおかしいの？
俺の頭がおかしいの？

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

>>774
遅レスだがコンストラクタについて幾つか書きます。
さすがに長文書いてコメントが無いのは可哀想だったから。

昔の言語仕様ではコンストラクタではインスタンスの生成途中であるから複雑な処理を書かないようにしていた。これは慣習・慣例の部類の話。
コンパイラの亜種が多くて、C++の仕様外の範疇での動作はどのようになっているのか分からない時代だったからという背景もある。

自分はコンストラクタに初期化処理を噛ませる横着な書き方をしていたときに先輩に指摘された事は、1,2,3以外にも、、、

・クラス設計者とクラス利用者は同じでない
⇒利用者がstaticで外部変数なインスタンスを生成するかもしれないから、
　mainよりも先に呼ばれる処理に複雑な記述を置くべきでない。
　つまり、利用者の立場になって明示的に初期化処理を宣言するべき。(手を抜くな)

・戻り値を持たない件に関して、例外処理を使うのは怠惰な手段である。
⇒try-catchを用いるのは、デバッグの最終手段である。(例外処理はネストできない為)
　例外処理は一般的にコンパイラの最適化の阻害となり遅くなる要因となる。(ジャンプテーブルを生成する為)
　つまり、保持値チェックにはassert使えというお話。
⇒メモリ確保に失敗する危険性をもっと認識するべき
　特定のハードウェアを対象にする場合、大概は独自のメモリアロケーター(dlmalloc等)を実装していることが多く、
　new失敗の可能性(インスタンス生成失敗)は大いにある。
とのことでした。

>問題点は、
>「このような状態で他のクラスのインスタンスのメンバ関数を読んだりすると巡り巡ってまだ生成途中の自分自身のメンバ関数が呼ばれるかもしれないから」
>との事です。
これには同意です。
だから「コンストラクタに記述するのはせいぜいメンバ変数に対して初期値の代入ぐらい」に留めている人が大半で自分もそうしています。

いや～、バグの無いプログラムって難しいですね。

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

>>794
上手くできないってどういう意味？
char m_cKey[2][256]; //キーバッファ
とでもして
毎フレーム
void GetAllState(){
memcpy(m_cKey[1],m_cKey[0],256);
::GetHitKeyStateAll(m_cKey[0]);
}
を呼んで、
int GetKeyPress(int KeyCode){return m_cKey[0][KeyCode];}//キーが押されているかどうか
int GetKeyDown(int KeyCode){return (m_cKey[0][KeyCode] && !m_cKey[1][KeyCode]);}//キーが押された瞬間
int GetKeyUp(int KeyCode){return (!m_cKey[0][KeyCode] && m_cKey[1][KeyCode]);}//キーが離された瞬間
とでもすればおｋ
前フレームとの差分で押された瞬間と話された瞬間を検出するべさ

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

>>794　エスパーじゃないんで、
何をやって何ができないのかすら分らん。
とりあえず、×ctrcmp　=>○strcmpだと過程しても検討範囲外。
ポインタの使い方とか、関数の使い方は大丈夫だと仮定してもだ・・・・。

そもそも、そのchar a[]が何を入れるか理解してるかい？
そいつらに入るのは、あるキーが押されてるかどうかのon offフラグであって、
押されてるキーがchar型として'o'みたいに入るわけじゃないぞ。

押しっぱなしは、基本的には、

char NowKey[256];
char OldKey[256];
// ....somewhere to initilaize Nowkey[] and OldKey[], to 0.

GetHitKeyStateAll( NowKey );//Now get putting on key
if( NowKey[ KEY_INPUT_Z ] == 1 )
{ if( OldKey[KEY_INPUT_Z] != 1 )
{ PutOnFUNCTION(); // only not on putting Z_KEY.
OldKey[KEY_INPUT_Z]=1;
}
//There is No doing on putting Z_KEY.
}
else
{
OldKey[KEY_INPUT_Z]= 0 ; //No to put Z_KEY, initialize OldKey[] to 0.
}

な感じに書く。

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

推しっぱをできないようにするなんて
int pushOK = 0;
とか用意しといて

if (a[チェックしたいキー] && pushOK) {押したときの処理}
if (!a[チェックしたいキー]) pushOK = 1;

とかやればいいじゃない
（※厳密な文法に突っ込むのなしね、あと変数名が良くないことにもね）

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

あぁ。詳しくなくてすまん。ありがとう。
でも、なんとか、動作はしたぜ。

**名前は開発中のものです。** · 2009/03/10(火) 00:11:41

LoadSoftImage()でPNG-8のパレットが取得も設定もできん…。
パレットはBMPしか有効じゃないんか。
透過色設定とパレット変更を同時にしようと思うと、PNG-8がベストな選択だったんだけど、
さてどうするべか……。

**名前は開発中のものです。** · 2009/03/10(火) 00:43:20

どっかの時点でBMPに変換されるんだろうけど
その時点じゃまだなんだろうかね。

てかそんな命令あったのか……。

**名前は開発中のものです。** · 2009/03/10(火) 01:39:41

PNGについてはlibpng使ってるっぽいからなぁ。
パレット変えられないのは困ったぜ。

**名前は開発中のものです。** · 2009/03/10(火) 02:42:45

libpngって最近脆弱性が発見されたよね

**名前は開発中のものです。** · 2009/03/10(火) 05:14:32

パレットアニメーション諦めて、アルファブレンディングで代用できるんかな……。

例えば、パレットアニメーションで
void PatteGradation(int red,int green,int blue,float ratio)
{
int new_red,new_green,new_blue;
int* p = m_pPalette; //元のパレット配列[3*256]
for (int i=0;i<256;++i)
{
new_red = *p + (int)((red - *p)*ratio);
p++;
new_green = *p + (int)((green - *p)*ratio);
p++;
new_blue = *p + (int)((blue - *p)*ratio);
SetPaletteSoftImage(m_nSoftHandle,i,new_red,new_green,new_blue,0);
}
}
という感じで指定の色(red,green,blue)にratioの比(0～1.0)で近づくエフェクトを考えているんですが、
これと同じ機能をブレンドモードを変更することで代用可です？
上手い演算具合が見つからない。

**名前は開発中のものです。** · 2009/03/10(火) 05:17:44

あ、一個p++抜けてた。
でも、伝えたいことは伝わったはず。

**名前は開発中のものです。** · 2009/03/10(火) 05:52:02

フェードイン?

**名前は開発中のものです。** · 2009/03/10(火) 06:29:38

そうですね、指定色へのフェードイン・フェードアウトという感じです。
SetDrawBright()では黒フェードが出来ますが、それの多色化＆抜き色対応版です。

**名前は開発中のものです。** · 2009/03/10(火) 09:58:02

2パターンだけ作って重ねてアルファを変えていくのが効率いいんじゃないかな

**名前は開発中のものです。** · 2009/03/10(火) 11:39:59

>>793
ゲームパッドがX-BOX専用コントローラーしか使えないとか論外すぎる。

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

>>809　
　つ　http://www.4gamer.net/games/027/G002741/20090227065/

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

使う側ならともかく、作って配布する側ならそれは解決にならんでしょ。
まあ自分で対応のパッド追加できると思うけどな。

**名前は開発中のものです。** · 2009/03/10(火) 16:12:21

>>810
いや、そういう問題では・・

**名前は開発中のものです。** · 2009/03/10(火) 21:25:09

>>809
やっぱり白黒2値のパターンが別途居るようですよね……。
PNG使ってるのに、わざわざマスク画像が必要なのがめんどくさいと敬遠しているんですよ。

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

あれGraphLockって関数がいつのまにか消えたのか、と思って検索したら出た

http://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=view&no=1044
>GraphLock は現在のＰＣ環境に適していないので非公開関数にすることにしました

これってどういう意味なの？非対応な環境が多いの？詳しい人教えて

一応コピペ
宣言　　　　　　 int GraphLock( int GrHandle , int *PitchBuf , void **DataPointBuf ) ;
概略　　　　　　グラフィックメモリ領域のロック
引数　　　　　　GrHandle 　　:　ロックするグラフィックのハンドル(または画面の識別子)
PitchBuf 　　:　ロックするグラフィックの１ライン辺りのバイト数を保存する変数へのポインタ
DataPointBuf :グラフィックデータのあるメモリへのアドレスを保存するポインタへのポインタ
戻り値　　　　　０：成功　　－１：エラー発生

宣言　　　　int GraphUnLock( int GrHandle ) ;
概略　　　　グラフィックメモリ領域のロック解除
引数　　　　GrHandle : ロックしたグラフィックのハンドル（または画面の識別子）
戻り値　　　０：成功　　－１：エラー発生

**名前は開発中のものです。** · 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

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

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

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