FC2ブログ
<-->


アンチエイリアスとジャギーの奇妙な関係

 はじめに

ね?
たしか前回ちゃんとお話しましたよね?

 >(テンプレートが)これからも気まぐれで、ころころ替わったりするかとは思いますが、
   どうか生温かい目で見守ってください。

気まぐれつっても、程ってものがあるだろう!

はい。皆さんのお気持ち、よーくわかります。
まさか前回の今回でブログのテンプレートがまた変わるなんて、自分でもなんじゃそりゃあ! 
ってなもんなのです。
それほどまでにvanの心は気まぐれだと思ってください。

……つかみにくい性格だな、とは、人からよく言われます。はい。

この項では、フォントサイズに対してのアンチエイリアスとジャギーについて簡単な覚書きを
残しておきます。


 アンチエイリアスとは?

まず「アンチエイリアス」について説明します。
簡単に説明すると、ドットのギザギザを目立たなくさせるコンピューターグラフィックス技術の一つです。
「アンチエイリアスが効いてて、このCGは綺麗に見えるねー」とか
「アンチエイリアスがかかっていないから、ジャギー(ギザギザ)が目立って見にくいなぁ」
という風に使われます。

間違っても
「この宅急便の荷物、俺ァンチエ入イリアス(この宅急便の荷物、俺んちへ入りやす)」
なんて、使わないようにしましょう。
恥をかくのは、きっとあなたです……

「アンチエイリアス」について詳しく知りたい方はこの辺を参考にしてください。


 アンチエイリアスとジャギーの奇妙な関係

ある高名な方の話によれば、物事には二つの面があるそうです。

 光と影、正義と邪悪、勇者と魔王。
 そして、納豆にネギ入れる派と入れない派。
              by 夜種王(フリーゲーム 「Ruina 廃都の物語」より)

相反する二つの要素は、ある地点を境に同じベクトル量を保っていることが解ります。
裏を返せば双方とも、同じ内容を指しているのかもしれません。
どちらが良い、どちらが悪いというものではなく、ケースバイケースで双方を使いこなせる事が
重要なのではないでしょうか。

アンチエイリアスとジャギーの関係も、それに似た関係といえるでしょう。
残念ながらアンチエイリアスだけでは、物事はうまく廻らないのです。

ドットが滑らかに見えるという事は、輪郭が明瞭ではない事を意味します。
つまり全体がぼやけて見えるのです。
その現象は、フォントの大きさが小さくなればなるほど顕著です。

参考として、ウディタでフォントサイズ2から16のフォントを表示させ、アンチエイリアスありなし二つのフォント画像を用意しました。

ScreenShot_2010_0423_04_41_.jpg
※画像の内容は、例のブラジル人とは一切関係がありません。

見ていただけると解るかと思いますが、アンチエイリアス有は曲線が滑らかで読みやすいものの、文字サイズが小さくなるにつれ、ぼやけ具合も高まってると思います。

逆にアンチエイリアス無は、大きなサイズだと確かにジャギーが目立つものの、
アンチエイリアス有で読みにくかったサイズでは一転して、可読性の高さが伺われます。
つまりある程度の小さい文字は、逆にアンチエイリアスを無にした方が読みやすい。
そういう結果に繋がります。

では、その境目は何処でしょうか?
アンチエイリアス無しを見ると、フォントサイズが11を超えると文字が太くなり、
ジャギーの荒さも顕著であることが解ります。
つまりフォントサイズ11を目安に、11を超えるフォントはアンチエイリアス有で、
12を下回るフォントはアンチエイリアス無という、一つのセオリーが導かれます。

とはいっても、フォントサイズ9くらいまでであれば有でも問題なく読めるはずですので、
セリフ文なら問答無用で有にしても問題ないかと思います。
その辺は、製作者様のセンスやカン、あるいは日頃の行い等を加味してご判断ください。

なお上記内容は、デフォルト設定であるフォント「MS ゴシック」について該当します。
当然の事ながら他のフォントでは全く異なる内容になりますので、ご注意ください。

付録として「MS 明朝」の同じ内容の画像を上げつつ、この辺で失礼させていただきます。

