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

**名前は開発中のものです。** · 2011/08/18(木) 17:18:15.54

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/
DXライブラリ総合スレッドその8
http://hibari.2ch.net/test/read.cgi/gamedev/1301818631/
DXライブラリ総合スレッドその9
http://hibari.2ch.net/test/read.cgi/gamedev/1310904069/

**名前は開発中のものです。** · 2011/08/23(火) 12:16:04.94

当たり判定のやつ？
あれも実際は効果あるか怪しそうだけど

**名前は開発中のものです。** · 2011/08/23(火) 12:33:19.39

>>69
このスレで糞糞言う奴の言葉とか全くあてにならんよ

if文の問題点はコードの見通しが悪くなることと仕様変更時に面倒くさいこと
利点は言うまでもないけど早く組めること

利点と問題点を理解して自分にあったスタイルで組めばいいと思う

**名前は開発中のものです。** · 2011/08/23(火) 14:39:43.09

DrawGraphでの描画速度に限界を感じてきました。
そこでDrawPrimitive2D及びDrawPrimitiveIndexed2Dを使えば
速くなるのでは無いかと考えたのですが、使い方が探しても
見つからなくて困っています。

これらの関数でテクスチャを表示する方法をどなたかご教授
いただけないでしょうか。

**名前は開発中のものです。** · 2011/08/23(火) 14:44:21.90

俺知ってるけどスレ違いだから教えない

**名前は開発中のものです。** · 2011/08/23(火) 14:58:04.31

ライブラリ変えるかDirectX直接叩いた方がいいような気がしないでもない

**名前は開発中のものです。** · 2011/08/23(火) 15:06:37.37

スレ違いでもないけど、教えるのは難しいな
昔は公式なリファレンスがあったんだっけ？
とりあえず↓をDXライブラリの関数に置き換えて読めば概要はわかるはず　これで理解できなかったら使う事自体おすすめしない
http://www.c3.club.kyutech.ac.jp/gamewiki/index.php?DrawPrimitive

72 · 2011/08/23(火) 15:11:36.26

>>74
DXライブラリは概ね使いやすくて非常に気に入ってるので、あと描画速度を
もう少し何とかできればという感じなのですよね。

>>75
ありがとうございます。
構造体のメンバも同じですし、DirectXの情報を追えばなんとかなりそうですね。
頑張ってみます！

**名前は開発中のものです。** · 2011/08/23(火) 15:18:11.27

てかDrawGraphで重いって一体どういう状況なんだろう
弾幕STGで、弾毎に頂点カラーで色を決めてるとかそういう感じ……？
ブレンドカラーの変更処理ってデフォだとエラーチェックが入るからフレーム毎に1000回くらいで重くなるし

**名前は開発中のものです。** · 2011/08/23(火) 15:29:08.46

>>77
マップチップの描画処理です。
640*480に16*16のチップを3レイヤー分敷き詰めるとチップ無し
のマスもあるので平均して1500くらいの回数に。
で、内蔵グラフィックボードだと60fpsを割ったり割らなかったり。

一応透過pngをLoadDivGraphで読み込んだものを描画してるので
SetDrawBlendModeとかはしてないです。

**名前は開発中のものです。** · 2011/08/23(火) 15:32:07.66

マップチップ画像のサイズは？

**名前は開発中のものです。** · 2011/08/23(火) 15:34:41.23

>>79
4096*768でARGB32の2.52MBのpngファイルです。

**名前は開発中のものです。** · 2011/08/23(火) 15:36:09.16

1500ねぇ。オンボだと確かに微妙な数字だな

**名前は開発中のものです。** · 2011/08/23(火) 15:37:05.17

試しに256*256とかにしてみたら高速にならんかね

**名前は開発中のものです。** · 2011/08/23(火) 15:38:11.89

マップチップだったのか
マップチップの最適な描画法ってある気がするんだけどなー

**名前は開発中のものです。** · 2011/08/23(火) 15:46:29.02

全部16*16でやるんじゃなくて、形が決まってるものは大きいサイズで描画するとか
あとバッファをうまく利用するとか

