>>242
WM_LBUTTONDOWNとかWM_MOVINGとかWM_DESTROYみたいなイベントも扱う。
それら入出力関係・アプリ生存期間の制御関係のものと、ゲーム処理をいっしょくたに
扱える標準的インタフェースなんて作るなというのが主旨。
もし作ろうとすると
　1.イベントハンドラで統一
　2.やっぱ使い勝手悪いのでゲーム処理はenter_frame(), display(), move()の３つだけに集約
　　→タスクシステムいっちょあがり
となる。

あとenterframe()とdisplay()で分けたけど、よく考えたらenterframe()１個で足りるかも。
ゲーム処理は1フレームに1回、1つの関数呼ぶだけで足りるし。
というかenter_frame()さえもいらないかも。
どこかで誰かが全入出力デバイスの面倒見る必要は結局あるもんね。
俺はなんか分けてたからああ書いたけど。その辺はごめん。

重要なのは「入出力デバイス処理とゲーム処理は別物」ということ。
そして別物なので、「ゲーム処理にまでイベントハンドラ適用しようとすんな」ということ。
タスクシステム＝イベントハンドラ崩れorイベントハンドラの俺ゲーム最適化後というイメージを持ってる。
OSも昔とか組み込み系の貧弱な環境とかではユーザランドとOSの切り分け曖昧だったりOS無しで自前管理だったりするけど、
規模大きくなるとそれじゃ成立しなくなるのに似てるかも。

メインループとかの構造はそう、大体そんな感じでＯＫじゃね？　あんまそこは興味ない。
main関数からじゃなくいきなりイベントハンドラから始まる環境とかあるし、正直動けばそれでいい。
一応俺はそのd3ddev->Present()をdevice.wait_frame()に置き換えてその中でDispatchMessage()ぐるぐる回しつつ1フレーム待ってるやり方。