次はＨＤＤかキーボードか
そうと決まったら、まずは最小構成のコンピュータを作らねばならない。
これを先生なり父上なりに見せてプレゼンを行い、お金なり人材なりを融通してもらう。
スポンサーと協力者を見つけてもらうのだ。
なんでもかんでも一人でできるわけではない。
基礎部分は自分しか作れないかもしれないが、応用まで自分がやる必要はない。
電子計算機がまさかエロゲに使われるとか昔の人は思ってもいなかったはずだ。
大勢の人が関われば中には思いもかけないアイディアを出す人がいるかもしれない。
ジョブズにはなれなくても、コンピュータの父にはなれるはずだ。
「さて、ディスプレイの次は何を作るか」
当初考えていたのはディスプレイ、メモリーかＨＤＤ、そしてキーボードだ。
「ＨＤＤは複写と消去のシーケンスが手に入ったからこれを改造すれば問題ないな」
僕の魔導書にはすでにいくつかのシーケンスが収められている。
中でも複写と消去は魔導書に入れる最初のシーケンスでもある。
これがないと自分で魔導書をアップデートできないからね。
いや、できないことはないが、全部手書きで書き写さなければならないほか、消すのも手間がかかる。
魔導書は基本的に羊皮紙を束ねて作っている。
羊皮紙なので、書き間違えたらナイフなどで削って消すことが出来ない訳ではないが、いくら羊皮紙が普通の紙に比べ丈夫だとはいえ薄くなるし毛羽立つと書きにくくなってくる。
しかも魔導書は、その表面に特殊なコーティングがされているらしく、削ったらコーティングし直さなければならない。
穴が空いたり切れたりすると誤動作する可能性があるのでそのページを交換するしかなくなるだろう。
そうなるとページごと書き直さないといけなくなるわけだから、そんなことをするくらいなら複写で一気に書き写したほうが楽だ。
魔導士ギルドには一般的なシーケンス辞典も売っているし、普通の人は魔導書の半分はそこからコピーして使うらしい。
後の半分は自作のシーケンスを植物紙に鉛筆書きして、最後に魔導書へコピーする。
僕の魔導書は練習用なので、一般的なシーケンスはこの複写と消去が先頭に書かれている他、明かりのシーケンスや、微風などの危険のないいくつかの生活魔法が書かれているだけだ。
大したページ数が書かれているわけでもないが、元々練習用の魔導書は子供の手に合わせて少し小さくページ数も少ない。
三〇ページくらいしか無いし、そのうち一〇ページはそういったシーケンスで使われてしまっている。
しかもすでにディスプレイ関連と共用シーケンスだけで一〇ページを使ってしまっていた。
ここに下手にメモリーやHDD領域をとると今度はシーケンスが入れられなくなる。
「ここに来てメモリーが足りない病にかかるとは」
今でこそメモリーが足りないとかよっぽどメモリー喰らいのソフトかメモリリークでもさせなきゃ起こりえないが、プログラマなら割と頻繁にかかるのがこのメモリーが足りない病だ。
適当にメモリーを確保しまくったり開放し忘れるとすぐにこの病気に罹るので、プログラマの持病とも言える。
「ディスプレイのように外部に基準点を設け、板にでも書き込みたいところだが」
魔導書の複写のシーケンスは、基本、魔導書へ書き込むようになっている。
基準点のようなものが必要ないからだ。
魔導書の各ページは魔導線によって魔石とつながっていて、精霊はページを指定しなくても空きページを認識できるらしい。
外部記憶とするにはディスプレイで使ったシーケンスと複写のシーケンスから必要な部分のみ抜き出して関数化する必要があるだろう。
「となるとやはり外部に記憶装置を作るのがいいか」
ディスプレイ用の板なら裏面が使える。
どの程度のデータが書き込めるかわからないが、当面はしのげるはずだ。
シーケンスは魔導線がつながっている魔導書内に書かなければいけないから、基本、データは外部に置いたまま、シーケンスは外部から一旦魔導書内にコピーして使うようにするか。
ＨＤＤにプログラムを保存しておき、メモリーに読み込んで実行するようなものだ。
現在は手動で行っているものを自動で行えればだいぶ楽になるしページの節約にもなる。
「あと魔導書は残り一〇ページくらいしか無いから節約しないとな」
シーケンスの一部を外部に保存しておいて必要に応じて魔導書へ複写すればページが節約できるはずだ。
「とすれば最初に作るのはＨＤＤがいいか。キーボードの代わりなら手書きでなんとかなるからな」
僕はＨＤＤを制御するシーケンスを作るべくまずは複写のシーケンスを解析していった。
「メモリー足りない病」の主な原因はメモリリーク、つまりメモリの開放し忘れです。
最近のC++などのオブジェクト指向言語ならコンストラクタとデストラクタで対応するようにメモリ確保と開放をすれば、リークするようなことはないのですが、ある複数の関数でメモリを確保し別の複数の関数で開放するようなメモリの使いをすると、あっという間にリークさせてしまいます。
もちろんそれは設計が悪いのですが、オブジェクト指向言語ではないC言語なんかではよくメモリリークさせてましたね。
昔、C言語でｅｘｉｔ（）の前にｆｒｅｅ（）でメモリを開放するかどうかで論争になったことがあります。
ようはｅｘｉｔしてしまえば後のメモリー開放はＯＳの仕事だから、不要だよね派と、後でｅｘｉｔ以降に処理を追加するかもしれないから、メモリリークを防ぐためにも入れておいたほうがいいよね派です。
私はｆｒｅｅで開放しておいたほうがいいよね派でした。
後から処理を追加することなんかよくあることですし、その時になってメモリーを開放する処理を入れるのはとてつもなく困難です。
昔書いたプログラムを理解するのはとてつもなく大変で、なんでこんなことをしているんだと思うこともしばし。
そんな状態で間違いなくメモリーを開放できるはずもありません。
細かいエリアを大量に確保するようなケースだと、開放するのに時間がかかるという意見もありましたが、すくなくとも開放するためのルーチンは予め書いておいて、不要であるならコメントアウトする等、やりようはあったかと思います。