私の心はいつも、マリワナ海溝よりも深く頭を垂れてる次第です。

ScreenShot_2010_0423_06_47_00.png


以下は拍手の返信コメントです。

続きを読む

スポンサーサイト



各イベントの実行順序について


※以下の内容はサイト「WOLF RPGエディター エラーコレクション - 非公式 -」
 からの移転記事になります




 はじめに

「バックアップについて」の記事を執筆中、気になったので少し確認してみました。
ただし、「バックアップについて」の内容に携わる範囲しか確認しておりません。
また、認識違い・検証ミス等あればご指摘いただけると助かります。

以下、端的に説明、詳しい説明は割愛します。
意味がわからない方は読み飛ばしていただいて、差し支えありません。

< 2009.10.05付[WOLF RPG エディター Ver.1.14]をDL、【完全初期状態】にて検証 >

 マップイベントの実行順序について

 a.複数ページの起動条件が同一の時:
          ページ数の大きい内容のみ実行される(小さい方は実行されない)

 b.重なっているイベントの起動条件が同一の時:
              イベントID が若い方 → 古い方の順にイベントが実行される

 c.上記a.b.が混在している時:a → b の順に実行される

   検証例>
Ev0 のページ1 → 文章表示:「0-1」 ページ2 → 文章表示:「0-2」と指定
Ev1 のページ1 → 文章表示:「1-1」 ページ2 → 文章表示:「1-2」と指定
双方の起動条件:プレイヤー接触に指定 Ev0 の上にEv1 を重ねる

上記条件下のイベント起動時は「0-2」→「1-2」と文章表示される
(「0-1」「1-1」は非表示)



 コモンイベントの実行順序について

 「自動実行」処理と「並列実行」処理において、双方の「条件」が同一のときは
  コモン番号には左右されずに「自動実行」 → 「並列実行」の順に実行される。

   検証例>
コモン番号000 → 起動条件:自動実行 条件:V0が1と同じ 
            文章表示:「自動実行」と指定

コモン番号001 → 起動条件:並列実行 条件:V0が1と同じ 
            文章表示:「並列実行」と指定

マップイベント0 → 起動条件:プレイヤー接触 変数操作「V0=1」と指定

上記のイベント起動時は「自動実行」 → 「並列実行」(繰り返し)と表示される
※双方のコモン番号順を変更しても変化無し


---

 起動条件と条件が同一のコモンが複数あった場合、処理タイプによって変化する
 双方が「自動実行」の場合:コモン番号の若いイベントのみ実行される
 双方が「並列実行」の場合:コモン番号の若いイベント → 古いイベントの順に実行される

   検証例>
コモン番号000 → 起動条件:自動実行 条件:V0が1と同じ
            文章表示:「自動実行0」

コモン番号001 → 起動条件:自動実行 条件:V0が1と同じ
            文章表示:「自動実行1」

マップイベント0 → 起動条件:プレイヤー接触 変数操作「V0=1」

上記条件の自動イベント起動時は「自動実行0」(以下繰り返し)と表示される
同様の条件で並列イベント起動時は「並列実行0」→「並列実行1」(繰り返し)
と表示される

※双方のコモン番号順を変更すれば、変更したとおりに表示される


---

 名前で呼ばれた時に同一名称が複数存在した場合の実行順:
 基本的には「その他2」>「コモン名で呼び出し」で選択したコモンのみが実行される
 削除や移動して、その場所にコモンが無くなった場合、他に同じ名前があれば番号の若い
 同一名称のコモンのみが実行される
 他に同一名称のコモンが存在しなければ、無視される(エラー非表示)

   検証例>
コモン番号000 → 名前:test 起動条件:呼び出しのみ 文章表示:「test0」と指定
コモン番号001 → 名前:test 起動条件:呼び出しのみ 文章表示:「test1」と指定
コモン番号002 → 名前:test 起動条件:呼び出しのみ 文章表示:「test2」と指定
マップイベント0 → 起動条件:プレイヤー接触 その他2>コモンイベント名で
            呼び出し、最上段の「test」を指定
            コモン番号000を消去、もしくはコモン番号004に移動