何とか描画回数を減らすように工夫するのがまず必要だと思う
全部16*16ってのはかなり非効率的だし

**名前は開発中のものです。** · 2011/08/23(火) 16:03:28.86

俺は全然描画に対して不便感じたことないけどな
重かったのは俺が、ミスって毎ゲームループごとにLoadGraphしてた時だった

**名前は開発中のものです。** · 2011/08/23(火) 16:04:12.77

例えば、草原や床のようなフィルする機会の多いチップは2*2,4*4のような大きいサイズを作っておく
ソースから2*2のような形をそのまま持ってくる場合はその都度Derivationする
カリングする（上のレイヤによって完全に塗りつぶされる場合は描画しない）

など

**名前は開発中のものです。** · 2011/08/23(火) 16:05:11.97

>>82
LoadDivGraphの速度は遅くなるけど、ハンドル取得後の描画には
影響しないんじゃないかと思ってましたがどうなんでしょう。

>>84
ですよね。大きな画像を作ってそれに最初にマップチップを全部
描画しておいて、その大きな画像を描画するというのも考えたの
ですが、なにぶんゲーム中に一部のチップだけ差し替えたりという
要素があるのでできれば全チップ舐めて描画したいなと。
でもよく考えるとチップ差し替え時に大きな画像の方にそのチップ
だけ上描ききすれば良いですね。

**名前は開発中のものです。** · 2011/08/23(火) 16:06:07.50

俺も同じ事やった事あるな。
640*480で16*16のマップチップを３枚重ねるやつ。
透過pngじゃなかったけど結構負荷がかかった記憶がある。

んで、諦めて一番裏の背景は諦めて一枚絵にしてしまったり、
オプションで二枚目の背景も消せるようにしたりしたなぁ。

まだDXライブラリ使い始めの頃だったけど。

描画の前に重なり具合を調べて、見えなくなる部分は描画しないとかいう手もありかもしれない。

**名前は開発中のものです。** · 2011/08/23(火) 16:09:10.07

>>87
画像サイズはVRAMとメインメモリでスワップが発生してるかどうかが問題かな
計算してみたら4096*768の32bitカラーで12MBの消費だから、それだけではスワップはしないと思うけど

**名前は開発中のものです。** · 2011/08/23(火) 16:13:36.75

DXライブラリは内部的に同じテクスチャならある程度まとめ書きしてくれなかったっけ？
最大テクスチャサイズは2048x2048だっけな、オンボなら1024x1024ぐらいに抑えたほうがいいだろうけど
元画像を幾つかに分割してソート掛けときゃ気持ちぐらいは速くなるかもね

**名前は開発中のものです。** · 2011/08/23(火) 16:16:13.66

>>90
そういえばそうだっけ
大きい画像は内部的に分割されるからまとめ描きがきかなくなる（と思う）ことを忘れてた

72 · 2011/08/23(火) 16:17:17.68

なるほど、元画像の大きさが影響する可能性もあるんですね。
ちょっと1024*1024あたりに抑えたので試してみます。
あとやはり画像をまとめて1枚にしてしまおうかとも。
幸いにもアニメーションするマップチップは無いので。

**名前は開発中のものです。** · 2011/08/23(火) 16:20:53.24

1024でもでかいと思うけどな

**名前は開発中のものです。** · 2011/08/23(火) 16:29:41.37

でっかい描画可能テクスチャを用意して、シーン切替時にマップ全部描画して、
マップ移動時はその中から描画したいとこだけを描画するってどうだろう
アニメーションするチップがあるなら工夫必要だけど、これが最速な気がする

**名前は開発中のものです。** · 2011/08/23(火) 16:31:44.49

低スペックＰＣなんか切り捨てればええんや

**名前は開発中のものです。** · 2011/08/23(火) 16:42:31.81

>>94
フィールドみたいにサイズがでかすぎるとVRAMから溢れそう

描画可能テクスチャに1画面分描画して、スクロールが発生する時に
スクロール先の部分を描画可能テクスチャに1ライン描画するとかどうだろう
プライマリサーフェスに転送する場合はxオフセットとyオフセットを設定すれば、
描画可能テクスチャ1枚で足りるし、描画時に4転送で済む

