CSSで間違い探しを解く

Tags: reading webdev

Hacker News経由で読んだ記事。2枚のよく似た絵から違いを見つけ出す、いわゆる「間違い探し」を、CSSのfilter機能を使って解くというもの。

原理は単純で、一枚目の絵はふつうに表示しておいて、二枚目の絵をCSSのfilter機能のinvert(100%)で色を反転させて、opacity(50%)で半透過させた状態で、一枚目の絵の上にぴったり重ねるように配置するだけ。簡単だけど、これで画像のdiffが取れるとは思いつかなかった。CSS filterは画像だけでなく普通の要素にも適用できるので、DOM要素を複製すれば「visual diff」も取れるとのこと。

こういうのを見ると自分でも試してみたくなりますな。というわけで、難しいと評判サイゼリヤのキッズメニューの間違い探しをネタにやってみました。輪郭抽出みたいになってしまっているのは、元絵がJPEGなために画素単位で色成分が一致していないからか、あるいは切り出しの時点でずれているためなのか。「次の画像」ボタンを押すと、過去に出題された問題を順番に切り替えられるようにしています。

なお、元記事ではFirefox 34以前ではCSS filterが使えないために代わりに「SVG filter」を使うようにしているようだけど、Firefox 35からは(vender prefixなしで)CSS filterが使えるようなので、このサンプルではそちらを使っています。

元絵

diff結果


HDリメイク版ファイナルファンタジーVの問題点

Hacker News経由で読んだ記事。HDリメイク版のファイナルファンタジーV(以下「FFV」)がリリースされたものの、肝心のグラフィックまわりの品質にいろいろ問題があるとのこと。記事の筆者はインディーズゲームの開発者で、自身の旧作をHDリメイクした際の経験を元に、ドット絵ベースのゲームを高解像度にリメイクする際に具体的にどうするべきであるのかを、HDリメイク版FFVの問題点を引き合いに出しつつ論じている。一般的な話だけ抜粋しておおざっぱにまとめると、以下のような感じですかね。

  • まず最初に言いたいのは「オリジナル版と同じグラフィック」のモードをオプションとして用意しておこう、ということ。
    • どんなにうまくHD化したとしても、一部のユーザーは「オリジナルの方がいい」と言うものだ。
  • オリジナル版のグラフィックを何倍に拡大するかは非常に重要。
    • 「1.0倍より上~2.0倍未満」の倍率は絵がつぶれて不鮮明になるので避けるべし。
    • キリのいい倍率に拡大しようとすると一般的なディスプレイ解像度に合致しない場合、内部的にはキリのいい倍率を採用して、実行時にダウンスケールするという手もある。
  • スプライト等のアセットを手っ取り早くHD化する場合、実行時に拡大するのではなく、事前に拡大した画像をアセットとして持つ方がいい。
    • スプライト画像の拡大の際には、ドット絵に適した拡大アルゴリズムを選択すること。
    • アルファ値の扱いには気をつける。
      • RGB部分とアルファ部分は分けてから拡大アルゴリズムを適用すること。
      • 適切なツールを使って作業する。
  • もし、オリジナル版の製作時に作ったドット絵にする前の「元絵」があるなら、それをベースに作るのが一番いい結果になる。
    • 「元絵」にはアンチエイリアスがかかっていないほうが望ましい。
  • 「タイル」の並びで絵を作っている場合、タイル一枚ごとに拡大処理を行ってはいけない。
    • そうすると、タイルを並べたときに境界ができてしまう。
  • カットシーンでの大きなサイズのグラフィックを拡大するにはWaifu2Xが適している。

詳しくは元記事を読んでください。


で、これが問題のリメイク版FFVの画像。タイルの継ぎ目が見えている、スプライトのドット絵がやたら平坦、全体的に画がぼやけている、などなど。たしかにこれはお世辞にも褒められたものではないな……。

この記事にも書いてあるように、以前スクウェア・エニックスがFFIやFFIVをPSPに移植した際は、スプライトのキャラにせよBGタイルの背景にせよ、きちんときれいに描きなおした形でリメイクされていたわけで、かつてはできていたことがなぜ今はできない(or やらない)のか……という気分になる。1 これは今作のFFVリメイクに限った話ではなく、モバイル版FFVIのレビューあたりを見るに、ドット絵ベースのFFシリーズにおけるここ最近のリメイクのクオリティは、どれも似たような体たらくらしい。


記事の中で指摘されている点の一つに、「顔グラフィックに“天野絵”をそのまま使っているけど、ゲーム内のドット絵キャラと乖離がありすぎる」という話が出ていて、思わず苦笑。初期FFシリーズにおけるこの件に関しては、我々もみんな20年以上前から同じようなことを思っていたものですよ……。

例として挙げられているこのシーンの場合、ドット絵キャラのバッツとレナの髪の色はそれぞれ茶色とピンクなのに対して、顔グラフィックの髪の色はどちらにもあてはまらないので、確かにこれは初見だとどっちのキャラなのか分からなくてもおかしくない。おまけに天野氏の描くキャラクターの絵が中性的なので、混乱に拍車をかけている感じ。

この件についてオリジナル版のFFVIが引き合いに出されていて、FFVIのメニュー画面では天野絵ベースの顔グラフィックが使われているが、これはオリジナルのアートワークをそのまま使っているわけではなく、ちゃんとゲーム内のドット絵キャラのデザインに合わせてアレンジしているとのこと。こうして比較すると、確かにだいぶ違いがある。

初期のFFシリーズでゲーム内で顔グラフィックがあったのはFFII・IV・VIだけど、自分の認識としては、IIとIVではゲームに映えるように天野絵をポップ寄りな絵にアレンジしていたのに対し、VIはそのままの絵をゲーム内に載せてきた、と思っていた。が、実はそうではなく、VIの絵も元絵をかなりアレンジしてたんですな。