上記条件下の呼び出しイベント起動時には「test1」と表示される

バックアップについて

※以下の内容はサイト「WOLF RPGエディター エラーコレクション - 非公式 -」
 からの移転記事になります




 はじめに

ウディタに限った話ではありませんが、デジタルデータを編集する際にバックアップを
確保しておくのは、基本中の基本です。

万が一の事故を想定するのはもちろんの事、コモンイベントを散々いじった挙句に元に
戻せない・・・といった、やるせない失敗を防ぐためにも、適切なバックアップは必要です。
(経験者談)

またそれとは別に、前の状態への復旧を余儀なくされるケースも往々にしてあることです。
手を加えてみたものの後で見直してみて、やっぱり前の方法が良かった、なんて
一度や二度ではありません。
しかしバックアップデータさえあれば、すぐに前の状態に戻すことが可能です。

この項では私的な方法を交え、基本的なバックアップ方法について簡単に説明いたします。
実践できる内容があれば、ぜひお役立てください。


 全データのバックアップ

製作前に日付入りのフォルダを用意、最低でも一回、前データをバックアップする

 et_backup1.jpg

 私は製作を始める前に、必ず前回までのバックアップを取るように心がけています。
 目的は作成データの保護と、これから手を入れる内容の保険の為です。
 これは後述する「マップイベントのバックアップ」「コモンイベントのバックアップ」でも
 復旧できない際にも効果を発揮します。

 また、ドライブの事故からデータを防ぐことも可能なので、専用ドライブを設けて
 バックアップするのが推奨です。
 ただし、ドライブを一つしか持っていない環境では選択できないので、具体的な場所は
 お任せします。

 なお、データを何世代(何日分)確保しておくかは、利用されているHDD容量をかんがみて
 ご検討ください。

 参考:同じ階層のフォルダにコピーする際は、[Ctrl+ドラッグ]で対象フォルダを
     コピー可能(Windowsの場合)



 マップイベントのバックアップ
 
方法1:イベントをコピーして、マップ内の任意の箇所に張り付け

 et_backup2.jpg

 イベント起動を防止するため、起動条件を「決定キーで実行」に変更、通行許可設定が
 ×で囲まれたマップの上(海の中など)に張り付けて保管するのが良いでしょう。

 注意:元のイベントから離れすぎてるとバックアップの存在を忘れるので、
     極力近くに置いておく
     もしくは、【Ev1は0のバックアップ】等の注釈を元イベントに入れておく
     更に、バックアップ側にも【Ev0のバックアップ】等とコメントを入れておけば尚よし



方法2:イベント内容を全コピーして、同イベントの新規ページに張り付け

 et_backup3.jpg

 バックアップ内容が乖離せず、データのアクセスも容易なので、場合によっては
 こちらの方法も使うでしょう。

 注意:バックアップイベントを起動させないようにすることが不可能
     テストプレイ中に誤って起動させないように、適する起動条件に変更する事や
     変数の管理に気をつける

 参考:複数ページの起動条件が同一の時は、ページ数の大きい内容が実行される
     (詳細は「各イベントの実行順序について」を参照ください)


 コモンイベントのバックアップ
 方法1:.common形式のファイルとして出力

 et_backup4.jpg

 出力されたファイルの中を直接確認することは出来ませんが、複数のコモンを
 まとめて一つに出力できるといったメリットがあります。
 複数のコモンが複雑に絡み合うコモンに改変を加える際には、こちらを利用するのも
 良いでしょう。

  参考:[Shift+単体保存ボタン]でコモンイベントの内容を.txt形式で
     書き出す事が可能


 オンラインマニュアル>コモンイベントの設定>5.ファイル出力b.コモンイベントウインドウの空白コモン番号部にコピー

 方法2:コモンイベントウインドウの空白コモン番号部にコピー

 et_backup5.jpg

 手軽に退避・復旧が可能なので、この方法をよく利用しています。
 またバックアップデータにすぐにアクセスできるので、必要な内容のコピー等も
 容易に行えます。
 改変を加えるコモンをCキーでコピー、空白のコモン番号部にVキーで貼り付けて
 バックアップとします。

  注意:バックアップしたコモンイベントの起動条件を「呼び出しのみ」に変更する

 同名のコモンイベントが複数あるとまず間違えますので、バックアップ側をリネーム
 (名前変更)します。
 ぱっと見て一番判別しやすい、というのが最大の理由です。
 コメントでその旨を記載してもよいのですが、何らかの拍子で順番が入れ替わって
 しまった際に、名前で呼ばれて起動することも防げます。

 リネームはどんな名前でも構いませんが元の名前からかけ離れすぎると後で確認した際に
 意味不明になるので、元のコモン名+(bak)とか日付を入れるのが良いでしょう。


 おわりに

 以上、バックアップの方法について簡単に説明させていただきました。
 これで自作コモンであろうが、基本システムの改変であろうが、恐れる必要はありません。
 思いのままに、思うがままに、気の済むまでいじり倒してください!