**名前は開発中のものです。** · 2011/08/23(火) 17:04:15.97

それスクロールするときに描画可能テクスチャ？を全描画しなおさないといけないんじゃないの？
オフセットだけだとはみ出すよね俺間違ってる？

**名前は開発中のものです。** · 2011/08/23(火) 17:10:08.05

>>97
うーん、説明しづらいから分かりにくくてすまんｗ
スクロールするときにスクロールアウトする部分に1ライン描画するって言う意味
そうすると描画可能テクスチャは頂点がスクロールした方向に1ラインずれる
つまり、最初の状態で0～100を1回描画だとすると、5ラインスクロールしたら5～100＋0～4の2回描画になるって具合
この場合オフセットは5ライン目
スクロールによるずれがx方向とy方向で生じるから、通常は都合4回の描画になる

実際にはスクロールする時のために上下左右に1ライン分のマージンが必要だけど

**名前は開発中のものです。** · 2011/08/23(火) 17:16:54.74

つまり、描画可能テクスチャの初期状態が
00,01,02,03,04,05
10,11,12,13,14,15
20,21,22,23,24,25
30,31,32,33,34,35
40,41,42,43,44,45
50,51,52,53,54,55
で右にスクロールすると、描画可能テクスチャは左1ラインがスクロールアウトするから上書きして
06,01,02,03,04,05
16,11,12,13,14,15
26,21,22,23,24,25
36,31,32,33,34,35
46,41,42,43,44,45
56,51,52,53,54,55
って形になる。バックバッファに転送するときは最初に01~55を左詰めで転送し、次に06~56を転送

**名前は開発中のものです。** · 2011/08/23(火) 17:24:53.71

へえ。勉強になったわサンクソ

**名前は開発中のものです。** · 2011/08/23(火) 17:26:09.22

なんかファミコンっぽいｗ
バグると移動中に描画オフセットが効かなくてそのままマップが変わって行くのが見えちゃうみたいなｗ

**名前は開発中のものです。** · 2011/08/23(火) 17:30:00.21

ファミコン言うなｗｗｗｗｗ

ただ難点は、描画可能テクスチャを使うってことなんだよね
3.00になって公開関数になった（っけ？）から前よりは安定してるんだろうけど、
2.xx系列だと隠し関数扱いだったからなー
動作の安定性が問題

**名前は開発中のものです。** · 2011/08/23(火) 19:59:00.13

レイヤーが３つあるってことは画面サイズ＊３枚分のバッファが必要で、画面3枚分の画面描画をするんだよな
16＊16で描画する場合は描画回数は増えるだろうけど全体では1画面分くらいしか描画しなくていいわけだからどっちの方がいいんだろ
一番手前のレイヤーとかほとんど透過色でほとんど描画しないんじゃないのか
てかMakeScreenで作ったバッファに透過色設定とかできたっけ

**名前は開発中のものです。** · 2011/08/23(火) 20:24:26.48

α付きPNGは、必要な箇所のみに絞って使ったほうが良いような気がする

**名前は開発中のものです。** · 2011/08/23(火) 23:30:59.29

話題は変わってしまうけど質問

DrawGraphとかの座標の設定は、int x, int y　ってなってるけど、
doubleの値を代入したりするとやっぱりバグるのか？

三角関数とか使って座標の計算とかしてるとどうしてもdoubleの値がでてきてしまうんだが

**名前は開発中のものです。** · 2011/08/23(火) 23:35:10.20

>>105
自動的にintにキャストされる

float値を使いたい場合はDrawGraphFでおｋ
使い分けはまぁ色々試してみるといいかと

**名前は開発中のものです。** · 2011/08/23(火) 23:57:38.50

少し説明が不親切だったか

描画モードがBILINEARの時にfloatでDrawすると各描画点の座標をfloatで計算してくれる
1pixel未満の単位で描画できるけど、描画画像がボケるから使い分けが必要

NEARESTの時にfloatでのDrawはやったことないから分からない

**名前は開発中のものです。** · 2011/08/24(水) 00:01:48.23

今の２Dゲームってスクロールした時に描画してるんじゃないと思うけどなあ
技術的には挑戦してみたいけど

