「ナマライザ」に関する日記(6)

また爆ボンのページを更新しました。
なんというか、スプリガン強いですね。
というか、フルパワーだとすぐ自爆してしまいます。
それでいて、やっぱり相手の攻撃も強い、と。

のんびりナマライザの単純なフィルタができました。
複合フィルタはまだできていませんが、とりあえずこれで基本的なフィルタの性能は出来上がりました。
とにかく項目が多くてコードも長くなるので面倒でしたね。

そういえば今日新しいテレビにプレステ2繋いでドラクエ5やったんですけどね、それでさっそくカジノに入り浸ってスロット三昧だったんですよ。
勝っては負け勝っては負け負けては負け負けては負け…2万枚あったコインがだんだんだんだん減っていくんですよ。
そして最後の1回、ああこれはリセットしかないなと思っていたら、1万コインが当たるんです。
ああ寿命が延びたなと思ってもう一度やってみるとね、スイカが1個、2個、3個…これで当面の軍資金はできたなと思ってたんですよ。
そして4個目もまたスイカ、これはもしかして儲かる？と思ってたらですね……スイカ。
5つ目もまたスイカでした。
30万枚ですね。はい。
このコインで全員にメタルキングの剣をプレゼントしたんですがそれでも10万コインあまりました。

爆ボンのページ更新です。
今日からそれぞれのページで具体的にスピード攻略について記述していきます。
今日はとりあえずブラックシティ1面だけ。
書式についてはまだ改善の余地はありそうです。

ナマライザのフィルタ処理を内部的に改良してました。
いや、コンパイル通るようにしたり、フィルタ編集ダイアログで識別できるように識別子を定義したりとか、そんな地味なところですが。

昨日言っていたソフトが出来上がりました。
同じフォルダ(というよりカレントフォルダ)にあるgzファイルを回答して中身をアクセスログとして解析し月別にファイルに追記してgzファイルを削除するプログラム、すなわち私がアクセスログを回収してから解析し始めるまでにしている作業を自動化したプログラムです。
単純なコンソールアプリケーションで、今日の日記からダウンロードできます。

でまあアクセスログ関連ということで、ナマライザのフィルタ編集ウィンドウの形式が決まりました。
結局どの形式も一つのウィンドウで済ますことにして、フィルタの分類を大きく3つ、細かく7つに分けて作ることにしました。
大きな分類では、条件指定なし、具体的な内容を指定、サブフィルタのリストを指定、の3つで、細かな分類では、無条件、特定の条件を満たす、特定の条件を満たさない、AND、OR、NAND、NOR、の7つになります。

1169305100.lzh

ふにゃさんプレイムービー全ステージ分アップし終わりました！
最難関のギロチン台は時間のかけすぎでうまく録画できなかったので改めて録画しなおしたのですが、他は滞りなく一発で録画成功しました。
あと、二重起動すると白い四角が出る問題を調べてみたのですが、原因はよくわかりませんでした。
もしかしたらShowWindowで間違ったウィンドウをアクティブにしているのではないかとも思うのですが、なぜ間違ったウィンドウが出るのかもわからないのです。

Bomber丸Worldの高さマップは廃止することになりました。
詳しいことはWikiに書いてありますが、主な理由はたいした利点がないことと、様々な欠点があったことです。

のんびりナマライザ、とは直接的には関係ないのですが、gzファイルの中に圧縮してあるアクセスログを解凍した上に適切なファイルに内容を書き込むソフトを作り始めました。
完全に自分専用に特化したソフトなので他の人にはほとんど使えない代物ですが、一部にナマライザのコードを流用してたりします。

BSch3Vね、単なるドローツールとしてもそれなりに使えそうです。
もちろん回路図に特化したソフトなのでドローツールとしては全然強力ではありませんが、回路図を書いてる途中で他の図も使いたくなったときなんかはなかなか便利です。

