トップページのカウンターを強化しました。
結局ロック処理は行わず、開いた結果が変だったらしばらく待ってもう一度読み直し、それでも変ならバックアップから読みにいくという方式にしました。
バックアップも壊れていたらもうカウントは諦めます。
ところでBomber丸WorldのHTML表示、どうにも不安定だと思っていたら、配列の大きさ決定のところで、バイト数でカウントすべきところを文字数でカウントしていたため、長いマルチバイト文字の文章だった場合メモリエラーが起こっていました。
昨日の時点で把握できなかったのは、部分文字列のためのバッファに全体のデータを入れていたために、部分文字列のバイト数＜全体の文字数となっていたからでした。
あと、タグの後の最初の1文字をうまく自動改行できなかった問題を解消しました。
Shift_JISのデータがどんな範囲を取りうるかをあまり意識していなかったため嵌りかけました。
読み込んだ1バイトがマルチバイト文字の1バイト目の可能性がある間はスキップするという処理を書いていたのですが、実際には、マルチバイト文字の2バイト目はどんなデータが来てもよいので、「1バイト目にあった場合はマルチバイト文字の1バイト目として機能するデータ」が2バイト目に来る可能性もあったわけで、そういうのまでマルチバイト文字の1バイト目として解釈するとまともな文字列として矛盾が出るわけです。
だから、直前に見たのがマルチバイト文字の1バイト目ならば次は1バイト目じゃないという結果を返す関数を作ってみたのですが、この関数が、理由はよくわかっていないのですがあるタイミングで判断を誤って逆の結果を返してしまい、結果としてそれが原因だとは想像もつかないエラーが出てしまい、根本的な原因を見つけるのに時間がかかってしまいました。
結局のところ、マルチバイト文字の1バイト目が来たら忘れないうちにさっさと2バイト目を読み込んでしまうことでこの問題は解決しました。
そんなわけで、表示に関してはyaneTextDrawよりも充実したものが出来上がりました。
表示結果がイタリック体や打消し線・下線付きでも正確であることや、理屈の上ではyaneTextDrawより数倍画像生成が速く、解像度変化への対応も自動で可能であり、「外字」という特別な枠組みを設けずに素直にimgタグで画像の表示が可能で、テキスト表示の拡張であるがゆえにただの文字列からある程度自由な装飾まで可能であり、自然な形で自動改行もされ(ただしワードラップは未対応のはず)、セリフ表示への利用向けに特定文字数相当の部分のみの表示などなど、RPGのセリフ枠に使うためにかなりyaneTextDrawとは違うものになりました。
まあ、良く頑張った自分。ということで。
なーんかBomber丸WorldのHTML表示、文字列の大きさの計算で手間取ってます。
とりあえずGetTextExtentExPoint使ってみるかーというところで、戻り値のそれぞれの文字までの距離の配列alpDxはマルチバイト文字に対してどうなるかがわからないとか、まあ、そんなところなんです。
あと、HTML解析で一部の重要な実体参照が使えるようになったりもしました。
なんというか、イタリック体の処理が面倒ですね。
あまり使いどころがないのに！
日記PHPに既に書いた日記の編集機能をつけました。
以前に編集フォームだけ作って放置していたのをやっと実装できました。
で、Bomber丸WorldのHTML表示、内容的には別に進展してないんですが、HTML解析の部分と、解析結果から画像を作る部分が、両方ともそれなりに複雑で、そして完全に切り離せそうな処理だったので、HTML表示クラスのアシスト用として別のクラスに切り離しました。
HTML表示のうち、imgによる画像表示はauto_resourceを使うことにしたので、auto_resourceの画像用カスタマイズバージョンを作っていました。
で、ついでにサウンド用も作ってやろうと思ったのですが、こちらは終了時にメモリエラーが出てうまくいきませんでした。
どうにもプログラムの最後の最後にメモリ解放しようとすると、もう既になくなっているコンポーネントにアクセスしようとして失敗しているらしく、そのあたりをうまく回避できるように試行錯誤していたのですが、そうすると今度はどうしても別のところで別のエラーを起こしてしまい、結局元のサウンドが使えない状態から進展はありませんでした。
まあ、CDIB32用のができたのでそれはそれで進展だったのですが。
さて、それじゃ大きさ計算のほうも進めておくか！
ひっさびさにHP作成論を更新しました。
どこをどう更新したのかというと、fontタグのsize属性のページを作ったんです。
なぜ作ったのかというと、まあ、これまでの流れで想像がつく人もいると思いますが、Bomber丸WorldのHTML表示の参考にするためなんですね。
で、そのHTML表示のほうはというと、一応解析結果をデバッグ用テキストに出力するプログラムを書いて、BRタグを解析開始するコードを間違って消してしまったことに気付き、直しました。
今は実際に表示する前に画像を大きさを計算する処理を作っているところですが、どうにもyaneFontの実装が怪しい気がするのでそのあたりを自分で作るため、Font関係を色々調べている途中です。
簡易HTMLまだやってます。
とりあえず表示に関わるタグのみを残して他は全部はずすことにしました。
まあ要するに論理タグとやらの全面廃止です。
HEADも、BODYも、INPUTも、Aも、Pも、使いません。
ほんと、太字にするとか、画像を表示するとかばっかりです。
…が、それはそれでIMGとか、BRとか、単体で効果のあるタグは周りの文字列に影響を与えるほかのタグとは違った処理になるので面倒だったりします。
Bomber丸Worldのための簡易HTML表示、タグ名と属性名と属性値を解析するところまではできたのですが、その結果を使って表示に反映するのは思ったより面倒で、どうしたものか思案中です。
あと、Aタグはどう扱うべきか、あるいは無視するべきか、そしてIMGタグは是非対応させたいのでそのためのデータは用意してあるけど、INPUTタグとかは果たして必要になるのかどうか、BやIタグは画面の拡大率によって影響が変化するけどどう吸収していけばよいか、そのあたりも悩みどころです。
それとは関係なく、明日の更新のためにランダムバナーリンクをいじってました。
うちで使ってる表示するたびにバナーが変わるリンク集です。
もともとKENT-WEBのCGIの改造から始まったものなので100%オリジナルというわけではないのですが、KENT-WEBのCGIならではという部分はほぼ完全になくなったはずなので、そろそろ公開してもいいかなと。
Bomber丸Worldのための簡易HTML表示を作りかけてました。
作りかけてるからにはできてません。
とりあえず今はタグ名の抽出まではできているつもりです。
だったらbとかiとかはすぐにでも実装できそうな気はするけど…。
やっぱり閉じタグとか属性とかを考えると面倒なのです。
トップページを見ればわかると思いますが、カウンターが吹っ飛びました。
最近はバックアップを取ってないし、そもそも地味で目立ってないし、それ以前に私自身忘れかけてたので、もう戻さなくていいかと思ってます。
でも今後のためにロック処理はきっちりしておかないと。
それはそうと、爆ボンのページのバトルステージ4と7を詳しく書きました。
「よくばりはまれ」と「みずのせせらぎ」です。
それと、ふにゃさんのBGMの睡眠時用アレンジ、あれをMIDIファイルじゃなくてプログラムで制御することにしました。
というのも、Bomber丸Worldでも同じようなことをしようと考えていて、その練習もかねてDirectMusicToolを使ってみようと思い立ったのです。
そうでなくとも今の状態だと眠った次の瞬間に起こすとボリュームがおかしくなるので、そのあたりの不自然さの解消もかねています。
Bomber丸WorldのHTML風表示を作り始めました。
yaneSDKに入っていたCTextDrawが使いやすかったら自分で作る必要もなかったんですが、<hr>で区切ることが前提だったもので、最後に<hr>をいちいちつけないと動かなくて不便だったんですよね。
あと、画像の自動拡大には対応できないというのもありましてね。
やっぱりですね、画像を表示するのに<img src="1.bmp">じゃなくて<gaiji 1>と書くしかなくて、ファイルの直接指定ができないというのがつらいんですよね。
そんなわけで、まだ何も表示できませんが、骨組みぐらいはできてきました。
Bomber丸World、高さマップ廃止とかで、マップ構造にも変化が現れそうなので、いっそマップシステムをまた1から作り直すとして、やりたいことを考えてみます。
1.複数のマスにまたがるキャラを作れるようにする。
これ、当初主人公たちも2マス×2マスにしていて、つまり半歩ずつ歩けるようにしていたんですね。
ただ、実装の面倒さから再び1マスの大きさに戻したんです。
しかし、このゲームはかなり体格差のある人々が出てくるため、やっぱり主人公基準の1マスじゃ小さすぎるわけです。
2.高速な追跡アルゴリズムを実現する。
現在の次に探索すべき場所をすべて含む矩形内をくまなく調べる追跡アルゴリズムはマップの一辺を1として最悪でO(l3)の処理時間でしたが、次に探索すべき場所を記録しておいて調べるのは実際調べなければならない場所だけというアルゴリズムにすればO(l2)の処理時間に短縮することが可能なはずです。
3.エディタを利用することを前提としたファイル形式にする。
何しろアニメーションにせよキャラクターにせよテキストエディタで書いていること前提であらゆる省略記法を想定し、ファイル形式が複雑になってしまいました。
専用のエディタを作れば、データ量が増えてもあまり手間は増えないので、データ構造の単純化が実現でき、同時に作る人の頭も単純な考えで動かしてかまわなくなるのです。
ふにゃさんプレイムービー全ステージ分アップし終わりました！
最難関のギロチン台は時間のかけすぎでうまく録画できなかったので改めて録画しなおしたのですが、他は滞りなく一発で録画成功しました。
あと、二重起動すると白い四角が出る問題を調べてみたのですが、原因はよくわかりませんでした。
もしかしたらShowWindowで間違ったウィンドウをアクティブにしているのではないかとも思うのですが、なぜ間違ったウィンドウが出るのかもわからないのです。
Bomber丸Worldの高さマップは廃止することになりました。
詳しいことはWikiに書いてありますが、主な理由はたいした利点がないことと、様々な欠点があったことです。
のんびりナマライザ、とは直接的には関係ないのですが、gzファイルの中に圧縮してあるアクセスログを解凍した上に適切なファイルに内容を書き込むソフトを作り始めました。
完全に自分専用に特化したソフトなので他の人にはほとんど使えない代物ですが、一部にナマライザのコードを流用してたりします。
Bomber丸World開発Wikiに旧開発室のライブラリのページを移行しました。
どうにも手抜きして旧ページからコピーしただけのCBWWindowクラスのページは不正確なようです。
他は細かい修正などもあって位置から書いたりしたのでわりと正確なはずですが。
yaneSDKのバージョンや内容も変わったし、最初にCBWDrawを作ったときからゲーム画面の処理も変わってきたのでCBWDrawを手直し中です。
まず、DirectDrawによるフルスクリーンを使わなくなったこと。
これによりディスプレイ解像度の変更が完全になくなるのでゲーム画面の大きさ変更からフルスクリーンとフルスクリーンのときのビット深度のオプションがはずされました。
そして、ウィンドウサイズが自由になったこと。
これはyaneSDKの前提の一つを覆すものなので結構修正が多いかと思ったのですが、CWindowのことあるごとにウィンドウを画面中央に持ってくる部分を修正すれば、他はCBWDraw内部の処理だけでなんとかなりそうです。
そうそう、TGWSにある全てのWikiの更新状況を管理者が一箇所で監視できるようにしてみました。
ユーザー側から見れば別に何もありませんが、こっちから見れば、他の掲示板などへの書き込み通知と同じように見ることができるので非常に便利になるのです。
本当はそういうのに対しては予めメール通知機能がついていたりするのですが、元々私はあまりメールチェックをしませんし、メール送信は案外重い処理らしいので、できるだけ一つのサーバー内で起こったことは一つのサーバー内だけで完結させたかったのです。
で、yaneDirectDrawとyaneDIBDrawの性能を比較してみました。
結果はWikiに書いてあります。
圧倒的というか、話になりませんね。
yaneDirectDraw、単純な等倍転送以外、使い物になりません。
で、全てを拡大する可能性のあるこのゲームでは使えないというわけです。
何しろ一つ転送するのに10ms以上かかるということは、よくあるキャラを二人描いたら60FPSは達成できなくて、五人描いたら20FPSすら出なくなります。
う～ん、今日yaneSDK1stでDirectDrawによる2倍拡大を試してみたらyaneDIB32にあったような整数倍拡大時のドット潰れが起きていなくて、Bomber丸Worldの描画エンジンも半透明とかエフェクトなどをあまり豪勢に使わないならDirectDrawでもいいかなと思っていたりします。
Bomber丸Worldではドット絵と解像度の関係上拡大処理が多くなって、そうするとyaneDIB32の本領発揮となるエフェクトや各画素ごとの処理などがうまく働かなくなる可能性もあったり、その上単純に処理すべきドット数が増えることによる速度低下なども考えられたりして、その意味でもDirectDrawのほうが良いのかなと思ったりしてます。
だけどそうするとまた描画関連のプログラムがごっそり入れ替わる可能性もあるわけで…。
とりあえずブレンド処理の速度を測ってみてから考えたいと思います。
ふにゃさんのプレイムービー5～10面をアップしました。
11面以降も録画しようと思ったのですが、あいにく11面でゲームオーバーになってしまったので録画は先延ばしです。
そうそう、現在ふにゃさんのシークレット機能の空を飛ぶふわふわふにゃの動きを考えています。
別にふわふわふにゃそのものの動きでもかまわないのですが、やっぱりふにゃさんなんだから、空気の抵抗を受けたり、くるくる回してみたり、色々やりたいわけですよ。
くるくる回すというのがよくわからないかもしれませんが、やってみればわかるかもしれません。
曲率を利用することも考えてます。
Bomber丸World開発室のWikiへの移行は順調です。
本当はプログラムの深いところをどんどん追記していきたいのですが、やっぱりキャラとかストーリーを書くほうが楽しいので、そっちのほうばかりが充実していきます。
引き続いてBomber丸Worldの開発室もWikiに移行してみました。
とりあえずはもともとの開発室の内容の移行とキャラやストーリー情報の記載をしていきたいのですが、Wikiの記法に慣れないため思うように進んでいません。
ふにゃさんのキャラセレクト機能、いい加減に作ろうかなと思って、肝心の入れ替えるべきキャラの絵がうまくできなかったんだということを思い出しました。
あんことサングラスをつけたふにゃが必要なのですが、あんこはふにゃとは違う表情のところが、サングラスのふにゃはサングラスそのものがうまく描けないのですよ。
Bomber丸Worldでは昨日ふにゃでやっていたような整理をやっていました。
yaneSDKの中にはいらない部分が多くてそれによりファイルサイズやメモリ使用量が増大しているという部分があるので。