デバッグの方法について


※以下の内容はサイト「WOLF RPGエディター エラーコレクション - 非公式 -」
 からの移転記事になります





 はじめに

デバッグとは、想定外の挙動を見せているプログラム部分を探し出し、適切な内容に修正、
想定している挙動に近づける作業です。

想定している挙動に近づけるためには、ゲーム内部で管理されている内部情報
(変数や使用されているファイル名等)を正確に把握していないと効率よく進みません。

そこで内部情報を画面に表示して、目視しながら進めていくと、認識ミスを防ぎながら
効率良いデバッグが可能です。

この項では、内部情報を画面で確認する方法と、デバッグの方法について端的に説明します。
なお、デバッグについての基本的な考えは「現象の切り分けについて」について記載した内容を用いることが可能です。
そのため考え方については割愛いたします。





 内部情報を確認する方法について


内部情報を確認する方法については、主に以下の方法があります。

 a.テストプレーで開始、F8にて確認
 b.同、F9で確認
 c.「文字列をピクチャとして描画」にて、特殊文字を指定して確認
 d.文章表示にて、特殊文字を指定して確認
 e.自分でデバッグイベントを作成する

順に説明していきます。




 a.テストプレーで開始、F8にて確認

   F8で確認


 ■確認できる内容:

  ① 使用中のピクチャ(括弧内は画像)と音声の総数
  ② 読み込まれている画像ファイル名と、Dataフォルダを基準としたパス
  ③ 読み込まれている音声ファイル名と、Dataフォルダを基準としたパス
  ④ 読み込まれている各種チップファイル名と、Dataフォルダを基準としたパス
  ⑤ 利用されているピクチャ番号
  ⑥ 同時に実行されている並列コモン番号

 ■特徴:
 F8を押している間のみ表示される
 「並列イベント」と同じような挙動のため、表示させながらゲームの進行が可能

 ■注意:
 game.exeで開始した際には実行できないので、editor.exeからの
「テストプレイ開始」から実行すること




 b.同、F9で確認

   F9で確認

 ■確認できる内容:
通常変数、文字列変数、システム変数、システム文字列に格納されている値、
及び文字

 ■特徴:
F9を押すと表示され、決定キー(Enterキー)・スペース・マウスクリックで画面の
更新・終了が可能
「自動実行イベント」と同じような挙動のため、表示させながらゲームの進行は不可

 ■注意:
game.exeで開始した際には確認できないので、
editor.exeからの「テストプレイ開始」から確認すること

 ■参考:
F9中は決定キー(Enterキー)・スペース・マウスクリック以外のボタン操作が
無効になる
そのためPrint Screenキーでキャプチャの採取は不可




 c.「文字列をピクチャとして描画」にて、特殊文字を指定して確認

   デバッグ

 ■確認できる内容:
特殊文字で表示可能な変数

 ■特徴:
表示イベントの組み方に依存

 ■注意:
表示はイベントの組み方に依存するので、表示させたタイミングと現時点で値が
異る場合があることに注意




 d.文章表示にて、特殊文字を指定して確認

   デバッグ2

 ■確認できる内容:
特殊文字で表示可能な変数

 ■特徴:
