DXライブラリ質問&雑談掲示板2
[トップに戻る] [使いかた] [ワード検索] [管理用]
おなまえ
題  名
メッセージ
削除キー (記事削除用。英数字で8文字以内)
クッキー情報を保存

<管理人>
ご返信は一週間に一度、土日のどちらかで行います。平日は時間に余裕があるときだけご返信します。
この掲示板はマルチポスト禁止です。

[5401] CheckHitKeyAll()に付いて。 投稿者:辺見!真琴 投稿日:2024/03/05(Tue) 15:08 [返信]
細事に対応いただき、ありがとうございました。

[5400] ご返信 投稿者:管理人 投稿日:2024/03/04(Mon) 21:31 [返信]
> 辺見!真琴さん すみません、『ヘッダコメントの方が正しい』となります リファレンスマニュアルの方を修正しておきました m(_ _;m

[5399] CheckHitKeyAll()に付いて。 投稿者:辺見!真琴 投稿日:2024/03/04(Mon) 09:41 [返信]
毎度毎度、細かい事をお聞きします。 CheckHitKeyAll()ですが、マニュアルによれば返り値は0かー1ですが、DxLib.hのコメントには0かそれ以外となっています。 実際、戻り値が42となっていて面食らっております。 ヘッダコメントの方が正しい、で良いのでしょうか。

[5398] 無題 投稿者:sino 投稿日:2024/02/21(Wed) 17:47 [返信]
>>5397 助言ありがとうございます。 DrawCircleから、火花の色でSetBrightして白い円の画像ファイルをDrawRotaGraphで描画するようにして、変更したら、描画するオブジェクトの数が80万になっても変更前の20万よりずっと軽くなりました。

[5397] ご返信 投稿者:管理人 投稿日:2024/02/19(Mon) 21:48 [返信]
> sinoさん > お手数ですが管理人様に削除していただきたい次第であります 承知しました、削除させていただきました 20万という時点で十分な数が出ていると思いますが、そこで突然となると何かあるのかもしれませんね ( GPU が原因なのか、CPU が原因なのか、C# のGC等が原因なのかは調べてみないとわかりませんが… ) 因みに火花を DrawCircle で描画されていましたら、それを円が描かれた画像を DrawGraph で描画するように 変更するだけで描画負荷はかなり下がりますので、よろしければお試しください( DrawCircle は DrawGraph より かなり重い処理なので… ) あと、複数の火花画像を別々の画像ファイルで用意してそれぞれ LoadGraph で読み込んで描画するより、 一つの大きな画像に全ての火花画像を敷き詰めて LoadGraph でその大きな画像を読み込んだ後、 DerivationGraph でそれぞれの火花画像部分を抜き出して使う方が別々の画像ファイルの場合より かなり高速に描画できますので、もし火花を既に画像にされていて、別々の画像ファイルで 扱っていましたら『大きな画像に敷き詰めて LoadGraph → DerivationGraph で分けて使用』をお試しください 後は、動画を拝見する限りでは C# で組まれていると思われますが、C# の実行速度は C++ のデバッグ実行くらいの 速度だったと思いますので、もし FPS 低下が CPU 負荷が原因でしたら C++ で実行するように変更すると解決するかもしれません

[5396] 無題 投稿者:sino 投稿日:2024/02/17(Sat) 23:27 [返信]
お返事ありがとうございます。 とりあえずC#で作っているアプリを完成させようと思います。 それからC/C++用に移植するかどうか検討してみることにします 最後になりましたが、素晴らしいライブラリを公開してくれて本当にありがとうございます!

[5395] ご返信 投稿者:管理人 投稿日:2024/02/16(Fri) 22:15 [返信]
> sinoさん 動画拝見しました 花火のような表示が綺麗ですね > 右下のモード表示にenumで用意して変換した文字列付け加えていたら良かったかなぁ... 確かに数字だけでは DX_BLENDMODE_ALPHA などの名称が不明なので、文字列の方が良いかもしれません > あと、C#(DotNet?)、でクロスプラットフォーム(?)できるようにする予定はまだありませんか? はい、C#版は現在の Windows用の物以外を開発する予定はありません

[5394] 無題 投稿者:sino 投稿日:2024/02/16(Fri) 20:55 [返信]
youtube.com/watch?v=oA8uGRD0eBc ブレンドモードの違いがよくわからなかったので、こういうの作ってたのを宣伝。 初心者の人は倍速でさっくり見てみるといいかも? 今見返して思うところは、右下のモード表示にenumで用意して変換した文字列付け加えていたら良かったかなぁ... あと、C#(DotNet?)、でクロスプラットフォーム(?)できるようにする予定はまだありませんか? delkey="del"

[5393] 無題 投稿者:dra 投稿日:2024/02/05(Mon) 00:59 [返信]
> 12月を過ぎてもアドベントカレンダーに書き込めるのですね (・・; 去年も割と長い間(数ヶ月?)空いてた気がしました。 > 『GetClipboardText(NULL, 0); の時点でクリップボードの内容を取得している( キャッシュしている )ので >  GetClipboardText(str, len); までの間にクリップボードの内容が変更されても >  問題が発生しないようになっている』というのは目から鱗でした、勉強になります OSによって機能を実現する方法が大きく違うことがあるので使い方の制約でカバーする必要がありますが そこを考えるのもおもしろいところですね。

[5392] ご返信 投稿者:管理人 投稿日:2024/02/02(Fri) 03:37 [返信]
> かじるさん ご反応ありがとうございます 何か問題がありましたらご連絡ください m(_ _)m > draさん 労いのお言葉ありがとうございます draさんも DXライブラリ Linux版のご対応ありがとうございます m(_ _)m > 旧暦ではまだ12月なので、アドベントカレンダーを書きました。 12月を過ぎてもアドベントカレンダーに書き込めるのですね (・・; > int len = GetClipboardText(NULL, 0); // A > char* str = (char*)malloc(len); > GetClipboardText(str, len); // B 『GetClipboardText(NULL, 0); の時点でクリップボードの内容を取得している( キャッシュしている )ので  GetClipboardText(str, len); までの間にクリップボードの内容が変更されても  問題が発生しないようになっている』というのは目から鱗でした、勉強になります

[5391] 無題 投稿者:dra 投稿日:2024/02/01(Thu) 00:08 [返信]
アプデおつかれさまです。 旧暦ではまだ12月なので、アドベントカレンダーを書きました。 DxLib Ver 3.24d以降でのGetClipboardTextの使い方 qiita.com/dragoon2014/items/5c5630f15a1fa0cedfec dxlib-for-linux 2023年(+α)の進捗 qiita.com/dragoon2014/items/a2a4909e160748226ecc GetClipboardTextをお使いの方はアプデ&対応をおすすめします。

[5390] Re:[5389] DXライブラリ 3.24d をアップしました 投稿者:かじる 投稿日:2024/01/29(Mon) 11:21 [返信]
> 今回は機能追加が結構ありますが、一般的にはあまり使用しないものが殆どだと思います > > 機能追加よりも今回は SetUseASyncLoad( TRUE ); を使用した非同期読み込みに関係した致命的なバグを修正していますので、 > もし SetUseASyncLoad( TRUE ); の非同期読み込み機能を使用されている場合は更新をしてください m(_ _;m > > その他の更新項目についてはこちらをご参照ください m(_ _)m > > <DXライブラリ更新履歴> > https://dxlib.xsrv.jp/dxlog.html 3.24dありがとうございますー!! 有り難く使わせていただきますっ!!

[5389] DXライブラリ 3.24d をアップしました 投稿者:管理人 投稿日:2024/01/03(Wed) 01:36 [返信]
今回は機能追加が結構ありますが、一般的にはあまり使用しないものが殆どだと思います 機能追加よりも今回は SetUseASyncLoad( TRUE ); を使用した非同期読み込みに関係した致命的なバグを修正していますので、 もし SetUseASyncLoad( TRUE ); の非同期読み込み機能を使用されている場合は更新をしてください m(_ _;m その他の更新項目についてはこちらをご参照ください m(_ _)m <DXライブラリ更新履歴> https://dxlib.xsrv.jp/dxlog.html

[5388] ご返信 投稿者:管理人 投稿日:2023/11/29(Wed) 23:55 [返信]
> かじるさん > 日経ソフトウェアにDXライブラリがっ!! ご情報ありがとうございます、私も拝見しました 丁寧に解説されていて嬉しいです (^ ^

[5387] 日経ソフトウェアにDXライブラリがっ!! 投稿者:かじる 投稿日:2023/11/28(Tue) 11:37 [返信]
表題の通りでやんすー!! 弾幕シューティングっすー!! //info.nikkeibp.co.jp/media/NSW/

[5386] ご返信 投稿者:管理人 投稿日:2023/11/20(Mon) 00:30 [返信]
> 名無三さん > カレンダー作成しました 了解です といっても私は毎年不関与ですが (・・;

[5385] AdventCalendar2023を作成しました 投稿者:名無三 投稿日:2023/11/18(Sat) 15:36 [返信]
> 管理人様 お疲れ様です、毎度お世話になります カレンダー作成しました=> qiita.com/advent-calendar/2023/dxlib

[5384] ご返信 投稿者:管理人 投稿日:2023/11/18(Sat) 00:20 [返信]
> 名無三さん なんと、今年ももうそのような時期ですか… 今年はいつにも増して何もしない内に一年が過ぎてしまったかもしれません… (・・;; ( 因みに私はカレンダーは作成していません )

[5383] AdventCalendar2023について 投稿者:名無三 投稿日:2023/11/17(Fri) 13:00 [返信]
お疲れ様です、もうそろそろ年末ですね。 アドベントカレンダーの方を僭越ながら作成させていただこうと思います。もう作ってる等々ございましたら取り下げますのでご連絡ください。 18日午前までに特に連絡ございませんでしたら立てます。 今年も何かしら記事を出せるよう頑張ります、よろしくお願いします。

[5382] ご返信 投稿者:管理人 投稿日:2023/11/04(Sat) 01:44 [返信]
> Tirさん TEXMOD、そのようなソフトがあったのですね (・・; 他に類似のソフトがあるかは分かりませんが 実行中のプログラムのメモリを閲覧したり書き換えたりするソフトがあるので 暗号化が解かれたデータをメモリから取り出すのも技術的には可能だと思います

[5381] 無題 投稿者:Tir 投稿日:2023/11/03(Fri) 01:03 [返信]
以前TEXMODというメモリからテクスチャを抜き出したり差し替えたりするツールを自分のゲームに試してみたのですが 対応してなかったのか使えなかったので他にもそのようなツールがあるのでしょうかね? リテラル文字はバイナリエディタで簡単に変更できるからまだしもテキストファイルの方は自作のスクリプトを使用しているので なんにしても何かしらの解析はしたのでしょうね

[5380] ご返信 投稿者:管理人 投稿日:2023/11/02(Thu) 01:18 [返信]
> Tirさん > アセンブリ言語で解析するのはとても大変(人によっては簡単なのかも)だと思うので ソフトを全てアセンブリ言語で組んだことがあるような方からすると exeファイルは 逆アセンブルを使えばプログラムがそのまま見れるようなものなので仰る通り人によってはある程度簡単ではないかと思います クラッキング用のツールも時代と共に進化していると思いますし… > 逆コンパイラで等のツールでも使ったのかなと考えたのですが、C++での逆コンパイルは難しいらしいですね… マシン語と1対1の関係にあるアセンブリ言語と異なりコンパイルして生成されたマシン語には変数名や関数名などの情報が一切無い上に 構造体やクラスや列挙型などの情報も無くなるので、逆コンパイルはかなり難しいと思います ( 出来たとしても元の C++ のコードとは似ても似つかないものになりそうです ) > もう突破されたので言いますけど今までのはファイルを個別にDXライブラリのミニテクニックに乗っているLZSS圧縮を使用した後ビット反転を行うというだけでした。 > それで十分だと思っていたんですけどね… そうだったんですね… 私もそれで十分なような気がします… (・・; ただ、どんな暗号化を施したデータも最終的には RGBA の生ビットマップだったり リニアPCM の波形データだったりにデコードされるので、 個人的な推測としては暗号化を解除するプログラムを編み出されたのではなくデコードされた生ビットマップや生波形のデータを メモリ上から抜き出したのではないかと思いました ( そうではなく地道にアセンブリコードとにらめっこして暗号化処理を解読されたのかもしれませんが… )

[5379] 無題 投稿者:Tir 投稿日:2023/11/01(Wed) 23:59 [返信]
技術がある人なら解析されてしまうとは分かってはいるものの アセンブリ言語で解析するのはとても大変(人によっては簡単なのかも)だと思うので 逆コンパイラで等のツールでも使ったのかなと考えたのですが、C++での逆コンパイルは難しいらしいですね… もしアセンブリ言語で解析したのなら、そこまでの労力をつぎ込んだのが驚きです。そこまでする程のゲームでもないと思うので… なんにせよ一度突破されたセキュリティで次回作を作るのはとても気持ち悪いので、またちょっとファイルの暗号化形式を変えなくてはいけませんね。 もう突破されたので言いますけど今までのはファイルを個別にDXライブラリのミニテクニックに乗っているLZSS圧縮を使用した後ビット反転を行うというだけでした。 それで十分だと思っていたんですけどね…

[5378] ご返信 投稿者:管理人 投稿日:2023/11/01(Wed) 00:59 [返信]
> DirectX99さん > なのでDXライブラリを今後扱っていこうと考えておりますが,DXライブラリで得た記述法であったり, > 考え方というのは今後DirectX11を勉強する際に役立つと思いますか? いえ、DXライブラリは DirectX や Windows関連の知識が一切無くても DirectX が使えるようにした ライブラリなので、DXライブラリを使いこなせるようになっても DirectX11 の勉強にはなりません > また,DXライブラリは、DirectXやWindows関連のプログラムを使い易くまとめた形で利用できるようにしたC++言語用のゲームライブラリとありますが, > どの程度扱いやすくしたのでしょうか? DirectX を直接使用するプログラムを作成する場合は、まず DirectX の前にウィンドウを CreateWindow などで 作成したりウィンドウプロシージャの処理を書くなどウィンドウ関連のプログラムを組んだ後、 漸く CreateDXGIFactory2 で DXGIオブジェクトを作成するなどの DirectX 関連の初期化処理を組むことが出来るわけですが、 そこから更に Direct3D11 の初期化が始まり、頂点バッファの初期化、頂点シェーダー・ピクセルシェーダーの初期化などなど ウィンドウの中心に白い四角形を描画するプログラムを作成するだけで最低でも数百行のプログラムを組む必要がありますが、 DXライブラリを使用する場合は 10行ほどで同じ動作をするプログラムを組むことが出来ます > Tirさん お久しぶりです DXArchive はエンコーダーと共にデコーダーも配布しているので、パスワードさえ分かれば簡単にアーカイブの中身を 見れてしまうという弱点があります パスワードはプログラムの中に直接書かれていたり、仮にプログラムの中に書かれていなくても何らかの経緯を経て アーカイブを開く際に生の文字列の状態になって使用されるので、実行時のメモリ解析などを行える技術のある人に掛かれば 容易にパスワードを知ることができてしまうのかもしれません( 実際にそのような技術を持った方と知り合いだったりはしないので 本当のところはどうなのか不明ですが… ) プログラムの中に埋め込まれたパスワードを抜き出す事ができるような技術のある方であれば、同様にプログラムの中で データの暗号化を解除している処理も解析することが出来ると思いますので( アセンブリ言語の知識のある人であれば 実行ファイルのバイナリを逆アセンブルしてアセンブリコードからどのような暗号処理が行われているかを知ることが出来ます )、 手元で暗号化されたファイルを解除するプログラムを組んでしまえば、暗号化される前のファイルを手に入れられてしまうという訳です… 私が関わった ASTLIBRA Revision も同様にパスワード付き DXArchive を使用して、且つパスワードを生文字列ではなく ビット反転やビットシフトをした状態でプログラムに書き込んでおいたりしましたが、リリース後数日で中のファイルの一覧の スクリーンショットがツイートされていました ただ、画像ファイルは独自の可逆圧縮形式にしていたのですが、それは破られる( bmp や png などの一般的な 画像形式に変換される )ことはありませんでした 暗号化したパスワードを抜き出せる技術のある人なら同様に独自画像形式から通常画像への変換もできてしまいそうなものですが… ハッキング技術には疎いので何故画像抜き出しは出来なかったのかは不明です… 因みに、定期的に『このソフトは◯◯社の最新暗号化技術を使用しました、なのでこのソフトを不届き者がクラックして タダでプレイするということは絶対にできません』と豪語してリリースされたソフトが1週間もしない内にクラックされて ネット上に違法配布される、ということが起きていますので 一般的なPCソフトで不正解析されないようにするというのはほぼ不可能だと考えたほうが良さそうです… (- -;; ( PCソフトは家庭用ゲーム機用ソフトよりも解析されやすいので、解析される可能性を下げるためにPCには絶対リリースしない  と決めているゲーム会社もあるようです )

[5377] 無題 投稿者:Tir 投稿日:2023/10/31(Tue) 23:25 [返信]
お久しぶりです。 ただの雑談なのですが、僕が作ったゲームの中国語版ができました。僕の知らないところで勝手に。 当然DXArchiveでパス付のアーカイブ(リテラル文字不使用)をして、更に全てのファイルを圧縮した後適当な間隔でビット反転をして暗号化しましたが それでも中身を弄られていました。技術がある人なら解析できるとは思うのですが、まさか自分のゲームが対象になると思わずいったいどういう方法で解析したのか 不思議で気になっています…。

[5376] DXライブラリとは? 投稿者:DirectX99 投稿日:2023/10/31(Tue) 16:34 [返信]
管理人様 初めまして。 DirectX11を勉強中にこのDXライブラリなるものを発見しました。 DirectX11よりもこのDXライブラリの方が扱いやすそうというのが所見でございます。 なのでDXライブラリを今後扱っていこうと考えておりますが,DXライブラリで得た記述法であったり, 考え方というのは今後DirectX11を勉強する際に役立つと思いますか? また,DXライブラリは、DirectXやWindows関連のプログラムを使い易くまとめた形で利用できるようにしたC++言語用のゲームライブラリとありますが, どの程度扱いやすくしたのでしょうか? よろしくお願いします。

[5375] Re:[5374] ご返信 投稿者:a 投稿日:2023/10/31(Tue) 00:04 [返信]
詳細なご説明ありがとうございます サイズはあまり気にしなくてよさそうですね 教えていただいたようになるべく同じ画像を連続して使うプログラムを組むようにします ありがとうございました

[5374] ご返信 投稿者:管理人 投稿日:2023/10/30(Mon) 18:43 [返信]
> aさん > DrawRectGraphなどで部分描画をする場合 > 元となる画像のサイズは処理速度に関係しますか? 極端な例ですが、例えば縦横8pixelの描画を DrawRectGraph で描画するにあたって 32768x32768 のサイズの画像の中の 8x8 の領域を DrawRectGraph で描画する場合と、 16x16 のサイズの画像の中の 8x8 の領域を DrawRectGraph で描画する場合でしたら、 後者の方が処理負荷は低いと思います ただ、これは極端な例なので、 1024x1024 の画像の中の 8x8 の領域を DrawRectGraph で描画する場合と 256x256 の画像の中の 8x8 の領域を DrawRectGraph で描画する場合などでしたら 気にするほどの違いは無いと思います 因みに、画像の大きさとは別に『同じ画像を使って連続で描画処理を行ったほうが速い』というルールが ありますので、例えば 1個の 4096x4096 の画像の中の 16x16 の領域を 100回 DrawRectGraph で描画する場合と 100個の 16x16 の画像をそれぞれ 1回ずつ DrawGraph で描画する場合では 描画する回数はどちらも『16x16 の画像 100回』ですが、前者の方が圧倒的に高速に描画が行なえます ( 後者の場合は、1回の描画毎に GPU に対して『描画に使用する画像を切り替える』という命令が 挟まるので、その分重くなります ) なので、処理速度を気にされる場合は DrawRectGraph で使用する画像の大きさよりも 『同じ画像を使って何回連続で描画を行えるか』の方が重要になります

[5373] 無題 投稿者:a 投稿日:2023/10/30(Mon) 11:09 [返信]
DrawRectGraphなどで部分描画をする場合 元となる画像のサイズは処理速度に関係しますか? あまり大きなサイズはよくなかったりとか..

[5372] ご返信 投稿者:管理人 投稿日:2023/10/11(Wed) 23:52 [返信]
> wataさん DXライブラリに CreateFontHandle という関数はありませんが、 CreateFontToHandle という関数はありますので、CreateFontHandle を CreateFontToHandle に変更すると コンパイルが成功すると思います よろしければお試しください m(_ _)m

記事No 削除キー

- Aska BBS -