こんにちは！
お忙しいところすみません
E3DLoadMQOFileAsGroundThreadについてなのですが、
マルチスレッドで実行できていないみたいなのです。
テスト用にサンプルのSimpleMotionで15000ポリゴン程度のモデルを
背景で読み込ませたところ、CPU使用率がほぼ50%（1コア分）になりました。

同じMqoファイルをコピーして名前を変更し
今度は二つ同時に背景で読み込ませたところ、
こちらでもCPU使用率がほぼ50%となりました。

マルチスレッドなら2コア目も使用するはずだと思うのですが、
使い方が悪いのでしょうか…？
BeginThreadEX関数を使用してE3DLoadMQOFileAsGroundThread自体を
別スレッドで実行しても変化がありませんでした。
（強制的にメインスレッドで計算するような仕組みになっているのでしょうか）

E3DSigLoadThreadの方でも試してみようと思ったのですが、
こちらでは15000ポリゴンでもCPU使用率が数%にしかならず一瞬で終ってしまうので
CPUを占有するほどの大きさのファイルを作成できず、
確認が取れませんでした…

E3DLoadMQOFileAsGroundThreadはとても重い関数なので
メイン処理とは別のCPUで計算させたいところなのですが
スレッドを分けることは可能でしょうか…？

昔は１つのCPUだけで動かすような命令を呼んでいましたが
今は呼んでいません。

マルチスレッドで動いているかどうかは
CPU稼働率だけでは分かりません。
１つのCPU内で複数スレッドが動くこともあるので。

e3dhsp3_LoadByNewThread.hspで試したところ
描画しながら読み込めるので
マルチスレッドには間違いないと思います。

ただCPUへのスケジューリングはOSがやることなので
そういうOSの判断なのでしょう、、、

としか言いようが無いです。

何で遊んでるCPUをもっと使わないんだろうと
実はぼくも不思議に思っています。

> e3dhsp3_LoadByNewThread.hspで試したところ
> 描画しながら読み込めるので
> マルチスレッドには間違いないと思います。
すみません。
ProcessExplorerで確認したところ、
確かにスレッドはちゃんと起動しているようです。
ですが、ためしに1万5千ポリゴンのMQO読み込みを20スレッド起動して
みましたが、CPU使用率が50%(1コア)を超えることはありませんでした。
この処理は1スレッド立てるだけでもCPUを1コア占有してしまうほどの処理です。
流石にOSのスケジューリングだけが原因とは思えないのです。

そして今分かったことなのですが、
E3Dを使用中はどのようなスレッドをいくつ作成しても
強制的に1コアしか使わないようになるようです。（自前の関数もです）

ためしに以下のような関数を作成して、スレッドとして20個起動してみました

　static unsigned __stdcall threadTest(LPVOID pParam){
　　int i;
　　While(true){
　　　for(int j=0; j<10; j++){
　　　　i= j*j+i*i;
　　　}
　　　Sleep(1)
　　}
　　return 0;
　}

最適化が働かないようにデバッグモードでテストしました。
（中身の処理にはまったく意味はありません）

E3Dを使用せずに、新しく作成したC++のプロジェクトでこれを行うと
CPU使用率は80%程度を中心に大きく振れました。
ですが、SimpleMotionの中で全く同じ処理を行うとCPU使用率は50%を超えません。

恐らくプロセスが使用するCPUのコアを限定するような関数が
まだどこかで呼ばれているんじゃないかと思うのですが、どうでしょうか…？
ttp://msdn.microsoft.com/ja-jp/library/cc429334.aspx
↑これなんかが近いと思います。

2コア目まで使用することが出来ました…！！
やはりプロセスに使用コアのマスクが掛けられていたみたいです。

実際は使用可能なマスクを取得してから設定する必要があるのでもう少し複雑になりますが
下記のようなコードをMQO読み込み前に挿入することで2コア目まで問題なく使用できました。

HANDLE curproc= GetCurrentProcess();
SetProcessAffinityMask(curProc,1+(1<<1));

C++の場合はユーザー側でマスク解除をすることが出来ますが、
HSPの場合は難しいと思うので、いずれDLLの方で実装なされる方がベストだと思います。
お騒がせしました…！

Affinityでしたか！！「Afi」で検索して無いと思ってました。
ffだったんですね。

すいません。CPUを限定する命令を呼んでいました。
明日にでも解除します。

しばらくお待ちください。

ちなみに解除してもfpsは安定していますか？
昔のマルチコア６４ビットの環境でPerformanceCounterがうまく動かないというドライバのバグのために
こういう対処をしていたんです。

> ちなみに解除してもfpsは安定していますか？
> 昔のマルチコア６４ビットの環境でPerformanceCounterがうまく動かないというドライバのバグのために
> こういう対処をしていたんです。
なんと…！そういう理由だったんですね…
開発用PCでは特にFPSの変化は分からなかったのですが
もとからPCが非力な為に、マスクを解除する前からFPSが変動していて
ちょっと当てにならない状態なので、今から別のPCで確認してみます。

Corei5のノートで自作のゲームを試してみましたが、とても安定してます！
全く読み込み時から、非読み込み時までずっと振れ無しです。
ただ、FPS調整にオリジナルライブラリを用いているので
他の外部ライブラリ等でFPS調整をした場合は分かりません…
FPS調整ライブラリは必要でしたら差し上げます

そのライブラリは内部でQueryPerformanceCounterを使っていますよね？？
この命令がCPUごとに異なる基準の値を返すという
マザーボードのドライバのバグが原因で、Easy3Dがこのような仕様になっているのです。

でもたぶんこれはすごい限られた環境だと思うので
もうCPUをフルに使うように変えてもいいかもしれません。

QueryPerformanceCounterを使用したために起きるバグだったのですか…！
私はtimeGetTimeを用いてシステム時刻の差分からFPSを測定しました
timeGetTimeなら恐らくバグに影響されるということも無いのではないかと思います
参考までにインクルードファイルとリンクするライブラリを記載しておきますと
#include <MMSystem.h>
#pragma comment(lib,"winmm.lib")
です

TimeGetTimeの差分を直接毎回計るだけですと、確かに精度は高分解能のタイマーより劣りますが
2フレーム間の時刻だけでなく複数フレームにまたがって測定をすることでゲームのFPS程度になら十分なくらいまで精度を上げることが出来ますよ
可変フレームレート用にコーディングしましたが、FPSは±0.05の精度で30をキープできています！

おお、なかなか高性能ですね。
ぜひライブラリ、ください！！

DropBoxにアップロードしました…！
Readmeに説明を書きましたが、何かご不明な点などがあれば説明します
非常に短いコードなので、権利関係は完全にフリーとしますので
好きなように使用・改変を加えてくださって構いません

うっかりファイル名を書き忘れていましたので追記です。
ファイル名はNazobiGame内のFPSMasterです。

ありがとうございます。
あとでE3DNazobiWaitっていう命令を作ろうと思いますｗｗ

今日はCPUの制限を解除したバージョンをリリースする予定です。

リリースしました！

お疲れ様です…！
C++版を今試してみたところ、マルチスレッドでのモデル読み込みで
正常に2コア目まで使用されることが確認できました…！