NeoMupl、テストしてみたらスキップ条件がまるっきり逆になっていました。
まあ、そのおかげで全部スキップだったときの挙動も確認できて、結果的には全部スキップされたときの挙動を改善することもできました。
全部スキップされたときの挙動は、まあ、つまらないことなんですが、全くスキップされなかったときと同じ挙動を示すようにしています。
あと、スキップ率のスクロールバーの挙動がおかしかったので修正です。
高速読み込みは現状の速くない方式でも3000曲で0.25秒なのであまり問題ないとして、予定リストからはずしました。
あと、今更ながらリスト編集ウィンドウの参照ボタンを実装しました。
情報バーは最近存在すら忘れていたので完璧に時代遅れの状態となっています。
何とかしてリスト編集ウィンドウと同じ挙動を楽してさせたいものですが。

のんびりナマライザのフィルタをちょっといじってました。
具体的なものはなかなか作りにくいのでやっつけでORとNOTのフィルタを作ったりしてみました。
ANDは昔からあります。

NeoMuplをちょっといじってました。
気に入らない曲をあまり演奏しないようにするオプションの実際の内容を決めました。
スキップ率という要素を使って、気に入らない曲が選ばれた場合、指定された確率で演奏せずに次の曲に移るようにします。
ただ、中身をまだ実装していないので今回はアップしてません。

のんびりナマライザのフィルタ機能の実現方法も考えたりしました。
まあ、結局、フィルタのリストを普通のリストで表示して、それを選択して編集すると編集ダイアログが出るという、もっとも安直な妥協案を取ることになりました。
編集ダイアログをどうするかというのが次の問題なのですが…。

Bomber丸World、C#で作るかC++で作るかということを考えていましたが、やはり今まで通りVC++6で作ることに決めました。
今まで作ったものの資産が多少なりともありますし、手馴れている分C#よりも速くできそうな気がしますし、今やっているスクリプト作成講座はずばりこのゲームのためですし。
それでも、最後までVC++6で作るということが完全に決定したわけではないので、C#に移行する場合の労力が最低限になるようにできるだけC#との違いが少なくなるようなコードを作ろうと考えています。
コレクションの要素全てにアクセスするときはただ単純に短くなるだけだし、テンプレートがジェネリックになったり、deleteが不要になったり、形式的な違いが大半だと思うので、アルゴリズムの方面では多分大丈夫だと思うのです。
もっとも、WindowsAPIやDirectXを直接(とはいっても現状YaneSDK経由で)扱うプログラムとC#での.NETプログラミングとでは手法がかなり違うので、そのあたりはかなり厄介です。
括弧の中にYaneSDK経由と書いたのですが、.NETのYaneSDKはVC++6のものとは全く、というよりもはや根本から構造が違うので、今まで楽してた部分をそっくり自分で書かなければいけない可能性があるのです。
もちろん、YaneSDKの中にはC++という言語と標準ライブラリの不足を補う部分が数多くあるので、言語機能と標準ライブラリが強力なC#ではそれらの面倒ごとをある程度は補ってくれるのでしょうが。

ナマライザの開発を進めてます。
フィルタ機能はひとまず置いといて、エクスプローラ型表示を作ろうと試みています。
エクスプローラ型表示というのは、つまり、どのファイルにどれだけアクセスがあったのかというのを、視覚的にわかりやすく階層構造で表示するというものであります。
ディレクトリアイコンをクリックするとそのディレクトリから下の階層へのアクセス状況が見られるようになります。
さらに、特定のファイルをクリックするとそのファイルへのアクセスを詳細に解析した個別表示のウィンドウが開きます。
で、それらがまだできていないわけです。

