K-Shoot MANIAの微妙な点としてよく挙げられるのが、「テクスチャの画像ファイルにGIF形式を使用しているせいでグラフィックが汚い」という点です。

GIF形式は256色しか使えないため減色が必要で、グラデーションを含むような画像には明らかに不向きです。それなのに、なぜGIF形式なんかが使われているの・・・?

ズバリお答えしましょう。理由は「歴史的経緯」です。
…なのですが、単なるK-Shoot MANIA自体の歴史的経緯というよりは、少し別の歴史的経緯なのです。こちらについて触れていきましょう。

開発当時はね…

K-Shoot MANIAの最初の公開バージョンであるv0.10は2013/04/17に公開されました。実際の開発はこの半年ほど前の2012/10から着手し始めました。

当時、慣れないVisual C++を片手にC言語で開発に着手し、何とか格闘してテキストファイルの内容をコマンドプロンプト上に表示させるところまではできました。
しかし、テキストの読み込みだけでここまで苦労している状況ではいつまでも完成しないと思い、C言語はやめて当時使い慣れていたHSP(Hot Soup Processor)で作るよう方針転換しました。


プログラミング言語 HSP3 公式 - HSPTV!

開発時は当時の最新版より少し前のバージョン(3.3だったか3.3aだったか)のHSPを使っていました。
当時は1ヶ月前に3.31(2012/9/5)が出ていましたが、あまり気にしていなかったので前のバージョンのまま開発に使用していました。

HSPでの開発へ方針転換してからの開発スピード向上は絶大なもので、読み込んだ譜面テキストをもとにウィンドウ上にノーツを描画するプログラム(200行ちょい)まで1~2日程度でたどり着くことができました。C言語で作るのやめて良かったね!

2012/10/20当時の試作バージョンはこんな感じでした(使用されていた譜面データは描画テストのための適当なもの)。

画像読み込み部分は下記のような感じです。画像を読み込むためのHSP標準命令であるpicload命令を使っています。

それでは、当時(HSP3.3)のpicload命令のマニュアルを見てみましょう。

PNG形式は・・・

PNG形式は・・・!?

PNG形式は・・・

ありませんでした!!!

という訳で、当時のHSPにはPNG形式の画像を読み込む機能がそもそも備わっていなかった訳です1Artlet2DというHSP付属ライブラリを使用すればHSP3.3の当時の時点でもPNG形式を扱うことができましたが、何となく重そうなイメージだった(※実際はどっこいどっこい)ので使用していませんでした。この2ヶ月後に選曲画面を作る際は半透明が使用したくなったので、Artlet2DでPNG形式の画像を読み込んでいます。あと今更知りましたが、他にも外部の拡張プラグインを使用してPNGファイルを扱う方法など、色々やりようはあったみたいですね→参考

そこで、当時取ることができる選択肢としては

  • BMP形式(非圧縮)
  • GIF形式(圧縮。256色のみ使用可)
  • JPEG形式(圧縮)

の3択でした。当時検討した感じでは、下記のような所感でした。

  • 「BMP形式だと非圧縮なのでキレイに出せそう。でもファイルサイズがやたら大きくなる…。1024x768の画像で2.25MBも食ってしまうので、この調子だとテクスチャ全部で100~200MBは行きそうだし、BMP形式はやめておこう…」
  • 「GIF形式は256色に減色しないといけないのでかなり微妙…。でもまあ、Photoshop上で誤差拡散法とかで減色すればある程度誤魔化せるし、ノーツのグラフィックとかであれば何とかなりそう?」
  • 「JPEG形式はどちらかというと写真向けだし、ぼやける・にじむので論外。でも背景グラフィックだけに関しては写真とかと同じような部類のものだし、この中だとJPEGを使うのが妥当そう?」

このような経緯で、ノーツ等の画像ファイルには泣く泣くGIF形式を、背景グラフィックにはJPEG形式を採用するに至った訳です。

いや、実はね…

ここまでがGIF形式を採用するに至った経緯なのですが、実はもう少し不幸な事実もありました。

HSPの更新履歴を見てみます。

まさか・・・

ちょうど開発着手当時の最新バージョンであるHSP 3.31(2012/9/5正式リリース)で、picload命令がPNG形式の読み込みをサポートしたのでした。

当時HSPを最新版にアップデートさえしていれば、この歴史的経緯を生まずに済んだのかも知れません…2picload命令のマニュアルは3.31時点ですぐ更新されていなかったので、実際は3.31にアップデートしていても気づかなかった可能性も高そうです。さらに、気づいた後もPNG形式を読み込んだ場合は「gmode 7」用にアルファチャンネルが右側についてくると誤解していた節があり、座標まわりが面倒になりそうなイメージを勝手に持っていたので、PNG対応にすぐ気づいた場合でも使っていなかった可能性は割と高そうです。

"スキン"の台頭

こちらは当初想定していなかったのですが、imgsフォルダ内の画像ファイルを差し替えるために非公式画像差分データ(俗に"スキン"と呼ばれているもの)を配布して、ゲーム画面の見た目をユーザー側で好きなものに変えるという流れが後付けで生まれていきました。

もちろん"スキン"はこちらで想定したものではなく、単にimgsフォルダ内の画像ファイルを上書きしているだけなので、ファイル名やファイル形式、画像サイズなどを元のものと同じに揃えて作成する必要が出てきます3"スキン"を作成する場合はインデックスカラー(256色)に対応した画像編集ソフトを使用してGIF画像を作成する作業を強いられます。非対応のソフト(例えばWindows付属のペイント)は256色のパレットをどの色に割り当てるかを自由に決定できないので、上書き保存するとひどい色になってしまいます。。そのため、GIF形式で作成された"スキン"が数多く出回ることになりました。

v1.40(2014/11/12)でプレイ画面を一新した際に、そのタイミングでGIF形式のテクスチャを廃止してPNG形式に変更できないか検討していました。
しかし、当時の時点でGIF画像を使用した"スキン"が数多く出回っており、これが使用できなくなると影響が大きいとみられたので、変更を見送ることにしました。
その後そのままの状態が現状という訳です。

結論

まとめると、こんな感じです。

  • 当時のHSPが読み込める画像形式はBMP/GIF/JPEGのみであり、GIF形式が妥当だったので仕方なく選ばれた
  • 配布されている"スキン"との互換性の観点でPNG形式への変更は見送ることになった

この投稿をシェアする