**名前は開発中のものです。** · 2011/08/24(水) 00:08:03.99

>>108
まぁ性能が低い場合の工夫だからね
ユーザー環境にばらつきがあって下限が低いPCゲーだとファミコンみたいな工夫も必要なのかと

**名前は開発中のものです。** · 2011/08/24(水) 11:46:00.65

>>106
そうだったか
doubleからint型に変換されるとバグる時あるけど、バグるときとバグらない時の
違いってなんなのかね

**名前は開発中のものです。** · 2011/08/24(水) 12:03:34.50

>>110
全然関係ないところでバグってるって可能性が一番高い
あとint型は+20億～-20億程度が保持できる値の範囲だから、キャスト前の値がそれを外れてるとバグる

他に良くある誤りとしては、printfで%d指定してるのにdoubleやfloat突っ込むと変な値が出るとか

**名前は開発中のものです。** · 2011/08/24(水) 12:08:51.65

reinterpret_castしてるとか……は、流石に無いな。

**名前は開発中のものです。** · 2011/08/24(水) 12:37:25.60

int型やdouble型をまぜこぜに計算した結果、なんか想定とズレた事になることはたまにある……。

**名前は開発中のものです。** · 2011/08/24(水) 12:55:33.53

そりゃ浮動小数点って近似値でしかないからな
丸め誤差が蓄積してintにしたときに大きくずれることはよくある

**名前は開発中のものです。** · 2011/08/24(水) 13:35:52.82

ある数を別のある数で割って、同じ値で掛けると思いもよらない所で別の数値が出る、っていう例がなんかあったな

**名前は開発中のものです。** · 2011/08/24(水) 14:39:56.73

少し高度だけど、浮動小数点周りの挙動はこれが参考になるかも

ttp://0xcc.net/blog/archives/000164.html

**名前は開発中のものです。** · 2011/08/24(水) 14:53:30.67

ゲームなら普通浮動小数点モデルをfastに設定するだろうから80bitは使われないしまた違ってくるな
最近偶数丸めの四捨五入とか負の値の切り上げ切捨ては
理解してないと整数にしたときに違ってくるのはある

**名前は開発中のものです。** · 2011/08/24(水) 15:18:28.07

fastは不安すぎて使えない

**名前は開発中のものです。** · 2011/08/24(水) 15:30:40.78

ゲームの場合、浮動小数点演算は速度よりも精度の方が重要な気がする
高度な物理演算でもさせるのなら別だけど、物理演算なら何か物理エンジン持ってきた方が手っ取り早いだろうし

**名前は開発中のものです。** · 2011/08/25(木) 00:25:28.37

構造体のメンバがめっさ増えてしまったよ
心が痛むけど便利だから仕方ない

**名前は開発中のものです。** · 2011/08/25(木) 00:28:02.81

>>119
フリーでシェアウェアにも使える3Dの物理エンジンってあるかな

**名前は開発中のものです。** · 2011/08/25(木) 00:31:33.05

ODEとか？

**名前は開発中のものです。** · 2011/08/25(木) 00:58:40.19

Windows版ならPhysXも普通に商用無料だけど

**名前は開発中のものです。** · 2011/08/25(木) 01:18:03.52

Havok?

**名前は開発中のものです。** · 2011/08/25(木) 19:31:31.34

3Dのポリゴンはfloatじゃないと怒ってくるよねｗ

**名前は開発中のものです。** · 2011/08/25(木) 19:43:51.78

>>122
調べてみるサンクス

>>123
PhysXってゲフォ使ってないとダメとかそういう制限ないの？

>>124
Havokはシェアウェアに制限があったと思う

**名前は開発中のものです。** · 2011/08/25(木) 19:46:15.26

bullet physicsでいんじゃね
かなり重いが

**名前は開発中のものです。** · 2011/08/25(木) 19:51:22.21

>>127
GTA4なんかにも使われてるんだな
これももうちょい調べてみる

**名前は開発中のものです。** · 2011/08/25(木) 20:36:10.22

Newton Game Dynamics

**名前は開発中のものです。** · 2011/08/25(木) 20:36:41.74

