バッファクラス
いい名前が思いつかなかったのでそのままBufferというクラスを作りました。IrmBufferとかirm_bufferとかだと格好いいかなと思いましたが、namespace Irminzulの中にあるわけですし、そこからIrmBufferとかなるとIrminzul::IrmBufferと意味が重複するような気がしていやだったのでBufferです。
しかし、Bufferはライブラリ内部でしか使わない予定ではあるんだよな…。外部でも使おうと思えば使えるが、それ使えるようにしたらライブラリの意味無いですし。
プログラミングは難しそうだと思っている方がいるようですが、とんでもない。賢い小学生を一人連れてきてCの本を渡せば( 国語辞典も渡せば )1週間程度でプログラムは書けるようになるでしょう。
ただ面倒。ただただ 面倒。難しいという問題よりも面倒という問題の方が深刻です。
それでもテンプレートとか、その面倒をコンパイル時に解決する方法はいろいろ出てきたんですが、面倒なものは面倒です。
あと30個ぐらい関数を書かなければなりません。
今のところソースコードが全部で1.7MBでした。だいたい200万文字以下くらい？
そう思うと大した量ではないという気がしないでもないですが。とりあえずフロッピーには入りません。
次
キャッシュシステムはとりあえず実装だけ終了。テストはまだ。
自分のブログの過去ログを見返しながら次何するかを確認してます。
結構役に立ってます、ブログ。
次はファイルシステムか無圧縮アーカイバ。無圧縮アーカイバができればそこに流し込むデータストリームを圧縮してやればいいので、問題ないはず。実装するまで問題点はわかりませんが…。
最近Macを使うことが多々あり、相変わらずMacのインタフェースにしびれている昨今ですが、Windows用のDock( Macについてるプログラムランチャ )を導入しようと思うものの足りない。機能が足りない。
今使ってるプログラムランチャには5グループに20個程度ずつアイ コンを登録してあるので少なくとも100個程度はアイコンを登録できるような仕組みが必要なのです。
延々横スクロールとかあり得ませんから、やはりグループ切り替え機能は必要です。そんなDockって無いだろうな…。と試しに導入してみてやめました。
たまには
コンピュータの使い方 - wids
http://wids.net/lib/mimix.html
Dragonfly BSDを導入しようとか思い立ち( 結局やらないんだろうけどなあ )ウェブ上をさまよっていたら見つかりました。上記の文章。読んでみてください。IT革命なんてそんなに大したものではないんです。
余談ですが、世の中に変革をもたらした多くのものは実は大したことをしていないように見えるし、多くは実際そうです。産業革命は緩やかに始まりました。何年もかけて。
僕はコンピュータが嫌いです。
上の文章に関連してどうこう、というものではないです。性能が、有用性が、ユーザビリティが、可用性が、という問題ではなく、単に幼い頃のトラウマから嫌いです。
死ぬほど泣いてそのあと半年はコンピュータがおいてある方向を向いて寝られなかったことを覚えています。
今でもコンピュータがいきなり止まって画面が暗転すると気持ち悪くなります。
どこがどう悪くてどうすればいいのかが明確にわかっていたとしても
数日前に同じコンピュータにWindowsをもう一つ入れたときにエラーで起動しなくなりました( 当たり前です。NTLDRのバージョンが違います )。
そのときも頭の中ではC:\i386からNTLDRをコピーしてルートにおけばいいなと思いつつも気持ち悪いはお腹はきゅうっとなるし泣きそうになります。だから大嫌いです。
人間どこでどう転がるかわからないもの。そんな人間が情報分野を専攻することになろうとは。
そんな人間がWin32のAPIについてなんか悩んだりするんだから、わからないものです。
今でも嫌いです。たぶん一生好きになれません。コンピュータを使って何かをしたいとも思いませんし、コンピュータのアーキテクチャに興味はありません。
僕はなんのためにコンピュータを使っている？
OBに
うちの大学のOBに声優さんがいるらしい。
エクレールの人と時雨先輩がいるそうだ。他にも探せば結構いる気がしないでもない。
日日の人と人文の人らしい。
つくばの人の傾向として良くも悪くも内向きなところがあるそうで。
日本語日本文化学類のことです( 来年無くなる )。ちなみに同郷出身。
ちなみに筑波大学-Wikipediaの内容には決定的な誤りがある。
筑波大学 - Wikipedia
それは文部科学省も言うとおり学群、学類「再編」ではなく「改組」である点。
わざわざ文科省が指摘してきたぐらいなので直しておくのがよいのでは。
ちなみに確認してみたら日日無くなりませんね。失敬。
情報学類は情報学群へ図書館情報専門学群を吸収合併して格上げ。
個人的にはナンバー学群の方がわかりやすい気がするが・・・。建物の名前はやっぱり変わるんだろうか。
すると…ちょっとおかしなことになりはしないか。
というわけで、久しぶりの普通の話でした。
牛乳なら完全に吹いてる
//
// sizeの検査
// そのオブジェクト、入る？
if( limitSize < size )
{
finalizer();
return false;
}
CacheLump< T > cl = new CacheLump();
cl.object = t;
cl.handle = handle;
cl.last_access_time = GetNowTime();
cl.size = size;
cl.Finalizer = finalizer;
totalSize += size;
//
// chachelist尼僧乳
なんだそれ。尼僧乳って。
えろすぎ。ATOKさんしっかりしてくださいっ！！何ですか尼僧乳って！！
面白いので気が向くまでこのままです。なんてはしたないコードかしら。
プログラムソースのコメントって意外と面白いことが書いてあることが多い気がします。いろんなソースを読みますが…。ひたすら愚痴ってあったり。
前にも書いたかもしれませんが、NTのコードには至る所に戦争の跡がみられるようです。
「これはこうすると何でか知らんが動く！ 絶対変更するんじゃねえぞ！」
とか
「ここから先は絶対いじるな！ いじったら芝生みたいに蹴散らしてくれるからな！」
とか( 記憶不鮮明につき雰囲気だけお伝えします )。物騒なことばっかり書いてあるそうで。
あれだけ巨大なプログラムだと大変なんだろうなとしみじみ思います。一からコードを書き起こすのがよいのではないでしょうか、と。外から大量の技術者を投入して。もしくはどっかのプログラムハウスを買収して。
5兆もあるんだからさ…( ビルはもうマイクロソフトの会長じゃないはず )。
やねさんところが…
大変なことになってる。壮大なコントであることを期待したいが…。
それにしてもみんな暇なんだね。
買ってから読んでない本( 斜め読みは買ってすぐにやるのです。でないとどこに何が書いてあるかがわからなくなりますから )が大量にある僕には真似のできない時間の使い方です。羨ましいです( 言っておくが皮肉じゃないぞ。時間を効率的に使える人と使えない人がいるんだってば。使えない僕にしてみれば羨ましいことこの上ない )。
非同期IOはレイヤ管理クラス( テクスチャマネージャ )を用いることで効果を発揮するのであって現状のシステムをそのまま移しただけではそんなにスピードアップしないと言うことがわかった。
手を動かします…。はいはいキャッシュシステムキャッシュシステム…もにゅもにゅ。
HeapAlloc - Win32、メモ リ管理API
メモリ管理はmallocで大丈夫です。とりあえず難しいことを考えたくなかったらWin32ではmallocですませておきましょう。
Dibを扱っているクラスを眺めていたところ、メモリ確保にGlobalAlloc関数が使われていました。アドベンチャーゲームプログラミング( 坂本千尋氏・著 )にも書かれていますが、このAPIはWin16時代のAPIです。
GlobalAllocはWin32では内部的にHeapAllocになっています。
で、Win32のメモリ管理APIというのはVirtualAllocとHeapAllocです。
詳しくはこの二つでググるとすぐに出てくるのですが、たいていの場合、1MBに満たないデータをちょこちょこメモリに確保して使う場合はHeapAllocを使うべきだそうです。mallocはVC++のランタイムではHeapAllocで実装されているそうです。
メモリ管理豆知識でした。
圧縮アーカイブ仕様の策定
というわけで、汎用性を捨てます。いや、嘘です。汎用性はもちろん持たせておきますが、現状で汎用アーカイバをサポートする気はさらさらありません。だったら圧縮アルゴリズムの勉強などしません。
といっても、zipファイルも扱えるとは思います。どれもこれも似たようなものです。bzipも大丈夫なはず。
他はどうだろう。gcaなんかは大丈夫っぽいけど。
bzipの仕様をパクってファイルをブロックごとに圧縮して保持します。
このブロックサイズは可変です。アーカイブ内では一定です。語弊。
一つのファイルを圧縮したあとのストリームでは一定です。ファイル一つを圧縮ストリーム一つとして処理します。いわゆるソリッド圧縮みたいのには対応しません。理由はランダムアクセスできなくなるからです。
ゲームに使うのが目的で、しかもCD-ROMからの利用が前提になっているのでランダムアクセス機能は必須です。
しかしこのランダムアクセス機能が非同期I/O( 以下AIO )と相性が悪い。
ランダムにアクセスされては先読みなどできません。というわけで、どこにアクセスされても言いようにファイル全体をメモリの中に格納しておきます。
たいていは画像の読み込みなり音声の読み込みなりどうせ全部要るんです。先読みしておけば当然スピードは大幅にアップします。
が、全部要らないデータがあります。そうです。動画データです。ちなみに音声も動画もストリーミング読み込みにはもちろん対応しております。
OGGならばせいぜい1ファイル5MBが関の山。しかし動画ファイルはオープニング( 1分 )程度でも画質次第では100MBにもなります。とてもじゃないがこんなでかいデータをメモリに置いておくわけにはいかない。
するとストリーミングで読んでは再生読んでは再生( もちろん読みながら再生ですが )でデータを取得し続けて捨て続けることになります。
だから、ランダムアクセスであり、ブロック圧縮な訳です。
たとえばブロックを5MBにしておけばファイルシステムの消費メモリはせいぜい10MBから15MB程度でしょう( bzipのmanpageを参照 )。このぐらいならば問題はないでしょう。
5MB以下のファイルならばその全てがメモリに読み込まれていつでも読み込み可能です。
動画ならば頭5MB読み込んでスタンバイ。あとはストリーミング読み込みルーチンの性能如何というわけです。
つーわけで能書きはこのぐらいにしてひとまずは無圧縮アーカイブのクラスとファイルシステム、キャッシュシステムの残りを書きます。このあたりがないとサンプルも書けないので。
CRCおわり
char -> unsigned char
charにunsignedなんてあったのか…、いや、それはあるだろうけどしまった…。死にたい。さすがにこれは。
もちろんですがcharにもunsignedがあります。変数のとる範囲も違います。ええ。
というわけで、正しくCRC32を吐いてくれるようになりましたまる。