-
Notifications
You must be signed in to change notification settings - Fork 3
The_beginning_of_the_DxLibEx
yumetodo edited this page May 11, 2016
·
3 revisions
http://dxlib.o.oo7.jp/cgi/aska/aska.cgi より。
- vicさんがDxLibraryのDirectX12対応を提案し、同時に複数人での開発を提案し、その際についでとしてC++らしい、というかオブジェクト指向なものを提案した(vicさんはC#のXNAがお好き)
- NamelessさんがDxLibをラップするだけで事足るのでは？と書き出す
- DxLibの入力周りで混乱した質問者Kto氏登場
- vicさんが燃え出す(yumetodoの私見)
- 疲れ気味でボーっとして組んでいて間違えても静的にエラー出してほしいよね(4270番、vicさん)
- 管理人さん的には型を増やしたくない
- Namelessさん、vicさんともに幾つか実装コードを張り出す
- yumetodoが唐突に参入、GitHubで作ろうといいだす。同時にDxLib側でもマクロではなくenumにしようと言い出す。
- Namelessさんがとりあえずで今のリポジトリを作る
- yumetodoがenchant.jsの簡単さを導入したいと言い出す
- そのうちenum化するかもしれないと管理人さんが言い出す
- 今に至る
PS4 VITA がらみで大変お忙しいことと思いますが、
ひと段落したら、ちょぼちょぼでもいいのでDirectX12対応のDXライブラリも視野に入れて欲しいです。
DirectX12SDKはいつ発表か分かりませんが、マルチコアCPUやGPUの効率的な使用を考えた、逆に今までのDirectXを否定する自虐的なことも述べてました。古いアーキテキチャのままで非効率なライブラリ開発だと。
マイクロソフトの言い分では今までには無い抽象化と使いやすさのものだと述べていました。
とは言うもののまた使いにくいライブラリでしょうから、DirectX１２版の新生ＤＸライブラリを希望したいです。
XBOXONE WINDOWSアプリ その他、時代の流れ的にできればお願いしたいです。
自分も出来る範囲で協力したいです。
ほかにも有志を募って協力者を参加してもらい、作業の多い調べることを分担とか、いかがでしょうか？
キー入力クラスもenum classにして Keys::Z とか、簡単に入力できたり、基本はint型にせず、Key入力はKeyState型、３DモデルはModel型、画像はTexture2Dクラス、音はSoundEffectクラスとか、マウスオーバーで何のハンドルかすぐに分かるような仕組みを追加したり・・・
新生DXライブラリも視野に入れたものを考えていただきたいです。
DXライブラリは２Dライブラリです、と言いながらも、３Dライブラリのいきなりの導入、PS4 PSVITAの導入など、突然の進化は驚きの連続です。ぜひサプライズ開発を視野に入れるならば、DirextX12のラッパーライブラリもぜひお願いします。
> vicさん
DirectX12 は確かもう使えたと思います( DirectX SDK の形ではなく Windows SDK の中に含まれて配布されているはず )
新生ＤＸライブラリですか・・・
現状のＤＸライブラリのまま DirectX12 に対応する可能性はありますが、
今までの仕様を全て捨てて新しいライブラリとしての DirectX12 版新生ＤＸライブラリを作ることは恐らく無いか、
あるとしても相当先の話になると思います・・・
ハンドルが全部 int 型だったり、定義が全て専用の型をもっていないのは「憶える型が少なくて済む」のが
目的なので、なかなか難しいところです
( C言語覚えたての頃、Windowsソフトを作ろうとして「HINSTANCE!? WINAPI!? LPSTR!? HANDLE!? なんだこれ!?
C言語の参考書にはこんな型無かったぞ・・・ int と char と void しか知らないんだけど・・・」となったので
( typedef や #define で型を別名にできることも当然知らなかった )、なるべく基礎的な型だけで済ませたいのです )
> vicさん
こういうラッパーを作れば、現状のＤＸライブラリを変更せずに新生ＤＸライブラリが作れるのではないでしょうか。
#include "DxLib.h"
namespace DxLibEx
{
class SoundEffect
{
friend SoundEffect LoadSoundMem(const TCHAR *FileName, int BufferNum = 3, int UnionHandle = -1) {
return DxLib::LoadSoundMem(FileName, BufferNum, UnionHandle);
}
public:
int get()const { return handle; }
~SoundEffect() {
//真面目にやるとしたらリークを防ぐために参照カウンタを付けてDeleteするほうが良いかもしれない
//DeleteSoundMem(handle);
}
private:
//間違えて他の種類のハンドルを持たないようにprivateにしておく
SoundEffect(int param_handle)
: handle(param_handle)
{}
int handle;
};
int PlaySoundMem(SoundEffect SoundHandle, int PlayType, int TopPositionFlag = TRUE) {
DxLib::PlaySoundMem(SoundHandle.get(), PlayType, TopPositionFlag);
}
}真面目にやったら面白そうですね。やるなら僕にも手伝わせてください。
DXライブリを書籍を購入して勉強始めたところなのですが、うまくいきません。よろしくお願いします。
困っているのは、
読み込んだキャラ画像を下方向に移動させるとき、「下方向キー」と「テンキーの2」と「ジョイパッドの下キー」では反応せず、下に移動しません。
なぜか「zキー」で、ジョイパッドではPSコントローラーでいうと「□ボタン」で下に移動します。
書籍の環境はVisualStudio2013で、私はvisualStudio2015なのですが、そのためにGetJoypadInputStateの使い方が変わっていたりするのでしょうか？
#include <DxLib.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
ChangeWindowMode(TRUE);
if (DxLib_Init() == -1)return -1;
int ghandle = LoadGraph("media\\smp1_chara01.png");
int x = 0, y = 0;
SetDrawScreen(DX_SCREEN_BACK);
while (ProcessMessage() == 0 && CheckHitKey(KEY_INPUT_ESCAPE) == 0) {
ClearDrawScreen();
//自キャラ移動
int key = GetJoypadInputState(DX_INPUT_KEY_PAD1);
if (key & KEY_INPUT_UP) { y -= 4; }
//下の行の代わりに、if (CheckHitKey(KEY_INPUT_DOWN)) { y += 4; }とすると下方向キーで、キャラ画像は下へ移動します。
if (key & KEY_INPUT_DOWN) { y += 4; }
if (key & KEY_INPUT_LEFT) { x -= 4; }
if (key & KEY_INPUT_RIGHT) { x += 4; }
DrawGraph(x, y, ghandle, TRUE);
ScreenFlip();
}
WaitKey();
DxLib_End();
return 0;
}> Ktoさん
KEY_INPUT_...ではなくてPAD_INPUT_...だと思います。
> > Ktoさん
> KEY_INPUT_...ではなくてPAD_INPUT_...だと思います。
ありがとうございます。うまく動作しました。
今、本もよく見ると、PAD_INPUT_...と書かれていました。情けない、見落としていました。
使い分けがあるのですね。勉強になりました。
これ、ミスする人は多いですね。
いままで少なくとも４人以上見ました。
自分もDXライブラリからしばらく離れていて過去に使っていたにもかかわらず
同様なミスをしたことがあります。
int型なので、間違えてもビルドが通ってしまうのと、リファレンスを読み直すのが面倒なので、自前のキー入力クラスを作っています。
> > > Ktoさん
> > KEY_INPUT_...ではなくてPAD_INPUT_...だと思います。
>
> ありがとうございます。うまく動作しました。
> 今、本もよく見ると、PAD_INPUT_...と書かれていました。情けない、見落としていました。
> 使い分けがあるのですね。勉強になりました。
以前、グラフィック系で独自型で同様なことを行って、デストラクタで開放処理を作って気づかずに時間をとられたことがあります。
メモリー管理とリソース管理は全く別系統なので、リソース開放処理は入れないほうがいいです。生成と代入が発生するケースもあるからです。
それよりも拡張メソッドでリファレンスを見なくてもすぐできる作業効率重視のほうに重視したほうがいいですよね。
別言語への移植やシンプルさを考えて、C#では削除されたマイナーな friend も使わないほうがいいですよね。
必要以上な余計なことはせず、シンプルで分かりやすいソースおよび用途でバグが発生しにくいのがいいですよね。
ＤＸライブラリVECTOR を XNAの Vector3 相当の機能にしてしまうとか・・・オペレーターメソッド追加とかこれもあると便利そうですよね。
さらには、外人に人気のMonoライブラリ（ザマリン）を参考にするほうが、今後、ワールドワイドに人気を上げるライブラリにするならばいいかとも思いますね。まあＸＮＡが元ネタですが。
Gitとかやろうとしたんですが、ほかにやることも多く調べる時間がかかりそうなので断念しました。DXライブラリのような分かりやすいサイトがあったらやる気がおきるかもしれません。
ラッパーライブラリ、というかlib で固めてはいませんが、同様なことは行っていて、すでに同人ゲームのライブラリなどでいま協力している最中ですが、ＸＮＡを参考にしているところです。
ＤＸライブラリとＸＮＡで同じ処理のプログラムを２つ書いてみて並べてみるとわかるのですが、
ＸＮＡの場合、型さえわかっていれば、忘れてもインスタンスに . を打てばインテリセンスが表示されていちいち調べなくてもいいのが大変便利です。
画像の幅も ＸＸＸＸ.Width たったこれだけですよ。
ＤＸライブラリの場合、ヘッダーファイルか、サイトで調べて行う形になります。
ＤＸライブラリのリファレンスサイトの親切さはほかを追従できないくらいのすばらしさではあります。
int型が多用されているので、勘違いや間違いをするとビルドが通ってしまいますが、ＸＮＡの場合は、静的エラーがすぐに反応してくれるのでミス修正の作業コストもかなり少なくてすみます。
マイクロソフトのＸＮＡライブラリが開発終了になって外人が怒りまくってますが、気持ちはわかります。
有志の外人さんがDirectX12対応のＸＮＡ5.0を現在開発中だそうです。
外人大人気のＸＮＡライブラリ（mono、ザマリン、・・・）形式の拡張ＤＸライブラリと
英文マニュアルとリファレンスさえあれば、日本の人口よりはるかに多い外人にも受けるのでよりＤＸライブラリが発展するのではないでしょうか？
DXライブラリですごいのが、たとえばXNAで影を出そうとするとマイクロソフトのバグ付サンプルを元に解析して実装して追加しなければならないとか、結構面倒です。
しかし、DXライブラリには豊富な関数郡があり1行2行でできると言った秀逸さです。
ちなみに、C++とDXライブラリ、C#とXNA、両方初心者に２D関係を複数人に教えたところ、後者のほうが習熟度は高かったです。オブジェクト指向も言わなくても実感的に習熟してくれました。
しかし、XNAにはかゆいところに手が届かない場合もありますが、DXライブラリはそこらあたりが本当にすごいなと感じます。
個人的にはＤＸライブラリの優秀なメソッド＋ＸＮＡのオブジェクト指向（使用する用途に合わせた型）これらが合わさり、さらに、外人向けのリファレンスサイトなどがあれば、海外でも人気が広がるのではないでしょうか？
Ｄ＿ＸＮＡライブラリとか、ＸＮＡという名前を内包すれば外人も喜ぶしやる気がおきやすいし、アメリカの大学などでＸＮＡ担当の先生も授業に移行しやすいです。
外国の人口は日本よりはるかに大きいですから、上記ができればすごい発展ができるのではないでしょうか？
平行して書籍も書いてしまいキンドルやその他・・・
話が止まらないのでここら辺で止めておきます。
ソースの１部を書くのを忘れていました。
自前ゲームパッドクラスでこんな感じなソースになります。
WGamePadState pad = WGamePad::GetState(PlayerIndex::Keyboard_and_OnePlayer);
if (pad.IsButtonDown(Buttons::Left)) X -= 4;
if (pad.IsButtonDown(Buttons::Right)) X += 4;
if (pad.IsButtonDown(Buttons::Up)) Y -= 4;
if (pad.IsButtonDown(Buttons::Down)) Y += 4;上記で慣れたら、疲れ気味でボーっとして組んでいて間違えても波線が出てくれるし、
. や :: で可能なもののみリストで出るので安心です。
Vectorで公開するか、DXライブラリの制作者様に提供を承諾して内包して頂ければありがたいですが、いかがでしょうか？
> vicさん
> 以前、グラフィック系で独自型で同様なことを行って、デストラクタで開放処理を作って気づかずに時間をとられたことがあります。
> メモリー管理とリソース管理は全く別系統なので、リソース開放処理は入れないほうがいいです。生成と代入が発生するケースもあるからです。
この間僕が作ったゲームでフォントハンドルを削除し忘れて、最終的にはフォントが使えなくなるという失態をしたばかりなので必要かなと思った次第です。
「生成と代入が発生するケース」とはどのようなケースでしょうか。
ちなみに僕が念頭に置いているのはC++のスマートポインタです。
> 別言語への移植やシンプルさを考えて、C#では削除されたマイナーな friend も使わないほうがいいですよね。
friendは現行のDXライブラリとの互換を考えて使いました。確かにfriendはあまり行儀が良くないので他の手法をとったほうが良いかもしれませんね。
> ＸＮＡの場合、型さえわかっていれば、忘れてもインスタンスに . を打てばインテリセンスが表示されていちいち調べなくてもいいのが大変便利です。
確かにインテリセンスが表示されるというのはVisualStudio使いにとってうれしいです。
現行のDXライブラリでも関数宣言の後ろのコメントがインテリセンスで表示されるだけでも違いますし。
ただ、VisualStudio以外のエディタでもインテリセンスが期待通りに働くとは限らないので、やはりリファレンスが重要だとは思いますが。
>ちなみに、C++とDXライブラリ、C#とXNA、両方初心者に２D関係を複数人に教えたところ、後者のほうが習熟度は高かったです。オブジェクト指向も言わなくても実感的に習熟してくれました。
これはDXライブラリがC用のライブラリという事からしても仕方のないことかもしれませんね。その分C++erは歯がゆい感じを覚えるのですが。
僕はC#もＸＮＡも使ったことがないのですが、オブジェクト指向なDXライブラリが欲しいという点は同感です。
[4270]のような物は僕も作りましたし、おそらく他にも独自に作っている人がいると思います。
そんなに手間のかかるものではないですが、できればこういう再発明は避けたいですね。
とは言うものの、一人で作るのはなかなか難しそうで手が出せず、他の人と共同でというのも経験がないので僕主導では厳しいです。
> Nameless さん
生成と代入の例です。下記でグラフィックの開放をデストラクタで行ったことを考えてみてください。xxxxxxxx にグラフィック関連が入っていた場合、デストラクタでもしグラフィック開放を行っていたら・・・
Sprite ssss;
void Vvv()
{
ssss=Sprite(xxxxxxxx);
.
.
.
}話は脱線しますが、ちなみに人気のある COCOS2D-X ライブラリでは、new は基本的に使用するな、スタティックメソッドを使って生成しろ、というルールになっています。リソースも絡んでいるメモリ管理は、自作となるとややこしいのでやばそうです。
こっちでもC++で、Windowsゲームを作ることができますが、フルスクリーンが無理っぽいので、「ゲームはフルスクリーンっしょ！」という自分にはこの点は譲れません。
XNA関連もリファレンスはけっこう良くて、今までのMSの中で最高と思っています。
しかし、DXライブラリリファレンスHPのサンプルコードがすぐある！には全くかないません。
ここを超えるいいリファレンスがあったら見てみたいです。MSのだだ長い作りこまれた解析時間のかかるサンプルじゃモチベーション下がるし、DXライブラリの人気がここまで継続しているのもうなずけます。短くてリファレンスのすぐそこにあるサンプル、これはすばらしいです。
ＸＮＡのリファレンスでも小さいサンプルがある場合もありますが、ＤＸライブラリのリファレンスにはかないません。
マイナーなＣ＋＋命令についてですが、バグがあったり仕様がおかしかったりなどのうわさをどこかのサイトで目にしました。あまり使われないのでバグチェックが不十分とからしいです。
無難に考えて多くの人が使っている汎用のものを使うのが安定性や情報量としても安心できますよね。個人的には、よっぽどメリットが無い限り汎用的なコードを使い必要に迫られたときだけ考えることを自分はします。逆に考えればリスキーな命令の開拓者はやりたくない感じです。
前ログで考えの押し付けっぽくなってすみません。これは自分の考えです。
自分的には、C#でやっていることをC++と同様にしたいだけという考えもあるかもしれません。
「安定して確実に動作させる」「面倒にしない」「早く終わらせる」これが自分のモットーです。
> vicさん
ご意見ありがとうございます
XNAは出来が良いというお話はよく目にするので、いつかC++風にする際は参考にしてみたいと思います
> Vectorで公開するか、DXライブラリの制作者様に提供を承諾して内包して頂ければありがたいですが、いかがでしょうか？
現状は今行っている作業以外のことには手が回らない状況なので、内包することは難しいです
あと、もし Vector で公開されたらＤＸライブラリ置き場からリンクを張らせてください m(_ _)m
> NameLessさん
[4270] のようなものは実はもうあります。
DirectXToolKitです。
ただし、解読に時間がかかりそうで面倒なので撤退しました。
ＸＮＡの開発者が作ったＣ＋＋ライブラリだそうで、関心があったのですが、
情報量が少なくて、しかもＳＴＬをいろいろかましていて見た目ちょっと抵抗がありました。
[4270]をＸＮＡ風に書き直すとこうです。
※Keyboard_and_OnePlayer は無いです。
※ＤＸライブラリのような便利なキーとゲームパッド両対応のものは無いです。
GamePadState pad = WGamePad.GetState(PlayerIndex.Keyboard_and_OnePlayer);
if (pad.IsButtonDown(Buttons.DPadLeft)) X -= 4;
if (pad.IsButtonDown(Buttons.DPadRight)) X += 4;
if (pad.IsButtonDown(Buttons.DPadUp)) Y -= 4;
if (pad.IsButtonDown(Buttons.DPadDown)) Y += 4;※Keyboard_and_OnePlayer はＸＮＡに無いのでこの部分はエラーになります。
> 管理人さん
キー入力とゲームパッドクラスですが、とりあえずVectorに投稿しようと思います。
ヘッダーファイルだけですが、もしうまく投稿できたらご報告いたします。
さっき気づいたばかりですが、指定すれば、なんとDirectX11には対応されていたのですね。
いつの間にという感じです。２Dの方はDirectX9なのでしょうか？
関数は、クラスのスタティックメソッドを機会があれば検討していただきたいです。
例
auto mtrx = Camera::GetViewMatrix();> vicさん
newを使用するなという意見には僕も賛成で、他の人には代わりにスマートポインタを使うべきだと言っています。
ただ、friendはそれほどマイナーなものではないです。おそらく今の著名なコンパイラなら問題ないと思います。
むしろC++11やC++14の新機能のほうがコンパイラによって実装のばらつきがあるので避けるべきかもしれないです。
（と言いつつしっかり使っていますが）
とりあえず、先ほどの物をnewを使わずリソース管理も問題ないコードにしてみました。
SoundEffect_Uniqueの方はunique_ptrを参考に、常に一つしかハンドルが存在しないようにして、
リソースの解放をしたときに問題が起こらないようにするもの。
SoundEffectの方は単純にデストラクタでDeleteするのではなく、shared_ptrを使ってリソースへの
最後のハンドルが削除される場合のみにリソースを開放するようになっています。
これならば[4261]の場合でもssssのデストラクタでのリソース解放となるため、
（ssssがグローバル変数なので結局リソースが解放されないという問題を除いて）問題は起こらないはずです。
#include "DxLib.h"
#include <memory>
//オーバーヘッドが少ないVer
//ただしコピーができない
class SoundEffect_Unique
{
public:
void release() {
DeleteSoundMem(handle);
//handle = -1;
}
static SoundEffect_Unique LoadSoundMem(const TCHAR *FileName, int BufferNum = 3, int UnionHandle = -1) {
return DxLib::LoadSoundMem(FileName, BufferNum, UnionHandle);
}
static int PlaySoundMem(const SoundEffect_Unique& SoundHandle, int PlayType, int TopPositionFlag = TRUE) {
return DxLib::PlaySoundMem(SoundHandle.handle, PlayType, TopPositionFlag);
}
private:
//コピー禁止
SoundEffect_Unique(const SoundEffect_Unique&);// = delete;
SoundEffect_Unique& operator=(const SoundEffect_Unique&);// = delete;
public:
SoundEffect_Unique()
:handle(-1)
{}
//所有権の譲渡
SoundEffect_Unique(SoundEffect_Unique&& other)
: handle(other.handle)
{
other.handle = -1;
}
//所有権の譲渡
SoundEffect_Unique& operator=(SoundEffect_Unique&& other)
{
if (this == &other) { return *this; }
handle = other.handle;
other.handle = -1;
SetDeleteHandleFlag(handle, &handle);
return *this;
}
~SoundEffect_Unique() {
//リソース解放
DeleteSoundMem(handle);
}
private:
//間違えて他の種類のハンドルを持たないようにprivateにしておく
SoundEffect_Unique(int param_handle)
: handle(param_handle)
{
SetDeleteHandleFlag(handle, &handle);
}
int handle;
};
class SoundEffect
{
public:
void release() {
p_handle.reset();
}
static SoundEffect LoadSoundMem(const TCHAR *FileName, int BufferNum = 3, int UnionHandle = -1) {
return SoundEffect_Unique::LoadSoundMem(FileName, BufferNum, UnionHandle);
}
static int PlaySoundMem(const SoundEffect& SoundHandle, int PlayType, int TopPositionFlag = TRUE) {
if(SoundHandle.p_handle == nullptr){ return -1; }
return SoundEffect_Unique::PlaySoundMem(*SoundHandle.p_handle, PlayType, TopPositionFlag);
}
SoundEffect(SoundEffect_Unique&& handle)
: p_handle(std::make_shared<SoundEffect_Unique>(std::move(handle)))
{}
SoundEffect(){}
private:
std::shared_ptr<SoundEffect_Unique> p_handle;
};コードを書くのに夢中で言いたいことを書き忘れていました。
newを使うなという主張の主な根拠は「deleteし忘れるから」です。
また、DXライブラリの各Load系関数はリソースの確保という点でnewに近いです。
ただ、これを使うなというわけにはいかないので、「deleteし忘れる」ことのないようにする何かが必要だと思います。
C++のスマートポインタはまさにdeleteし忘れることのないようにと言って開発されたものなので、
これを参考にすれば簡単にこのシステムを作ることができます。
ただ、ここで議論しても反映させる場所がないんですよね...。
> Namelessさん
DXライブラリのグラフィックの開放に関してはシンプルでわかりやすいのでこれでいいかと考えています。
リソースの開放とメモリーの解放に関しては、一筋縄でいかず、COCOSのように内部カウンタを設けて・・・とかまあかなり面倒なことになります。
リソース開放タイミングを間違うとまずいので、DXライブラリのまとめて開放をうまく活用するのが制作効率上便利というか楽です。読み直しとか無駄は少し発生しますが、まあ楽を取る形です。
ハンドルのコピーは必須なので、これははずせないです。
friendに関しても自分的には好みでないし、どうやら、Namelessさんと志向性が違うようですね。
C#で廃止されるようなコードはできるだけ排除したいです。
C#では、new を使っても自動的に開放してくれるのでまあ安心です。GC挙動さえ何とかなればですが。
たぶん、自分と考え方やスタイルが違うと感じましたので、頑張ってこちらにコードを貼り付けてもあまり見ないと思いますので、もうよろしいですよ。
> 管理人様
Vectorやその他に上げるのはほかのメンバーなどの都合で見送りになりました。
ですが、ここに1部のものを貼り付けいたします。
int型はそのままで、試験的にオーバーロードで enum class 型のものを追加していただけないでしょうか？
これがあるだけでもだいぶ楽になります。（下記のをコピペで可能。もしよろしければお使いください）
enum class PlayerIndex
{
One = DX_INPUT_PAD1, Two = DX_INPUT_PAD2, Three = DX_INPUT_PAD3, Four = DX_INPUT_PAD4,
Keyboard_and_OnePlayer = DX_INPUT_KEY_PAD1, Keyboard = DX_INPUT_KEY
};
enum class Buttons:unsigned int // XX のワーニング消しのため
{
A = PAD_INPUT_A, B = PAD_INPUT_B, C = PAD_INPUT_C, D = PAD_INPUT_D,
F= PAD_INPUT_F, G= PAD_INPUT_G, H= PAD_INPUT_H,
I= PAD_INPUT_I, J = PAD_INPUT_J, K = PAD_INPUT_K, L = PAD_INPUT_L,
M = PAD_INPUT_M, N = PAD_INPUT_N, O = PAD_INPUT_O, P = PAD_INPUT_P,
R = PAD_INPUT_R, S = PAD_INPUT_S, T = PAD_INPUT_T, U = PAD_INPUT_U,
V = PAD_INPUT_V, W = PAD_INPUT_W, X = PAD_INPUT_X, Y = PAD_INPUT_Y,
Z = PAD_INPUT_Z, LL = PAD_INPUT_LL, RR = PAD_INPUT_RR, XX = PAD_INPUT_XX, START = PAD_INPUT_START,
B1 = PAD_INPUT_1, B2 = PAD_INPUT_2, B3 = PAD_INPUT_3, B4 = PAD_INPUT_4,
B5 = PAD_INPUT_5, B6 = PAD_INPUT_6, B7 = PAD_INPUT_7, B8 = PAD_INPUT_8,
B9 = PAD_INPUT_9, B10 = PAD_INPUT_10, B11 = PAD_INPUT_11, B12 = PAD_INPUT_12,
B13 = PAD_INPUT_13, B14 = PAD_INPUT_14, B15 = PAD_INPUT_15, B16 = PAD_INPUT_16,
B19 = PAD_INPUT_19, B20 = PAD_INPUT_20, B21 = PAD_INPUT_21, B22 = PAD_INPUT_22,
B23 = PAD_INPUT_23, B24 = PAD_INPUT_24, B25 = PAD_INPUT_25, B26 = PAD_INPUT_26,
B27 = PAD_INPUT_27, /*B28 = PAD_INPUT_28,*/
Space = PAD_INPUT_10,
Left = PAD_INPUT_LEFT, Right = PAD_INPUT_RIGHT, Up = PAD_INPUT_UP, Down = PAD_INPUT_DOWN
};
enum class Keys
{
A = KEY_INPUT_A, B = KEY_INPUT_B, C = KEY_INPUT_C,
D = KEY_INPUT_D, E = KEY_INPUT_E, F= KEY_INPUT_F,
G= KEY_INPUT_G, H= KEY_INPUT_H, I= KEY_INPUT_I,
J= KEY_INPUT_J, K= KEY_INPUT_K, L= KEY_INPUT_L,
M= KEY_INPUT_M, N= KEY_INPUT_N, O= KEY_INPUT_O,
P = KEY_INPUT_P, Q = KEY_INPUT_Q, R = KEY_INPUT_R,
S = KEY_INPUT_S, T = KEY_INPUT_T, U = KEY_INPUT_U,
V= KEY_INPUT_V, W= KEY_INPUT_W, X= KEY_INPUT_X,
Y= KEY_INPUT_Y, Z= KEY_INPUT_Z,
D1 = KEY_INPUT_1, D2 = KEY_INPUT_2, D3 = KEY_INPUT_3,
D4 = KEY_INPUT_4, D5 = KEY_INPUT_5, D6 = KEY_INPUT_6,
D7 = KEY_INPUT_7, D8 = KEY_INPUT_8, D9 = KEY_INPUT_9,
D0 = KEY_INPUT_0, Minus = KEY_INPUT_MINUS, Prevtrack = KEY_INPUT_PREVTRACK, Yen = KEY_INPUT_YEN, BackSpace = KEY_INPUT_BACK,
Divede = KEY_INPUT_DIVIDE,BackSlash = KEY_INPUT_BACKSLASH,
F1 = KEY_INPUT_F1, F2 = KEY_INPUT_F2, F3 = KEY_INPUT_F3,
F4 = KEY_INPUT_F4, F5 = KEY_INPUT_F5, F6 = KEY_INPUT_F6,
F7 = KEY_INPUT_F7, F8 = KEY_INPUT_F8, F9 = KEY_INPUT_F9,
F10= KEY_INPUT_F10, F11= KEY_INPUT_F11, F12= KEY_INPUT_F12,
Space = KEY_INPUT_SPACE, Enter = KEY_INPUT_RETURN,Tab = KEY_INPUT_TAB,
LShift = KEY_INPUT_LSHIFT, RShift = KEY_INPUT_RSHIFT,
LCtrl = KEY_INPUT_LCONTROL, RCtrl = KEY_INPUT_RCONTROL,
Comma = KEY_INPUT_COMMA, Period = KEY_INPUT_PERIOD, Slash = KEY_INPUT_SLASH,
Semicolon = KEY_INPUT_SEMICOLON, Colon = KEY_INPUT_COLON, RBracket = KEY_INPUT_RBRACKET, LBracket = KEY_INPUT_LBRACKET,
At = KEY_INPUT_AT,
Left = KEY_INPUT_LEFT, Right = KEY_INPUT_RIGHT, Up = KEY_INPUT_UP, Down = KEY_INPUT_DOWN
};上記をヘッダー追加で、
たとえばですが、
CheckHitKey( int KeyCode ) + オーバーロードで
CheckHitKey( Keys key )
内部的には、
(int)key でキャストするだけです。
関数を使う側は、Keys::Left とかするだけなのでかなり重宝します。
intの部分をenum class にするだけでも使い勝手が良くなりますので、
もしよろしかったらご検討ください。
違うenum class型を引数で使用すれば、波線が出て即座に間違っているのがわかります。
初学者のミス対応がぐっと減りますのでenum class型が実装されると相当ありがたいです。
もちろんオーバーロードで行えば以前のコードにも支障をきたしません。
> vicさん
> さっき気づいたばかりですが、指定すれば、なんとDirectX11には対応されていたのですね。
今年の春頃のバージョンから Direct3D11 の Feature Level 11.0 以上に対応している環境では
自動的に Direct3D11 を使用するようになっています
> いつの間にという感じです。２Dの方はDirectX9なのでしょうか？
Direct3D9 と Direct3D11 を同時に使用することはできないので、Direct3D11 を使用する場合は2Dも3Dも
Direct3D11 で処理しています
> 関数は、クラスのスタティックメソッドを機会があれば検討していただきたいです。
それは大きな変更になるので、暫くは考えられないと思います
> int型はそのままで、試験的にオーバーロードで enum class 型のものを追加していただけないでしょうか？
それはちょっとやりたくないです
一度入れてしまうと使う方がいらっしゃるかもしれないので、「やっぱり辞めよう」と簡単に削除するわけには
いかなくなってしまうので・・・
> 今年の春頃のバージョンから Direct3D11 の Feature Level 11.0 以上に対応している環境では
> 自動的に Direct3D11 を使用するようになっています
>
いやはやなんとも進化がすさまじいですね。
２Dゲームライブラリです。と言い切っていた時代とは偉い違いです。
> Direct3D9 と Direct3D11 を同時に使用することはできないので、Direct3D11 を使用する場合は2Dも3Dも
> Direct3D11 で処理しています
>
ひょっとして、XBOXONE用として使えるのでしょうか？ここら辺はサードパーティー契約していないと情報を取得できないかもしれませんが、視野に入れられているのでしょうか？
> > 関数は、クラスのスタティックメソッドを機会があれば検討していただきたいです。
>
> それは大きな変更になるので、暫くは考えられないと思います
>
もし、そのときになったらお願いします。
あまり凝ってしまうと大変なので、
カメラ系 Camera::～～ で統一
#define パラメータ >>>> enum class でカテゴリごとにまとめる、文字数を大幅カット
など基本形は実質同じとかだとリファレンスも文字列が違うだけになるので
ありがたいです。
> > int型はそのままで、試験的にオーバーロードで enum class 型のものを追加していただけないでしょうか？
>
> それはちょっとやりたくないです
> 一度入れてしまうと使う方がいらっしゃるかもしれないので、「やっぱり辞めよう」と簡単に削除するわけには
> いかなくなってしまうので・・・
それは残念です。
というか、入れてしまったらその便利さに感動してもうint型のパラメータには戻ってこなくなることと思います。
もし気が変わりましたら、
※試験的に導入したものですので削除される可能性があります。
と前置きを置いた上での導入をお願いします。(隠し命令扱い)
カテゴリごとのenum class型引数 は本当に便利で、自分はこればっかりです。
C++11初学者にもこれはがんがんすすめています。
これはC#のenum相当です。これは本当に便利で感動しました。
ヘッダーに突っ込むだけだし簡単です。
>
> いえ、Direct3D11 対応は複数環境対応の練習の為と、Windowsストアアプリ対応を見据えてのものです
> ( Windowsストアアプリで使える Direct3D は当時 Direct3D11 しかなかったので )
そういう事情がおありでしたか・・・
ご存知かもしれませんが、DirectX11とX12では３D描画速度にかなり差があるようです。
情報が少なくて大変ですが、ここら辺も視野に入れられていただけたら面白そうです。
ひと段落して行けそうだと感じられたら、検討していただきたいです。
> > 関数は、クラスのスタティックメソッドを機会があれば検討していただきたいです。
>
> それは大きな変更になるので、暫くは考えられないと思います
よく考えたら、スタティックメソッドにしなくても、
namespace で区切るだけでカテゴライズされた命令群から選択できるようになります。
もし気が変わりましたら、実装をお願いしたいです。
例：
Camera::～
::でCamera関連のみメニュー（インテリセンス）で表示
#define に関しても namespace で区切れば、:: で選択可能なもののみインテリセンスで表示されます。迷わなくて済みますので助かります。
また #defineのキーワードも少なくなります。
試しに自分でキー入力とジョイパッドのクラスを作ってみました。
使い勝手など、入力の少なさ、可読性、性能、直感で使いやすいか、なども検討して
ソースの短さに反して、やり直しや再検証などで時間を取られました。
アロー無くせないか？ポインタ記述を排除できないか？もっと短い入力でできないか？
()無くせないか？などです。
キーとジョイパッド入力クラスだけですが、トリガーチェックと押している時間を取れるようにして、
しかもコード量は極力少なくなるように間違えて入力しないような配慮しました。
（DXT参考）
ただの短いヘッダーファイルですが、近じか公開します。
感触を見て拡張も考えていこうと思います。
初心者向けの説明文もわかりやすく作る予定です。
コマンド入力や離している時間の導入も考えたのですが、とりあえず公開して
要望があればという形にしようと思います。
ｕｒｌ張り付けがうまくいかなかったのでここに張り付けます。
DirectX 11 vs DirectX 12 | 3DMark Api Overhead Test | GTX 770
上記キーワードで検索するとyoutubeの動画で確認できます。
HDでフルスクリーンで動画確認すると違いが顕著に確認できます。
ここに極まれり、という印象しかない
管理人さんが某絵師だったら間違いなくアドバイス罪でブロックしてるレベル
少し自重してはどうですか
> vicさん
> ひと段落して行けそうだと感じられたら、検討していただきたいです。
DirectX12 に対応させることは可能だと思いますが、
対応するとしてもまだまだ先の話なので、今の所はなんとも言えません
> もし気が変わりましたら、実装をお願いしたいです。
はい
> YFさん
お気遣いありがとうございます
アドバイス罪・・・！
改めてまとめを読み直してみましたが、なんで助言がアドバイス罪になるかというと
「自分にとって何が最適の行動・選択かは自分( 又は自分と行動を同じくしている人 )が
一番良く知っているので、自分( 又は自分と行動を同じくしている人 )以外の人から
助言をして貰う必要は無い( 寧ろ誤った情報である可能性もあるので害ですらある )」
ということみたいですね
これは自分の行動を決定するのに必要な情報は全て把握していて、更にその情報から自分に
とって最も正しい選択を導き出せる自信があることが前提なので、私のように無精者で情報の
チェックも欠かすような人間には到底言えない台詞です
実際ＤＸライブラリはこれまでも沢山の方からいただいた助言や提案によって追加された
機能や修正も多いので、少なくともこの掲示板にご助言を書いていただいた際に私が「アドバイス罪」の
ようなことを言うことはありません
( 仮に「検討をお願いします」ではなくもっと強要するような内容でしたら困りますが・・・ )
ただ、vicさんがご提案されている DirectX12対応やソースの記述を新しいものへ変更することについては
どちらも簡単にできることではないので、色々なご情報・ご提案を頂いても
「今は別のことをしているのでできません」
「それが終わっても更に別のことを優先するかもしれませんし、最終的に対応するかどうかもわかりません」
としか申し上げられないのですが・・・
なんかvicさんがどどんと話を持ち込んでるなぁ・・・。
C++っぽく書きたいならDxLibをラップしたりSFMLなりをつかえばいいと思うんですけどねぇ。
ただ少なくともC99含めenumが使えない環境は無いはずなのでdefineをenumに置き換えるのはやってほしい、と切に願います。typedefしておいてもらえれば、リファレンスなくても調べやすいですし。
enum classは内部のコードが汚くなるのがソース覗けば一目瞭然なのでそこまで望まないです。
名前空間に関しては現状でもDxLib空間に入っていてたしかマクロで強制的に名前空間に入れられた(using namespaceを消せた)ように思うし、
他のライブラリも(OpenCVとか。boostは除く)そこまで名前空間は小分けしてないです。
コード長くなるだけだし。std::chronoの惨劇をまた繰り返したいんだろうか。
さらにADLという悪しき機能があるので名前空間の小分けは良くないと思います。
もしC++っぽくするなら優先順位的には
1.defineマクロの排除
2.keyinput周りの改造(配列を作るのはわかりにくい)
で、それも有志でラップすればいいだけかなぁと。
なおkey周りをどうせラップするならenum classではなくSproutのコンパイル時文字列ライブラリ使って文字列で指定できたほうがユーザーフレンドリーだと思いますが。
なんかvectorで公開とか書いてあるんだけどいっそGitHubにリポジトリでも作ってくれたほうがよほど建設的だと思うんですが。Issueなりで討論すればいいわけで。
とりあえずvicさんはGitHubか何かにリポジトリを作ってできてるところまで上げればいいと思うんです。
そこかしこでDxLibのC++ラッパーが量産されるのは流石にどうなんだと私自身も思いますし、一方ライブラリ本体はいじれないでしょうし。
リポジトリができたら私も参加したいです。
言いたいことがボケてしまったので言いたいことをまとめると
1. ライブラリ作者に大規模な変更を求めるのは、作者が大刷新している真っ最中でもない限り筋違い
2. DxLibラップしているならGitHubか何かにリポジトリつくってほしい、私参加したいです
3. DirectX12について私はノーコメントだ
です。どうして私は話を簡潔にできないのか。
なにやら、いろいろなことが起きてるようですが・・・
私も管理人さんや個々の人たちに結構意見を聞いてしまっているので
大きなことを言えた義理はありませんが管理人さんの負担を増やしまくるのはあんまりいいとはいえないかな・・・・
やり方がわかっているなら、自分で作ってから誘えばいいかと。そのほうが管理人さんもわかりやすいでしょうし・・・
えらそうなこといってしません・・・・余計なお世話でしたね・・・
とりあえず誰かが作れば少しは進展するかもしれないと思いGitHubの方にリポジトリを作りました。
https://github.com/Nagarei/DxLibEx/
とりあえず僕が勝手に作り始めた作りかけの物を上げてあります。
Issueの方も見てください。
[4271]にも書きましたが、僕一人では無理なので（特にクオリティ的に）ご協力お願いします。
管理人様、ありがとうございます。そして察していただけたようです。
おっしゃるとおり、あくまでも強要ではなく、そういった要望が情報があるといった意味なので、気が変わったらとか、文面に書いてある通りであります。
ここら辺はそう伝えたつもりでしたが、文面表現が甘かったです。今度から負担を感じない文章表現を再考します。
頭のかなり端っこにでも置いてもらってもし覚えていて、時間が空いた上でさらに気が向いたら遠い将来で、というイメージでお願いします。
掲示板というのもポイントで、この文面は他の人も見るので、「俺がやったるで」的な方もおられるかもしれません。データベースの役割もあり、あとで見直して便利に使用する要望情報という形にもなります。
むしろ管理人様のように謙虚に人の言うことに耳を向けるライブラリ作者様であるからここまで成長したすばらしいライブラリだと考えています。
どこかの会社の「クレームは宝だ」までは言いませんが、他のライブラリは停滞、または自然消滅がほとんどです。DirectX系ラッパーライブラリでは、ＤＸライブラリ以外は存在を感じないような印象です。
ライブラリ開発者で勘違いが多いのが、多くの人が便利に使う道具だという意識の欠如です。
マニュアルや説明やクイックスタートも性能に含まれます。
その点、ＤＸライブラリは説明文＋サンプルソース これは実にすばらしいです。
説明文を読むのが面倒な場合でも、すぐにわかりやすい余計なものが入っていないサンプル、
これも実にすばらしいです。このリファレンスのサンプルコードも本当にわかりやすいです。
また「ただ否定を述べるだけの人」は、場が盛り下がってしまうのと同時に、他の人も「ＸＸ言いたいけど、叩かれるのが嫌だな」と感じてしまい書き込みを控えてしまう。
ここら辺の対応もしっかりしておられます。優秀な仕事人がかなり伝わりますのでリアルでいっしょに仕事しているひとがうらやましいです。
質問掲示板でも、他のサイトだったら（要約して）「自分で調べてググれ」で終わるようなことでも丁寧に回答していて、しかもサンプルまで提供とはすごいです。
さすがとしか言いようがないです。
●NameLessさん、
活動的ですばらしいです。
Gitは面倒で途中で自分は止めちゃいました。
自分はＣ＋＋のＳＴＬ関係やその他で自分のバグではなく、仕様かそのバグに近いもので何度かはまってうんざりしているところがあります。他人のサンプルコードでも、たいしたことが無いのにわざわざメモリ確保してやっていてメモリリークがらみのバグがあったり嫌になったケースはあります。これも自分のバグじゃないです。
なので基本的にリスクの高いと感じるものに関してはよっぽど便利ということがない限り使わない方針です。逆にこれは便利だと思ったら最低限使うイメージです。
Ｃ＋＋よりＣ＃が好きなのでこちらの記述方法に意識が傾斜しているかもしれません。
Ｃ＃でＳＴＬ同等のものがありますが、記述短いしエラーわかりやすいし、あっちに慣れるとＣ＋＋に戻りたくなくなります。しかし、ＤＸライブラリのほうがＸＮＡより、便利なメソッドが多くていいんですよ。しかもリファレンスわかりやすいし、いいサンプルしっかり付いているし。
仕方なく、Ｃ＋＋をやっている感じです。Ｃ＃用でもＤＸライブラリがあるようですが、管理人さんが忙しいのと使用実績があまり見ないので堅実にＣ＋＋とＤＸライブラリがベストなのかなぁ・・・と考えています。
●yumetodoさん、
おおまかに同意です。
たとえば、Camera:: で必要なものだけ出たり、
Joy:: でコントローラーのボタンが出たり、とか、よく考えたら enum かnamespace でくくれば使う側が「う～んとどれだっけ？」とマニュアルを読む工程が短縮できます。
C++というよりは、使いたいものを間違えずにすぐに取り出せて、間違えたらすぐにエラー（静的エラー）になるのが望みです。
ジョイパッド関係は初心者のパラメータ間違いはすごい些細なことから含めると結構遭遇しているので、波線が出てほしい、と考えたのが発端でキーやジョイパッド入力系のは作りました。
ここに載せたColor::のものは何人か使ってもらったら好評で、「おおおー」と感嘆されてうれしかったです。色指定が面倒だからいつも白だったのを気軽にカラフルにできたと喜んでいます。
（まあこれもＸＮＡの真似ですが）
単純なことでもいいので、とにかく使いやすくより直感的にできるものが希望です。
ラッパーライブラリは多くてもマニュアルやリファレンスがしっかりしていれば問題ありません。
人によっては否定されそうですが、
ＧＡＭＥＬＯＯＰ { } というマクロで while を置き換えたり、より入力キーワードを少なくしたいという考えです。
Ｃ＋＋ぽいとかそれは考えていないです。もっと使いやすいかどうかだけです。
とにかく、直感的に選択して静的エラーが出やすく使えるのを望んでいるので、管理人さんが、enum（const int 系？） が好みでないならば namespace で#define をくくるのもありかと考えています。
Ｃ＋＋に意識が行き過ぎるとかえって生産性が落ちるので、基本は便利だから使うとか、効率が高いから使うとか、そんな感じです。STL系はエラーがわかりにくいので本当に便利と確信したとき以外は使わない方針です。
cout より printf の方が人気なのもそういう理由があるんじゃないでしょうか。
自分もprintf の方が好きです。
話がそれてしまいましたが、リポジトリ関係もドロップボックスでやっているというか、自動でやらされていますが、よくわからない状況で調べる時間がかかるのでやめちゃいました。
直感的にＵＰできるのはワンドライブ公開かＶｅｃｔｏｒ公開（クリエイター登録申請は完了済み）でしょうか。
とにかく調べて検証する時間（バッドテスト）がかかると問題なのが自分のやる気にも影響するので、これが怖いところです。ゲームなんかはまっちゃうと戻れなくなっちゃいますね。
std::chrono とか存在は知っていましたが、
ネットで調べると、あんまり使っていない印象があったので、また不完全じゃない？
とか先入観で使いませんでした。それに面倒だし time.h でいいじゃん、どんだけ作業メリットある？とか考えていました。
boost は全く使ったことが無いのでＳＴＬよりここがずっといいとか、なにか語ってくださると
勉強になります。boost に慣れるとstl はしたくないような話も聞きました。
ここら辺の実践的な内容も聞きたいところです。
> yumetodoさん
> ただ少なくともC99含めenumが使えない環境は無いはずなのでdefineをenumに置き換えるのはやってほしい、と切に願います。typedefしておいてもらえれば、リファレンスなくても調べやすいですし。
以前お話した通りなるべく「型」を増やしたくないので enum による定義を行わないようにしていましたが、
「リファレンスでしっかり説明していれば問題が無いのではないか？」と少し前から思い始めましたので、
複数環境対応が終わった後に考えてみます
> XSystemさん
お気遣いありがとうございます
複数環境対応なんて時間の掛かる事を始めてしまったせいでご要望に応えられない状況が続いているというのもあるので、
ある意味自業自得とも言えます・・・
> Namelessさん
よろしければリンクページに作成された GitHub のリポジトリのページを追加したいと思いますが、如何でしょうか？
> vicさん
お褒めいただきありがとうございます
> 管理人様
リンクへの追加お願いしたいです。
ただGitHubは作ったその日に始めたばかりで、作成をするときにミスをした気がしています。（確信がないのでとりあえずそのままにしてありますが）
リポジトリを作り直したときはURLの変更をお願いするかもしれません。
Namelessさんへ
Namelessさんお疲れ様です。
ちょっとじっくり読んでみたいと思います。これについてはIssueで議論でいいですかね？ここではなく。
> 管理人様
>複数環境対応が終わった後に考えてみます
はい。お願いします。enum classと違い型制約が少ないですし、
コンパイル時定数なので配列の要素数指定やtemplate引数にも使えるのでさほど使い勝手は変わらないと考えます。
>vic さんへ
私はenchant.jsの簡単さがいいなぁと思っている人で、これに対抗できるのはDxLibのC++ラッパーぐらいだろう、と思っています。
C#は・・・某社が個人的に好きになれないのでどうも避けがちです。
>enum（const int 系？）
方やコンパイル時、かたや実行時の定数です。念のため
>namespace で#define をくくる
くくれませんよ？プリプロセッサとコンパイラのお仕事を混ぜてはダメです(C11の型判別マクロはどうなんだという話はさておき)
namespace でのくくりすぎがstd::chrnoのつかいにくさの一因だと思っています。type数多すぎんよ。
#defineは・・・コンパイラー間の差異を埋めるのにしか使わないなぁ・・・。下手に使うとIntelliSenseがトレースしてくれなかったり、IntelliSenseが落ちたり、メモリーとCPUをバカ食いするので。
あと関数の呼び出し階層を辿れなくなるので。
例えばDxLibのソースはそのせいで関数定義に飛んだりできませんし。
>直感的にＵＰできるのはワンドライブ公開かＶｅｃｔｏｒ公開（クリエイター登録申請は完了済み）でしょうか。直感的にＵＰできるのはワンドライブ公開かＶｅｃｔｏｒ公開（クリエイター登録申請は完了済み）でしょうか。
昔は私もGoogleDriveとかOneDriveとか使ってたんですが、コードを複数人で開発となると大変で・・・。conflictが。
そんなのに労力かけるのは間違ってるよなぁということで、
gitもmargeのやり方以外はすぐに理解できたので愛用しています。
>cout より printf の方が人気なのもそういう理由があるんじゃないでしょうか。
printfはVSとgcc/clangでコード共有すると#defineマクロが必須になるので嫌いです。
型安全性とその件がなければprintf使うんですが。はようconceptこい。
>boost に慣れるとstl はしたくないような話も聞きました
初めて聞いた・・・。
C++11でboostの多くが標準に取り入れられたから
行列(boost.ublas)とか
ネットワーク(boost.asio C++17に入りそう)や
xml, jsonの読み込み(Boost.property_tree)や
コンパイル時系でもやらないかぎりあんまりいらない気がします。
ようやくVisual Studioも2015でC++11にだいぶ対応しましたし(constexpr周り除く)
長文失礼しました。
> Namelessさん
ご承諾ありがとうございます、早速リンクページに追加させていただきました
紹介文等に不備がありましたらご指摘ください m(_ _)m
> リポジトリを作り直したときはURLの変更をお願いするかもしれません。
分かりました、その際はご連絡ください
> 管理人様
リンクページへの追加ありがとうございます
どうやらリポジトリを作り直す必要もなさそうです
完成度が上がってきたらまたここで宣伝させていただこうと思っています
enum化の検討は先の話になるとのことのようですが、
個人的には、改変後にライブラリとその周辺環境が不安定化してしまうことを懸念しております。
やるならば、Namelessさんのプロジェクトで、もしくは「新生」させるタイミングで
やった方がいいのではないか？と思っています。
具体的には長くなるので書きませんが、どちらかというと技術的ではないところの心配です。
(反対というわけではないです。心配性なだけです。)
たしかにbreaking changeになりますが、プリプロセス時メタプログラミングでもやってないかぎり影響が出るとは考えにくいのですが・・・、どうなんでしょう？
>やるならば、Namelessさんのプロジェクトで
そっちはenum classまたはenumになるでしょう、多分、きっと、おそらく