ナマライザのフィルタ機能を作ってました。
フィルタ機能というのは、前の簡易アクセス解析で言う詳細検索機能であり、フィルタ条件を決定した時点で最適なフィルタを生成するので、無駄な条件分岐が発生して激しく遅いということがありません。
よって、簡易アクセス解析にあった単体での検索機能は廃止し、フィルタに統合します。
フィルタをかけるとフィルタ条件全てにマッチするログが選び出され、自動的に開いている全てのウィンドウを更新して解析結果を最新に保ちます。
もっとも、このウィンドウ自動更新機能は遅い場合は廃止する可能性がありますが。
ただ、この機能を実現するに当たって少し問題がありまして。
それは、フィルタの設定をするダイアログの構成です。
フィルタのリストにどんどんフィルタを追加してゆくという形なのですが、フィルタの種類によって使うパーツが異なったり、そのパーツの見せ方をやりたいようにやろうとすると難しくはないけど面倒なプログラムを組まないといけなかったり、だからといって作りやすいように作れば使い勝手が悪かったりして、どうにもうまくやるのに時間がかかりそうなのです。
まあ、適当に、頑張ってみます。

のんびりナマライザ、ファイル読み込みのテストを実際のログでやってみたのですが、思ったほどVB版と比べて速くなってはいませんでした。
やはりnewを大量に繰り返すためでしょうかね。
あるいはコンテナをLinkedListから別のものに切り替えるのも効果的かもしれません。

昨日の一件でマリオ64のキノコ封印プレイは撃沈したわけですが、今度はコインを取らないプレイに挑戦してみようと思います。
こちらの場合は1UPキノコと違ってたくさん配置されているし、記録にも残るのでやりがいがありそうです。
しかもプレイ内容も、回復が出来ないのでよりテクニカルになりますし。
問題はといえば1コースあたり7つあるスターのうち2つが絶対に取れなくなるので取れるスターがクリアに足りるかどうかですね。
状況次第では赤コインだけは封印解除するかもしれません。

スマブラの過去のお知らせを見ていたらシンプルとアドベンチャーのベリーハードのクリアの記録があったのにオールスターだけは無かったので今日やってみました。
いやぁ、スマブラのマゾゲーっぷりが遺憾なく発揮された最悪のゲームでした。
コインが540枚ほどあったから事実上コンティニューし放題だと思ってマルスを使って始めたら、途中1対2のところまでは1バトルあたりコンティニュー1回以内と言うまあまあいいペースで進んでいたのですが、1対3になると難易度が異常上昇、全く勝てないんですよ。
特に最後から3番目のリンク・ガノン・ピーチとのグレートベイでの戦いは厳しいものでした。
一気にみんな群がってきて、逃げる間もなくダメージが蓄積されて気付けば体は画面外で、何万点もあった得点も、気付けば1点と2点を行ったり来たり。
それでステージ下部の離れた二つの足場の間を行き来して追いかけさせ、自滅させる作戦に出たのですが、穴を飛び越えるという発想の無いコンピュータは安全な上の足場を歩くばかりで自滅するのは自分ばかり。
さりとてステージ下部を往復してないと確実に群がられて終わりなので、1対1だった頃はそれなりに戦えていたことを思い出し、とにかく往復して追いかけさせることで足の速さの違う敵たちをばらけさせ、一人だけ先にやっていたところをたたいては集まってくる前に反対側へ逃げるという戦法を取って数を減らし、最後の一人、体重が重く攻撃も重いガノンドロフだけになると、やっと1対1になると、それまでの戦いで満身創痍の体を気遣い接近戦は避け、壁越しに攻撃を繰り返すことで安全に倒しました。
この戦いで20回ぐらいはコンティニューしましたが、この戦いで一人用ゲームでは特に相手の弱点を見つけ出すのが大事だということを思い知らされました。
そして残りコインも心もとなくなった残りの2戦ですが、次の戦いはアイスクライマー・ネス・クッパとのアイシクルマウンテン、自滅の名所での対戦でした。
普通に戦っていてもいけそうな手応えがあったのですが、幸いにして2～3回のコンティニューの後に、CPキラーの猛烈スクロールが始まったので、無理に戦わず、コンピュータを落ちるに任せて倒さずに勝利しました。
最後のゲーム＆ウォッチの大群は上強攻撃で楽勝でした。
それに気付くまでは横スマッシュで頑張っていて何度かコンティニューしたのですが。
そんなこんなで最後に残ったコインは130枚程度。
実に400枚以上もコインを使ってしまいました。

