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

<管理人>
ご返信は一週間に一度、土日のどちらかで行います。平日は時間に余裕があるときだけご返信します。

[5084] ワールド->ローカル返還について 投稿者:名無三 投稿日:2019/12/15(Sun) 01:04 [返信]
タイトルの通りです。モデルのフレーム座標のMatrixからMV1SetMatrixで指定したMatrixを引けば ローカル座標が出てくるという認識で正しいでしょうか?

[5083] Kasperskyによるマルウェア検出について 投稿者:yrt 投稿日:2019/12/14(Sat) 14:02 [返信]
すみません、当サイトよりダウンロードした「DXライブラリ Windows版 VisualStudio( C++ )用(Ver3.21b)」 からカスペルスキーがマルウェアを検出しました。 マルウェアと判定されたのは DxLib_VC\Tool\ConvertImageToPMAImage\ConvertImageToPMAImage.exeで 検体オブジェクト名は「VHO:Hoax.Win32.ArchSMS.gen」でした。 こちらはセキュリティソフトの誤検出でしょうか? また、このファイルが削除されたことによってDXライブラリ使用上支障などを生じることはありますか? ご返信よろしくお願いいたします。

[5082] ご返信 投稿者:管理人 投稿日:2019/12/07(Sat) 01:26 [返信]
> にこようさん > すみません、サウンド関係のの構造体に音量の変数を設定するような処理かなと思っていたのですが、 > そんな単純なわけではないのですね はい、非同期読み込み処理中は非同期読み込み処理以外のスレッドからデータが書き換えられることが無いことを 前提とした処理を組んでいるので、そのルールを破るとなるとそれなりに手を加える必要が発生してしまいます… (- -;;

[5081] Re:[5080] ご返信 投稿者:にこよう 投稿日:2019/12/06(Fri) 03:08 [返信]
御返信ありがとうございますm(__)m >すみません、非同期読み込み処理の仕組みの関係上、対応には結構な改造が必要になるので難しいです すみません、サウンド関係のの構造体に音量の変数を設定するような処理かなと思っていたのですが、 そんな単純なわけではないのですね

[5080] ご返信 投稿者:管理人 投稿日:2019/12/06(Fri) 01:24 [返信]
> にこようさん > 普段、掲示板の方で頂いたDxlib_testの方を使用してソフトをコンパイルしているのですが、 > 公式アップデート版と何か差はありますでしょうか? 特に差はありません Dxlib_testの更新内容が大分溜まってきたタイミングで公式アップデート版として リリースしているだけですので… > ソフトの配布を考えているのですが、Dxlib_testを利用した物を配布しても問題はありませんか? はい、問題ありません > また、ChangeVolumeSoundMemの関数で非同期読み込み時に音量を指定する場合は、 > 読み込みが完了していない状態では登録できないと思いますが、 > 仮に帰ってきたサウンドハンドルを指定して音量を設定できるようにできませんか? すみません、非同期読み込み処理の仕組みの関係上、対応には結構な改造が必要になるので難しいです

[5079] ChangeVolumeSoundMemについて 投稿者:にこよう 投稿日:2019/12/05(Thu) 23:51 [返信]
また、ChangeVolumeSoundMemの関数で非同期読み込み時に音量を指定する場合は、 読み込みが完了していない状態では登録できないと思いますが、 仮に帰ってきたサウンドハンドルを指定して音量を設定できるようにできませんか? 些細なことではあるのですが、 ファイルから初期化データを読み取り〜音源ファイル読み込み〜読み込み完了を待って音量をそれぞれ登録 という処理をしているのですが、他の初期化と同時に(音源の読み込み)に登録できればわかりやすくなるので...

[5078] test版について 投稿者:にこよう 投稿日:2019/12/05(Thu) 18:07 [返信]
こんにちは、いつもお世話になっております 普段、掲示板の方で頂いたDxlib_testの方を使用してソフトをコンパイルしているのですが、 公式アップデート版と何か差はありますでしょうか? ソフトの配布を考えているのですが、Dxlib_testを利用した物を配布しても問題はありませんか?

[5077] ご返信 投稿者:管理人 投稿日:2019/11/23(Sat) 03:30 [返信]
> 焼肉さん ご情報ありがとうございます m(_ _)m XCode に Compress されたPNGも正常に読み込めれば一番良いのですが…ちょっと難しそうです…

[5076] 無題 投稿者:焼肉 投稿日:2019/11/20(Wed) 21:22 [返信]
いつも楽しく使わせて頂いております。 自分はiosでSpriteStudioを使わせて頂いて頂いております。 その中で解決済みではあるものの、詰まった所がありましたのでここで共有させて頂ければと思い書き込ませて頂きます。 dxlib.xsrv.jp/cgi/patiobbs/patio.cgi?mode=view&no=4475&p=2 ↑のトピックをiosでやった所SpriteStudioファイルのpngファイルが読み込めない状態になりました。 解決方法としては、XCode上のBuildSettingから 『Compress PNG Files -Packazing』項目の中の『Compress PNG Files』と『Remove Text Metadata from PNG Files』の項目両方を『NO』に変える事で正常に読み込むことが出来ました。 もし、同じように困った方の一助になれば幸いです。

[5075] ご返信 投稿者:管理人 投稿日:2019/11/12(Tue) 01:21 [返信]
> was-blue.0793さん なんと、カレンダーが埋まらないと悲しい雰囲気になってしまう Advent Calendar ではないですか 去年の状況をご存じの上で今年も立ち上げられるとはなかなかのチャレンジャーですね (・・;; 私も寄稿しようかと思ったのですが、一度寄稿すると多分毎年11月と12月は Advent Calendar の 記事を書くことだけで終わってしまうようになることが容易に想像できたので、控えることにしました… m(- -;m ( 典型的な『一度始めるとなかなか止めることができない』類の人間なので… ) > dnjiroさん Advent Calendar も 12月6日にエントリーされているので一瞬混乱しましたが、 大阪で開催される勉強会に登壇されるのですね…!

[5074] MOBILE ACT OSAKA #12 で DXライブラリの紹介をします 投稿者:dnjiro 投稿日:2019/11/11(Mon) 14:28 [返信]
MOBILE ACT OSAKA #12 (2019.12.6 グランフロント大阪)で、DXライブラリを使ってアプリ9VAeをつくった話をします。 資料はこちら qiita.com/danjiro/items/b43c8e21e38e88a3ff00

[5073] QiitaにDxLib Advent Calendarを立ち上げました 投稿者:was-blue.0793 投稿日:2019/11/06(Wed) 22:14 [返信]
昨年はがっちょさんが立ち上げておりましたが、今年は僭越ながら私がDxLib Advent Calendarを立ち上げさせていただきました。 今年も来年もDXライブラリを盛り上げていきたい所存ですので、よろしくお願いします! qiita.com/advent-calendar/2019/dxlib

[5072] Re:[5071] ご返信 投稿者:名無三 投稿日:2019/10/24(Thu) 20:48 [返信]
拡大治りました! ありがとうございます!

[5071] ご返信 投稿者:管理人 投稿日:2019/10/24(Thu) 01:35 [返信]
> 名無三さん スクリーンショットのアップありがとうございます 全然結果が異なりますね… そして、すみません、手元の環境でも同様の現象を再現できました 最新版で確認していると思っていたのですが、古いバージョンのままで確認していたという凡ミスでした orz 異常に拡大されてしまうバグを修正したバージョンをアップしましたので、よろしければお試しください m(_ _;m https://dxlib.xsrv.jp/temp/DxLibVCTest.zip // Windows版 VisualC++ 用 https://dxlib.xsrv.jp/temp/DxLibBCCTest.zip // Windows版 BorlandC++ 用 https://dxlib.xsrv.jp/temp/DxLibBCC2Test.zip // Windows版 C++ Builder 10.3 用 https://dxlib.xsrv.jp/temp/DxLibGCC_MinGWTest.zip // Windows版 MinGW 用 https://dxlib.xsrv.jp/temp/DxLibDotNet.zip // Windows版 .NET用 https://dxlib.xsrv.jp/temp/DxLibMakeTest.zip // ソース (中身を既存のライブラリのファイルに上書きして『リビルド』をして下さい)

[5070] 無題 投稿者:名無三 投稿日:2019/10/23(Wed) 06:02 [返信]
d.kuku.lu/da3c1a882 スクショです。どちらもDXLibの更新とリビルド以外の変更はありません

[5069] ご返信 投稿者:管理人 投稿日:2019/10/23(Wed) 01:46 [返信]
> 名無三さん > 今度はpmxモデルが歪に拡大されてしまいました… > (元モデルから、身長が1.65になるようリサイズしています。) 具体的にはどのような見た目になってしまっているのでしょうか? 手元で MV1SetScale( ModelHandle, VGet( 100.0f, 100.0f, 100.0f ) ); を実行して表示してみましたが、 特に違和感は感じませんでした… あと、本日も少しプログラムに手を加えて暫定最新版を更新しましたので、(3D関係には変更を加えていない筈なので)可能性は低いですが もしかしたらこちらのバージョンでは正常に表示されるかもしれません 何度も申し訳ありませんがよろしければお試しください m(_ _;m https://dxlib.xsrv.jp/temp/DxLibVCTest.zip // Windows版 VisualC++ 用 https://dxlib.xsrv.jp/temp/DxLibBCCTest.zip // Windows版 BorlandC++ 用 https://dxlib.xsrv.jp/temp/DxLibBCC2Test.zip // Windows版 C++ Builder 10.3 用 https://dxlib.xsrv.jp/temp/DxLibGCC_MinGWTest.zip // Windows版 MinGW 用 https://dxlib.xsrv.jp/temp/DxLibDotNet.zip // Windows版 .NET用 https://dxlib.xsrv.jp/temp/DxLibMakeTest.zip // ソース (中身を既存のライブラリのファイルに上書きして『リビルド』をして下さい)

[5068] Re:[5067] ご返信 投稿者:名無三 投稿日:2019/10/22(Tue) 13:17 [返信]
テストバージョンにてGraphfilterの動作を確認できましたが、今度はpmxモデルが歪に 拡大されてしまいました… 使用しているのは先述の drive.google.com/file/d/1wvBZkMRh5HanwPTDTj54v1KmWOczzkPl/view?usp=sharing にてdata/chara/~の先に入っているものです。 (元モデルから、身長が1.65になるようリサイズしています。)

[5067] ご返信 投稿者:管理人 投稿日:2019/10/22(Tue) 06:15 [返信]
> 名無三さん ご報告ありがとうございます > 最近気が付いたのですが、Direct3Dを11にしたところ、 > ・GraphFilterが無効 > ・DrawBillboard3Dにfogが効かない > ようです。 すみません、Direct3D 11 では DrawBillboard3D にfogが効かないのは仕様となります m(_ _;m ( なのでフォグに関しては Direct3D 9, 9EX の方が高機能です… ) GraphFilter については、手元の環境では Direct3D 11 で正常に動作しているようです もしお使いのバージョンが最新版ではありませんでしたら、最新版では正常に機能するかもしれませんので よろしければこちらの暫定最新版をお試しになってみてください m(_ _)m https://dxlib.xsrv.jp/temp/DxLibVCTest.zip // Windows版 VisualC++ 用 https://dxlib.xsrv.jp/temp/DxLibBCCTest.zip // Windows版 BorlandC++ 用 https://dxlib.xsrv.jp/temp/DxLibBCC2Test.zip // Windows版 C++ Builder 10.3 用 https://dxlib.xsrv.jp/temp/DxLibGCC_MinGWTest.zip // Windows版 MinGW 用 https://dxlib.xsrv.jp/temp/DxLibDotNet.zip // Windows版 .NET用 https://dxlib.xsrv.jp/temp/DxLibMakeTest.zip // ソース (中身を既存のライブラリのファイルに上書きして『リビルド』をして下さい)

[5066] 無題 投稿者:名無三 投稿日:2019/10/21(Mon) 22:29 [返信]
返答遅れましてすいません、解決しました。ありがとうございます。 最近気が付いたのですが、Direct3Dを11にしたところ、 ・GraphFilterが無効 ・DrawBillboard3Dにfogが効かない ようです。 9または9EXでは動作するのですが、気になったので報告です。

[5065] ご返信 投稿者:管理人 投稿日:2019/10/20(Sun) 04:49 [返信]
> スーパー初心者さん > 逆に言えば、SetDrawAreaで描画範囲を限定した場合も同じことが言えるのでしょうか? はい、同じことが言えます > DrawGraphの場合は、SetDrawArea範囲外の描画は行われず、DrawExtendGraph や DrawRotaGraphの場合は > SetDrawAreaを指定したとしても、表示はされないけど、描画はされているという認識で > 合っていますか? はい、合っています 画面外への描画と同じく DrawExtendGraph や DrawRotaGraph で SetDrawArea の外に描画されたものは 実際に描画された場合程ではありませんが処理負荷は0ではありません

[5064] ご返信 投稿者:スーパー初心者 投稿日:2019/10/19(Sat) 04:28 [返信]
> にこようさん 検証結果の報告、ありがとうございます! 私の先入観で、大きい画像を描画する=処理負荷が高いと思い込んでいましたが 気にする必要なかったんですね。 今のPCの場合はどちらにせよ、そこまで処理の早さは変わらないと思っていて 試していませんでしたが、たとえばファ○ナルファイトの様なベルトスクロールアクションで 画面遷移が発生しない前提でスクロールした場合は流石に処理負荷が高いだろうと思ったものの そんな長大な画像を用意するのが大変だったので、先に質問しましたが結果として良かったです。 > 管理人さん DrawGraphが画面内しか描画しないため処理負荷が低いというのを初めて知りました! 逆に言えば、SetDrawAreaで描画範囲を限定した場合も同じことが言えるのでしょうか? DrawGraphの場合は、SetDrawArea範囲外の描画は行われず、DrawExtendGraph や DrawRotaGraphの場合は SetDrawAreaを指定したとしても、表示はされないけど、描画はされているという認識で 合っていますか? 以上の事実を踏まえると、RPGなどでチップ単位でマップスクロールを行うのは 画像の大きさよりも、チップ情報を格納する配列の大きさを制限する目的の方が強そうですね。

[5063] ご返信 投稿者:管理人 投稿日:2019/10/19(Sat) 02:37 [返信]
> スーパー初心者さん にこようさんが計測された処理時間が示しています通り DrawGraph は画面内にある画像部分のみ 描画するようになっていますので、DrawGraph で描画する限りは画像が大きくても問題ありません ただ、DrawExtendGraph や DrawRotaGraph などで描画する場合は画面の外側の部分も( 画面内に 描画した場合よりは負荷は低いですが )描画処理が行われてしまうので、あんまり大きな画像を 描画するような場合はスーパー初心者さんが仰られている通り LoadDivGraph を使用して分割した グラフィックハンドルを画面内に入っている分だけ描画するようにして処理負荷を抑えた方が良いです ( 最近のPCであればゲーミングPCなどでなくても1920x1080を4画面分くらいなら大丈夫だと思いますが、 前景と背景でスクロール速度を変えるなどの目的で何回も大きな画像を描画する場合は処理負荷を 下げる工夫をした方が良いと思います )

[5062] >画面のスクロールについて 投稿者:にこよう 投稿日:2019/10/18(Fri) 20:16 [返信]
> スーパー初心者さん こんにちは 管理人さんではありませんが、(私のPCで)1920xの画像を画面外に3枚描画した時の処理の時間は 0.01ミリ秒程度だったと記憶してます(この精度の時間を正確に測れているのかはわかりませんが) 気にする必要はないのではないでしょうか?

[5061] 画面のスクロールについて 投稿者:スーパー初心者 投稿日:2019/10/18(Fri) 10:13 [返信]
いつもお世話になります。 表題の件に関してなのですが、スクロール方法は色々手法があると思うのですが 例えば格闘ゲームなんかの場合、背景画像にかなり大きいサイズの画像を 使っていると思うんですよね。 例として画面サイズが640*480の場合で、背景画像のサイズが横に画面3つ分、縦に2つ分として 640 * 3 = 1920 480 * 2 = 960 の大きい画像が必要になります。(大雑把ですが・・・ RPGみたいなマップチップを並べて描画する場合だと、スクロールも範囲外に1チップ分 描画するだけで、そこまでコストパフォーマンス的には問題なさそうだと思うのですが 格闘ゲームの様な一枚絵の大きい背景画像をスクロールする場合、どうしているのかなーと 思い、質問した次第です。 単純に考えると・・・ LoadGraph()で背景画像の画像ハンドルを取得し、移動分のxとyを制御してDrawGraph()で 描画するだけ・・・と、なりますがこの方法だと画面外についても当然描画されていると 思うので、その分コストがかかるんじゃないかなぁと思った次第です。 一応自分の考えた解決方法としては、背景画像は画面サイズの倍数分のサイズを前提として LoadDivGraph()で、分割して読込み、描画範囲外にある画像ハンドルは描画対象にしない くらいしか思いつかないです・・・。 これでも斜めにジャンプした場合なんかは、自画面を含む最大4画面分は 描画されてしまいますよね。あ、でも分割単位を半分、もしくは4分の1とかにすれば もう少し細かい制御ができそうですね。 以上を踏まえて質問事項をまとめると・・・ ・今のPCはスペックが高いのでそこまで気にする必要はないのでしょうか? ・やはり気にする必要があるなら、どの様な解決方法があるのでしょうか? 相変わらずフワッとした質問で申し訳ありません・・・。

[5060] Re:[5059] ご返信 投稿者:korio 投稿日:2019/10/07(Mon) 11:01 [返信]
お早いご対応ありがとうございます こちらの環境でも正常動作を確認できました。

[5059] ご返信 投稿者:管理人 投稿日:2019/10/07(Mon) 01:33 [返信]
> korioさん 再現用のコードを載せていただきありがとうございます ご指摘の通り GetInputChar のプログラムにバグがあり、バッファに存在する最後の文字しか取得できないようになっていました 載せていただいたプログラムでアプリケーション起動後から61フレーム目までに入力された文字を全て取得できるように 修正したバージョンをアップしましたので、よろしければお試しください m(_ _;m https://dxlib.xsrv.jp/temp/DxLibVCTest.zip // Windows版 VisualC++ 用 https://dxlib.xsrv.jp/temp/DxLibBCCTest.zip // Windows版 BorlandC++ 用 https://dxlib.xsrv.jp/temp/DxLibBCC2Test.zip // Windows版 C++ Builder 10.3 用 https://dxlib.xsrv.jp/temp/DxLibGCC_MinGWTest.zip // Windows版 MinGW 用 https://dxlib.xsrv.jp/temp/DxLibDotNet.zip // Windows版 .NET用 https://dxlib.xsrv.jp/temp/DxLibMakeTest.zip // ソース (中身を既存のライブラリのファイルに上書きして『リビルド』をして下さい)

[5058] GetInputChar関数が期待した動作をしない 投稿者:korio 投稿日:2019/10/06(Sun) 21:35 [返信]
お世話になっております ユーザーが入力した文字列を受け取る処理を、GetInputChar関数を利用して実装しているのですが、 GetInputChar関数のバッファに不具合があるように思ったので、ご対応お願いします 概要   アプリケーション起動後、61フレーム目以降で毎フレームGetInputChar関数を利用して入力を   string型の変数に追加する   画面にはフレームカウントと入力を受け取った文字列を表示する 問題点   0〜61フレームまでの入力も61フレーム目でバッファからすべて取得できることを期待   しているが、61フレーム目以前の入力の最後の1文字しか取得できない   DxLib3.21(DxLibNoneSoftDrawCode_VC)、DxLib3.21a(DxLibMake)を使用して   Visual Studio 2019で確認しました 以下ソースコードです(cpp) #include<string> #include "DxLib.h" int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { ChangeWindowMode(1); if (DxLib_Init() < 0) { return -1; } int cnt = 0; std::string s; while (ProcessMessage() != -1) { SetDrawScreen(DX_SCREEN_BACK); ClearDrawScreen(); if (cnt > 60) while (1) { char c = GetInputChar(1); if (c == 0) { break; } // 文字コード if (c >= CTRL_CODE_CMP) { char str[2] = { ' ', '\0', }; str[0] = c; s.push_back(c); } } ++cnt; DrawString(10, 10, std::to_string(cnt).c_str(), GetColor(255, 255, 96)); DrawString(10, 32, s.c_str(), GetColor(255, 255, 96)); ScreenFlip(); } // DXライブラリの後始末 DxLib_End(); // ソフトの終了 return 0; }

[5056] ご返信 投稿者:管理人 投稿日:2019/10/02(Wed) 23:21 [返信]
> スーパー初心者さん > これによってシーンクラスを削除しているのはなんとなくわかるものの、上記の処理を行った > 時点で、自動的にそのシーンで読み込んだメモリにある画像やサウンドなどの諸々も > 削除されるのでしょうか? いえ、削除されません > それとも、delete ActiveSceneが実行された際に、デストラクタが呼ばれて > そのデストラクタ内にDeleteGraphの様な各種リソース解放処理を書く想定でしょうか? はい、その想定です ( C++版の関数を呼び出せるようにしただけなのがC#版なので… )

[5055] リソースの解放について 投稿者:スーパー初心者 投稿日:2019/10/02(Wed) 21:29 [返信]
度々お世話になります。 先の質問への回答で思い出したのですが DXライブラリで各種ハンドルを取得した場合に、それを削除する処理として DeleteGraphの様な各種削除処理があったと思いますがC++についてあまり詳しくないので 質問させていただきます。 > if( ActiveScene != NULL ) delete ActiveScene; // 今までのシーンクラスを削除 これによってシーンクラスを削除しているのはなんとなくわかるものの、上記の処理を行った 時点で、自動的にそのシーンで読み込んだメモリにある画像やサウンドなどの諸々も 削除されるのでしょうか? それとも、delete ActiveSceneが実行された際に、デストラクタが呼ばれて そのデストラクタ内にDeleteGraphの様な各種リソース解放処理を書く想定でしょうか? というのも、C#はC++と違って、クラス等のメモリの解放はガベージコレクションという 機構が巡回して勝手に行うので明示的にしなくていい(というか、明示的にできない)という 特徴があるのですが、リソースの解放については話は別でテキストファイルなどを読み込んだ際に 能動的にリソースの解放を行う必要があるものについてはIDisposableインターフェースを 実装したDisposeメソッドを呼び出すことでリソースの解放を行ったりします。 毎度リソースを能動的に解放しないとダメなのであれば、各種ハンドルの種類とハンドルを 退避しておく機構が必要になると思ったので質問させていただきました。

[5054] Re:[5053] ご返信 投稿者:スーパー初心者 投稿日:2019/10/01(Tue) 15:31 [返信]
時間がなくてお返事が遅くなって申し訳ありません! わざわざサンプル第二弾を作って頂きありがとうございます! >ちゃんとしたプログラムになってくると そうです、このちゃんとしたプログラムというのを知りたかったんですよね。 今組んでるゲームをそのちゃんとしたプログラムに書き換えようと思っていたんですが あまり時間が取れず、検証できずじまいでした・・・。 抽象クラスを作ってみたり、デリゲート(C++ではコールバック関数?)でシーンの プログラムに相当する部分を作ってみようかと、色々考えてはいるのですが まだ試せていないです・・・。 >( そして機能の追加を繰り返していくうちに基底クラスが巨大なクラスに… ) この辺りはやっているとどうしてもそうなっていきますよねw フェードインとフェードアウトも別に今のままでもいいんですが、今のゲーム作成の目的が ゲームを完成させることではなく、比較的簡単なゲームを作る上で今後のゲーム作りに 何が必要かを見極めるのが主なんですよね。 その過程で、必要そうなら独自の共通部品を作成したりしているので フェードイン、フェードアウトもその一環になります。 ただ・・・気づくのが遅すぎたので、Sceneクラスを作って乗せかえる作業が必要ですが・・・。 個人的な理想としては、描画や画面切り替え等はなるべく個別実装せずに共通で行えるようにして それに影響を受けることな純粋なゲーム部分の実装を分けたいと思っています。 つまり、main関数内で直接状態遷移したり、ゲーム部分の実装をするようなことはなるべくなら したくないというのが本音なんですが・・・世の中のサンプルはあまりそういう作りに なっていないので、サンプル探しからして色々と難儀する状態で困っていました。 今回どういう作りにするかを悩んでいてフワッとした質問になってしまいましたが こちらの意図を正確に汲んでくださって感謝しています。

記事No 削除キー

- Aska BBS -