ZY-FGD1442701V1(5)
長い前フリでしたが（？）
やっと本題。
絵が出たので、次は文字列ですかね。
そーいうわけで、FONTファイルを探してたのですが
結局SJISの$FONTX2形式しか見つからなかったので
UnicodeからSJISへ変換しながら使うか、
それとも
フォントファイルをUnicodeで再構成してしまうか、ですが。
その前に、過去の経験からの話。
家庭用ゲーム機と呼ばれるものは、パソコンとは違って性能は
基本的に一定なわけです。
当然、使えるメモリサイズも一度決まってしまえば変わりませんね。
ここでは、各機の詳細は抜きで書きますけど
CPUから見えるメモリー範囲は一定であり、その時々によって中身が書き換わって、
ゲーム機のプログラムってのは動いています。
CD-ROMから読み込む、っていうのが、その書き換え行為そのものなのですが。
メモリが限られているわけですから、当然持てるデータが限られます。
たとえばRPGで、メッセージを出すために、すべてのフォントデータを常に丸ごと
メモリに置いてるか、といえば、そんなはずはありませんよね。
そのマップで、そのシーンで、必要な最低限をメモリにロードします。
メッセージ（文字列）は、開発過程で確定しますので、必要な文字はどれとどれか、ってのは
既に決まってるのです。
だから、そのフォントデータを抜き出して、番号を振りなおして、決まった場所に置いて、
メッセージはその再生順序を示すコードの列に置き換えられています。
たとえば
に 1
わ 2
に 1
は 3
に 1
わ 2
、 4
に 1
わ 2
と 5
り 6
が 7
い 8
る 9（振りなおした番号）
１４文字が、9文字分のデータに圧縮されます。
このデータをメッセージ表示の際に再生すれば、この文字列は再現できるわけです。
さて。
今回やってるマイコンでの画面表示ですが。
マイコンでも、同じようにメモリサイズは決まってますし、ROMサイズも決まっています。
ただ救いなのは、CD-ROMよりも大容量な（！）MicroSDが味方についてます。
たとえば、作ろうとしているものが、MP3プレイヤーだとしたら。
プレイリストをPC上で作らせて、その際にタグを解析して必要な文字列を全部洗い出して
必要な文字のフォントだけを集めて再構成し、文字列も全部プレイリストの中に持ってしまうのが
おそらく一番レスポンスよく動いてくれると思います。
その代わり、リストにないファイルについては、表示できなくなります。
まあ、最終的にどこを目指すかによるけど、とりあえずは、そうではなく。
もっと一般的に文字列を表示することを考えます。
そうすると、先の
Unicodeでフォントファイルを再構成する、という案が浮上してくるのです。
問題なのは、コードが飛び飛びになってること。
その辺をうまく使って、ファイルを分割するようにすれば、多少は速くなるんじゃないかと
思ったりもするのですが。
書き方次第、かな。
とりあえず、$FONTX2は、いつか来た道、なので。
まずはFONTの再編成から。