マイクロソフトの「よく寄せられる質問 : Visual Studio と Windows Vista」を見ていました。
何せWindowsXPとは全く異なるOSがもうすぐ出るっていうときに、開発に時間がかかり、なおかつ長い間プレイしてほしいゲームをWindowsXPで作ろうとしているのですから、気になるってものです。
これを見てまず驚いたのが、WindowsVistaでもまだ現役としてVisualBasic6.0が使えるということ。
こうなったのは修得の容易さからVB6を使う人が未だ多いためにしぶしぶといったところだそうですが、もうすぐ本格的にVB6とはお別れしなければいけないと思っていたところなのでちょっぴりうれしい気持ちです。
もっとも、VB6以外については、最新のVS2005と極端に変わらないと言う理由でVistaからはサポートしなくなるそうですが。
ただ、VB6やVS2005がWindowsVistaで使えるようになるのは2007年第１四半期からだそうで、そうなるとWindowsVistaの導入もそれにあわせて4月以降になってしまいそうです。
もちろん導入できればの話ですが。
WindowsVistaでは、.NET2のプログラムがそのまま動かせるそうで、また、WindowsXPでも.NET2をインストールすれば使えるということで、今後の開発は.NET2が中心になっていきそうです。
次のバージョンの.NET3も.NET2を完全にサポートするようですし。

それで気になるのが、今から作ろうとしているBomber丸Worldです。
まだ作り直しはききますし、C++からC#への移行はある程度容易です。
しかし今現在の状況では、開発環境が重い、ウィンドウ切り替え直後の再描画がなぜか遅い、などの欠点がありますし、そもそもVC#2005での本格的なゲームの開発経験は皆無です。
しかしその代わり、標準ライブラリは確実にVC6よりは充実していますし、開発環境も重くなった分やはり圧倒的に強力になっています。
すでに1割を切った古いウィンドウズの利用者を切り捨てて自分だけさっさと先に行ってしまうか、将来動くかどうかわからないプログラムをそのまま作り続けるべきか、悩みどころではあります。

それはそうと、今日はナマライザのファイル読み込みを作りました。
テスト用の小さなファイルで動作を確認したのですが、とりあえず現状ではうまく動いていそうです。
実はコピーして一部変更しなければならなかったコードをコピーだけして変更しないという初歩的なミスを犯したりしていたのですが。

今日メモちらしが原因不明の動作停止をしました。
元々暴走が怖かったため動いてるか動いてないかわからないぐらいの低速で動かしていたのでずいぶん長いこと気付きませんでした。
とりあえずソフトを再起動したら直ったのですが、止まる条件はプログラムの終了以外になかったはずだったので少し気持ち悪いです。

のんびりナマライザのログ読み込み部分の中枢が出来上がりました。
先月27日に言っていたところのファイル解析です。
まず、速度は多少遅くなるのですが、エラー処理を正しく行い、可読性の高いコードになるように、そしてもちろん正しいデータに対しては最低限正しく動くようにしました。
読み込みの都合や実際に解析するときの必要性などから一部のデータを使わないことにしたり場所を色々移動したりもしました。

掲示板の迷惑書き込み対策、もっと単純でなおかつ当たり前の方法がありました。
投稿内容反映の前に、投稿内容確認画面を入れて1ステップ多くするのです。
これにより一般のお客様には利便性が上がり、迷惑書き込みをする人には面倒になるのです。
一般のお客様から見れば、投稿結果のイメージが投稿前に確認できるし、やろうと思えばその場で修正もできるし、不適切な表現があれば警告が出るし(出せるようにしたい)、チャットのようにガンガン書き込みまくるということもないので便利さだけが大きく上がるのです。
そして迷惑書き込みをする人にとっては、一手間多くかかる(つまり2倍面倒になる)、機械での投稿がしにくくなる、ということで書き込みにくくなるのです。

