DXライブラリ総合スレッドその8

**名前は開発中のものです。** · 2011/04/03(日) 17:17:11.99

Cを習得した程度のスキルでも、
GUIのゲームを比較的容易に作成する事を可能にする、
「DXライブラリ」に関するスレッドです。
DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。

【公式】
http://homepage2.nifty.com/natupaji/DxLib/

【過去スレ】
DXライブラリ総合スレッド
http://pc11.2ch.net/test/read.cgi/gamedev/1197468399/
DXライブラリ総合スレッド 2008
http://pc11.2ch.net/test/read.cgi/gamedev/1224923873/
DXライブラリ総合スレッドその3
http://pc11.2ch.net/test/read.cgi/gamedev/1238429676/
DXライブラリ総合スレッドその4
http://pc11.2ch.net/test/read.cgi/gamedev/1249822550/
DXライブラリ総合スレッドその5
http://pc11.2ch.net/test/read.cgi/gamedev/1259912953/
DXライブラリ総合スレッドその6
http://hibari.2ch.net/test/read.cgi/gamedev/1267108154/
DXライブラリ総合スレッドその7
http://hibari.2ch.net/test/read.cgi/gamedev/1286180687/

**名前は開発中のものです。** · 2011/04/22(金) 19:41:48.50

描画系関数って、上位互換/下位互換的な関係のものが多いから
(例:DrawGraphで出来る描画はDrawExtendGraphでも可能)
どれぐらい複雑な描画をしたいか、に応じて使う関数を決めれば良いと思うよ。

**名前は開発中のものです。** · 2011/04/22(金) 19:48:39.62

>>203
流れから言って>>195はド初心者だ。
描画関数っていうのはLoadGraphScreenのことだと思われる。
プログラムを教えるときに初心者の説明が正しいと思って聞くことがまず間違い。

**名前は開発中のものです。** · 2011/04/22(金) 20:00:26.12

まずLoadGraph覚えて
DrawGraph等の描画関数使えるようにならないとだるい

**名前は開発中のものです。** · 2011/04/22(金) 20:21:32.51

>>203
ありがとうございました
おかげで解決しました

**名前は開発中のものです。** · 2011/04/23(土) 04:07:37.85

今までファイル読み込み関係の関数の存在意義がわからなかったのだが
もしかしてこれを使わないとDXアーカイブ内部のファイルが読めない？

**名前は開発中のものです。** · 2011/04/23(土) 04:19:37.94

んだねー

**名前は開発中のものです。** · 2011/04/23(土) 09:58:05.21

>>208
もろDXアーカイブ用の為の関数よ。

**名前は開発中のものです。** · 2011/04/23(土) 10:01:41.96

製作中はアーカイブにせずそのままだろうから
いざ最後にアーカイブ化してそのことに気づくというパターンはありそう
っていうか俺も今気づいた。
アーカイブにしたら動かないだろうな

**名前は開発中のものです。** · 2011/04/23(土) 10:10:56.27

>>211
DXアーカイブの強みは、DxLib内の関数のみを使用している意識せずに使えることなんだけど…。
ちゃんとリファレンスを読もう。

**名前は開発中のものです。** · 2011/04/23(土) 10:13:40.19

今日は起きたばかりなせいか文章能力がだいぶ欠落してるなｗ

>>210 用と為被ってておかしいのと、
>>212 DxLib内の読込関数を使用していれば意識せずに　です。

ごめんなさい、許して。

**名前は開発中のものです。** · 2011/04/23(土) 10:16:12.31

ゆるしますん

**名前は開発中のものです。** · 2011/04/23(土) 10:54:21.56

ゆるせませんん

**名前は開発中のものです。** · 2011/04/23(土) 11:02:02.06

ｽﾝｽﾝｽｰﾝ

**名前は開発中のものです。** · 2011/04/23(土) 12:14:29.86

FireRead_readをC標準関数のreadと同じ感覚で使おうとしたら
痛い目にあったことを思い出した。

**名前は開発中のものです。** · 2011/04/23(土) 12:15:37.75

FileRead_readをC標準関数のreadと同じ感覚で使おうとしたら
痛い目にあったことを思い出した。

**名前は開発中のものです。** · 2011/04/23(土) 12:16:51.97

生まれて初めて2重書き込みという物をやらかした。
すまん。

**名前は開発中のものです。** · 2011/04/23(土) 12:18:31.59

気にするな

**名前は開発中のものです。** · 2011/04/23(土) 12:23:49.62

どんまいだ

**名前は開発中のものです。** · 2011/04/23(土) 12:40:13.04

