Open lriki opened 3 years ago
しない。
以下、検討結果。
Lumino は次の2つのエントリーポイントの作成方法がある。
Application の実装では仮想関数などの知識が必要となるため、メインループと比べてやや前提知識のレベルが上がる。 簡単なサンプルではメインループを使って実装した方がわかりやすいのでは?
特に C と HSP3 へ対応するにあたって、継承といった概念の無い言語向けに作るサンプルが少し難しくならないか心配。
メインループの隠蔽が必要なケースに対応するため。
Web や Android 環境で期待通りのメインループを実装することは困難で、どうしても使いたいときはサブスレッドを使う必要がある。 ただサブスレッドでは UI 関係の API に制約がかかることが一般的で、問題の原因となりやすい。
また update のタイミングをエンジン側で完全に制御できるようになるので、 一時停止、ヒットストップ(これは Application でやるべきではないかもしれないが) といった時間制御がやり易くなったり、 メッセージキューが空なら更新しないことで負荷を落とすといった制御をすることが可能になる。
オブジェクト指向の知識を前提とする懸念はあるが、アプリの規模が大きくなりシーン遷移が必要になってくると、 どのみち同じように継承&仮想関数(or コールバック登録)の実装が必要になったり、この辺りの知識が必須になってくる。
Moduler Engine として、他のフレームワークに組み込めるようにするため。
ただこの場合、FPS制御などは他フレームワーク側に任せることになるため Engine::update はやめて、FrameWindow の描画関数や更新関数を直接呼び出すようにした方がいいかもしれない。
逆にこのFPS制御やシステムのメッセージキューの処理を誰に任せるかはっきりさせない限り、メインループサポートは待った方がよさそう。 (例えば HSP3 で await は誰が呼び出せばいいの?とか)
ざっと集めてみたゲームエンジン・ライブラリでは、Application クラス相当のエントリーポイントとなっているものが圧倒的に多かった。
メインループをサポートしているのは、低レイヤーの描画ライブラリであることが多い感じ。
Unity など大きなゲームエンジンや、Web系などプラットフォームの制約がかかるものは全てこちら。
しない。
以下、検討結果。
動機
Lumino は次の2つのエントリーポイントの作成方法がある。
Application の実装では仮想関数などの知識が必要となるため、メインループと比べてやや前提知識のレベルが上がる。 簡単なサンプルではメインループを使って実装した方がわかりやすいのでは?
特に C と HSP3 へ対応するにあたって、継承といった概念の無い言語向けに作るサンプルが少し難しくならないか心配。
対案
なぜ Application クラスを使うのか?
メインループの隠蔽が必要なケースに対応するため。
Web や Android 環境で期待通りのメインループを実装することは困難で、どうしても使いたいときはサブスレッドを使う必要がある。 ただサブスレッドでは UI 関係の API に制約がかかることが一般的で、問題の原因となりやすい。
また update のタイミングをエンジン側で完全に制御できるようになるので、 一時停止、ヒットストップ(これは Application でやるべきではないかもしれないが) といった時間制御がやり易くなったり、 メッセージキューが空なら更新しないことで負荷を落とすといった制御をすることが可能になる。
オブジェクト指向の知識を前提とする懸念はあるが、アプリの規模が大きくなりシーン遷移が必要になってくると、 どのみち同じように継承&仮想関数(or コールバック登録)の実装が必要になったり、この辺りの知識が必須になってくる。
なぜメインループをサポートするのか?
Moduler Engine として、他のフレームワークに組み込めるようにするため。
ただこの場合、FPS制御などは他フレームワーク側に任せることになるため Engine::update はやめて、FrameWindow の描画関数や更新関数を直接呼び出すようにした方がいいかもしれない。
逆にこのFPS制御やシステムのメッセージキューの処理を誰に任せるかはっきりさせない限り、メインループサポートは待った方がよさそう。 (例えば HSP3 で await は誰が呼び出せばいいの?とか)
Research
ざっと集めてみたゲームエンジン・ライブラリでは、Application クラス相当のエントリーポイントとなっているものが圧倒的に多かった。
メインループをサポートしているのは、低レイヤーの描画ライブラリであることが多い感じ。
Application クラス相当
Unity など大きなゲームエンジンや、Web系などプラットフォームの制約がかかるものは全てこちら。
Amethyst(rust)
Piston(rust)
Panda3D(python)
pyxel(python)
pyglet(python)
kivy(python)
KivEnt(python)
Tkinter(python)
defold(lua)
love2d(lua)
Gosu(ruby)
Shoes(ruby)
Ruby2D(ruby)
DotFeather(C#)
Stride(C#)
Ogre(C++)
openFramework
Cinder
Pomdog(C++)
MEGA(C++)
Processing
MainLoop
SDL
Altseed
Siv3D
DxRuby
pygame(python)
rubygame(ruby)