FPSを作ってみる@wiki
09)
最終更新:
slice
-
view
(2010/09/29)
なんか大事になっちょる.Luaにも弱参照と強参照を備えようという事になり
リソースマネージャの根っこから改変.
ちなみに強参照は所有権を持つが,弱参照は所有権を持たないリソースハンドルの事だ.
強参照はともかく弱参照は何に使うかと言うと例えば追尾レーザーの目標オブジェクトの保持や
デバッグの為に値表示する際にも監視するオブジェクトが破壊されたら出力も止めるとかですか.
強参照だとオブジェクトが破棄されませんからね.
リソースマネージャの根っこから改変.
ちなみに強参照は所有権を持つが,弱参照は所有権を持たないリソースハンドルの事だ.
強参照はともかく弱参照は何に使うかと言うと例えば追尾レーザーの目標オブジェクトの保持や
デバッグの為に値表示する際にも監視するオブジェクトが破壊されたら出力も止めるとかですか.
強参照だとオブジェクトが破棄されませんからね.
(2010/09/28)
昨日からどうしようか悩んだがinputクラス作り直し・・・だな.
ポーリングによるキー入力判定とバッファ形式での文字入力がごっちゃになっている.
この部分は半年は前に書いたので他人のコード感覚で読んだら無駄な箇所が結構ある.
エラー処理してそうでしてないとか.ジョイパッドの振動エフェクトも途中で放棄してあるし.
半端なオブジェクト指向で生のポインタを使っててLuaから触れなそーだなー等
ざっと挙げてこんな感じ.これはちょっと駄目だ.
ポーリングによるキー入力判定とバッファ形式での文字入力がごっちゃになっている.
この部分は半年は前に書いたので他人のコード感覚で読んだら無駄な箇所が結構ある.
エラー処理してそうでしてないとか.ジョイパッドの振動エフェクトも途中で放棄してあるし.
半端なオブジェクト指向で生のポインタを使っててLuaから触れなそーだなー等
ざっと挙げてこんな感じ.これはちょっと駄目だ.
入力デバイスの初期化についてはボタン数まで取得せずともデバイス名を列挙できれば
事足りるだろうと踏んで,そういう仕様に.
ただあんまりあれもこれも欲張ると簡単化の為にスクリプト採用したのに
結局Cで書くのと変わらなくなりそうだから注意か.
キーボードとマウスは明示的に初期化しなくてもデフォルトで使えていいよなあ・・
キーボードやポインティングデバイスが2つ以上接続されるケースも考えなくていいよね(多分)
事足りるだろうと踏んで,そういう仕様に.
ただあんまりあれもこれも欲張ると簡単化の為にスクリプト採用したのに
結局Cで書くのと変わらなくなりそうだから注意か.
キーボードとマウスは明示的に初期化しなくてもデフォルトで使えていいよなあ・・
キーボードやポインティングデバイスが2つ以上接続されるケースも考えなくていいよね(多分)
(2010/09/27)
ハンドルIDの予約は完了.
キー設定をLuaから読めるように,キーの状態をbooleanで返すクラスを用意.
input:pressing("識別ID")で押している間ずっとtrueが返り,
input:pressedは押したフレームのみtrue,
input:clickedなら押して離したフレームのみtrueとなる.
キーの区別をダイレクトにAキーやSキーとしなかったのは言うまでもなく
キーコンフィグの為である.
でもデバイスの列挙はまだ作ってない・・
input:pressing("識別ID")で押している間ずっとtrueが返り,
input:pressedは押したフレームのみtrue,
input:clickedなら押して離したフレームのみtrueとなる.
キーの区別をダイレクトにAキーやSキーとしなかったのは言うまでもなく
キーコンフィグの為である.
でもデバイスの列挙はまだ作ってない・・
(2010/09/23)#2
むぅ.思った以上に変更箇所があるな.
ハンドルIDを予約するのはいいがそれだとload()中で内部を参照できないじゃないか.
それで別にいいという場合もあるが・・・っと,いかんなぁ完ぺき主義は.
プログラムにおいて座右の銘は「制限を設ければ実装はシンプルになる」なので
そういう仕様にするか.
ハンドルIDを予約するのはいいがそれだとload()中で内部を参照できないじゃないか.
それで別にいいという場合もあるが・・・っと,いかんなぁ完ぺき主義は.
プログラムにおいて座右の銘は「制限を設ければ実装はシンプルになる」なので
そういう仕様にするか.
(2010/09/23)
リソース読み込み関数(Load())の中で同種のリソースを新たに読み込むケースで,リソース配列サイズが足りない際に
配列なので別の領域を割り当てしなおすわけだけどそしたら最初に呼んだLoad()関数に
処理が戻ってきたらThisポインタが違ってしまう.
知らずにアクセスすると当然一般保護エラーになってしまうわけで.はてどうしようかと.
配列なので別の領域を割り当てしなおすわけだけどそしたら最初に呼んだLoad()関数に
処理が戻ってきたらThisポインタが違ってしまう.
知らずにアクセスすると当然一般保護エラーになってしまうわけで.はてどうしようかと.
メンバ関数の呼び出し規約はthiscallと言う物でvisualstudioの場合は
レジスタecxにThisポインタを入れている.
じゃあ処理が戻ってきたら何らかの方法で新しいThisポインタを取得し,ecxに代入してやれば・・
と考えたがこれでは上手くいかないだろう.
ecxにThisポインタを入れるのはあくまでも呼び出す時の決まりなのであって
関数の中でebpやespにコピーして使おうがその先は保障されない.
...という事をインラインアセンブラを扱う関係で知っていたからだ.
レジスタecxにThisポインタを入れている.
じゃあ処理が戻ってきたら何らかの方法で新しいThisポインタを取得し,ecxに代入してやれば・・
と考えたがこれでは上手くいかないだろう.
ecxにThisポインタを入れるのはあくまでも呼び出す時の決まりなのであって
関数の中でebpやespにコピーして使おうがその先は保障されない.
...という事をインラインアセンブラを扱う関係で知っていたからだ.
オブジェクトのデストラクタとか考えるとload()で同種の別リソースを読んだらその時点でアウトか.
という事はload()の細工は無理.それを呼ぶマネージャでなんとかするしかない.
暫し考えた末に導き出した答えは
「メモリ領域を割り当てる前にハンドルIDを予約しておいて実際の読み込みは1つずつやる」
多分これで上手くいくはずだ・・・
という事はload()の細工は無理.それを呼ぶマネージャでなんとかするしかない.
暫し考えた末に導き出した答えは
「メモリ領域を割り当てる前にハンドルIDを予約しておいて実際の読み込みは1つずつやる」
多分これで上手くいくはずだ・・・
(2010/09/21)
なんかもう,進もうとしたらバグ発覚で1歩下がる状態が続いてモチベーション下がりまくり
scene構造は大体できてきたが,仕様煮詰めないと・・
scene構造は大体できてきたが,仕様煮詰めないと・・
(2010/09/15)
戻り値を複数返す仕組みを作ってみたり(C++とLuaで共通の記述)した.
もう少しで完成する.
インラインアセンブラ記述の部分が増えて微妙な気分ではあるがとりあえず気にしない.
もう少しで完成する.
インラインアセンブラ記述の部分が増えて微妙な気分ではあるがとりあえず気にしない.
場面の切り替えとリソース管理についても少々.
今後タイトル画面,ゲーム画面,ゲームオーバー画面・・等のゲーム状態と
そこで使うリソースを一纏めにSceneと呼ぶ事にした.
更にゲームSceneでアイテムメニューなんかを開いた場合を想定しSceneの上で別の子Sceneを呼び出せる仕様とした.
まだ実装に入ってないから,設計の是非についてはなんとも言えないが.
今後タイトル画面,ゲーム画面,ゲームオーバー画面・・等のゲーム状態と
そこで使うリソースを一纏めにSceneと呼ぶ事にした.
更にゲームSceneでアイテムメニューなんかを開いた場合を想定しSceneの上で別の子Sceneを呼び出せる仕様とした.
まだ実装に入ってないから,設計の是非についてはなんとも言えないが.
あとはエンジンの初期化方法か.リソースを読み込むクラスだけは予めC++で初期化しといて
その先のエンジン初期化等は全てLuaで行う.
具体的にはEngine.create(640,480,true)だ.
(引数は左から順にウィンドウサイズX,ウィンドウサイズY,フルスクリーンフラグ)
そしたらエンジンにアクセスする為のハンドルが取得できるので以後はコレを使って描画なりなんなりする.
リソースについてもテクスチャを読みたければTexture.create("file-name")と書けばハンドルが返ってくるし
サウンドならSound.create("file-name")となる.
これらはGC(ガベコレ)に回収された時点で後始末処理をする.楽々だ(多分).
その先のエンジン初期化等は全てLuaで行う.
具体的にはEngine.create(640,480,true)だ.
(引数は左から順にウィンドウサイズX,ウィンドウサイズY,フルスクリーンフラグ)
そしたらエンジンにアクセスする為のハンドルが取得できるので以後はコレを使って描画なりなんなりする.
リソースについてもテクスチャを読みたければTexture.create("file-name")と書けばハンドルが返ってくるし
サウンドならSound.create("file-name")となる.
これらはGC(ガベコレ)に回収された時点で後始末処理をする.楽々だ(多分).
描画と衝突判定の設定についてはほぼ確実に一悶着ありそうだし慎重に進めようか
(2010/09/10)
ここ2~3日はプログラムを触ってない時間が長い.
漠然と考えてるだけの時は気づかなかった仕様の不備(はっきり決まってない部分)がボロボロ出てくるものだな.
今日はスクリプトで動かせる範囲について思案していた.
漠然と考えてるだけの時は気づかなかった仕様の不備(はっきり決まってない部分)がボロボロ出てくるものだな.
今日はスクリプトで動かせる範囲について思案していた.
当初バッファの管理とかAPI呼び出しのお膳だてなどの面倒くさい処理を全部C++で記述し
Luaではエンジン初期化(解像度,フルスクリーンか否か),関数呼ぶだけでオブジェクトを作れて~なんて
軽く考えていたが.それでプログラムが書けたら苦労しないわけで.
以下に例を挙げてみれば
Luaではエンジン初期化(解像度,フルスクリーンか否か),関数呼ぶだけでオブジェクトを作れて~なんて
軽く考えていたが.それでプログラムが書けたら苦労しないわけで.
以下に例を挙げてみれば
- 実際にゲームを作る時に何の処理をどのようにLuaで記述するか,用意すべき関数は?
- 必要に応じてC++の関数を呼び出すわけだけどインタフェースは?
RS_CreateObj() 等のシステム関数を沢山定義しておく,それともエンジン自体を1つのオブジェクトとしてしまって
Engine.createObj() のようにドットでアクセスか?
Engine.createObj() のようにドットでアクセスか?
- DirectXの前のWIN32APIによるウィンドウ作成は誰が?C++側で自動的に1つ作成するか?
・・・なんだ,まだ殆ど何も決まってないじゃないか.それに
ちょっと形式の整ったゲームを作るとなればタイトル画面,プレイ画面,メニュー画面・・・とか,
シーン毎に必要なオブジェクト,リソースをまとめて管理する仕組みが必要だ.
これらをLuaに組み込むにはどうするか?
ちょっと形式の整ったゲームを作るとなればタイトル画面,プレイ画面,メニュー画面・・・とか,
シーン毎に必要なオブジェクト,リソースをまとめて管理する仕組みが必要だ.
これらをLuaに組み込むにはどうするか?
どうも今まで動画を撮る為にと即席でリソースを読み,アルゴリズムをソースにベタ書きした分の
ツケが回ってきているようだ.
ツケが回ってきているようだ.
(2010/09/08)
テクスチャやモデル等を読み込みながら文字がアニメーションする,所謂ローディング画面を実装したいのだが
何の対策もなしにDirect3Dオブジェクトを複数のスレッドから同時アクセスすると不具合が出る.
これを防ぐために初期化時にD3DCREATE_MULTITHREADEDというフラグを渡すのだが
ドキュメントによるとパフォーマンスの低下を招くとのこと.
どの位遅くなるかが良くわからんが,検索して出てくる掲示板などを見るに数パーセントの範囲のようだ.
もちろん自前でロック機構を設けるのも出来ない事は無かったがプログラムが長くなるし
開発段階では安定性を優先する方針なのでこのフラグに頼ることにした.
何の対策もなしにDirect3Dオブジェクトを複数のスレッドから同時アクセスすると不具合が出る.
これを防ぐために初期化時にD3DCREATE_MULTITHREADEDというフラグを渡すのだが
ドキュメントによるとパフォーマンスの低下を招くとのこと.
どの位遅くなるかが良くわからんが,検索して出てくる掲示板などを見るに数パーセントの範囲のようだ.
もちろん自前でロック機構を設けるのも出来ない事は無かったがプログラムが長くなるし
開発段階では安定性を優先する方針なのでこのフラグに頼ることにした.
それとLuaは数値の型としてデフォルトではdoubleを使う.
しかしD3Dは処理速度を稼ぐためかFPUの計算精度をfloatに変更してしまうようだ.
これは整数値を扱う際に問題で,floatは仮数部が24bitなので当然24bitまでしか精度が保障されない
(32bitのRGBA値を与えたら削られてしまう)
どうするか.大きい整数は扱わないと決めるという手もあるが今回は前述の”開発段階では~”の方針に従い
D3DCREATE_FPU_PRESERVEフラグで計算精度を保つようにした.
しかしD3Dは処理速度を稼ぐためかFPUの計算精度をfloatに変更してしまうようだ.
これは整数値を扱う際に問題で,floatは仮数部が24bitなので当然24bitまでしか精度が保障されない
(32bitのRGBA値を与えたら削られてしまう)
どうするか.大きい整数は扱わないと決めるという手もあるが今回は前述の”開発段階では~”の方針に従い
D3DCREATE_FPU_PRESERVEフラグで計算精度を保つようにした.
ここまで長々と書いたがなんのことはない.フラグ2つ加えただけっすな.
(2010/09/06)
Luaへのクラスの公開と資源管理は多分,出来た.使っていくうちに細かいバグは発見されると思うが・・
久々にインラインアセンブラを使った関係で思い出すのに時間掛かったり.
久々にインラインアセンブラを使った関係で思い出すのに時間掛かったり.
あとはテクスチャやサウンド等のリソースを読み込んで相互にやり取りする仕組みとか.
思案の結果リソースの中身のデータはC++で保持するようにした.
まぁリソースにはDirectXのハンドルも含まれるしデータに改変や
計算を加えたりといった事を考えれば処理効率の点で当然と言えば当然なのだが.
思案の結果リソースの中身のデータはC++で保持するようにした.
まぁリソースにはDirectXのハンドルも含まれるしデータに改変や
計算を加えたりといった事を考えれば処理効率の点で当然と言えば当然なのだが.
Lua又はC++でリソースを読み込んで使い,必要なくなったリソースはLuaでリソースハンドルがGCに回収された際に
参照カウントを減らし(C++側とLua側で共通)両方とも保持されてないと分かった時点で解放処理をする.
基本動作はこれだけだ.仕様の不備は使っているうちに出てくるだろう.
そういえばエラー処理もろくにしてないな.
参照カウントを減らし(C++側とLua側で共通)両方とも保持されてないと分かった時点で解放処理をする.
基本動作はこれだけだ.仕様の不備は使っているうちに出てくるだろう.
そういえばエラー処理もろくにしてないな.
現在の目標はサウンド再生,テクスチャ付き2Dオブジェクト,キー入力受付,描画処理,
デバッグ用文字表示,後できれば2Dの衝突判定 といった最低限の動作
これらをスクリプトで記述して動かせる状態まで持っていくことだ.
度々思うのだが自作エンジンの名前が決まっていないから何と書いて良いか困る(自分ではresonantと呼んでいるものの)
デバッグ用文字表示,後できれば2Dの衝突判定 といった最低限の動作
これらをスクリプトで記述して動かせる状態まで持っていくことだ.
度々思うのだが自作エンジンの名前が決まっていないから何と書いて良いか困る(自分ではresonantと呼んでいるものの)
添付ファイル