RSSイントレ。
Tag for "ツクールもどき"
ツクールもどきのスクリプト用に、文字列から四則演算するメソッドを書いてみました。
相変わらず、あちこちのサンプルコードから引っ張ってきてるのはご敬愛。
今回は長ったらしいのでファイル添付で。
20090309-Evaluation.cs(3.1KB)
括弧や乗算・除算による計算の優先度もちゃんと考慮されています。
数値の扱いにDecimalを使ったので、計算は正確ですがもしかしたら重いかも。
ですが、実数演算にも桁落ちせずに対応しています。
あと、剰余(割った余り)にも何となく対応。
やっていることは、文字列を文字に分解(+不要な文字のフィルタリング)して、
計算優先度が低い順から、項目の左から右へ文字を評価していってます。
ちょっと適当なんですが、うまくいっているようで。(汗)
相変わらず、あちこちのサンプルコードから引っ張ってきてるのはご敬愛。
今回は長ったらしいのでファイル添付で。
20090309-Evaluation.cs(3.1KB)括弧や乗算・除算による計算の優先度もちゃんと考慮されています。
数値の扱いにDecimalを使ったので、計算は正確ですがもしかしたら重いかも。
ですが、実数演算にも桁落ちせずに対応しています。
あと、剰余(割った余り)にも何となく対応。
やっていることは、文字列を文字に分解(+不要な文字のフィルタリング)して、
計算優先度が低い順から、項目の左から右へ文字を評価していってます。
ちょっと適当なんですが、うまくいっているようで。(汗)
本日のプログラミングテーマは、ずっと投げていたフレームレート調整部分を考察。
まずは基本のおさらい……と。
フレームレートの調整は、大きく分けて、
描画回数を特定の回数に固定してその回数から移動量を割り出す方法(A派)と、
全力で描画して処理時間から移動量などを割り出す方法(B派)があります。
A派はユーザーのキー入力などの反応タイミングが重要になる『ゲーム向き』で、
処理が重くなった場合でも移動量は変わらないので、ユーザーの正確な反応が期待できます。
B派は実際の時間経過が重要になる『デモ・映像向き』で、
処理が重くなった場合でも柔軟に移動量が変化するため、演出(音声など)との正確な同期が期待できます。
どちらも一長一短なので、場面に合わせて使い分けられるようになれば理想なのですが、
実装の関係上、どちらかを選択するか、どちらかを派生するという方法になると思います。
ツクールもどきのエンジンでは、B派をベースにA派の利点を取り込む事にしました。
一応、B派の派生と言うことになるんでしょうけど。
B派での移動量を割り出す際に一定の制限を設けることで、A派のような振る舞いをさせます。
制限をかけなければ通常通りB派の挙動になるので、場面によって切り替えるのも容易なはず。
A派には、一定のフレーム処理を間引いて処理を軽減させる『フレームスキップ』というのがあります。
移動量が固定なA派の弱点をある程度克服するものです。
B派にそのままA派の振る舞いをさせると、この弱点もついてきます。
それをどうするか… 考えている段階で本日は終了。
カウンタ60,000Hit突破。 いつも来てくれてありがとう。
まずは基本のおさらい……と。
フレームレートの調整は、大きく分けて、
描画回数を特定の回数に固定してその回数から移動量を割り出す方法(A派)と、
全力で描画して処理時間から移動量などを割り出す方法(B派)があります。
A派はユーザーのキー入力などの反応タイミングが重要になる『ゲーム向き』で、
処理が重くなった場合でも移動量は変わらないので、ユーザーの正確な反応が期待できます。
B派は実際の時間経過が重要になる『デモ・映像向き』で、
処理が重くなった場合でも柔軟に移動量が変化するため、演出(音声など)との正確な同期が期待できます。
どちらも一長一短なので、場面に合わせて使い分けられるようになれば理想なのですが、
実装の関係上、どちらかを選択するか、どちらかを派生するという方法になると思います。
ツクールもどきのエンジンでは、B派をベースにA派の利点を取り込む事にしました。
一応、B派の派生と言うことになるんでしょうけど。
B派での移動量を割り出す際に一定の制限を設けることで、A派のような振る舞いをさせます。
制限をかけなければ通常通りB派の挙動になるので、場面によって切り替えるのも容易なはず。
A派には、一定のフレーム処理を間引いて処理を軽減させる『フレームスキップ』というのがあります。
移動量が固定なA派の弱点をある程度克服するものです。
B派にそのままA派の振る舞いをさせると、この弱点もついてきます。
それをどうするか… 考えている段階で本日は終了。
カウンタ60,000Hit突破。 いつも来てくれてありがとう。
今日のツクールもどき。
エディタのベースとなる部分のクラス群を作成完了。
データのロードやデータ変更に同期してViewの変更などを、
ある程度の共通のフレームワークに納めることで今後の開発を容易にするのがねらい。
おかげでアンドゥのロジックを何処に組み込めばいいか不明になったので、それはひとまず放置。
編集後のデータも、保存されるまでは保持しちゃうけど一時的にこの仕様で。
エディタ方面での作成作業は、あとデータベースの一部のエディタを作ってしまえば一段落になる。
もうひとガンバリだ。
エディタのベースとなる部分のクラス群を作成完了。
データのロードやデータ変更に同期してViewの変更などを、
ある程度の共通のフレームワークに納めることで今後の開発を容易にするのがねらい。
おかげでアンドゥのロジックを何処に組み込めばいいか不明になったので、それはひとまず放置。
編集後のデータも、保存されるまでは保持しちゃうけど一時的にこの仕様で。
エディタ方面での作成作業は、あとデータベースの一部のエディタを作ってしまえば一段落になる。
もうひとガンバリだ。
本日のツクールもどき。
エディタやランタイムのベースとなるベーシックアーキテクチャはほぼ終了。
実装はMVCパターンを目指していたはずなのに、いつの間にかMediatorパターンに近くなった感じ。
WindowsFormsデザイナでの連携も考慮したらDoc/Viewにならざるを得ない感じなので、ちょっと仕方ないかと思ったり。
デザイナのサポートがあるのでこっちでいいかと割り切ってみる。
某プロジェクトが動き出したので、こっちも仕上げないと大変なことになる。
さっさと進めないと。
エディタやランタイムのベースとなるベーシックアーキテクチャはほぼ終了。
実装はMVCパターンを目指していたはずなのに、いつの間にかMediatorパターンに近くなった感じ。
WindowsFormsデザイナでの連携も考慮したらDoc/Viewにならざるを得ない感じなので、ちょっと仕方ないかと思ったり。
デザイナのサポートがあるのでこっちでいいかと割り切ってみる。
某プロジェクトが動き出したので、こっちも仕上げないと大変なことになる。
さっさと進めないと。
本日のツクールもどき。
アンドゥとリドゥの実装。…実装自体は難しくない。
アンドゥは、データに変更が加わる前にその状態を保持しておけばいいし、
リドゥも似たような実装で可能。
ただ、『その状態』を全部保持しておくのはメモリには優しくないので、
『その状態』にするための『操作』を保持させるという方向に変更。
ちょっとプログラムが面倒になるんだけど、メモリ使用量はぐんと減るはず。
ツクールのような統合環境を目指しているので、こういうのは避けて通れない。
取り敢えず、構想を纏めたところでスクラップを書いてみることにします。
ちなみにアンドゥとかの実装は、Cocoaがいい感じの実装をしているらしい。
今度、Cocoaのアーキテクチャをじっくり眺めてみようかな。
アンドゥとリドゥの実装。…実装自体は難しくない。
アンドゥは、データに変更が加わる前にその状態を保持しておけばいいし、
リドゥも似たような実装で可能。
ただ、『その状態』を全部保持しておくのはメモリには優しくないので、
『その状態』にするための『操作』を保持させるという方向に変更。
ちょっとプログラムが面倒になるんだけど、メモリ使用量はぐんと減るはず。
ツクールのような統合環境を目指しているので、こういうのは避けて通れない。
取り敢えず、構想を纏めたところでスクラップを書いてみることにします。
ちなみにアンドゥとかの実装は、Cocoaがいい感じの実装をしているらしい。
今度、Cocoaのアーキテクチャをじっくり眺めてみようかな。
Utilities
- タグ
- カレンダー
- 最近の更新
- Adsense