sourceforge.jp のCVS serverに現在開発中のクライアントの最新版のソースコードをcommitしました。module-name は sample/shudra です。

詳しくはSourceForge.jp: ソースコード管理を御覧下さい。

BuildにはSDL, SDL_net, SDL_ttf, SDL_image, OpenGL (Mesa)が必要です。
また、makefileの記述を適切に変更する必要があります。
（FreeBSDで各ライブラリをportsからインストールした場合に限り変更の必要はありません。）

マウスカーソルによるオブジェクトフォーカス検知機能を実装しました。
とりあえず確認のため、フォーカスされたオブジェクトの色を変えるようにしてます。

フォーカスのエフェクトに付いては後ほど改善します。
どういうのが良いか案があればコメントいただけると助かります。

実際のオブジェクト位置に基づいてオブジェクトを表示するようにしました。
マウスホイールでzoom-in/out ドラッグで表示位置の移動、カーソルキーでtiltが出来るようにしました。
左右のtiltに関してはもうちょっと調整が必要かと。

現在こんな感じです。

描画部分のコーディングに取り掛かりました。
とりあえず現在は下の画像のようにquarter viewで描画する部分のテストまで出来ました。



現在はまだ、実際のオブジェクトの位置を反映して描画しているわけではないです。

現在プラットホーム依存部分をSDLに書き直す作業を行っています。

今回はちょっとインフォーマルな感じで。

データ受信とプレイヤー入力受付と描画と、それとサウンドもか、のそれぞれの処理をどうやって実行すべきか迷っております。

データの受信とプレイヤーの入力は非同期的に起こる。

描画は基本的に描画周期60fpsとか30fpsとかで同期的に起こる。
ゲームのメインルーチンは描画のタイミングに合わせて進行され、ゲームの進行も基本的にはそちらに合わせて行われる。
プレイヤー入力は非同期的に起こるとはいえ、入力のゲーム状態に対する反映はゲームのフレーム・タイミングに合わせて同期的に行われる。

そこまではいい。

じゃあデータ受信はどうしたらいいんだろう。
Threadでも使うか？
どうせプロトコルのparse部分でBoostに染まってしまっている訳だからboost::threadを使うか?
けど、ゲームの状態保持部分などのリソースへのロックとかめんどくさいんだよな。

プレイヤー入力と同等に扱えばいいんじゃないだろうか。
select()がsocket descriptor がreadableと返すタイミングが考えどころか。ってかSDLでselect()はどうなるんだ？

SDL Net Tutorial

SDLNet_CheckSockets:
int SDLNet_CheckSockets(SDLNet_SocketSet set, Uint32 timeout)
Check and wait for sockets in a set to have activity.

とりあえずこれ使えばプラットフォーム依存は避けられるか。

だけどそのくせreadableが読み出せるけど受信途中でEOTまで受信していない状態なのか、それともEOTまで受信し終わった状態なのかそのへんがグレーなのは変わらんか。
さっきからなんでこれを気にしているかといえば、おそらくそのへんでパフォーマンスが大きく変わるからだ。
まードライバの実装依存なんでそのへんを気にするのはある意味ナンセンスか。
あくまでselect()はread()してもblockしないという条件を満たしているということを保証しているだけなのだから。


っつーことでなんか良いアイディアがあればコメント欄にて教えてください。

Vimukti VS server program をdaemon化しました。

この変更によるクライアントへの影響はありません。