フォントを扱うプログラムは、実に7年ぶりぐらい。
当時作ったフォント変換のプログラムを発掘して、
再度読み直してみる。
DOS窓で、フリーになったBorlandC++でコンパイルしていた形跡まで
全部残ってた。
あの時は、PICからAVRへと移りつつあった時期で、それでもまだ
PICでモノクロLCDパネルを表示して、その過程でフォント変換のシステムを
書いていた。
AVRの第一弾はLEDマトリックス。今みたいにキットがあったわけではなく
モジュールだけが簡単な資料とともに売られてた。
ゲーム業界からハードウェア設計に業種を変えたばかりで、
コードは書けても回路は描けない、そんな駆け出しにとって
その制御法は複雑怪奇なものでした。
それでもまあ、現場のボスに教えを乞い、タイミングチャートの読み方から始まった。
今にして思えば、たとえ制御できても、PC上での経験がなければ
文字の表示すら出来なかっただろう。
ゲーム業界、PCでの開発経験があったからこそ、今の自分がある。
まあ、絶対に無駄にはならないことは分かってたんだがｗ
で、フォントの変換システム。
単純な文字列からフォントデータを集めてアセンブリ形式のデータ定義ファイルに出す。
そんなものでも、いまだに役に立つのだから、これほど面白いことはない。
UnicodeとJISコードの変換テーブルを元にコードを取り出し、SJISに変換、その上でFONTXファイルから
データを探し出して、とりあえずファイルに。
16bitをUnicodeと見なして変換し、フォントのないところはダミーで埋めて・・・
そんなことをしたら2Mbyteになってしまった、なんてことがどこかに書いてあったな。
・・・・同じことを考えた人がいるんですねｗ
ファイルを分割してやれば何とかなるんじゃないかと思ってたんですが
予想以上に歯抜けというか、隙間が多い。
これだと分割の仕方が面倒になる。
というか、分割しきれない。
それよりも、SPIのシリアルROM、2MByteぐらいを積んで、
あとはテーブル引きしたほうが、断然速い気が・・・・・。
少なくとも、FATを辿っていくよりも、テーブルで一段引いて、それをオフセットにして
データ読み出ししたほうが、速いわな。。。
アドレスによる読み出し速度の違いはないんだし。
とはいえ、またSPIに頼るのも何だかな・・・
そんなことを考えながら、まだ画面には何も出てませぬ。。。
長い前フリでしたが（？）
やっと本題。
絵が出たので、次は文字列ですかね。
そーいうわけで、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の再編成から。
ここ数日、FONTを探してました。
WindowsがLFNでUnicodeを使うというので、
その配置で使える、$FONTX2形式を。
･･････････････････・・・・・・・・・・・・・・・・
そんなもん、ありませぬ ○|￣|＿
それよりも、
「文字コード、この乱立っぷりは一体何！何なの！」
英語圏は確かにASCIIコードで事足りるのかもしれないけど、
我々漢字圏は数万文字を持つわけで
確かに、昔から頭痛の種ではあったのですが。
日本には恐らく元々JISコードというものがあり、漢字にコードが振られていたのに
それをなぜかMicrosoftを含む数社が再マッピングしたShift-JIS、
ここ20年で国際化が進み、２バイトコードの標準化の過程で出てきた
EUC、そして、Unicode。
ややこしいのは、日本の漢字コードの規格化の過程において、幾度となく追加と修正が
行われ、そのたびにJISの規格番号が追加されていること。
その辺も含めないと、表示できない文字が出てきたりする。
・・・・・コード体系についてはかなり深いいきさつの元で成立してるようなので、
これ以上は突っ込みたくないな。
それ以上に、フォントファイルの形式がいっぱいありすぎて、
その殆どは仕様が公開されていない。
それらの相互変換を完璧にこなすようなツールもない。
Windowsで使われるttf形式とPostScript形式の変換は出来るようだが
旧来の$FONTX2形式にはならないらしい。。。
・・・・FatFsの説明書きをつらつらと読んでたら
どうも、SJISとUnicodeの変換テーブルを持ってるらしい。
使うにはcc932_avr.cをリンクしなさい、と。
ソースを覗いてみると・・・まあ、確かにあるね。
これでとりあえず、誤魔化せるのかしら。
じゃあ、変換するためのテーブルを探すか！と
検索すると・・・
ここでも、テーブルの内容にいくつものローカルなものが存在するらしい。
まぢですか～ ○|￣|＿
Unicodeの文字をSJISのどの文字のコードに変換するか、というのは
実はそうそう簡単な話ではないらしい。
この辺の話も、掘り下げればかなり深いのかもしれないけど
ここでは書きません。
スルーして、じゃあどの変換テーブルが当面安全なのか、というと
JAVA 1.4.0以降のテーブルと同じだ、というテーブル表に行き着いた。
とはいえ、こんなデカイテーブル、マイコンのメモリに納まるわけがないのは
明白なわけで。
どうしますかねぇ・・・
どういうわけか、ここ最近
私の周辺にはミニ四駆をやってる大人たちが頻出する。
まあ、私の世代は、誰もが通った道として
懐かしく思う・・・のはまあ、いいとして。
某店に出入りする関係で知り合った某氏を例に、
その大人気ないマシンについて。
彼が、去年10月の展示会の際にタミヤブース近辺でやってた
ミニ四駆の大会の際に見せてくれた、
エンペラーｊｒを使った「ノンターボエアブレーキ」。
なんでも、ジャンプ時にボディが開いて、結果的にエアーブレーキの役割をするんですって。
その蝶番の機構を組み込むのに、エンペラーのボディがうってつけらしい。
・・・・・・・・・・・ウケた。かなり。
他にも、金に糸目をつけず各種限定パーツてんこもりとか。
大人の財力に子供が敵うわけないわな・・・
そこまでして、子供相手に勝ちたいのか！？
おとなげないなぁ！
まったくもぅ・・・
でも、そんな大人たちであっても、タミヤは見捨てたりしないわけで
いろいろレギュレーションを調整したり、ジュニアクラスと分けたり。
なにより、そんな大人たちを取り込もうと、
昔なつかしのボディを再販、シャーシもタイプⅠからタイプⅢまで
古い金型を発掘して再生産、再販にまわすという復刻ビジネスに・・・・
・・・・・一番大人気ないのは、タミヤなんじゃないか、ってオチで。
いや、本当は、昨日大会があって、ソレを見に行ったことを書こうと思ったんだけどね(笑
オチがついたのでもう寝ます。
このくらい、外気温が下がってると
雪になるかもね。
これで、大雪になって交通機関が麻痺したら
ジタバタせずに「有給休暇！」って言えるのになｗｗ
「だって、雪だし・・・電車動かないし・・・」
たぶん、今日の雨が凍って終わりだろうけど。
#5cmは大雪じゃねーぞ
A劣者で逝こう９A列車で行こう9が、実は今日発売。
このゲーム、かなり頑張って続いてるんですけど、
だんだんダメになってるというか。
前回買ったのは、5年前のA7.。
3ヶ月以上前に大々的に発表会をやって、確かにそのゲーム画面の進歩に感心したものでしたが
何度か発売延期を繰り返した上に、発売当日にすでにパッチが出てるという、
低レベルっぷりを露呈してました。
その辺にも呆れてたんですが、少し経ってからパッケージを買ったんです。
起動したら、画面一面、白いBOXだらけ。
「なんなんだ、このゲームは・・・」と思うことしきり。
メディアの中身は、リビジョンが上がったものが入ってたので恐らく何度かマスター出しなおしてたんだろうけど、
インストール中になんか、チルダ付のフォルダが展開されてるのが見えた。
おかしいと思ってインストール先を見ると、画像が入ってるフォルダが2つに分かれてしまい、片方はチルダ付のファイル名で
展開されてました。そのフォルダの中身をもう一方に移したら直りましたけどね。
そして、パッチの嵐。
その修正内容もゲーム性直結な内容。笑うというか、呆れたわな。
デバッグしとるんかいな、こいつら。
A8は知らないうちに出てたので、とりあえずスルー。
気がつくとA9のアナウンス。
なんだか、時代の最高スペックを要求してくる。
事前チェック用に、A9ビュアーというのを配ってるのですが、
こいつが案の定、やらかしてる。
インストールすると、「X3DAudio1_5.dllが見つからない」とのたまうわけですよ。
で、それだけ入れると、次はまた違うDLLを要求する・・・と。
結局、DirectXのランタイム一式を入れないと動かないわけで。
ゲーム買ったわけじゃないんだから、そんなものデフォルトで入ってるわけないだろ！！
この会社が、ゲーム機でマトモなゲーム出せてるのが
ほとほと不思議だわ。
どんな体制で開発/デバッグしとるんだ。
そんなわけで、期待の発売日ですが
今のところパッチは上がってないようです(笑）
FAQも追加ないようですし。
線路引く画面がA5-完全版-に似てるのを見て、
嫌な予感がよぎったのですが・・・・
とりあえず、今のマシンではスペック的に足りないので
買うにしてもPCの新調が必要でしょうね。
なので、しばらく様子見かな。
と、言うわけで（？）
書き込みコマンドの使い方も分かったので
とりあえず、画像でも出してみますか。
まあ、ここに載せるにあたり、人様の著作物を無断で使うわけには行かないので
自分の写真から何枚か。
当然、こんなデカイデータ、ROMにもRAMにも入りませんから、
MicroSDとFatFsを使っています。
元画像はJPEGですけど、とりあえず24bitカラーのBMPに変換してからトリミング、
最終的には16bitカラーBMPに変換しています。
その割には、ここに貼ってる写真はトリミングしてねーじゃないかってのは
突っ込んじゃダメですからね。
ROMから再生するためにデータ変換してBMPのヘッダ削ってC言語の配列にして・・・なんて
やってましたが、さすがに飽きたので(笑
FatFsを有効にして、とりあえずファイル名はテーブルに持って。
BMPファイルは、いつか来た道ですから。
画像サイズの情報を取り出して矩形を設定後、
1ラインづつ読み出して一度RGBに分解。
フェードイン/アウトの演算後、Gのみ６ビット、あとは５ビットの計16bitフォーマットに再構成、
バッファに書き戻した後でバースト転送。
やろうと思えば、24bitカラーでも変換しながら描けるんですけどね～
ちなみに、16bitカラーのBMPってのは規格外ですからね。
BMPの仕様には正式に含まれていないらしいです。
まずは、予定通りバックライトのＰＷＭ制御を。
適当にタイマー割り込みにＰＷＭ動作の設定をして、カウントアウト時に
割り込み処理内で次のＰＷＭ時間の値を更新する。
メインループ側では、とりあえず一定時間経過ごとにカウンタを更新してみる。
・・・・動画もあるのだが、昔のデジカメで取ったのでは小さすぎて
何がなんだか分からないので割愛。
挙句の果てに携帯電話のカメラの方が解像度も高いし焦点距離も短いので
ここ最近の接写は全部携帯電話ですわ。
次。
フェードイン/フェードアウトをソフトウェアで。
データに演算をして輝度が変わったように見せかける。
さすがにリアルタイムで全画面書き換えるほどの能力はないらしい。
まあ、これはＣＰＵの問題なので、クロックとI/Oポートの性能によってしまう。
したがって、今のATmega128では限界ということで。
・・・・動画は(以下略 なので省略。
最後に、表示コマンドの仕様について。
他では、だれも何も書いてくれないようなんだけど。
内部バッファに於けるカレントのRow Address と Column Address を設定するコマンドと
メモリーに書き込むコマンドがあるけど、
この３つって、よくよく仕様を見ると、そんなに自由じゃないのね。
というか、カレントのアドレスを設定する、っていうより
転送先の矩形を設定するって感じかな。
アドレスといってるけど、実際は座標だし
要は左上座標と右下座標を設定するコマンドなわけ。
その上で書き込みコマンドは
「設定された矩形にデータを書き込む」感じ。
だから、矩形を満たすだけのデータを送らないと
次の書き込みコマンドを受け付けない。
最初に自分が書いたコードが動かないのは、ここに理由があって
毎回 コマンド→データ のセットで書いてた。
サンプル見ると、バースト転送してるわけだから
そりゃ気づくよな。
こんな仕様になってるメリットを考えてるんだけど・・・・
文字とかアニメーションのように、決まった矩形領域を書くときには、
こっちのほうが有利なのか？ぐらい・・・かな。
イメージは、カーソルのある位置に文字を書く、って感じ。
うーん。
とりあえず、他の記事を参考にしつつ(横着)
必要最低限のコマンドを。。。
・・・・・・・・・・・・・動かんｗ
じゃあ、aitendoにあったサンプルを・・・
・・・なんでこんなに設定が必要なんだ？？
まあいい。あとで削ってみよう。
動いた。
ハード的には問題なさそう。
データ形式は16bitカラーで。
みんな、あっさり動いたみたいに書いてるけど、
実際は違うね。
コマンドの出すタイミングで、描けたり描けなかったりする。
でも、誰もそれに触れてない。
とりあえず、画像を転送する余裕はないので
カウントまわして書いたBOXでしばらく実験しよう。
いろんなところで記事になっているので、
今更の気もするけど、とりあえず、やらなきゃならんので。
LCDはaitendoにあったZY-FGD1442701V1。
いろいろ探し回ったが、単一電源で厚さが3mm前後のモジュールがなかなかなくて。
OLEDもいいんだけど、小さいし、電圧いるしで今回は見送り。
LCDのバックライトはいづれPWM制御するつもりで、いつも使ってるスイッチICで切り離し。
CPUがATmega128なので、外部メモリにぶら下げる気満々で考えてたんだけど、
最終的にはXMEGA64A4あたりにするつもりなので
そこまで想定してI/Oポート経由の接続に直してある。
このモジュールの動作電圧について、いろいろ情報があるけど
中に載ってるコントローラーが3.3Vで平気なんだから、その外側から３Vしか入れちゃいけないなんていう
理由がどこにもないと思うがね。
追加部品はコンデンサぐらいしか必要ないんだから。
MicroSDも、画像データ用に搭載。
VS10ｘｘの時に苦労したので。
いづれは、フォントファイルを背負い込むことになるだろうから
今のうちに大容量を確保。
あとは、ALPSのジョグスイッチ。
思い切って電即納で買ってみた。
面実装用なので、運良く手元にあったシール基板で貼り付けてある。
最終的なシステム全体で必要な要素はこれで全部。。。かな。
正直、表示装置でここまでマトモに試作してるのって、かなり久々。
もともとVGAやビデオ信号で遊んでたのだが、
その辺のって表示装置が汎用で、デカくて
基板単独じゃ完結できないモノだったけど
これはユニバーサル基板で収まっちゃった。
というか、CPUのバスインターフェースで直接扱える表示装置って
はじめてかも。
・・・・・・・・今回はバス接続ぢゃないですけどね。
さて。
つらつらとコントローラの資料読みでもしますかね。。。
