Nagarei

#pragma warningもVC依存なので消したいですね。 関数の未使用引数に対するC4100は変数名を書かないことで(void f(int v)をvoid f(int)にする)、`while(1)`に対するC4127はfor(;;)に変えることで消せます。 こことは関係ないですけどDoNotPushGameにProcessMessageが見当たらないのですが...。

ハンドル系は一つずつラップして別々のクラスにすべきだと思います。 クラスの数が増えるのは気にしなくてよいでしょう。ユーザーにとっては使いたい機能があれば良い訳で、使わない機能があろうがなかろうが関係ないです。 実装は機械的変換でいいなら時間もかけずにできると思いますし。 そもそもフォント、グラフィック、動画、サウンド（サウンドとBGMは微妙）はそれぞれ別の物を表している物なので、同じ型であるべきではない（相互変換が許されるべきではない）と思います。 この考えに基づいて、僕のDxLibEx.hの下の方にあるTexture2DクラスとSoundEffectクラスではintからの生成を禁止しています。

別々のクラスにするとしてハンドル系のインターフェースをどうしましょう。 例えばLoad系関数を以下のどのような形で定義するか - 普通の関数 - staticメンバ関数 - 非staticメンバ関数 あとコンストラクタにロード系の機能を付けるべきか否か もう一つ、ハンドルの自動Deleteは付けていいですか？ 一応unique_ptrみたいに所有権の解放はできるようにするつもりですが。

> Handle系に開放っていりますかね？ 例えばDoNotPushGameではend関数やtitle関数に入るたびにCreateFontToHandleを呼んでいますが、20回くらいtitle->endを繰り返すとフォントが表示されなくなります。 ちなみに間にInitFontToHandleを挟むとちゃんと表示されたままです。 > ハンドルを要求する関数群をメンバー関数にするか否か メンバ関数にしたほうがインテリセンスも利くのでメンバ関数にしましょう。 DxLibのラップも作るならそちらにもオーバーロードを作りますが。

> DoNotPushGameのハンドルの実装そっくりになるのでしょうか・・・？ そこにさらにコメントも書きたしますが、メンバ関数部分はそれで良いと思います。 コードが無駄に長くなる気がしますがある程度仕方がないと割り切るしかないですね。 ただのラップなら後ろにくっつければ定義込で一行で書けると思いますが、無理そうだったら定義は下の方持って行って宣言部を多少はすっきりさせましょう。

> point classを作りますか？ 確かにそうですね。作成お願いしても良いですか？ .......... こちらはとりあえずグラッフィック系の試作品を作りました。とりあえず今はDxLibEx_Graph2D.hの中に入ってます。 ポイントは - コンストラクタでのロードが難しい（引数の重複の為）のでとりあえずロード系をグローバルと、staticメンバにしてある - 自動Deleteはつけた といったところでしょうか。 修正すべき点の指摘お願いしたいです。 以下使用例です。 ``` #include "DxLibEx.h" int WINAPI WinMain(HINSTANCE , HINSTANCE ,LPSTR, int ) { using namespace DxLibEx; using...

`#pragma once`がインクルードガードのシンタックスシュガーである以上 「そんな面倒な`#if`を書くぐらいだったら`#pragma once`そのものを書かなくて良い」 と思います。（少なくとも僕は書きたくないです） ただ、コンパイル時間の短縮につながる可能性もあるのでインクルードガードの`#ifdef`の上に`#if`で囲んだ`#pragma once`をおいておきましょう。

良いと思います。 ただ、グローバルスコープにdxlという短い名前が入るのだけは避けたほうが良いと思うので、DxLibExだけはそのままの方が良いと思いますが、どうでしょうか？

見直してみるとわかりづらいですね...。 ここではDxLibがスレッドセーフに動作するとしておきます。 例えば関数Texture2D::DrawGraphを呼び出すとします。 しかし、同時にScreen::draw関数が別のスレッドでよばれていた場合Texture2D::DrawGraphは**どこに**描画されるかがわからなくなってしまいます。 このように表から見れば異なるオブジェクトに対する操作なのにスレッドセーフでなくなってしまうというのが問題です。 - 解決策１：DxLibを使う関数は全てスレッドセーフ保障なしにする - 長所：楽。 - 短所：DxLibでは（効果があるかどうかはともかく）マルチスレッドに動作させることができるのに、DxLibExではできなくなってしまう。 - 解決策２：Screen::drawのようなDxLib内の静的変数を変更する関数だけその旨を注意書きとして書いておく - 長所：DxLibとマルチスレッド対応状況が合わせられる - 短所：間違いが起こる事を防げない。

下のケースではライブラリ内でmutexを使っても状況は変わりません。はじめからこっちを載せておくべきでした...。 ``` cpp //DxLibの他のオブジェクトからの動作と競合する例 //異なるオブジェクトへのアクセスのみだが、問題が起こる void func() { Screen screen(640, 480); screen.draw([]{ LoadGraphScreen( 0 , 0 , "test1.bmp" , TRUE ) ; }); } void Run(){ Texture2D graph1(Texture2D::LoadGraph("test1.bmp)); std::thread thd(func);...