ナマライザの読み込み処理、これで完成かと思いきや全く正常に動かないプログラムであることが判明！
いえ、まだ実行したわけじゃないですが、簡単なデータを想定してコードを順番にたどっていったら、まだ読み込まれていないデータを処理しようとして、データがないとして、データが丸々残ってるのに次のステップに行って、その次のステップでは次に来るデータが特定の形式であることしか想定していないので、誤った場所のデータでは当然形式が会わなくて、どんどん違うデータを生み出し続ける、ということになってしまっています。
特定のフォーマットのみに対応して高速化を図ろうという考えでしたが、ちょっといくらなんでもデータの狂いに対して弱すぎるようでした。
今の状態だと全く正しく読み込めないばかりか、その正しく読み込めないところを修正したとしても、データそのものに少しエラーがあった場合でも、どんどん誤りを蓄積してそれ以降の全てのデータに悪影響を及ぼすのです。
ログデータは行単位で記録されているので、データの破損があったとしてもそれにより信用できなくなるのは該当する行だけであり、改行コードの一つも出ればそれ以降のデータは正しい可能性が高いのです。
というわけで今後の課題は、データの正しい読み込みと、エラー時の復帰の２つになります。
末端の表示処理はまあ速度さえ気にしなけりゃそれなりに楽にできるでしょう。
データ読み込みのときにも同じことを思っていたような気がしてなりませんが。

メモちらしの改良を考えています。
どうしても粒子の数が増えてくると色々なところで腕が伸びきってしまって扱いにくくなるので、腕が必要以上に伸びないような対策を考えています。
これの根本的な原因は平方根計算をするのを嫌って反発力の算出に距離の二乗に反比例した値ではなく距離に反比例した値を使ってしまったことだったのですが、既にこの仕様で動き出してしまっている以上、この部分は現段階のメモちらしでは変更するわけには行きません。
そこで、対症療法的な考え方ですが、これ以上伸びてもらうと困るという、そういう数値を設定しておいて、腕の長さがその数値を超えている場合は腕の引っ張り強さを上げるのです。
ただ、腕が長すぎる間ひたすら上げっぱなしだと、本当は時間さえかければ規定の長さに戻るのに、その途中であっても規定の長さに達していないというだけで必要以上に腕を引っ張ってしまうので、それが暴走や、縮みすぎという結果を招く可能性が高いです。
それを防ぐには、自動で腕の引っ張り強さを下げることはしないので、とにかく腕の引っ張り強さの上げすぎに注意する必要があります。
腕が長すぎるということは、つまり、腕の引っ張り強さが弱すぎて、反発力に負けているということを意味するので、反発力≧引っ張り力である間だけ引っ張り強さを上げてゆきます。
反発力＜引っ張り力となっている間は腕は縮み、腕が縮むと反発力が上がり、引っ張り力は弱まります。
引っ張り強さが足りない場合、腕の長さが規定に達する前に再び反発力≧引っ張り力になるため、改めて引っ張り強さを上げてやります。
これを規定の長さになるまで続けてやれば、おおよそ規定の長さよりも少し短いところで腕は縮み終わるはずです。
縮みすぎたところがあれば、まあ、それを編集するのは長すぎの場合よりは簡単なので、手動で調整してもらいましょう。

今日28日だと思ってたのだ。
まあいいや。

のんびりナマライザのファイル読み込みと表示を作ろうとしてたんですが、その前に完成しているべきファイル解析ができていなかったので、今思い出しながら作成中です。

爆ボンのカスタムパーツのページを独立させました。
他にもいくつか更新してます。
ドラクエ8のエンディングの話とか。

