---

[トップに戻る] [使いかた] [ワード検索] [管理用]

---

おなまえ
題　　名
メッセージ > ご返信が遅くなっていてすみません > お書き込みの順番通りではない順番でご返信していますが > 土曜日は『バグのご報告』『不具合に関するお問い合わせ』を優先してご返信しました > 本日中にその他のお書き込みにもご返信します m(_ _;m > > > >　名無しさん > 本日私もソードバウトのプログラムを VC2015, 2017 でビルドして確認してみますので少々お待ちください > > > >　マツコSPさん > ＤＸライブラリAndroid版は CPU として ARM が搭載されている Android端末で動作するアプリを作成するためのものなのですが、 > Asus の P01Z は ARM ではなく x86系の CPU が搭載されているため、ダウンロードページから > ダウンロードできるＤＸライブラリAndroid版ではビルドが成功しても実行することができません > > 私の手元に x86系の CPU が搭載されている Android端末が無いので動作チェックはできていませんが、 > x86系用にビルドしたライブラリファイルを作成してみましたので、よろしければこちらをＤＸライブラリAndroid版の > パッケージの中にある『プロジェクトに追加すべきファイル_Android用』の中のファイルの代わりに使用してみてください m(_ _)m > > https://dxlib.xsrv.jp/temp/DxLibAndroidTest_x86.exe
削除キー	(記事削除用。英数字で8文字以内)
	クッキー情報を保存

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

下記、DrawExtendGraphでカード画像の裏表を表示しています。
カード画像を45°回転させた状態で裏表表示をしたいため、
色々と試行錯誤しましたが実現できませんでした。
ご助言をいただけないでしょうか。

double angle = 0;
double rateX;

// 時間をインクリメント
CountTime[0]++;

// 回転角度を変更
angle = (PI / 60) * CountTime[0];

// 現在の角度でのx座標値を算出
rateX = (int)(cos(angle) * 60 * 0.5);

// 裏と表、どちらが見えているかを角度で判断
if (angle < PI / 2.0f || angle > PI / 2.0f + PI)
{
　// 裏が見えている場合
　DrawExtendGraph((int)(20 + 60 * 0.5 - rateX) + 1, (int)y1, (int)(20 + 60 * 0.5 + rateX) - 1, (int)(20 + 80), backimage, transFlag);
}
else
{
　// 表が見えている場合
　DrawExtendGraph((int)(20 + 60 * 0.5 + rateX) - 1, (int)y1, (int)(20 + 60 * 0.5 - rateX) + 1, (int)(20 + 80), imageHandle, transFlag);
}

// １回転(π)以上
if (angle >= PI)
{
　// 時間を初期化
　CountTime[0] = 0;
}

>　naohiro19さん

ご提案ありがとうございます
現状でも文字列の描画は行えますが、DirectWrite による描画をお勧めされるのは
何か理由があるのでしょうか？ (・・

int SetDrawStringMode(int DrawTextMode);

DX_DRAWSTRING_DEAULT:従来の方法で文字列を描画する
DX_DRAWSTRING_DIRECTWRITE:DirectWriteを使った文字列描画

この関数はDrawString関数などをで従来の方法で文字列を描画するか
DirectWriteを使った描画にするのかを設定をする関数です。

この関数を読んだ後にDrawString関数を呼ぶとDirectWriteのAPIを使って文字列を描画する仕組みを用意したらどうでしょうか？

>　naohiro19さん

Visual Studio 2022 で

	GraphHandle = LoadGraph( R("Image\Graph1.bmp") );

をコンパイルしてみたのですが

	error C3861: 'R': 識別子が見つかりませんでした

と、コンパイルエラーになってしまいました
naohiro19さんの環境ではエラーにならずにコンパイルできますでしょうか？

C++の生文字リテラルを用いると、以下の記述は、

GraphHandle = LoadGraph( "Image\\Graph1.bmp" ) ;

この記述は、以下のように記述ができます。
GraphHandle = LoadGraph( R("Image\Graph1.bmp") )　;

\\ を書く必要がなくなります。

細事に対応いただき、ありがとうございました。

>　辺見！真琴さん

すみません、『ヘッダコメントの方が正しい』となります
リファレンスマニュアルの方を修正しておきました m(_ _;m

毎度毎度、細かい事をお聞きします。
CheckHitKeyAll()ですが、マニュアルによれば返り値は0かー1ですが、DxLib.hのコメントには0かそれ以外となっています。
実際、戻り値が42となっていて面食らっております。
ヘッダコメントの方が正しい、で良いのでしょうか。

>>5397
助言ありがとうございます。
DrawCircleから、火花の色でSetBrightして白い円の画像ファイルをDrawRotaGraphで描画するようにして、変更したら、描画するオブジェクトの数が80万になっても変更前の20万よりずっと軽くなりました。

>　sinoさん

>　お手数ですが管理人様に削除していただきたい次第であります

承知しました、削除させていただきました
20万という時点で十分な数が出ていると思いますが、そこで突然となると何かあるのかもしれませんね
( GPU が原因なのか、CPU が原因なのか、C# のGC等が原因なのかは調べてみないとわかりませんが… )

因みに火花を DrawCircle で描画されていましたら、それを円が描かれた画像を DrawGraph で描画するように
変更するだけで描画負荷はかなり下がりますので、よろしければお試しください( DrawCircle は DrawGraph より
かなり重い処理なので… )

あと、複数の火花画像を別々の画像ファイルで用意してそれぞれ LoadGraph で読み込んで描画するより、
一つの大きな画像に全ての火花画像を敷き詰めて LoadGraph でその大きな画像を読み込んだ後、
DerivationGraph でそれぞれの火花画像部分を抜き出して使う方が別々の画像ファイルの場合より
かなり高速に描画できますので、もし火花を既に画像にされていて、別々の画像ファイルで
扱っていましたら『大きな画像に敷き詰めて LoadGraph → DerivationGraph で分けて使用』をお試しください

後は、動画を拝見する限りでは C# で組まれていると思われますが、C# の実行速度は C++ のデバッグ実行くらいの
速度だったと思いますので、もし FPS 低下が CPU 負荷が原因でしたら C++ で実行するように変更すると解決するかもしれません

お返事ありがとうございます。
とりあえずC#で作っているアプリを完成させようと思います。
それからC/C++用に移植するかどうか検討してみることにします
最後になりましたが、素晴らしいライブラリを公開してくれて本当にありがとうございます！

>　sinoさん

動画拝見しました
花火のような表示が綺麗ですね

>　右下のモード表示にenumで用意して変換した文字列付け加えていたら良かったかなぁ...

確かに数字だけでは DX_BLENDMODE_ALPHA などの名称が不明なので、文字列の方が良いかもしれません

>　あと、C#(DotNet?)、でクロスプラットフォーム(?)できるようにする予定はまだありませんか？

はい、C#版は現在の Windows用の物以外を開発する予定はありません

youtube.com/watch?v=oA8uGRD0eBc
ブレンドモードの違いがよくわからなかったので、こういうの作ってたのを宣伝。
初心者の人は倍速でさっくり見てみるといいかも？
今見返して思うところは、右下のモード表示にenumで用意して変換した文字列付け加えていたら良かったかなぁ...

あと、C#(DotNet?)、でクロスプラットフォーム(?)できるようにする予定はまだありませんか？
delkey="del"

> 12月を過ぎてもアドベントカレンダーに書き込めるのですね (・・;

去年も割と長い間（数ヶ月？）空いてた気がしました。

> 『GetClipboardText(NULL, 0); の時点でクリップボードの内容を取得している( キャッシュしている )ので
> 　GetClipboardText(str, len); までの間にクリップボードの内容が変更されても
> 　問題が発生しないようになっている』というのは目から鱗でした、勉強になります

OSによって機能を実現する方法が大きく違うことがあるので使い方の制約でカバーする必要がありますが
そこを考えるのもおもしろいところですね。

>　かじるさん

ご反応ありがとうございます
何か問題がありましたらご連絡ください m(_ _)m


>　draさん

労いのお言葉ありがとうございます
draさんも ＤＸライブラリ 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); までの間にクリップボードの内容が変更されても
　問題が発生しないようになっている』というのは目から鱗でした、勉強になります

アプデおつかれさまです。
旧暦ではまだ12月なので、アドベントカレンダーを書きました。

DxLib Ver 3.24d以降でのGetClipboardTextの使い方
qiita.com/dragoon2014/items/5c5630f15a1fa0cedfec

dxlib-for-linux 2023年（+α）の進捗
qiita.com/dragoon2014/items/a2a4909e160748226ecc

GetClipboardTextをお使いの方はアプデ＆対応をおすすめします。

> 今回は機能追加が結構ありますが、一般的にはあまり使用しないものが殆どだと思います
> 				
> 機能追加よりも今回は SetUseASyncLoad( TRUE ); を使用した非同期読み込みに関係した致命的なバグを修正していますので、
> もし SetUseASyncLoad( TRUE ); の非同期読み込み機能を使用されている場合は更新をしてください m(_ _;m
> 
> その他の更新項目についてはこちらをご参照ください m(_ _)m
> 
> 	＜ＤＸライブラリ更新履歴＞
> 	https://dxlib.xsrv.jp/dxlog.html

3.24dありがとうございますー!!
有り難く使わせていただきますっ!!

今回は機能追加が結構ありますが、一般的にはあまり使用しないものが殆どだと思います
				
機能追加よりも今回は SetUseASyncLoad( TRUE ); を使用した非同期読み込みに関係した致命的なバグを修正していますので、
もし SetUseASyncLoad( TRUE ); の非同期読み込み機能を使用されている場合は更新をしてください m(_ _;m

その他の更新項目についてはこちらをご参照ください m(_ _)m

	＜ＤＸライブラリ更新履歴＞
	https://dxlib.xsrv.jp/dxlog.html

>　かじるさん

>　日経ソフトウェアにDXライブラリがっ!!

ご情報ありがとうございます、私も拝見しました
丁寧に解説されていて嬉しいです (^ ^

表題の通りでやんすー!!
弾幕シューティングっすー!!
//info.nikkeibp.co.jp/media/NSW/

>　名無三さん

>　カレンダー作成しました

了解です
といっても私は毎年不関与ですが (・・;

> 管理人様

お疲れ様です、毎度お世話になります




カレンダー作成しました＝＞ qiita.com/advent-calendar/2023/dxlib

>　名無三さん

なんと、今年ももうそのような時期ですか…
今年はいつにも増して何もしない内に一年が過ぎてしまったかもしれません… (・・;;
( 因みに私はカレンダーは作成していません )

お疲れ様です、もうそろそろ年末ですね。
アドベントカレンダーの方を僭越ながら作成させていただこうと思います。もう作ってる等々ございましたら取り下げますのでご連絡ください。
18日午前までに特に連絡ございませんでしたら立てます。
今年も何かしら記事を出せるよう頑張ります、よろしくお願いします。

>　Tirさん

TEXMOD、そのようなソフトがあったのですね (・・;

他に類似のソフトがあるかは分かりませんが
実行中のプログラムのメモリを閲覧したり書き換えたりするソフトがあるので
暗号化が解かれたデータをメモリから取り出すのも技術的には可能だと思います

以前TEXMODというメモリからテクスチャを抜き出したり差し替えたりするツールを自分のゲームに試してみたのですが
対応してなかったのか使えなかったので他にもそのようなツールがあるのでしょうかね？
リテラル文字はバイナリエディタで簡単に変更できるからまだしもテキストファイルの方は自作のスクリプトを使用しているので
なんにしても何かしらの解析はしたのでしょうね

>　Tirさん

>　アセンブリ言語で解析するのはとても大変（人によっては簡単なのかも）だと思うので

ソフトを全てアセンブリ言語で組んだことがあるような方からすると exeファイルは
逆アセンブルを使えばプログラムがそのまま見れるようなものなので仰る通り人によってはある程度簡単ではないかと思います
クラッキング用のツールも時代と共に進化していると思いますし…

>　逆コンパイラで等のツールでも使ったのかなと考えたのですが、C++での逆コンパイルは難しいらしいですね…

マシン語と1対1の関係にあるアセンブリ言語と異なりコンパイルして生成されたマシン語には変数名や関数名などの情報が一切無い上に
構造体やクラスや列挙型などの情報も無くなるので、逆コンパイルはかなり難しいと思います
( 出来たとしても元の C++ のコードとは似ても似つかないものになりそうです )

>　もう突破されたので言いますけど今までのはファイルを個別にDXライブラリのミニテクニックに乗っているLZSS圧縮を使用した後ビット反転を行うというだけでした。
>　それで十分だと思っていたんですけどね…

そうだったんですね…　私もそれで十分なような気がします… (・・;

ただ、どんな暗号化を施したデータも最終的には RGBA の生ビットマップだったり リニアPCM の波形データだったりにデコードされるので、
個人的な推測としては暗号化を解除するプログラムを編み出されたのではなくデコードされた生ビットマップや生波形のデータを
メモリ上から抜き出したのではないかと思いました
( そうではなく地道にアセンブリコードとにらめっこして暗号化処理を解読されたのかもしれませんが… )

技術がある人なら解析されてしまうとは分かってはいるものの
アセンブリ言語で解析するのはとても大変（人によっては簡単なのかも）だと思うので
逆コンパイラで等のツールでも使ったのかなと考えたのですが、C++での逆コンパイルは難しいらしいですね…
もしアセンブリ言語で解析したのなら、そこまでの労力をつぎ込んだのが驚きです。そこまでする程のゲームでもないと思うので…

なんにせよ一度突破されたセキュリティで次回作を作るのはとても気持ち悪いので、またちょっとファイルの暗号化形式を変えなくてはいけませんね。
もう突破されたので言いますけど今までのはファイルを個別にDXライブラリのミニテクニックに乗っているLZSS圧縮を使用した後ビット反転を行うというだけでした。
それで十分だと思っていたんですけどね…

>　DirectX99さん

>　なのでDXライブラリを今後扱っていこうと考えておりますが，DXライブラリで得た記述法であったり，
>　考え方というのは今後DirectX11を勉強する際に役立つと思いますか？

いえ、ＤＸライブラリは DirectX や Windows関連の知識が一切無くても DirectX が使えるようにした
ライブラリなので、ＤＸライブラリを使いこなせるようになっても DirectX11 の勉強にはなりません

>　また，DXライブラリは、DirectXやWindows関連のプログラムを使い易くまとめた形で利用できるようにしたＣ＋＋言語用のゲームライブラリとありますが，
>　どの程度扱いやすくしたのでしょうか？

DirectX を直接使用するプログラムを作成する場合は、まず DirectX の前にウィンドウを CreateWindow などで
作成したりウィンドウプロシージャの処理を書くなどウィンドウ関連のプログラムを組んだ後、
漸く CreateDXGIFactory2 で DXGIオブジェクトを作成するなどの DirectX 関連の初期化処理を組むことが出来るわけですが、
そこから更に Direct3D11 の初期化が始まり、頂点バッファの初期化、頂点シェーダー・ピクセルシェーダーの初期化などなど
ウィンドウの中心に白い四角形を描画するプログラムを作成するだけで最低でも数百行のプログラムを組む必要がありますが、
ＤＸライブラリを使用する場合は 10行ほどで同じ動作をするプログラムを組むことが出来ます


>　Tirさん

お久しぶりです

DXArchive はエンコーダーと共にデコーダーも配布しているので、パスワードさえ分かれば簡単にアーカイブの中身を
見れてしまうという弱点があります
パスワードはプログラムの中に直接書かれていたり、仮にプログラムの中に書かれていなくても何らかの経緯を経て
アーカイブを開く際に生の文字列の状態になって使用されるので、実行時のメモリ解析などを行える技術のある人に掛かれば
容易にパスワードを知ることができてしまうのかもしれません( 実際にそのような技術を持った方と知り合いだったりはしないので
本当のところはどうなのか不明ですが… )

プログラムの中に埋め込まれたパスワードを抜き出す事ができるような技術のある方であれば、同様にプログラムの中で
データの暗号化を解除している処理も解析することが出来ると思いますので( アセンブリ言語の知識のある人であれば
実行ファイルのバイナリを逆アセンブルしてアセンブリコードからどのような暗号処理が行われているかを知ることが出来ます )、
手元で暗号化されたファイルを解除するプログラムを組んでしまえば、暗号化される前のファイルを手に入れられてしまうという訳です…

私が関わった ASTLIBRA Revision も同様にパスワード付き DXArchive を使用して、且つパスワードを生文字列ではなく
ビット反転やビットシフトをした状態でプログラムに書き込んでおいたりしましたが、リリース後数日で中のファイルの一覧の
スクリーンショットがツイートされていました

ただ、画像ファイルは独自の可逆圧縮形式にしていたのですが、それは破られる( bmp や png などの一般的な
画像形式に変換される )ことはありませんでした

暗号化したパスワードを抜き出せる技術のある人なら同様に独自画像形式から通常画像への変換もできてしまいそうなものですが…
ハッキング技術には疎いので何故画像抜き出しは出来なかったのかは不明です…

因みに、定期的に『このソフトは◯◯社の最新暗号化技術を使用しました、なのでこのソフトを不届き者がクラックして
タダでプレイするということは絶対にできません』と豪語してリリースされたソフトが1週間もしない内にクラックされて
ネット上に違法配布される、ということが起きていますので
一般的なPCソフトで不正解析されないようにするというのはほぼ不可能だと考えたほうが良さそうです… (- -;;
( PCソフトは家庭用ゲーム機用ソフトよりも解析されやすいので、解析される可能性を下げるためにPCには絶対リリースしない
　と決めているゲーム会社もあるようです )

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