update 2004.4.20

ばんがいへん１　コンバータの作り方
～その２　フォントテーブルを作る理由(わけ)～

概要
前回はフォントテーブルを完成させるところまで進めましたが、
今回はそのフォントテーブルを作る理由を解説します。

１つずつ処理した場合
前回に作成したフォントテーブルを見てみましょう。

現段階のフォントテーブル＊＝未知 / □＝スペース

   +0+1+2+3+4+5+6+7+8+9+A+B+C+D+E+F
00 ＊１＊＊＊＊＊＊＊＊ＡＢＣＤＥＦ
10 ＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶ
20 ＷＸＹＺ「」＊＊□＊＊＊＊＊＊＊
30 あいうえおかきくけこさしすせそた
40 ちつてとなにぬねのはひふへほまみ
50 むめもやゆよらりるれろわをんっー
60 が＊＊＊＊＊じ＊＊＊だ＊＊でどば
70 び＊＊＊＊＊＊ぺ＊＊＊＊＊＊＊＊

これは「１」というキャラ画像に 01 という数値を割り当てていて、
「あ」というキャラ画像には 30 という数値を割り当てているということですが、
これをもしも「データ読み込み→数値を判断して分岐→その数値に対する文字を表示」
という手順を行うとなると、

GetFile=getc(fp); // 元データを読み込み
if(GetFile==0x0A) printf("Ａ");
if(GetFile==0x0B) printf("Ｂ");
.
.(中略)
.
if(GetFile==0x30) printf("あ");
if(GetFile==0x31) printf("い");

少々大げさなプログラムですが、これでは１文字に対して１行ずつコードが肥大化します。
確かに不可能ではないですが、全１００文字の変換には１００行のコードが必要となり、
もしも漢字などを含む全１０００文字を超えるような大規模な変換となると、
もはや現実的に難しいですし、変換効率も最悪です。

差異を利用して、読み込んだデータがShift-JISになるように計算してやることもできますが、
(例)SJIS[あ]=A082 → 独自[あ]=30 → A082 - 30 = A052 → 独自 + A052 = SJIS
上のフォントテーブルでは「あいうえお…」と並んでいますが、Shift-JISの定義では、
「ぁあぃいぅうぇえぉお」という形でパターンが並んでいます。
ということは、GCCODEの簡易フォントテーブル表示機能が完璧に出力されない原因…つまり、
フォントの並びの違いがネックになり、計算のみでは正常な出力を期待できません。

フォントテーブルを使う
正しくは「配列を使う」なのですが、細かい部分を説明します。
N88-BASICを使ってた人は一発で理解できると思いますが、例えば

DIM A$(&HFF) ※&HFF=16進数FF。C言語の 0xFF と同じです。

これを実行するとA$(0)～A$(&HFF)までの256個の文字型配列が定義されます。
そして、

A$(&H30)="あ"
A$(&H31)="い"

これでA$(&H30)には「あ」の文字が、A$(&H31)には「い」の文字が入ります。
上のやり方では手間ですが、反復命令を組み合わせることで、
わずかなプログラムコードで全フォントテーブルを配列に格納することができ、
以後はA$(フォント番号)という参照で、いつでも任意の文字を得ることができます。
(例) PRINT A$(23) → 画面には「Ｚ」が表示される。

つまり「読み込んだデータがxxならばyyの文字を表示」のような判断を行うのではなく、
「読み込んだデータを指標として使う」のです。
プログラム本体は読んだデータをフォントテーブルの通りに文字を出力する
という処理をメインに動作します。
ゲーム特有の拡張命令などの細かい部分は修正する必要がありますが、
プログラムコードの大半を流用することが出来るため、抜群に生産性が優れています。
（ファイルチェック→テーブル読み込み→テキスト出力のほとんどが流用可能）

というわけで
前回に比べて内容控えめ中身カラッポでしたが次回に続きます。
上の例ではわかりやすくするためにN88-BASIC風で配列を説明しましたが、
次回はきっかけサンプル同封のC++ソースコードを元に話を進めます。
C/C++には文字列型が存在せず、二次元配列を用いて擬似的に文字列を扱うので、
その辺の説明もあわせてしてみたいと思います。

＞＞最終回へ

TOPに戻る

ばんがいへん１ コンバータの作り方～その２ フォントテーブルを作る理由(わけ)～

ばんがいへん１　コンバータの作り方
～その２　フォントテーブルを作る理由(わけ)～