急にのんびりナマライザをいじりだしました。
ナマライザの読むログデータはテキストファイルなのですが、OSの関係で改行コードが\r\nじゃないことがある、というより私のところで\nだけなので、今回は会えてバイナリファイルとして読み込んで、１バイトずつ処理することにしました。
確証はありませんが、多分この方法を使ったほうが文字列として読み込むよりデータの分割が速くなると思われます。
ほかのところも色々考えてるのでやる気のあるときに一気に仕上げてしまいたいところです。

ふと思いついてふにゃさんにモーションブラーの機能をつけてみました。
ただ単純に前のフレームの内容を半透明で現在のフレームに合成しているだけなので画面全体に効果が及び、動くたびに全体がぼやけます。
やっぱりドット絵にモーションブラーは合いませんね。
画面写真は撮ってないけど沢山のものを配置している状況でブラーをかけると配置されたものがもはや別物に変化してしまいます。

そうそう、のんびりナマライザ、C#で書き直そうと画策中です。
やっぱりVB6じゃ、それもラーニングエディションじゃ遅くてお話にならないんですよ。
のんびり待つにも限界ってものがあるのです。

1144763600.png

ナマライザ、リクエスト先ごとの解析結果を表示する部分をさっさと作って公開しようと思っていたのですがどうにも簡単に作れる方法では処理時間がn^2のオーダーになってしまって、しかも対象となるデータが数万行あるからこればかりは適当ではいけないし。
のーんびりゆったりしてられるのにも限度というものがありますからね。

まずいよーまずいよー。
おさかなさんとけてるよー。
やきざかなにがいよー。

今日はブルーリゾートの1・3面のスピード攻略を作っていました。
3面のクリアタイムを更新、1面は3通りの方法を検討しています。
詳しいことはまだ後日書きます。

チャット配布用一応できましたがオリジナル版との違いが予想より大きくなってしまったためちょっと内容を再検討中です。
あと、やはり不足している機能が多すぎること。

ナマライザの解析部分でリクエスト先を更に分解してディレクトリ・ファイル名・?以下の文字列に分けるようにしました。
しかしそのときクラス内で使っているユーザー定義型はまともな方法では外部に公開できないということがわかってVBへの不信がいっそう募ったり。
外部標準モジュールに一時保存用の変数を作ってそれ経由で渡さねばならないようです。
本当にVB6のオブジェクト指向は形だけで役に立ちません。

のんびりナマライザのログ一覧表示を作りました。
LineConstructorを使いまわしています。
どうも少し重いようですが既存のコントロールを使ったときのような余計な制限やメモリ消費がないところが強みです。
コントロールを使うとコントロールにデータのコピーを置かなければならないのでメモリ消費とデータ反映にかかる時間が馬鹿にならないのですよ。
もっとも、スクロールにスクロールバーコントロールを使っているのでいまだに32767項目の制限があったりするのですがね。

日記を改良しました。
JavaScriptが有効になっている方は既にわかっていると思いますが、左側のリストがクリックで開いたり閉じたりできるようになっています。
Netscapeだとon～系のイベントが出ないようでクリックしても反応が無いのですがそのときはそのときで少なくとも前より悪いことはないと思うので勘弁してください。

爆ボンを改めて最初からプレイしてみました。
フルパワーなので楽勝楽勝！
と思いきやいきなりドラゴ戦で自爆！
あの過剰な爆発力に自分自身が餌食となってしまいました。
リッパーのときも同じく自爆しまくりだったのですがこちらはハートを何度でも回収できるので本当に楽勝でした。
しかし最大の難関！ブラックシティ！
正面突破は最短ルートでの突破に失敗し、かなりのタイムロス。
アルタイルタワーともなると、まさに難攻不落、フルパワーなんて全くの無力なのです。
あまりに全てが揃いすぎていて非現実的なパワーで侵攻しているというのにその結果があまりに現実的なタイム！
レインボーパレスがただのボムジャンプ練習場に見えてきます。
そしてクリアするとシアターでは見られないノーマルエンディング！
ものすごく久しぶりに見たのですがスタッフロールでのあの完璧なプレイと言ったら！
シリウス版のあの馬鹿なNGエンディングとは全く違う感動的なまでの完璧なスーパープレイ！
一瞬の無駄すらもありません！
最後のレインボーパレスへの布石はレインボーパレスとクリアしてから見るとまた違って感じるものがあります。
あの頃は単なる観光地だと思っていたなぁ。
クリアタイム16分です。
アルタイル１戦目の体力が分かったのでそこを更新です。