責任を取って死ぬべき

**名前は開発中のものです。** · 2011/04/23(土) 13:46:37.99

>>212
製作中はアーカイブにしないから
標準の読み込み関数を使ってしまって
そのためにアーカイブ化すると動かなくなるということ話ね。

**名前は開発中のものです。** · 2011/04/23(土) 17:29:32.03

>>223
あぁ、何も考えずに勝手に手が動いちゃってみたいな意味か。

**名前は開発中のものです。** · 2011/04/23(土) 17:53:52.76

>>203
それだったらクラスでスッキリ解決するのでは

**名前は開発中のものです。** · 2011/04/23(土) 17:55:44.84

自分もそのパターンだなあ。

俺用フレームワークを作ってる人は多いと思うけど、
拡張しながら使っているとは言え、新しい機能とか部分的に対応してなかったりするんだよなｗ

**名前は開発中のものです。** · 2011/04/23(土) 17:59:12.91

64bit版ライブラリを作ろうとしてソース調べてたんだけど
DxWin.cppのWM_MOVEShred関数の
WinData.WindowRect.left = ( lParam << 16 ) >> 16;
を筆頭に変な書き方をしている部分が多くて挫折しそう

**名前は開発中のものです。** · 2011/04/23(土) 20:46:39.92

固定小数点の変数として見てて
上位16ビットを捨てて小数点以下にしてるとか？

**名前は開発中のものです。** · 2011/04/23(土) 20:58:50.32

いや、lParamが32bitだと仮定して16bit左シフト16bit右シフトで
上位16bitをクリアしようとしてる
当然lParamが64bitであるx64では破綻する

むしろ符号拡張絡みで32bitでもやばい気がしないでもない
Windows的にはHIWORD,LOWORDマクロで取り出すのが正攻法

**名前は開発中のものです。** · 2011/04/23(土) 21:32:25.30

>>229
公式で指摘してあげたらいんじゃね？
管理人さんも万能のスーパーマンというわけではないのだから

**名前は開発中のものです。** · 2011/04/23(土) 21:45:55.91

結局、質問掲示板のほうに言ったか
向こうも大混乱だな

**名前は開発中のものです。** · 2011/04/23(土) 22:48:29.18

>>230
ネイティブ64bit対応なんてこのライブラリのユーザ層からして需要がないから
公式には書きにくくてね

**名前は開発中のものです。** · 2011/04/23(土) 23:55:35.46

ネイティブで64bit対応するとどういう得があるんだっけ？おしえてくだちい

**名前は開発中のものです。** · 2011/04/24(日) 02:35:50.16

開発側が32bitを切りたいと思ってるなら役立つ？
少なくともXPは全滅しそう。

**名前は開発中のものです。** · 2011/04/24(日) 18:35:19.94

>>233
doubleが64ビット

**名前は開発中のものです。** · 2011/04/24(日) 18:36:28.57

メモリコピーがちょっと早くなるだけ？それってそんなにいるの？

**名前は開発中のものです。** · 2011/04/24(日) 21:07:31.04

龍神録のＨＰのゲームプログラミングの館が一新されてる

**名前は開発中のものです。** · 2011/04/24(日) 21:08:50.83

あ、古いのは下側にあったわ

**名前は開発中のものです。** · 2011/04/24(日) 21:13:01.00

初心者が詰まりそうなトコが個別に分かりやすくまとめられてるな　ナイスだ

**名前は開発中のものです。** · 2011/04/24(日) 22:28:09.84

おおおおお

**名前は開発中のものです。** · 2011/04/24(日) 22:57:06.46

SNS設置してねーわとか思ってたけど無くなったの？
やっぱり不評だったんだな。
まあ個人サイトをここでとやかく言うことではないか。

**名前は開発中のものです。** · 2011/04/24(日) 23:19:51.61

mixc++とかいうのがバーンとあるじゃん

**名前は開発中のものです。** · 2011/04/25(月) 00:09:14.76

いや、前はSNSだったけど今はForumになってるみたい。

**名前は開発中のものです。** · 2011/04/25(月) 05:58:47.55

あれはフォーラムにしてSNSだよ

**名前は開発中のものです。** · 2011/04/27(水) 16:41:50.17

このゲームはDXライブラリ使ってるとか分かる方法ありますか？

**名前は開発中のものです。** · 2011/04/27(水) 16:50:07.54

何か根本的な勘違いをしてる気もするが……まあいいや。

Log.txtとDXライブラリ用アーカイブあたりで判別できることはある。
あとreadme