決定キーで文章を終了させない限り表示される
また、「文章表示」を置いたプログラムの進行もそこでストップされる
プログラムが進まないので、その時点での正確な内容を把握する際に便利




 e.デバッグイベントを自作する

 ■確認できる内容、特徴、注意:
作成したイベント内容に依存

デバッグイベントの参考として、wikiに登録されているデバッグコモンを
リンクとして挙げておきます。

   icon2.png WOLF RPGエディターWiki>自作コモンイベント>Self変数&cdb監視コモン


デバッグの方法について 

特定のコマンド部分が怪しいと察した場合、その部分を除外してテストプレイすることで判別が可能です。

 ■除外しても現象発生
  →除外した箇所は要因ではない

 ■除外して現象改善
  →除外した箇所に要因あり

除外する際にdelキーで削除してしまうと、除外した内容を復旧させることが出来ません(※1)。
イベントやコマンドを除外する際はdelキーでなくxキーで切り取って除外しておきます。
テストプレーの確認後、除外箇所をvキーで復旧を簡単にするためです。

※1:
Ver 1.14にて「一つ元に戻す」機能が実装されました。
コモンイベントでの編集時であればdelキーで除外しても「一つ元に戻す」機能で
復旧可能です。ただし、マップイベント側には実装されていないので、
マップイベント編集時にはご注意ください。






 コメントアウトについて

ウディタではいわゆる「コメントアウト」機能は実装されていません。
擬似的な方法として、ラベル移動とラベルで挟んでおく事で実質可能です。
テストプレイで確認する際に、ラベル移動を削除して確認、ラベル移動を追加して
コメントとして保持します。
(逆の、ラベルとラベル移動だと無限ループになるので、気をつけてください)

   コメントアウト1

また、公式サイトで他のユーザーの方から教わった方法ですが、ループ回数0回の
回数付ループにコマンド内容を格納しておいても同様の処理が可能です。

   コメントアウト2


但し、二つの方法は単体では想定どおりの挙動を確認していますが、他プログラムに
どう影響するか保障できません。
使用は自己責任でお願いします。





 おわりに

以上、デバッグの方法について端的に説明させていただきました。
デバッグの効率は、製作状況にそのまま影響します。
独自で効率の良いデバッグ方法を見つけ出すのも、製作を早める一歩だと思います。


現象の切り分けについて


※以下の内容はサイト「WOLF RPGエディター エラーコレクション - 非公式 -」
 からの移転記事になります




 はじめに

このページではウディタの不具合について、現象の切り分けについて簡単に説明します。
切り分けの極々基本的な内容しか記載できませんが、お役に立てればと思います。
なお、この項の内容は【基本的な対処法】をクリアしていることが前提です。

現象の切り分け内容は多岐に渡り、有効的な方法もケースバイケースのため
汎用的に言える事は少ないです。
ただし、要素をしっかり絞り込めば必要な計算・方法の算出は意外と簡単です。

A(環境/状態)+B(操作)=C(現象)

方程式があるとすれば、こんな具合でしょうか。
文章で言うとこうなります。

ある状態中に(A) 一定の操作をすると(B) 現象が発生する(C)

現象を確認した際に、上記のAとBが何を意味しているのか漠然とでも解るようになると、
それを確認するためにどういった計算や処理を行えばよいのか、自ずと導かれます。

以降、自作ゲーム中マップaからマップbに移動するとゲームが強制終了するという、
架空の現象を例題として進めます。



  第一歩

まず最初に行うことは、A・Bそれぞれに対して、要因を特定することです。
切り分けの基本は、確かめたい要素だけを変化させ、他の要素は何も変化させない
ことです。           

【 方法例 】
同じデータ上で同じ内容の、異なる操作を行ってみます。
マップの端にキャラが移動したら、「場所移動」でマップbに移動する処理を
設けているかと思います。
そこで、マップ移動を管理しているイベント上で、マップbではなくマップcに
移動するイベントに変更してみます。