>>126
そんな制限あったら誰も使わねえよｗ

**名前は開発中のものです。** · 2011/08/25(木) 20:55:20.29

>>130
そうなんだ
数年前にnVidia以外のGPUを検知するとPhysXの機能が停止されるようになったとか見た記憶があったから
自動的に選択肢から外してたけど、いつの間にか解消されてたのね

**名前は開発中のものです。** · 2011/08/25(木) 21:11:09.88

>>131
何か勘違いしてるみたいだけどPhysXはGPU限定じゃないぞ？
GeForceならCPUより速くなるだけで
普通にCPUのみで常用出来るしUnityやUDKはPhysXがデフォ

**名前は開発中のものです。** · 2011/08/25(木) 21:16:10.43

>>132
なるほど、勉強になった
思ってる通り完全に勘違いしてたわ恥ずかしい限りで・・・

**名前は開発中のものです。** · 2011/08/26(金) 03:17:13.81

DXlibで作ったゲームをより多くの人にプレイしてもらう一番の方法って何だろう

**名前は開発中のものです。** · 2011/08/26(金) 13:41:24.01

どうやって宣伝するかの話になるから一筋縄ではいかない問題だな

**名前は開発中のものです。** · 2011/08/26(金) 13:55:01.38

>>134
テレビCM

**名前は開発中のものです。** · 2011/08/26(金) 16:54:57.79

公式ページに宣伝する場所あるけど、そこの数見るとやはりグラフィックじゃないか
・・・あそこ東方多いなー

**名前は開発中のものです。** · 2011/08/26(金) 22:58:00.36

>>110
doubleとintじゃメモリ長違うからな(double-8バイト、int-4バイト)
代入の時に(int)のようなキャスト文を記述するのがプログラムの基本だと思うけど
自動キャストにあまり期待しないほうがいいのでは

**名前は開発中のものです。** · 2011/08/27(土) 05:50:17.26

久しぶりにライブラリ更新したら、フォントサイズがのきなみデカくなってしまった。
3.05aの時にフォントが小さくなる不具合が修正されたとあったので、
この不具合を受けていたんだろうな。

**名前は開発中のものです。** · 2011/08/28(日) 01:38:40.08

画像の透明度が上手く反映されない
マジ糞

**名前は開発中のものです。** · 2011/08/28(日) 01:50:59.35

お前の技術が糞なだけ

**名前は開発中のものです。** · 2011/08/30(火) 00:57:40.02

ＤＸいじり始めて少したった今、始めたばかりの頃のコードが糞すぎることに
気付いて直したいんだけど、これを直すとかなりの部分を直さなければならなくなる

どうしようか悩みどころだ

**名前は開発中のものです。** · 2011/08/30(火) 01:06:28.73

何か完成目標があるのなら必要な部分だけ直しつつ進めることを勧める
そんなに大作志向のものでは無いのなら、適当に区切りをつけて終了するのがいいかもしれない

**名前は開発中のものです。** · 2011/08/30(火) 01:55:16.10

進めば進むほど直したくなる部分が増えるから問題が起こらないのであれば触らないほうがいい
糞すぎてもいいからそのまま完成させ、その答えは次回作る時に回す

**名前は開発中のものです。** · 2011/08/30(火) 01:58:10.42

ネームスペースを分けて併用する
古いコードは触らず、新しく書く部分は新しいライブラリを使う

**名前は開発中のものです。** · 2011/08/30(火) 04:01:10.54

そういうことに走り出したら完成しない

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

結構根本的なところが適当に作っちゃってたからな、本当に反省ものだわ～
そもそも一つ実装するのに複数同じコード書かなきゃいけないのは、エレガントじゃなかった
始めた頃は、同じの書くだけか、とか思ってたんだが

意気込んで色々作ったから、結構大作にする予定だったけど
今回は、ある程度区切りがついたら終了しないにしても、次の作品に取りかかろうと思う

**名前は開発中のものです。** · 2011/08/30(火) 15:23:57.82

>>146に同意だが、根本となると後々不便になること多いからねぇ

**名前は開発中のものです。** · 2011/08/30(火) 15:26:34.28

