日記(1052)

履いていた靴があまりにもボロだったので新しい靴を買いました。
試し履きせずに買ってしまったのですがピッタリだったようで安心しました。

「パネルγ」のプレス機の絵を描きました。
金属光沢がよくわからなかったのですが…まあまあ妥協しておくことにします。
しかし256色パレットを使っているのにまだ16色パレットにある色しか使ってない…色を使うために絵があるわけじゃないけど、気になるところではあります。

パネルγの色パレットの設定を作りました。
ウィンドウモードでパレットが指定できないのは多分サーフェスがパレットモードじゃないから。
となれば正式版ではフルスクリーンモードだけにするか…？
それともウィンドウモードではパレットアニメーションを使わないことにするか…？
いっそのこと3Dをもう一度やり直すか…？
実際に使ってみたら良い点悪い点がよくわかりますのー。

12月も終わりというこのころになってやっと「冬の寒さ」がやってきて、思い出したように雪が降り出しました。
昨日までの寒さは秋の肌寒さ。
雪は地面で速やかに融けてしまいましたが。

最近キリ番とかにあまりこだわらなくなってきたのでカウンターの文字の大きさを普通の大きさで統一するようにしました。
以前のように大きさが変わるバージョンがいいという人がいたら戻しますが。

まずはウェイト処理。
フレームスキップはせず、必ず1msは休むという動作にしたので遅れるときは普通に遅れます。
毎フレーム実行したフレーム数と最小待ち時間(1ms未満だと遅い)を記録しているのでそれが重さの指標になりそうです。
あと、スクリーンショットを更新しました。
本当のスクリーンショットではなくこういうふうにできればいいなという完成予想図なんですが。
あ、DrawBaseの派生クラスとしてGDIによる描画を作ってみてもいいかも。

さて、処理落ちが起こるとゲームのテンポが変わってしまい、ランキングを開催したいと思っていることもあって、公正さに欠けるのは致命的だと思うので、最も時間のかかると思われる描画処理について考えていました。

1.普通に描画する。

とにかく簡単。
でもマシンの性能によっては普通に処理落ちします。

2.遅れていたらフレームスキップする。

例えば２フレームの時間で描画していたら、ゲーム処理→描画→ゲーム処理→フレームスキップ→ゲーム処理、となって、２フレームの時間が経過した跡に瞬時に２フレーム分の処理が行われ、これはこれで公正さが失われます。

3.描画命令をキューに入れて後でまとめて実行する。

「後で実行」を別スレッドで管理すれば描画でもたついている間にも裏ではゲームが普通のスピードで進んでいるため実質的な公正さは保たれるはずです。
ただし、「キューに入れる」とという作業が余計に加わるので全体的な速度そのものはかえって遅くなりますし、メモリ使用量もキューの分だけ増えます。

プライマリサーフェスを作ってました。
フルスクリーンとウィンドウモードで扱いが違うから少し厄介です。
もしかしたらパネルγ、かわいい女の子は別として、何か別のキャラクターが出てくるかもしれません。
今のところはまだ可能性の段階ですが。

変更。
空のクラス→クラスそのものを作らない。
そうでもしないと純粋仮想クラスのメンバとやらがまずいんじゃないかなと思って。
で、例のDirectDraw、早速実装してみました。
さて、ウィンドウモードとフルスクリーンモードでは画面の反映の仕方が違うそうだけど、どうなるか。
なんとなくBGMのパターンを増やしてみたり。
神秘的かもしれないイメージで作ってみたけど、だけど神秘のカケラもないこのゲーム、どうなることやら。
低い点数のときは暗い曲調なのです。

練習用としてはMazeCubeを作ることにしました。
MazeSquareの3D版っぽい位置付けだけどこっちは完成したら一般公開します。
とはいえルールすら決まってなくて、完成するかどうかすら怪しいものですが…
ギヤバネくんが歩き回るゲームになるような気がしないでもない。
DirectX AppWizard使用。

で、めでたく本番用になったパネルγ、DirectDrawを使えるようにするため、Direct3DとDirectDrawを切り替えやすいようにしていました。
Direct3D使用時はDirectDrawクラスが空のクラスになり、DirectDraw使用時にはDirect3Dが空のクラスになって使わないことになります。
どちらでも同じ感覚で使えるように基底クラスとしてCDrawBaseを作って、その派生クラスとしてCDirectDrawとCDirect3Dを作っています。