**名前は開発中のものです。** · 2011/04/27(水) 23:12:59.43

そのゲームのexeをメモ帳で開いてDxLibで検索してみ

**名前は開発中のものです。** · 2011/04/29(金) 19:09:37.42

ふと思ったんだが
DXライブラリでつくられたゲームで売れているのってあるか？

**名前は開発中のものです。** · 2011/04/29(金) 19:16:58.08

>>248
有名なのはディアドラエンプティとかかな
売れてるかはわからないけどアナザーアポカリプスってのも評判良かった
あと東方二次創作ではDXライブラリ製が結構多い

**名前は開発中のものです。** · 2011/04/29(金) 20:00:19.32

全部シューティングか

**名前は開発中のものです。** · 2011/04/29(金) 20:09:32.74

ロックマンみたいなやつもあったね

**名前は開発中のものです。** · 2011/04/30(土) 00:40:51.92

>>251
あーそれ、さっきまで遊んでた
フロイデンシュタヘルとかいって喋るやつじゃない?

**名前は開発中のものです。** · 2011/04/30(土) 07:10:23.99

Rosenkreuzstiletteだね
あと古いゲームだけど、だんえたもそこそこ売れたんじゃないかな
調べてみるとフリーで有名なゲームにもDXlib使ってるのがちらほら

**名前は開発中のものです。** · 2011/05/01(日) 01:22:54.30

SetAlwaysRunFlagをTRUEにして、GetActiveFlagがTRUEの時に
キー判定をするようにしても、VC++がアクティブ時だとキーが
反応してる気がする

**名前は開発中のものです。** · 2011/05/01(日) 06:52:06.21

VC++が親プロセスになってるからかな？
単独で動かしたときはどうよ？

**名前は開発中のものです。** · 2011/05/07(土) 23:50:21.56

DXライブラリからSeleneに移行したみたいな人っている？
3DならSeleneがいいみたいな話を小耳に挟んだのでちょっと興味が沸いた

**名前は開発中のものです。** · 2011/05/07(土) 23:57:59.16

2.xの頃はたまに聞いたけど今はどうなんだろう

**名前は開発中のものです。** · 2011/05/08(日) 00:06:46.40

DXライブラリに慣れてるならそのままがいいんじゃないかな
感覚そのままで3Dに以降できるし

昔selene使ってみようとしたことがあったけど、
色々用意されすぎてて独自ルール満載のseleneプログラミングを勉強しなおす事になっちゃう

**名前は開発中のものです。** · 2011/05/08(日) 01:22:47.21

ちょっと見てみたけど確かに難しそうだったな。
やっぱ慣れてるほうのがいいか。ありがとう。

**名前は開発中のものです。** · 2011/05/08(日) 02:26:03.19

dxライブラリで物足りなくなったら大人しくdirectx直叩きに移行するかなぁ

[―{}@{}@{}-] **名前は開発中のものです。** · 2011/05/08(日) 14:34:35.09

やっぱり読み込む画像のサイズが小さい方が描画速度が速いようだぞ
画像を読み込むときに画像を16x16毎に分けて個別に配列に格納して描画するようにしたら
めっちゃ早くなったわ。処理を見直すよりよっぽど効果があるわ。
画像が小さい方がビデオメモリに画像データをキャッシュさせやすくなるとかなのかな。

**名前は開発中のものです。** · 2011/05/08(日) 14:43:22.94

例えば横513ピクセルだと1024まで拡張しちゃう的ななにかかもしれない

[―{}@{}@{}-] **名前は開発中のものです。** · 2011/05/08(日) 14:50:31.40

なんでソフト屋様がハード仕様を意識してコーディングしないといけないんだよふざけんあよ

**名前は開発中のものです。** · 2011/05/08(日) 14:58:04.98

高級言語プログラマ様はお偉くていらっしゃるｗ

**名前は開発中のものです。** · 2011/05/08(日) 15:01:59.49

と思ったけどDxライブラリってそこ勝手に分割してくれるとかなんとか
フラグ建てないとだめなんだっけ？そんな感じの記述をどっかで読んだ覚えが

**名前は開発中のものです。** · 2011/05/08(日) 15:03:18.18

というよりそんなことしないといけないような重いプログラムのほうが問題だったりしないか

**名前は開発中のものです。** · 2011/05/08(日) 15:07:00.89

軽くできるなら軽くだぜ

**名前は開発中のものです。** · 2011/05/08(日) 16:06:55.79

ＤＸライブラリの通信プログラムを触ってゲームつくりたいんだけど
詳しく載ってるサイトない？

