戻る


2013/11/28 07:05

とりあえずプロジェクト名を変更した。

今まで使っていたプロジェクト名は管理用インターフェースのディレクトリ名にした。で、新しい名前空間をゲーム用インターフェースのディレクトリ名にして、プロジェクト名はそっちにすることにした。

ソースの方も名前空間とかincludeとか型とかの記述を全部置換した。ビルドが通って、デモが動作するところまでは確認したけど、量がなかなか多かったためなにかミスしてないか不安だ。

まー、ミスってたら直すだけのこと。気にしても仕方がない。

起きたら、さっそくOpenGL対応を進めよう。片付いたら、今まで作った部分も見直していこう。


2013/11/28 03:22

OpenGL対応を進めている。

ちょっと方針を変えるべきかもしれない。作り直しとかは必要ないんだけど。

インターフェースの定義とそれを実装するライブラリ、ライブラリを運用するプログラムはそれぞれ別にしているけど、その依存関係を変えるべきかも。

ライブラリとプログラムはどちらもインターフェースに依存させているが、やはりプログラムはライブラリに依存させる方がいいかもしれない。

ライブラリを運用するプログラムから、ライブラリを使用するゲームを実行するわけだけど、同じインターフェースを提供すると困ることがある。

基本的に、プログラムからゲームを実行するという関係からも分かる通り、プログラムはゲームより上位の存在なのだ。プログラム側ではできるけど、ゲーム側ではできない、というような処理を存在させたい。

簡単に言えば、プログラム側で生成したものをゲーム側に渡し、それをゲーム側で使用して色々させたいが、生成自体をゲーム側でやらせたくないだとか、渡したものをゲーム側で勝手に破棄させたくないだとか、そういうこと。

そのためには、そういったプログラム側でやらせたい処理のインターフェースはライブラリの中だけに存在させ、ゲーム側も利用するインターフェースには存在させない、というようなことが必要になってくる。

なので、プログラムはライブラリに直接依存させた方がいいかな、と考えたわけだ。

でもそれは早計かもしれない。もっと考えたら色々案が出てきた。

例えば、インターフェースプロジェクトを2つに分ける。アプリ用と管理用の2つに分け、アプリ用はゲーム側が使い、アプリ用をカバーする管理用はプログラム側が使う。

プロジェクトを2つに分けなくても、処理を実装するライブラリを別々にするという手もある。それが一番手っ取り早いかもしれない。

で、そういうことをするとなると、今まではまぁいいかで済ませていたものも、分割するべきな気がしてきた。

とまぁ、このようなことをなぜ考え始めたかと言えば、OpenGL対応が関わってくる。

OpenGLのパラメータは、ゲーム側に設定させたくないのだ。

パラメータ自体は必要であり、それを使用したOpenGLの初期化、つまりコンテキストの生成はゲーム側で自由にできるようにしたいが、パラメータの設定はゲーム側でやらせたくない。パラメータ自体は、プログラム側が生成した1つだけがあればよく、ゲーム側は生成も破棄もする必要がない。

そのような要件を満たすにはどうしたらいいか考えたところ、そんな感じにする必要がありそうだな、となったわけだ。

さて、どこから取り掛かろうか。


2013/11/24 04:49

linux用のウィンドウ制御できた。

前に作ったやつは、ウィンドウのイベントを処理するスレッドとは別に描画用のスレッドを作るという、1つウィンドウ作っただけで2つのスレッドが走り出すような感じにしていたんだけど、それをやめた。

ウィンドウのイベントを処理するスレッドだけにしたので、記述が単純になった。

描画用のスレッドなんてのは、ライブラリ利用側でどうにかすればいいのだ。

C言語のインターフェースのC++ラッパーを使って、動作確認用のデモを色々作っていたのだが、せっかくなのでC言語のインターフェースをC言語で直接叩いてみようかと思ったがやめた。

C言語のインターフェースでは、ウィンドウのイベント処理を行なうイベントハンドラを関数ポインタでしか処理できない。そしてその関数の引数に、余分なデータはない。

C++ならstd::function、ファンクタで処理する形になっているので、関数の引数以外のデータを持たせられるのだが、C言語のインターフェースではそれができないのだ。

つまり、複数のイベントハンドラ間でデータを共有したり受け渡したり、といったことが、グローバル変数を使うしか方法がない、という感じになってしまっている。ごみくずである。

C言語のイベント周りのインターフェースが無駄になってしまった香りがする。C/C++以外の言語に対応する場合も、多分C++のファンクタを使ったインターフェースを使うだろうし。まぁいいか。

というわけで次は運用の方に関わってくるウィンドウ、メインウィンドウにとりかかろうと思ったが、気が早いかもしれない。

だって、そんな特殊なウィンドウ作ったところで、まだウィンドウに描画できないんだもの。先にOpenGLをやっつけるべきか。

OpenGLコンテキストに関係する部分は大して量がないはずだし、OpenGL関数についての部分はほぼ使い回せるはずだし。ぱぱっとやってしまうか。