この記事の筆者は当時のFFシリーズをかなりリスペクトしているようで、そのことは文章を読んでいても伝わってくる。2 別の記事になるが、自分たちの開発したインディーズゲームのメインテーマ作曲に、あの植松伸夫氏をフィーチャーしたというのだからすごい話だ。このプレスリリースの記事を出したのが4月2日なのだが、ほんとは昨日出すつもりだったけど、エイプリルフールのジョークだと思われそうなので一日待ったのだとか。


  1. 下請けの力量の差か、あるいは予算が少ないのか、はたまたその両方なのか。
  2. “a legendary game series like Final Fantasy”とか“the legendary Yoshitako Amano”とか。まあ、名前をスペルミスしているのはご愛嬌。

Hello Hugo!

Tags: Hugo

hugo

新たにHugoでブログを始めることにした。はたして何度目のブログになるのかな。今度こそ継続させたいとは思うものの、どうなることやら。

ブログ遍歴

今まで何度もブログを始めては、だんだんやる気がなくなってやめるのを繰り返していた。振り返ってみるとこんなところか。

  • blosxom
    • ブログを最初に書き始めた時に使ったのはblosxomというPerl製のツールで、これも静的生成ツールだった。当時ホスティングに使っていたサーバーではCGIも動くしDBも使えたので、別に動的生成のツールでもよかったけど、分かりやすさと手離れの良さを重視してこれに決めたような記憶が。
    • 記憶が曖昧だけど、プラグインを入れてWiki記法で書けるようにしていたはず。
    • しばらく書かない時期が続いた後、再開しようと思ったけど、記事の出力方法や公開方法を忘れてしまい、止めてしまったのではなかったかな……。
  • iKnow!の日記機能
    • かつて英語学習サイトのiKnowでは自前のSNSサービスを用意していて、そこの日記機能を使って何かしらの文章を(時には英語で)書いていた時期があった。
    • たしかそのサイトではTextileをベースに独自拡張を入れたような記法を採用していたはず。“はず”、というのは、サイト内には日記機能についての詳しい説明が用意されておらず、どんな記法がサポートされているのか明確に文書化されていなかったため。
    • Textileは表現力が高くていろいろできるものの、それが災いしてか普通の文章中に出てくる記号や表記がTextileの記法とかち合うことも多く、思い通りに制御するのに苦労した覚えがある。
  • Blogger
    • 前述のiKnowが運営方針をがらっと変更した結果、SNS的要素が撤廃されてしまい、日記機能もなくなってしまった。当時はGoogleのサービスをメインで利用していたので、とりあえずBloggerを使うことに。
    • しかしながら、当時の(今も?)Bloggerは軽量マークアップ言語の類をサポートしておらず、いろいろ横車を押して、はてな記法だかなんだったかを使って投稿できるようにした記憶が。
    • こういうふうに、投稿する際にちょっとした手間を要するようなワークフローにしてしまうと、少し間が空いた後に再開しようとする際に、やり方を思い出せずにそのままフェードアウトすることになりがち。
  • Tumblr
    • Markdownをサポートしていることと、気軽に書けそうなところを重視して、Tumblrを選択。
    • 確かにちょっとした(かつ140文字には収まらない)ことをさらっと書くのにはいいけど、ある程度まとまったブログの記事を書く場としては「なんか違う」感を常に感じていた。

今回ブログを再開するにあたってHugoを選んだ理由だが、実のところ「なんとなく流行ってるなー」くらいの軽い気持ちだったりする。ただ、BloggerやTumblr等の外部サービスを使っていた頃も、自分のPCでファイルに下書きした上で投稿画面のフォームに貼り付けてポストしていたわけで、だったら最初からローカル側でリソースをすべて管理する静的生成ツールに回帰するのもいいかな、といった気分もあった。

Hugoを触ってみての印象

「速い」という話は事前に聞いていて、使う前はさほど重要とは思っていなかったものの、これがLiveReloadと組み合わさるとかなりの威力を発揮すると感じた。Hugoにはlocalhostで動くWebサーバー機能があって、生成したサイトをローカルで確認できるが、この場合ローカルファイルの更新を検知して自動的にリロードされるようになっている。エディタ上でテキストをセーブして1秒後にはブラウザの画面に反映される、というのは、実際に体感してみるとインパクトが強い。単に「速いから快適」というレベルの話ではなく、速さによってユーザー体験が質的に向上している感じ。公式サイトにこんなことを書いているのは伊達ではない。

Hugo may not be the first static site generator to utilize LiveReload technology, but it’s the first to do it right.

The combination of Hugo’s insane build speed and LiveReload make crafting your content pure joy. Virtually instantly after you hit save your rebuilt content will appear in your browser.

当初はブログ再開を機にMarkdownプレビュー機能のあるエディタでも導入しようかと思っていたけれども、少なくともこのブログの記事を書くためには必要なさそうかなあ。いつも使っているエディタといつも使っているブラウザで十分っぽい。

ちょっと困っているのは、Tumblrでは使えたMarkdownの拡張機能が一部使えない点。上のリストは、本当は定義リスト(<dl><dt><dd>)を使いたかったところではある。Hugo内部で使っているMarkdownパーサーの設定を変えるとか、あるいは差し替えることとかはできるのかな。後で調べておかないと。

あとは、見出し要素に自動でidが振られるのはいいんだけど、その属性値が「見出し文字列をUTF-8でそのまま + : + md5文字列」というのは個人的にはちょっときつい。HTML5からはid属性値の制限がほとんど取っ払われたらしいので、日本語文字列が混じってもvalidなんでしょうけど、URLの一部にもなる文字列なのでもう少し穏やかな感じにしたい。これも調べておかないと。