**名前は開発中のものです。** · 2011/05/08(日) 16:40:31.79

軽くできるならそうすべきだけど、他に原因があんじゃね？って話だよな
普通に考えるとBlt回数減らした方が早いと思うんだけど

[―{}@{}@{}-] **名前は開発中のものです。** · 2011/05/08(日) 16:46:24.33

いや16x16のマップチップを画面左上から右下方向に順に画面全体に表示させるということをやっていて、
マップチップ画像全体を読み込んで表示位置をIDに従って切り替えるんじゃなくて
16x16毎に画像を切って読み込んだら早くなったっていうことなんだけど、
Blt回数減らせるかね？

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

>>270
以前は一部だけ描画する関数を使ってたってこと？
それなら比較すれば早くなるだろうけど

[―{}@{}@{}-] **名前は開発中のものです。** · 2011/05/08(日) 17:13:04.05

>>271
マップチップ画像の事をマップ画像だと思ってる？
マップ画像は持ってなくて、マップチップ画像からチップＩＤに従って16x16を抜き出して適切な位置に表示してる
描画回数はどちらも(ウィンドウの幅/16)*(ウィンドウの高さ/16)回ですよ

**名前は開発中のものです。** · 2011/05/08(日) 17:21:00.55

DrawRectGraph?
それとも1マス毎にDerivationGraph+DrawGraph?

[―{}@{}@{}-] **名前は開発中のものです。** · 2011/05/08(日) 17:24:04.24

DrawRectGraph

**名前は開発中のものです。** · 2011/05/08(日) 17:37:06.78

マップチップ画像をLoadDivGraphで分割読み込みすればDrawRectGraphより速くない？
あ、でもマップチップ画像が2のｎ乗サイズじゃないと重いかも
マップチップ画像のサイズは幅・高さ何？

**名前は開発中のものです。** · 2011/05/08(日) 18:40:29.78

大きな画像があってそれを分割転送してるのかと思って。マップ並べる話ね。ごめん
俺はLoadDivGraphだと元画像でチップの境目がわからなくなるので、
普通にLoadGraphしてDerivationGraphでチップに切り分けるLoad関数を作って使ってる
線引いて格子状にした上と横に番号振った画像用意すると、どこに何が割り当たってるのかわかりやすいので

**名前は開発中のものです。** · 2011/05/08(日) 19:47:03.68

格子＆ナンバリングした画像を用意するのと、LoadDivGraph云々の関係が分からなかったorz

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

>>277
LoadDivGraphだけで画像分割ロードを一括して行なった場合
画像内全てに対して切り出しを行うから格子だのナンバリングだの落書きできるスペースがない
でもLoadGraphしてDerivationGraphした場合は好きな場所から切り出すことができるので
画像内に落書きしてあっても利用したい画像同士が離れていても問題ない

**名前は開発中のものです。** · 2011/05/09(月) 08:00:21.68

この話ってすごく有益な情報じゃね？
なのにこんがらがってよくわからん…

**名前は開発中のものです。** · 2011/05/09(月) 10:49:02.99

なんとなく分かったような分からんような。
画像を出してくれれば一発な気がする。

**名前は開発中のものです。** · 2011/05/09(月) 18:24:49.96

はい、こんなん
これの黒く塗りつぶされた所を32*32で切り出すのはLoadDivGraphじゃ出来ない
ttp://gmdev.xrea.jp/st/up/270.png

**名前は開発中のものです。** · 2011/05/09(月) 18:31:07.26

最初っから言ってることは理解できるけど、
それをやる意味が理解できない。

配布するときは画像差し替えるのか？
面倒だし意味なくね。

**名前は開発中のものです。** · 2011/05/09(月) 18:36:42.25

改善前と改善後のコード貼ってくれよもう
お前の脳内を知ってること前提で話しててわけわからん

**名前は開発中のものです。** · 2011/05/09(月) 18:41:40.67

たぶん、本人の糞コードが一部書き直したら改善されたんだが
本人はなぜ改善されたのかを誤った解釈をしている、というパターン
有益な知見は含んでいそうにない

**名前は開発中のものです。** · 2011/05/09(月) 19:10:30.39

あなたはすごいエスパーなんですね

**280** · 2011/05/09(月) 20:00:02.26

画像の方にばかり意識が集中してて、
元々の話題がコードを修正したら速くなったって話だったのを忘れてたぜ！

>>281
なるほど、実際に使う機会があるかどうかは別として
確かにLoadDivGraphじゃ難しいな。

**名前は開発中のものです。** · 2011/05/09(月) 20:17:17.03