あ、ウィンドウを属性や位置を指定して生成する関数作ってなかった。まぁいいか。必要になったら追加しよう。メインウィンドウでサイズ固定ウィンドウが必要になるだろうし。


2013/11/23 14:42

開発は順調に進んでいる。

構成とか、だいぶいい感じになってきている。

言語別のインターフェースの定義、その実装、その運用をそれぞれ別プロジェクトに分けた。

インターフェースを実装した運用プログラムであれば、その実装ライブラリがなんであろうと、動かせるような感じになっている。

インターフェースの定義プロジェクトには、実装が空のソースを含んでいる。

そのソースをビルドして作った動的ライブラリを使えば、実際に実装したライブラリがなくても運用プログラムの開発を行なうことができる。

実装が空なので、それを使って実行してもまともに動かすことはできないが、実行時には実際に実装したライブラリをリンクすればいい。

インターフェースを同一にすることで、実装と運用を完全に分離することが重要なのだ。

インターフェースを定めてしまえば、その運用と実装を、完全に別々に開発することができる。

今のところ、インターフェースプロジェクトはCとC++の2つを作っている。

C++のインターフェースから、Cのインターフェースを実装したライブラリを使うためのラッパープロジェクトも作っている。

Cのインターフェースは関数名の重複ができなくて扱いにくいためだ。

最初からC++のインターフェースを実装したライブラリを作ればいいと思うかもしれないが、CのインターフェースをC++から利用できるように、Cのインターフェースで作っておけば他の言語から利用しやすいのだ。

後々、D言語やその他の言語用のラッパーも作ろうと考えている。

それで、今はウィンドウ周りの実装を作っている。前に作ったものを流用しているが、処理を見直して、より単純な形にした。前に作ったものは余計に作り込みすぎていた点があったのだ。

それが終わったら、運用の方に関わってくるウィンドウについて作ろうと考えている。どのように実装するかは、まだもやもやしているが。


2013/11/05 19:06

dlopen()とかLoadLibrary()とかの挙動を確認した。

linuxの.soファイルには未定義シンボルが存在していても、実行時に解決することで問題なくできるんだけど、windowsのdllはそうはいかなくて残念。

LoadLibrary()を使って実行時にリンクするにしても、どの関数がなんて名前のライブラリに含まれるか、などをビルド時に確定しなければならないというのが残念だ。

とはいえ、そこまできつい制約というわけでもないのでいいけど。

ゲームを作る際に使うのはヘッダファイルだけ(windowsの場合はインポートライブラリも必要)、ヘッダファイルに記述されている関数や構造体の実体は、ゲームを起動するためのプログラムの方にライブラリとして実装する、みたいな感じで。

うん、イメージできてきた。根底のインターフェースはCで用意しておいて、それをラッピングすることにより様々な言語に対応できる形にしよう。今度はちゃんとできるはずだ。


2013/11/05 13:38

次の段階に進んで気付いたことは、どうやら構成が間違っているらしい、ということだった。

早い話が、また作り直しである。だがその前に検証しておかなければならないことがいくつかあるので、それらを試してから。

ハードウェア周りの抽象化としてdpを作り、その上にもう1つライブラリを重ねてそれ以外の機能に対応、そのライブラリとdpを使って作る、という感じをイメージしていたが、ハードウェア周りとそれ以外の機能を分けることにあまり意味がない感じがした。

逆に、名前空間を分けていたりして扱いにくいのだ。

よく考えたら、ライブラリの機能を使う、ゲーム部分は単体で動作できなくてもいいわけだし、そうなると機能の実装を行なうのも別の場所でいいなぁ、とか。

そんな感じで色々考えた結果、またしてもプロジェクト作るところからやり直した方がいいんじゃないだろうか、という印象。

というわけでまずは機能の検証から。

ライブラリの名前も変える。dpの上に重ねる予定だったライブラリの名前を使うことにする。


2013/11/02 05:40

luaスクリプト見直していたら、やはりというか私が悪かったようだ。

スクリーン切り替え処理がグローバルではなく各ウィンドウに対する処理として設定していた。

ディスプレイにウィンドウが存在しないといかんというのも仕方がないというものだ。

バージョンを上げることになんとか成功したので、それに合わせて修正を加えていたら気が付いた。

とかいうのを、前の日記を書いて、起きた後に作業してたら判明したので書いていたんだけど、途中で書くのやめて今日まで忘れてた。

どうにも、どう進めたものか、どう設計したものかイメージがまるでまとまらなかったのだけれど、ようやく見えてきた。

とりあえずは、直接起動機能を作ることにした。ランチャのようなものは、それで起動したものとして実装するような感じにする。

その辺から考え始めたら、ディレクトリ構成とか、起動に必要なデータとかが見えてきた。

見えてきたのはいいのだが、機能を実装するとなると、その機能を実装するために必要な機能がたくさんある。

完成は遠そうだなぁ。


戻る