ナマライザの解析処理部を改良しました。
以前のだと複数のファイルを読み込むと一つ読み込むたびに解析を行っていたのですが、今回で全てのファイルを読み終わった後に解析を行いようにしたのでたぶん回数分だけ軽くなっています。
ついでに、ステータス表示に現在の読み込み状況を表示していたのですが、その表示そのものを受け持つ部分と表示される文字列を作る部分とを分け、ステータス作成部分では現在の状態のリスト(通常は0～1項目)をStringArrayクラスにつんで一番新しいものだけを表示させるようにしました。

それに伴ってStringArrayクラスも改良しました。
戻り値の一部がVariant型になっていたりしたのを修正して、新しいメソッドDeleteValueを追加しています。
DeleteValueでは指定した値を持つ要素を全部消去してその分を詰めます。

ふにゃさんのBGMをループできるようにしました。
設定項目を増やしてそれを認識してループフラグを操作するだけだったのですが、設定プログラムのほうでyaneLineParserと同じはずのクラスで読み取りポインタが増加しないバグがあったので正しく読み取れない事態が発生していました。
もちろん即行で原因を見つけて直しておきましたが。
標準BGMのほうはどうしようかなぁ。
敵が周りにいて変化、というのは難しいかもしれないし重いかもしれないし。
ふにゃ本人の状態だけで変化させるんなら簡単で軽いはずなんですよ。
例えば眠ったときに静かな曲調にするとか…。

メテオスのスタッフロールにあった楽譜、あれオープニングの一部なんですね。
MIDIに打ち込んで気付きました。

どうもここのところサーバーで用意してもらっているアクセス解析が不調で、何度も見に行っていたら、いつの間にやら空き容量が3桁になっていました。
本来利用できる容量は100MBなので3桁もあるはずはなかったのですが、確認してみるとさりげなく250MBに増えていました。
最近色んなのに手を出して使用領域が増えてきていたため少しファイルサイズをケチろうかと考えていたのですが、この容量増加はつまり、ケチらずガンガン使えという意味だったのでしょうか。
そうと分かれば気兼ねなくどんどん使うぞ！！
といいたいところなのですが、無駄にファイルサイズを大きくしてしまうと閲覧者側の負担に繋がるのでファイルサイズ増加は目指さないことにして、逆にファイルサイズ削減のためにクオリティを落とすことはしないようにしたいと思います。
やっぱりファイルサイズ制限がなくなったことで充実させられるといえばダウンロードコーナーのソフト紹介ページとか、プログラミングコーナーのサンプルとかでしょうね～。

久しぶりにナマライザの開発をやっていて、ログの分解に正規表現を使えないかと思って探していたら、Boost Regex++なんてC++用のライブラリを見つけて、インストールしようとしたのですが、ライブラリをソースからビルドしていたらあまりに時間がかかっておかしいと思いビルド状況を見てみると、いくつものファイルをビルドしていて、その全てで100以上のエラーが出ていたので、仕方なくビルドを中断して、それにかわるライブラリといえば、有料のVB用DLLがあるぐらいで他はよく確認はしていないのですがVBでは直接的にも間接的にも使えそうになかったので、正規表現はいったん諦めて簡易アクセス解析と同様にVBのSplit関数で分解して後でそれを加工する方式をとることにしました。
それ以外では、一応各種情報のための情報を用意したりしたのですが、どうもそれらは一気に全部取得したほうが速そうなので、まとめて取得する方式にしたら変数の数を半分近くにまで減らせそうです。