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

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

[5022] 無題 投稿者:Effekseer 投稿日:2019/07/16(Tue) 01:14 [返信]
管理人様 わざわざありがとうございます。 Effekseerです。 引き続き調査はしてみますが、 もうそろそろDirectX11を勧めてもいいのでは、とは思いました。

[5021] Re:[5020] MV1DrawModelとDrawCapsule3DのDirectX9版について 投稿者:管理人 投稿日:2019/07/15(Mon) 23:57 [返信]
MV1DrawModel による3Dモデル描画と2D描画はかなり毛色が違う関係でステートを独立して持っているので、特定が難しいですね… 一番の違いは DrawCapsule3D では頂点バッファ・インデックスバッファ・頂点シェーダー・ピクセルシェーダーを使用していないということです あと、シェーダーを使用していない関係で、SetVertexDeclaration の代わりに SetFVF で頂点フォーマットを設定しています あとは SetRenderState の D3DRS_DIFFUSEMATERIALSOURCE と D3DRS_SPECULARMATERIALSOURCE が D3DMCS_MATERIAL ではなく D3DMCS_COLOR1 となっている、とかでしょうか… それ以外は、MV1DrawModel との違いは以下の通りです( 網羅できているか分かりませんが… ) D3DRS_ZENABLE, D3DRS_ZWRITEENABLE, D3DRS_ZFUNC, D3DRS_DEPTHBIAS などのZバッファ系の設定がMV1DrawModelと2D描画で違う可能性がある D3DRS_SRCBLEND, D3DRS_DESTBLEND, D3DRS_BLENDOP, D3DRS_ALPHABLENDENABLE, D3DRS_ALPHATESTENABLE, D3DRS_ALPHAREF, D3DRS_ALPHAFUNC D3DRS_SEPARATEALPHABLENDENABLE, D3DRS_SRCBLENDALPHA, D3DRS_DESTBLENDALPHA, D3DRS_BLENDOPALPHA 辺りのブレンド系の設定がMV1DrawModelと2D描画で違う可能性がある D3DRS_TEXTUREFACTOR, D3DTSS_TEXCOORDINDEX, D3DTSS_RESULTARG, D3DTSS_ALPHAOP, D3DTSS_ALPHAARG1, D3DTSS_ALPHAARG2, D3DTSS_COLOROP, D3DTSS_COLORARG1, D3DTSS_COLORARG2 辺りのテクスチャステージステート系がMV1DrawModelと2D描画で違う ( MV1DrawModel = テクスチャステージはテクスチャを設定するだけ 2D描画 = ピクセルシェーダーを使っていないのでテクスチャステージの設定でピクセルシェーダーの代わりとなる処理を行っている ) D3DSAMP_ADDRESSU, D3DSAMP_ADDRESSV のテクスチャアドレス系が違う( MV1DrawModel = WRAP DrawCapsule3D = CLAMP )

[5020] MV1DrawModelとDrawCapsule3DのDirectX9版について 投稿者:Effekseer 投稿日:2019/07/15(Mon) 16:32 [返信]
いつもお手数をおかけしています。 Effekseerです。 今回はどちらかというとEffekseer側の不具合の相談です。 DirectX9版にて MV1DrawModel // mqoの描画 DrawCapsule3D RenderVertex Effekseerの描画処理 という順番で描画を行うとエフェクトが描画されるのですが MV1DrawModel // mqoの描画 // DrawCapsule3D RenderVertex Effekseerの描画処理 とするとエフェクトが描画されなくなる状況です。 おそらくMV1DrawModelで何らかのステートを変更し、DrawCapsule3Dでその変更が 元に戻っていると考えているのですが、DirectX9のデバッグ環境が既に用意するのが辛く、 調査が難航している状況です。 もし、MV1DrawModelとDrawCapsule3Dでステート回りが異なる部分の候補等、 思いつくところがありましたら教えていただけないでしょうか? よろしくお願いします。