>>147
素材を流用して次を大作にすればいいのさ

**名前は開発中のものです。** · 2011/08/30(火) 15:29:14.00

俺も同じようなケースに陥ったが新しくフレームワーク書いてその上に全部移植したよ

**名前は開発中のものです。** · 2011/08/30(火) 20:57:25.09

綺麗なブラー（リニア＆放射）かけてみたいんだけど、シェーダを勉強するしかないかな。
2Dゲーム前提で、今作ってるゲームが完成するまでは、あんまり勉強に時間を割けられない。

**名前は開発中のものです。** · 2011/08/30(火) 21:01:51.66

シェーダよりは重くなるが、描画可能画像に全ての画像を書き込んだ後、
その画像を半透明にずらしながら数枚置けばそういうことが出来る
軽くやりたいならシェーダを学べばいい

**名前は開発中のものです。** · 2011/08/30(火) 21:15:37.01

加算合成のブラーならシェーダ使わず軽めに綺麗にできるんだけどなー
別の描画可能テクスチャにブラー掛けたいものを加算描画して、毎フレームクリアせずに減算で少しだけ全体を暗くする
そのテクスチャを画面に加算で合成すればおｋ

**名前は開発中のものです。** · 2011/08/30(火) 22:09:15.00

>>142
オレは最初の勉強しながら書いた糞コードは途中で全部書き直した。
コードも短くなって綺麗になり、バグも直ったよ。
直しとけ

**名前は開発中のものです。** · 2011/08/30(火) 22:10:19.14

そしてコード直しの無限ループに陥っていつまでたっても完成しないんですね
分かります

**名前は開発中のものです。** · 2011/08/30(火) 23:48:45.32

ありがとう。

>>152
ピンポイントで使う分には力技もアリっちゃありか

>>153
それ面白いな

**名前は開発中のものです。** · 2011/09/01(木) 00:19:30.76

素材作りが面倒くさすぎる
特に選択画面とかメニュー周りのレイアウト考えて作るの嫌だわ

**名前は開発中のものです。** · 2011/09/01(木) 00:20:51.61

慣れだ

**名前は開発中のものです。** · 2011/09/01(木) 00:43:11.59

どっかのニュースでGoogle+風のアイコンやUIのフリー素材とかあったからそういうの使えばいいんじゃね

**名前は開発中のものです。** · 2011/09/01(木) 01:14:25.00

スクロールとかめんどいよね

**名前は開発中のものです。** · 2011/09/01(木) 01:52:07.28

レイアウトは色んなゲームからパクればいいよ
どうせどれも似たようなもんだ

**名前は開発中のものです。** · 2011/09/02(金) 21:26:41.41

編成画面、一発でビルド成功した
夢精しちゃった

**名前は開発中のものです。** · 2011/09/02(金) 21:29:21.25

夢落ちかｗ

**名前は開発中のものです。** · 2011/09/02(金) 21:51:54.23

夢精吹いたｗｗｗ

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

初心者的質問ですまないがMV1LoadModelFromMemってどういう使い方すればいいんだ？
メモリに読み込んでも展開する時のロード時間がMV1LoadModelとほとんど変わらない
マルチスレッドによるローディングのお供かと思ったがやっぱり他と競合するからなぁ

**名前は開発中のものです。** · 2011/09/04(日) 18:23:24.33

使ったことないから適当抜かすけど、
メモリ上に読み込んで編集したものを読み込んで使ったりするんじゃないの。

**名前は開発中のものです。** · 2011/09/04(日) 18:28:01.69

メタセコのモデルデータとかテキスト形式だしなー
でも実際はメモリからファイルとして読み込む関数はただひと通り用意してあるだけなんじゃないの？
独自アーカイブとか使いたい人居るでしょ

**名前は開発中のものです。** · 2011/09/04(日) 18:34:14.15

暗号化とか考えだすとまずファイル名指定系は使えなくなる

**名前は開発中のものです。** · 2011/09/04(日) 19:10:16.22

データを予め圧縮しておいてそれをメモリに展開してから読み込む
～FromMem関係はだいたいそんな使い方をしてる

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

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