2016年09月17日

実験的にexeファイルに48x48アイコン・256x256アイコンを追加してみたり

巨大サイズのアイコンは、exeフィルのサイズを無駄にでかくするのでバカバカしいけど、アイコンがボヤけて表示されるのも嫌だという話を、先日書いたわけなのですが、その後色々調べてみたところ、アイコンファイルは条件次第で圧縮可能であることが分かりました。

拡張子icoのファイルは、複数のサイズ・複数の色数の画像を格納することができるのですが、その際、ベタで非圧縮な画像にするか、PNG圧縮の画像にするかが選べるフォーマットになっているとのこと。

ただし、exeファイルを閲覧する環境(OS)によっては、非圧縮な画像しか読めない場合があります。
例えば、Windows 95/98は非圧縮なアイコン画像しか読めません。
Windows Vista以降になるとPNG圧縮のアイコン画像を読めるようになるとか。

色々総合すると、

  • 16x16 BMP
  • 32x32 BMP
  • 48x48 BMP
  • 256x256 PNG

という揃え方をすると良さそうな感じです。

で、問題は、上記のようなファイル構成を実現するための方法。

残念ながら、Visual Studioでは、少なくとも2010では、画像形式をPNGに切り替える方法はなさそう。通常のアイコンは形式名をBMPと認識している、というか表示しているくらいだから、PNGもできそうなもんだけど。表示だけに対応なんだろうか。

vs2010iconedit.png

いろいろ調べてみたら、フリーソフトのアイコン編集ツール「@icon変換」を使えばできるみたい。こんなところでサードパーティのソフトを使うのが必須とはなぁ。

vs2010iconedit3.png

結果から言えばできました。たかが4KB増程度で、48x48と256x256のアイコンを追加できました。

vs2010iconedit2.png

まぁ、効率よく通過色部分を処理するために、昔ゲーム作りの時に使っていた自作の「左上のピクセル色をアルファ値0にする」ツールを行使することになったんですけどね。PNGで通過色処理をうまくやるには、それなりのツールを持っていないと駄目そうですね。Photoshopとか。


続きを読む
posted by ayacy at 04:20 | Comment(0) | TrackBack(0) | プログラミング

2016年09月13日

アイコンがデカいのバカバカしいと思っていたモノの…。

8bitカラーの256x256アイコン(icoファイル)は、200KB近いサイズになります。
150KBのexeファイルのアイコンとして、そんなアイコンを付加すると、併せて350KB。

コンパイラが頑張ってスマート化したexeファイルに、そのサイズを上回るアイコンをくっつける行為。
これはバカバカしいと考えていました。

言うなれば、大きさや厚さや重さを極限まで削ったスマートフォンに、その何倍もの重さのストラップをくっつけるような感じ。
非常にばかばかしい。

実は作者の環境は、デスクトップのアイコンサイズが32x32に統一されておりまして、アイコンのサイズが小さいせいで「不快感を感じる」ということがありませんでした。そのため、当サイトで公開されているソフトも、最大でも32x32のアイコンが搭載されているものが限度だったはず。

ただ先日、アイコンサイズが48x48に統一された環境に放り込まれたとき、初めて不快感を感じました。
32x32のアイコンが不都合に拡大されて、中途半端に色補完されて表示されて感じる違和感。そこから来る不快感。

256x256のアイコンを搭載しようとは思わないけど、48x48くらいまでなら搭載しても、バチは当たらないんじゃないかな、と思い始めています。
(大きいサイズのアイコンを描こうにも、僕には絵心がないので、描こうとしても、ピクセル数の多さから途中で断念してしまう可能性もありまして)



posted by ayacy at 22:37 | Comment(0) | TrackBack(0) | プログラミング

2016年08月12日

要望をいただく場合について - 仕様は矛盾のないよう。でもその前に重要な前提が。

なんだか、最近の「顧客vsエンジニア」の構図みたいなのですが、フリーソフトへ要望を出す場合も、結局は同じ事かと思っています。

仕様は明確に。
矛盾の無いように。
言葉はコンセンサスの取れている使い方で。

最近、これで困ってしまう経験がありましたので。

まぁ、これは私に機能追加要望を出す場合に限った話ではなく、他のフリーソフトの作者さんに対して要望を出そうとしているとか、仕事でシステム開発を発注しようとしている場合とかにも同じ事が言えるかと思います。

顧客のキーパーソンが何人かいて、キーパーソン毎に要望が矛盾している、なんて話も、しばしば聞きますからね。
フリーソフトで要望を受け取るときも、要望を出す人は1人ですが、メールをやりとりしていくごとに対象が変わっていく、なんてことがありました。まさに、仕事で受注するシステム開発の経験の縮図です。

要望者は1人なので、せめて意見をまとめてから、要望を出されるのが良いでしょうね。

まぁ多少、言葉が分かりにくいとか、矛盾が入っているというのは、人間のやりとりですので、仕方の無い部分はあると思います。
ただ、システム開発は、仕様が曖昧なままでは作れません。作り始められません。作り終われません。

曖昧な仕様が提示されたままの状態で「これでやるかやらないか結論を出してくれ」と言われても、何をやるんだか明確でないのに結論が出せるわけがない

曖昧な仕様は、詰めていくことで明確化していくことができます。
仕様は一回で伝わるのが理想的ではありますが、一回で正しく伝わるとは限りません。人間同士のやりとりですから伝わらないことも多いかと思います。3回や4回のメールのやりとりで仕様が伝わらないこともあるでしょう。

私が過去にゲーム作りをしていた頃は、開発規模が大きかったですから、メールやチャットや、電話や対面で何度も打合せを実施して仕様を詰めていきます。仕様を詰めるだけで何週間もかかります。

開発規模が小さく、依頼者が一行くらいで済むだろうと思い込んでいるような要望であっても、何日かかかってしまうこともあるでしょう。

冒頭で「言葉はコンセンサスの取れている使い方で」ということを書きましたが、初対面の相手に対してコンセンサスが取れているかどうか、そもそも分からない事の方が多いです。

私がフリーソフトのサポートや要望受付をしていて困るのは、「話し相手とのボキャブラリーの統一ができているか」「話し相手のリテラシーレベルがどれくらいか」がわからないときです。

仕様を詰める前に、まずはボキャブラリーの統一を図り、リテラシーレベルを測る必要がある場合もあります。
仕様を詰めていて、どうしても会話が上手く行かない場合は、そこらへんからスタートするので、より多くの時間が必要になることがあります。

でも結局、フリーソフトへの要望を含む、仕様決めって、そんな感じなんだろうと思います。

だから、要望を出す場合というのは、その前提の取り組みも非常に重要になってくることかと思います。


posted by ayacy at 00:00 | Comment(0) | TrackBack(0) | プログラミング