A+B=C ならば A+B'=C が成り立つか確認する作業です。
これを行うことで、B(操作)の要因が「マップbに移動すること」かどうか判別します。

  ■マップcに移動すると現象未発生
   →「マップbに移動すること」に要因の可能性あり

  ■マップcに移動しても現象確認
   →「他マップに移動すること」に要因の可能性あり

「他マップに移動すること」に要因があると確認できれば、同様にマップd やe にも
移動処理を行って確認します。
その結果、特定のマップに移動することが要因ではなく「場所移動」コマンドに要因がある、
という結論に至るかもしれません。




 第二歩


続いて環境/状態の切り分けです。
異なる環境で同じ操作を行った際に現象が確認できなければ、元の環境による
問題の可能性があります。

A+B=C ならば A'+B=C が成り立つか確認する作業です。

【 方法例 】
手段の一つとして、改変の無いサンプルゲームで確認するというのは、有効な切り分けの一つです。サンプルゲームに同じイベントをおいて検証してみます。

  ■サンプルゲームでも現象が確認
   →環境/状態は要因ではない(全ての環境/状態で起こりうる可能性あり)

  ■サンプルゲームで現象が確認出来ない
   →自作された部分(AとA'の差分)に要因の可能性あり

結果より、上記の内容に結論付けることが可能です。
冒頭でも述べましたが、切り分けを行う際は A'+B'=C になっていないかどうかご注意ください。
「確かめたい要素だけを変化させ、他の要素は何も変化させない」ことが肝心です。

一度に二つの要素の切り分けは、要因をあやふやにさせるだけでなく、要因の誤認に
繋がりかねません。

必ず A'+B=C、A+B'=C を個別に確認するようにしてください。


 第三歩

A・Bの要因が特定できたら、確認した内容が正しいかどうか「逆」を使って確定させます。
たとえば要因が「マップa からb に移動する事」と認識したとします。
上記の場合、マップa からマップb に移動したときのみ現象が確認できなければ、
正確ではありません。

【 方法例 】
マップa → b だけではなく、マップb → a に移動した際に、現象が発生しないことを確認しておきます。

もし、マップb → a に移動した際にも現象が確認できれば、「場所移動」コマンドそのものに
要因があるのかもしれません。
少なくとも要因が「マップa からb に移動する事」ではなくなりますので、
認識を改める必要があります。

要因を特定できたなら、「逆」を使って要因を確定させるところまで試行できれば、ベストです。
               


 最終確認

A・Bそれぞれの要因が確定できました。
確定できたら、さらにもう一手指しておきます。

【 方法例 】
空データを用意して、最低限のイベントやグラフィックのみを置いて現象を確認
できるかどうか、検証します。

こうする事によって他要素から影響を受ける事なく、要因を検証することが可能です。

不必要な要素が存在すると、検証結果が異なったり正しい結果に繋がらなかったりします。
不必要な要素を排除することで、要因のみをダイレクトに一点検証することが可能です。
正しい認識と正確な切り分けが出来ていたら、最低限のデータだけで現象の確認が出来るはずです。

余計な要素を省いているので、それはシンプルで純度の高いソースになります。
シンプルで純度の高いソースは、「バグ報告スレッド」にて検証データをアップするにあたり、
申し分のないデータとなるでしょう。
また余計な要素を省いているので、製作者様も確認を行う際にスムーズに確認できるに違いありません。



 おわりに

以上、現象の切り分けについて思いつくままに記載しました。
話が長くなりましたが、考え方についての基本なので、慣れてくれば途中を省いたり応用が可能です。
また、最後まで確認するためには工数が少しかさみます。
しかし正確な情報を掴むためにも、自身の環境で確かめられる所までは、
頑張って確認してみてください。

なお、A+B=C A'+B=C A+B'=C という考え方は、デバッグやプログラムの組み方にも応用が可能です。
確認された現象が、どんなイベントコマンドが要因になっているのか特定が早ければ、
効率の良いデバッグを行うことが可能です。

イベント(C)がどんな要素(A・B)を含んで成立しているか細分化できるようになれば、
ウディタで複雑なイベントを組む際に大きな手助けになるはずです。

ぜひ、お役立てください。
リンク
twitter
http://twitter.com/vanzgraphica
このページのトップへ