[5019] Re:[5018] [5017] GraphBlendで何も描画されない 投稿者:アチコッタ 投稿日:2019/07/04(Thu) 01:49 [返信]
GraphBlendが正常に動作したことを確認しました。 お手数をおかけしてすみません。ご対応本当にありがとうございました。 素晴らしいゲームライブラリを使わせていただきありがとうございます。 > 画面モード切替は正常に動作したようで何よりです > > > 下記の修正されたライブラリを自分のゲームのほうに組み込んでみたところ、 > > 画面モード切替時の挙動は正常に動作しましたが、GraphBlendで何も描画されてなくなってしまいました。 > > すみません、別件の対応で行った変更が原因で GraphFilter や GraphBlend が正常に動作しない状態になっていました > > 修正版をアップしましたので、よろしければお試しください m(_ _;m

[5018] Re:[5017] GraphBlendで何も描画されない 投稿者:管理人 投稿日:2019/07/04(Thu) 00:29 [返信]
画面モード切替は正常に動作したようで何よりです > 下記の修正されたライブラリを自分のゲームのほうに組み込んでみたところ、 > 画面モード切替時の挙動は正常に動作しましたが、GraphBlendで何も描画されてなくなってしまいました。 すみません、別件の対応で行った変更が原因で GraphFilter や GraphBlend が正常に動作しない状態になっていました 修正版をアップしましたので、よろしければお試しください 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.2 用 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 // ソース (中身を既存のライブラリのファイルに上書きして『リビルド』をして下さい)

[5017] GraphBlendで何も描画されない 投稿者:アチコッタ 投稿日:2019/07/03(Wed) 17:43 [返信]
こんにちは。アチコッタと申します。 Effekseer様にデバイスロストのことで相談させてもらってました。 管理人様、Effekseer様、ご対応していただき本当にありがとうございます。 下記の修正されたライブラリを自分のゲームのほうに組み込んでみたところ、 画面モード切替時の挙動は正常に動作しましたが、GraphBlendで何も描画されてなくなってしまいました。 GraphBlendのサンプルを動かしてみても同じ現象が出ました。(描画されないというより、クリアされている?) お時間があるときで大丈夫ですので、一度確認していただいてもよろしいでしょうか。 お手数をおかけしてすみません。

[5016] Re:[5015] [5014] [5013] [5012] デバイスロストの挙動について 投稿者:Effekseer 投稿日:2019/07/03(Wed) 00:05 [返信]
ありがとうございます。 これで正常に動作するようになりそうです。 > IDXGISwapChain を作り直すようにしたらフルスクリーン状態での解像度変更も正常に動作するようになりました > > というわけで何とか『SetChangeScreenModeGraphicsSystemResetFlag に False を指定した場合に限りデバイスを解放しない』 > 状態のものができましたので、よろしければお試しください 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.2 用 > 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 // ソース > (中身を既存のライブラリのファイルに上書きして『リビルド』をして下さい)

[5015] Re:[5014] [5013] [5012] デバイスロストの挙動について 投稿者:管理人 投稿日:2019/07/02(Tue) 00:38 [返信]
IDXGISwapChain を作り直すようにしたらフルスクリーン状態での解像度変更も正常に動作するようになりました というわけで何とか『SetChangeScreenModeGraphicsSystemResetFlag に False を指定した場合に限りデバイスを解放しない』 状態のものができましたので、よろしければお試しください 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.2 用 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 // ソース (中身を既存のライブラリのファイルに上書きして『リビルド』をして下さい)

[5014] Re:[5013] [5012] デバイスロストの挙動について 投稿者:Effekseer 投稿日:2019/07/01(Mon) 09:30 [返信]
返答ありがとうございます。 確かにフルスクリーン状態での解像度変更は試したことがなかったです。 軽く調べた限り情報もないようです。 こちらでも簡単にデバイスの破棄に対応できないか検討してみます。 フルスクリーンモードでの解像度切り替えの方法がわかりましたら伝えます。 > > DirectX11自体にはデバイスロストが存在せず、デバイスロストは起きないと考えていたのですが、 > > DXライブラリはスクリーンモードを変更した際にリセットが行われる、いるような挙動になってるのですが > > この認識は正しいでしょうか? > > はい、DirectX 7 時代に画面モード切り替わり時にはデバイス等は全て作成し直すようにして、 > Direct3D 9 では Reset を呼べばOK、と謳われながら、実際には Reset が正常に動作しないことがある > ということで結局 Direct3D 7 と同様の再作成方式にしたことがあったので、 > Direct3D 10 以降の『デバイスロストしないので各種オブジェクトを作り直す必要が無い』も > 怪しんでしまい『作り直すのが確実だ』と考え Direct3D 7 時代と同じく作り直すようにしています > > > もし、そうでしたら、一切リセットを行わないフラグを追加することはお願いできないでしょうか? > > フラグが増えるのも分かりにくいので、SetChangeScreenModeGraphicsSystemResetFlag に False を > 指定した場合に限りデバイスを解放しない処理に変更しようとしてみたのですが、フルスクリーンモード状態での > 画面モードの変更で詰まりました… > > IDXGISwapChain の ResizeTarget や ResizeBuffers や SetFullscreenState を使用して > 変更しようとしたのですが、2回目以降正常に画面モードが切り替わらず… > ( フルスクリーンモードで起動 → フルスクリーン状態で画面解像度変更( 成功 ) → 更にフルスクリーンモードで画面解像度変更( 失敗 ) ) > > 次は IDXGISwapChain を再生し直す方法を試そうと思っていますが、もしフルスクリーンモードでの > 画面解像度変更の正しい方法をご存じでしたら教えていただけないでしょうか? m(_ _;m

[5013] Re:[5012] デバイスロストの挙動について 投稿者:管理人 投稿日:2019/07/01(Mon) 03:13 [返信]
> DirectX11自体にはデバイスロストが存在せず、デバイスロストは起きないと考えていたのですが、 > DXライブラリはスクリーンモードを変更した際にリセットが行われる、いるような挙動になってるのですが > この認識は正しいでしょうか? はい、DirectX 7 時代に画面モード切り替わり時にはデバイス等は全て作成し直すようにして、 Direct3D 9 では Reset を呼べばOK、と謳われながら、実際には Reset が正常に動作しないことがある ということで結局 Direct3D 7 と同様の再作成方式にしたことがあったので、 Direct3D 10 以降の『デバイスロストしないので各種オブジェクトを作り直す必要が無い』も 怪しんでしまい『作り直すのが確実だ』と考え Direct3D 7 時代と同じく作り直すようにしています > もし、そうでしたら、一切リセットを行わないフラグを追加することはお願いできないでしょうか? フラグが増えるのも分かりにくいので、SetChangeScreenModeGraphicsSystemResetFlag に False を 指定した場合に限りデバイスを解放しない処理に変更しようとしてみたのですが、フルスクリーンモード状態での 画面モードの変更で詰まりました… IDXGISwapChain の ResizeTarget や ResizeBuffers や SetFullscreenState を使用して 変更しようとしたのですが、2回目以降正常に画面モードが切り替わらず… ( フルスクリーンモードで起動 → フルスクリーン状態で画面解像度変更( 成功 ) → 更にフルスクリーンモードで画面解像度変更( 失敗 ) ) 次は IDXGISwapChain を再生し直す方法を試そうと思っていますが、もしフルスクリーンモードでの 画面解像度変更の正しい方法をご存じでしたら教えていただけないでしょうか? m(_ _;m

[5012] デバイスロストの挙動について 投稿者:Effekseer 投稿日:2019/06/29(Sat) 17:09 [返信]
いつもお手数をおかけしています。 Effekseerです。 デバイスロストに関する挙動について質問と要望です。 現在、EffekseerとDXライブラリのDirectX11のサポートを行っています。 DirectX11自体にはデバイスロストが存在せず、デバイスロストは起きないと考えていたのですが、 DXライブラリはスクリーンモードを変更した際にリセットが行われる、いるような挙動になってるのですが この認識は正しいでしょうか? SetChangeScreenModeGraphicsSystemResetFlagにFalseを指定しても同様に行われています。 もし、そうでしたら、一切リセットを行わないフラグを追加することはお願いできないでしょうか? というのも、DirectX11以降ではデバイスロストに関する処理を一切Effekseerでは実装していないためです。 何卒、よろしくお願いします。

[5011] Re:[5010] 無題 投稿者:sandbox 投稿日:2019/06/24(Mon) 23:10 [返信]
> vmd形式のアニメーションの仕方を教えてください まず、公式マニュアルの dxlib.xsrv.jp/function/dxfunc_3d_model_1.html#R4N1 の例題は試しましたか? これをビルド、実行できる状態になりましょう。 このサンプルでは DxChara.x を使用していますが、うまくいったら お好みの PMDやPMX、そして VMDを用意しましょう。やり方は dxlib.xsrv.jp/function/dxfunc_3d_model_0.html#R1N1 に書いてありますが xxxxx.pmx xxxxx000.vmd xxxxx001.vmd のようにファイルを用意しておき、DxChara.xのかわりにxxxxx.pmxを指定すると VMD付きで読み込んでくれます。 が、この方法では読み込み時間が非常に長いので、MV1形式に変換することをおすすめします。 (DxLib Model Viewerを使ってください。) あとはMV1系の関数のマニュアルを片っ端から読んだり実行してみてください。 とはいえ、PMD/PMXを動かすのはうまくいかないことの方が多いので、「うまくいったらラッキー」 くらいに思っていたほうがいいです。 それとも、VMDのファイルフォーマットを知りたい、という質問でしょうか? ネットにあるフォーマット情報は古く、終盤部分のデータ構造が抜けているものが多いのでご注意ください。

[5010] 無題 投稿者:アニメーションしたい 投稿日:2019/06/24(Mon) 20:28 [返信]
こんにちは vmd形式のアニメーションの仕方を教えてください お願いします

[5009] 無題 投稿者:名無三 投稿日:2019/05/15(Wed) 05:54 [返信]
mv1様 貴重なデータをありがとうございます。 管理人様 影の有無をグラフィック設定で追加することにします。 drive.google.com/file/d/1f8hPM0M8qevkK-Kl1Q_q1Sux8cmDg3lf/view?usp=sharing キャラモデルを艤装分軽いであろうお船のゲームのものに置換したところ、十分に60~70fpsが出ました。 改めて、今回もアドバイスありがとうございました。

[5008] ご返信 投稿者:管理人 投稿日:2019/05/15(Wed) 00:54 [返信]
> 名無三さん、.m1vさん おお、解決されている… .m1vさんご情報・ご対応ありがとうございます m(_ _)m pmxファイルは一般的に動画用の豪華な造りのモデルなので ゲーム用に作られる軽量なモデルよりはかなり処理負荷が高くなると思います あと、ShadowMapの処理は重いのでShadowMapの処理を行う対象を減らすだけでも結構軽くなるかもしれません

[5007] Re:[5006] 無題 投稿者:.m1v 投稿日:2019/05/14(Tue) 20:42 [返信]
念のためですが補足情報を書いておきます。 コメントNo.4994のソースを実行した結果ですが、会社の事務用PCでは54fps程度で、nowtime3と4、つまり ShadowMapにMV1を描くところで70fpsあたりまで落ちています。(Win7 x86 Corei3 チップセットVideo 1280x1024) 床部分を表示すると45fpsくらいまで落ちます。 ごっそりプログラムを削り、GetNowCount()の間を上から埋めていって都度fpsをチェックし、どこでがくっと 落ちるかを確認した結果は以下の通りです。 oldtimeとnowtimeのみ ⇒ 750fps nowtime1とnowtime2の間を追加 ⇒ 710fps nowtime2とnowtime3の間を追加 ⇒ 300fps <--- ここで半分以下 nowtime3とnowtime4の間を追加 ⇒ 70fps <--- ここで1/4以下! nowtime4とnowtime5の間を追加 ⇒ 69fps nowtime5とnowtime6の間を追加 ⇒ 54fps ※Corei7 GTX1060 1920x1080 Win10 x64のPCでは 520〜600fpsくらい出ます。

[5006] 無題 投稿者:名無三 投稿日:2019/05/14(Tue) 16:28 [返信]
PMX読み込んでいるところをコメントアウトしてみたら122fps出ました… 単純にポリゴン数で比較してはいけませんね、他モデルで試してみようと思います。 管理人様お手数をおかけしました。 mv1様、管理人様ありがとうございました。

[5005] Re:[5004] [5003] 無題 投稿者:名無三 投稿日:2019/05/14(Tue) 13:07 [返信]
> 要は「描くものがいっぱいなので重く、60fpsにならない」というシンプルな理由です。 drive.google.com/file/d/1N2pKyXQ-SYMGUPEU-QE7nki0qIBoYSYu/view?usp=drivesdk 前作では1〜6万ポリゴン前後の車両を10両+風景を描画しましたが、額面通りに計測結果が出ていました。 この差はなんでしょうか

[5004] Re:[5003] 無題 投稿者:.m1v 投稿日:2019/05/14(Tue) 10:10 [返信]
DxLibは描画命令を実行してもあとでまとめて実行される方式なので、描画命令を強制的に フラッシュさせないかぎり、その間の描画時間を測ってもあまり意味がありません(描画していないので) 例えばnowtime4と3の間は数ミリ秒しかかかっていませんが、強制描画させると15ミリ秒くらい かかっていると思います。 要は「描くものがいっぱいなので重く、60fpsにならない」というシンプルな理由です。 ScreenFlipが重いのはまとめ描画が(このソースでは)ここで実行されているからです。

[5003] 無題 投稿者:名無三 投稿日:2019/05/14(Tue) 05:14 [返信]
>管理人様 >fps HSPの仕様上awaitまたはwaitを0msでも挿入しておかないと、キー入力をした時点で応答無しになるので不可です。 あらかじめデバッグ画面を開いた状態で起動しても54fps以上は出ませんでした >MV1CollCheck_Line 必要な変数が増えていたんですね。きちんと動くようになりました、ありがとうございます! >モニター answers.microsoft.com/ja-jp/windows/forum/windows8_1-gaming/%E3%83%AA%E3%83%95%E3%83%AC%E3%83%83%E3%82%B7/a93bae4b-3691-41b3-a9e7-5931228151d2 こちらで40~55というワードが引っかかったからです。

[5002] ご返信 投稿者:管理人 投稿日:2019/05/14(Tue) 00:33 [返信]
> 名無三さん > 200~300でした。 > 今までも問題なかったので、今回追加した処理とHSPが合わなかったという結論…ですかね。 実際のプログラムの方では await 0;1000./frate で 60fps に保たれるようにウェイトを入れていますが、 こちらをコメントアウトしてもフレームレートが 54〜40 しか出ないのでしょうか? ( SetWaitVSyncFlag( FALSE ); を実行している場合、制限がなくなるので最近の PC では 200fps などになるのですが… ) > MV1CollCheck_Sphereの代用としてgame_mainの44行目から壁判定に使用しています… > が、1行書いて実行した時点で発症したので繰り返しなどは関係ないと思います。 原因かは分かりませんが、dim HitPoly,19 とされていますが、最新バージョンでは MV1_COLL_RESULT_POLY の メンバー変数が増え、容量は 100byte となっているので、dim HitPoly,25 としなければならないのではないかと思います よろしければ dim HitPoly,25 でお試しください m(_ _)m > 常時接続しているわけではないですが、60〜75Hzで動く1280×1080のモニターDsubで接続しています。 > MSのページでそれらしいものがあった為、念のためのご報告です。 接続した場合としない場合では何か動作結果が異なるのでしょうか…? 質問ばかりですみません…

[5001] 無題 投稿者:名無三 投稿日:2019/05/13(Mon) 17:20 [返信]
常時接続しているわけではないですが、60〜75Hzで動く1280×1080のモニターDsubで接続しています。 MSのページでそれらしいものがあった為、念のためのご報告です。

[5000] 無題 投稿者:名無三 投稿日:2019/05/13(Mon) 05:20 [返信]
#include "source/DxLib.as"//DXlib ; long Time = 0 ; // ウインドウモードで起動 ChangeWindowMode TRUE // VSYNC 待ちをしない SetWaitVSyncFlag FALSE // DXライブラリの初期化 DxLib_Init//DxLibの初期化 if stat = -1{dialog"エラー"} // 描画先を裏画面にする SetDrawScreen DX_SCREEN_BACK // メインループ while DX.ProcessMessage() == 0 // 画面のクリア ClearDrawScreen 0 // 処理時間の描画 DrawString 0, 0, strf("Time:%d",Time), GetColor( 255, 255, 255 ) Time = GetNowHiPerformanceCount() ; // 裏画面の内容を表画面に反映 ScreenFlip ; Time = GetNowHiPerformanceCount() - Time ; wend // DXライブラリの後始末 DxLib_End if stat = -1{dialog"エラー"} end 200~300でした。 今までも問題なかったので、今回追加した処理とHSPが合わなかったという結論…ですかね。 drive.google.com/file/d/13ACK2Uy-NzvAwzA7-hgZpFuLSff2M6fL/view?usp=sharing (暫定で3.18あたりにしています) MV1CollCheck_Sphereの代用としてgame_mainの44行目から壁判定に使用しています… が、1行書いて実行した時点で発症したので繰り返しなどは関係ないと思います。

[4999] ご返信 投稿者:管理人 投稿日:2019/05/13(Mon) 00:40 [返信]
> 名無三さん 手元で C# で以下のようなプログラムを組んで SetWaitVSync( FALSE ); を実行した状態で ScreenFlip の処理時間を計測してみたのですが、大体 0.2ms でした long Time = 0 ; // ウインドウモードで起動 DX.ChangeWindowMode( DX.TRUE ) ; // VSYNC 待ちをしない DX.SetWaitVSyncFlag( DX.FALSE ) ; // DXライブラリの初期化 if( DX.DxLib_Init() < 0 ) return ; // 描画先を裏画面にする DX.SetDrawScreen( DX.DX_SCREEN_BACK ) ; // メインループ while( DX.ProcessMessage() == 0 ) { // 画面のクリア DX.ClearDrawScreen() ; // 処理時間の描画 DX.DrawString( 0, 0, "Time:" + Time.ToString(), DX.GetColor( 255, 255, 255 ) ) ; Time = DX.GetNowHiPerformanceCount() ; // 裏画面の内容を表画面に反映 DX.ScreenFlip() ; Time = DX.GetNowHiPerformanceCount() - Time ; } // DXライブラリの後始末 DX.DxLib_End() ; よろしければ上記のプログラムと同様の処理を HSP で実行してみていただけないでしょうか? もしそれでも 16ms 掛かってしまうとしますと、申し訳ありませんが DxLib.dll 以外の HSP 関連の 何かの影響で 16ms になっている可能性があり、私の方ではどうしようもできない可能性が高いです > そして新たな質問なのですが、前回質問したMV1CollCheck_Line使用後に終了後…の件なのですが、 > 再燃しました。dxlib.asは最新です。 > それ以外の関数ではいまのところ発生していないです…(報告) HSP については全く知識が無いのでこちらもお力にはなれるか分かりませんが、とりあえず今回アップしていただいた プログラムでは MV1CollCheck_Line は使用されていないようですね… MV1CollCheck_Line を使用するようにされたものを拝見することはできますでしょうか?

[4998] 無題 投稿者:名無三 投稿日:2019/05/12(Sun) 07:44 [返信]
何度も失礼します、SetWaitVSyncFlag FALSEはしているのですが、 それでもScreenFlipで16ms取られてます…

[4997] 無題 投稿者:名無三 投稿日:2019/05/12(Sun) 07:35 [返信]
ごめんなさい書いてる途中で送信しました。質問ではないです。

[4996] 無題 投稿者:名無三 投稿日:2019/05/12(Sun) 07:29 [返信]
> 管理人様 なるほど、自動でしてくれるようになっているのですね。ありがとうございます。 そして新たな質問なのですが、前回質問したMV1CollCheck_Line使用後に終了後…の件なのですが、 再燃しました。dxlib.asは最新です。 それ以外の関数ではいまのところ発生していないです…(報告)

[4995] ご返信 投稿者:管理人 投稿日:2019/05/12(Sun) 02:43 [返信]
> 名無三さん ScreenFlip は内部で VSYNC 待ちを行っていますので、関数から出てくるまでの時間は処理に 余裕があればあるほど長くなります 表画面に直接描画する方法ですが、実は最近の DirectX では『表画面』という概念が無くなって しまっているので、表画面を描画対象にした場合はDXライブラリ内部で『裏画面に描画したものを 定期的に自動で ScreenFlip する』という処理が行われていて、『裏画面』に描画するよりも 動作が不安定になってしまいますので『表画面』への描画は行わないようにしてください m(_ _;m DxLib_Init を実行する前に SetWaitVSyncFlag( FALSE ); を実行すると VSYNC 待ちをしなく なりますのでフレームレートが改善されるかもしれません よろしければお試しください m(_ _)m

[4994] 無題 投稿者:名無三 投稿日:2019/05/11(Sat) 21:15 [返信]
またHSPから失礼します 8drive.google.com/file/d/1bW32X7xJ9ovFVYUCcjwWXwJ-110Q453r/view?usp=sharing (前回の反省から、.csを.asに変換するコードにより3.20c対応しました) 戦車の方がほぼ完成したので、FPSを製作しだしました。その際にフレームレートが54~40しか 出ない現象に遭遇しています。(60+-1が目標です) F3キーで処理時間を計測できるようにすると、 await 0 //HSP標準の待機命令 ScreenFlip ProcessMessage で14~16ms取り、それ以外の部分の3~6msと合わさり目標の16.67msを超えてしまっているようです そのためScreenFlipを使わないように 表画面にmakescreenで作成した画面を持ってくるように書くと、今度は SetDrawScreen をそのループ出始めて使用した際に16ms処理するようになってしまいました。 何かいけない処理を使ってしまっているのでしょうか…

[4993] DXライブラリ 3.20f をアップしました 投稿者:管理人 投稿日:2019/05/06(Mon) 20:57 [返信]
今回の大きな変更点は、Windows版のみですが ・Windows版:文字コードの変換に文字コード変換用数値配列を使用しない方式に変更。  ( 数値配列がセキュリティソフトに不正なソフトウェアと判定される原因となっていた可能性があるため ) です 以前DXライブラリ内部で持つバイナリデータ( シェーダーコードなど )が原因でセキュリティソフトに 不正なソフトと誤判定された際に、このバイナリデータを文字列の羅列に変換して持つようにすることで 誤判定されないようにしたのですが、シフトJISなどの文字コードを Unicode の文字コードに変換したり、 逆に Unicode の文字コードをシフトJISの文字コードに変換したりするための数値配列だけ文字列に 変換しない状態で内部に持ってしまっていました 最近もちょくちょくセキュリティソフトに引っかかっていたのはこれが原因だと思います ( CreateDXFontData.exe などでも最近同様の文字コードテーブルを使用するようにしたら CreateDXFontData.exe も  セキュリティソフトに不正なソフト扱いされたので、高確率でこれが原因… ) この『文字コード変換用数値配列』も文字列の羅列にすればそれで良いのですが、 このデータは元々 Windows API を使用して取得していたものなので、Windows版では グローバル配列として持たず Windows API を使用して実行時に数値配列を構築するようにしました これで、セキュリティソフトにも誤判定されなくなり、おまけに作成される実行ファイルの容量が バイナリデータ分の数百KB減らせました ( 因みに、この配列 PS4 対応などを始めた 2014年半ば頃から内部に持っていたので、5年間ほど  誤判定され易い状態を放置してしまっていたことに… orz )

記事No 削除キー

- Aska BBS -