ペイントツールのレイヤーで対応できることだな
素材レイヤーだけを出力するだけだし

[―{}@{}@{}-] **名前は開発中のものです。** · 2011/05/09(月) 21:39:19.39

こんだけ説明してんのになんでわかんないんだよ馬鹿か。
読み込む画像サイズが小さい方が高速化するからもともと256x2560(適当)とかのサイズのマップチップ画像を
16x16の小さい画像にプログラム内部で切って分割して読み込んだら早くなったってことだろうがよ。
あと俺はBlt回数減らせるかね？と質問してるわけだが答えてないよね。

**名前は開発中のものです。** · 2011/05/09(月) 21:45:23.74

min(縦幅, 横幅)を超えない最大の2のn乗サイズの正方形を使えばちょうどいいんじゃないかな

**名前は開発中のものです。** · 2011/05/09(月) 21:45:44.68

そうだといいですね。

**名前は開発中のものです。** · 2011/05/09(月) 22:05:01.12

Bltとか言ってるのに内部でどういう処理してるのかわかってないように思える
「大きいサイズのマップチップ画像を読み込んでた」のと
「16x16の小さい画像にプログラム内部で切って分割して読み込んだ」っていうのが具体的にどんな処理の違いなのか、
抽象的というか>288の脳内でのみの定義を前提にしてるから理解しにくいんだよ

ちなみにブリットに関しては何も変わらない　というかこの場合全く関係ないし

正直串の人は頭良く見られてたい馬鹿にしか見えないにゃー　やきとりもぐもぐ

[―{}@{}@{}-] **名前は開発中のものです。** · 2011/05/09(月) 22:23:27.58

あっそ。俺の問題は解決したからもうどうでもいい。
情報を提供したところで俺には何のメリットもないし。

**名前は開発中のものです。** · 2011/05/09(月) 22:26:21.91

DXLIBはもう覚えてないけどたしか配列にして画像ロードするやつでしょ？

uv座標の計算をあらかじめしておくだけで画像は分割しないと思うよ。
同じ画像を繰り返し描画（描画時にUV座標で一部を切り出す）をするのが
drawIndexedPrimitive()で速いんだから。

**名前は開発中のものです。** · 2011/05/09(月) 22:29:13.88

正直、全然意味がわからん

１チップが64*64ピクセルで、512*512ピクセルのBMPファイルに8*8チップ分描いた場合、
通常は
「64*64を１チップとして切り出し、ハンドルを64（8*8）個作成する」
が、
「１チップをさらに16分割（4*4）し、ハンドルを1024個（32*32）作成する。描画時は16チップを一まとめに扱う」
ってことか？

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

公式で高速化のことどっかで見たなと思ったら過去ログにあった、No.4の下のほう
ttp://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=past&no=1162
これ見る限りだとでかい画像にチップを全部書き込んでLoadDivGraphなり
DerivationGraphなりで分割使用した方が速いはず

**名前は開発中のものです。** · 2011/05/10(火) 03:13:56.68

まあ串は何か馬鹿なミスをしてたんだろうね

**名前は開発中のものです。** · 2011/05/10(火) 15:30:17.54

ソースコードがわからないから
なんとも言えない
が正解

**名前は開発中のものです。** · 2011/05/10(火) 15:59:37.85

バカっぽいからバカなミスしてたんだろう
が正解

**名前は開発中のものです。** · 2011/05/10(火) 19:44:50.74

あー、ソース見てみたいね
処理時間比較の結果とかも見たい

**名前は開発中のものです。** · 2011/05/10(火) 20:54:36.44

ソースみなくてもDirect3Dの仕組みから見当つくだろ
内部がDirectX9なら

**名前は開発中のものです。** · 2011/05/12(木) 04:24:06.32

言いたいことが何となく分かった
LoadDivGraphだと分けたい画像を同じ大きさの奴を左上からびちっと並べなければならないのを
DerivationGraphだと好きな所切り分けられるから例えば>>281のように分割対象の画像を作れるような自由度があるってわけか

**名前は開発中のものです。** · 2011/05/12(木) 04:39:39.52

VRAMが勿体無いから普通はみっちり詰めちゃうけどね

**名前は開発中のものです。** · 2011/05/12(木) 17:51:39.48

描画時に好きなところ切り分けられるってことは
描画時にUV座標の計算をしているってこと。

画像ロードしたときにUV座標の計算して固定したほうが
割り算いくつか分だけCPUが効率的だけど高速化といえる程ではない。

DXライブラリ 総合スレッド その8

DXライブラリ総合スレッドその8