はい、どーも!!

広告消しに記事投入。

はやいよ、一ヶ月・・・

まだまだ改装は続きます。

HTML+CSSをちょっぴり理解したので、一気にやれることが広がりましたよ！
理解は幸せ。

フラットデザインというのが流行りですが、
適当にフラットにしたところでとてもダサくなるだけなのでとても難しいです。

うっすらグラデーション、
うっすら縁取り、くっきりボタン、
ちょこーっと角丸を使う。

うーむ、まだこのサイトださいぞ。。。

現在ブログを改装中です。

デザインセンス皆無なため無難なところに着地する予定。
コード載せるためのあれやこれや、javascriptやらいろいろ仕込んでみようと画策中。

お久しぶりです。
化石ブログですがちょっと復活してみるテスト。


もうそろそろ前記事から1年です。。
あのころは社会人1年目、今ではもうそろ3年目に入るところです。
早いものですね。このブログは確か高校生くらいの時に作ったものでです。
2005年開設とのことなのです、あと1年くらいでなんとまぁ10周年になってしまいます。

10年前というとプログラミングやったことなかったかと思います。
今ではすっかりお仕事になってしまっているあたり、人間成長するもんですね。
ちょっと10年を振り返ってみましょう。


初めて触ったプログラミング言語はJavaでした。
JavaはJavaでもiアプリです。Javaとしての機能は大きく制限されていましたが、だれでも持ってる携帯電話で動き、なおかつネットワークを通して、他の人にダウンロードしてもらえることがたまらなく面白かったのが記憶にあります。
最初はネットで知り合った(?)方からEZアプリのコードをいただき、それをドコモ版に書き換えたところから始まりました。
確か「走れ、クワービィ」ってゲームだった気がします。
クワービィっていうあれこれ怒られそうなキャラを走らせて、ジャンプで穴を飛び越え続けるっていうお手軽横スクロールアクションでした。(当時はつんという名前ではなかったです。)

それこそ「if文て何よ。変数って何ができるん？」みたいなところからでした。
THE初心者。クラスっていうものを知るのはその3年後あたり。
かろうじてGraphicsオブジェクトというものに気づき、なんとか動くようになったのでした。
出会ったアプリも初心者でもわかるくらいの、今思えばちょうどよい教材でした。


そのあと作ったのはポケモンのパクリなiアプリだった気がします。
ポケモン金銀のバトルをアプリで再現しようというこれまたいろいろ怒られそうなものでした。
配列をやっと使える程度の腕前でしたが、クラスも使わずに、一応バトルっぽいことができるもので、一瞬だけ公開した記憶があります。
当時、「ポケモンのアプリがある。バトルだけできるものがある。」みたいな噂がネットで流れてましたが、犯人は私です。ごめんなさい。
中身はポンコツそのもの。自分の成長の遅さに目を見張るものがありました。
ただこの辺りで、常識に囚われない謎の解決能力を開拓していき、今でもそれはちょっとだけ役立っていると思います。
誰かに正攻法を教えてもらいたかった…定数も知らず、すべて配列番号で管理されてたっていう恐ろしいコードです。
これもまだこのブログを開く前だったんでしょうか。


そのあとついにこのブログが誕生し、しばらく3DCGを作った後、たしかMobileDJっていうものを作ったんだったかと思います。
今もびーもばっていう名前で残ってます。iアプリ初(?)のBMSプレイヤーってことで、それなりに人気がでました。
当時の私には相当無茶な試みでした。初期はBMSファイルは内部に埋め込んで使うことを考えていましたが、偽装GIFからの読み込みとか、SDカードの読み込みとか、なかなか先進的(?)な技術を投入したちょっと背伸びしたアプリになりました。
このときですらクラスを知らず、1クラスで実装されているのは今考えると恐ろしい。
iアプリ界ではクラスを使うとアプリサイズが大きくなり、動作も重くなるとか言われていて躊躇していましたが、今考えると使わないっていう選択肢はないです。
そんな中でBMSを読み取ってMIDIを作成したり、曲に同期させて譜面を動かしたり、複雑になっておもしろかったです。
このアプリは偽装GIFを読み込め、譜面を半無限に増やすことができたのが受けたのか、アングラサイト(死語)みたいな、背景が黒くて赤い文字がペカペカしているようなサイトにばかうけ。あちこちで譜面データの無断の２次配布が確認できてしまい、そのショックでアプリを公開停止にした記憶があります。
(最初の記事：http://tsunsan.blog28.fc2.com/category31-23.html)


その後継として、グラフィックを大幅に強化したびーもばを作りました。
偽装GIF読み込みは削除し、SDカード読み込み専用となりました。
高速な機種では60fpsを出せるようになり、ちらほら公式超えなんて声も聞こえてきて、とてもうれしかったです。
最終的にはニコニコ動画にプレイ動画にアップしていただいちゃいまして、びーもば絶頂期が過ぎました。
このときはかろうじてクラスが使えました。しかしなぜnewなんてことが必要なのか不明で、全部staticだった気がします。当時のDoJaには標準でListもなかったですし、時代とは恐ろしい。
このころ初めてfps制御というものを知り、いよいよゲーム入門って雰囲気でした。
フレーム単位での制御、アニメーション、アプリからの画像の加工、半透明などなど、それなりに今でも使える技術はこのころ学びみました。
やってることはしょぼいんですけど、もっと速く！もっと綺麗に！っていう考え方は今にも通じています。


いつかその２に続く・・・

ふと、「1ピクセルってRGBのセル３つセットで成り立ってるんだよなぁ。なら、ピクセルをまたいでもRGBが連続して光ってさえいればそれは白に見えるんじゃないだろか？」と、思い、MSペイントで簡単に検証してみた。

■基本的な情報
・今現在の一般的な表示機器は、それぞれ自在に色を変化させることができる粒[ピクセル]の集まりでできている。
・一般的にピクセルは正方形で格子状に並んでいる。
・１つのピクセルは赤(R)、緑(G)、B(B)の3つの長方形を組み合わせてものである。
・RGBセルはR、G、Bの順番でピクセル内部に横１列に並んでいる。
・RGBセルは隙間なくびっちりならんでいるわけでなく、大体仕組みの問題で極小さな隙間があいている。

(255,255,255)はRGBすべてのセルが全開に光ってるから白色に見えます。
ならば(0, 255, 255)=水色,(255, 0, 0)=赤っていう２つのピクセルを並べて見てはどうでしょうか。
この２色をくっつけて縦線を描くと、画像の意味的には水色の線と赤の線っていう２色２本の線ですが、
表示機器からすると、RGBの順番に点灯しているか、GBRの順番に点灯しているかの違いしかありません。
(ただし、後者のBとRの間には、構造上1ピクセル内のRGBセルの間隔より広い隙間があると思われます。)


それを実際に再現してみたら次の画像のようになります。




緑から上の縦線の構造は以下の通り。
左から

1. (255,255,255)のただの白線(幅1ピクセル)
2. (0, 255, 255)と(255, 0, 0)の２色の線(幅2ピクセル)
3. (0, 0, 255)と(255, 255, 0)の２色の線(幅2ピクセル)
4. (255, 0, 255)のただの紫線(幅1ピクセル)
5. (0, 0, 255)と(255, 0, 0)の青と赤の２色の線(幅2ピクセル)

緑線以下は幅2ピクセルの線のみ左右の順番を入れ替えたものになってます。
(画像は必ず100%状態で表示してください。)


表示機器によりけりなんですが、
1,2,3は大体白に見えるはずです。
ただし、2,3は1よりも使っているRGBセルの間隔が均一ではないために、白線の両サイドに元の色が見える、みたいな状況かもしれません。
構成を左右いれかえると、あら不思議、完全に２色に見えます。
(上が２色に見える場合はBGRの順に1ピクセルが構成されているんだろうなぁ。)

それどころか、２色の間に黒線が見えるかもしれません。
2番の場合、左右入れ替えるとB,G,Rの順で0が並び、少なくとも1ピクセル分程度の大きさの黒色ができます。


4と5はGを使わなかった場合です。
白のときに比べて、4,5はほとんど同じに色に見えるかもしれません。
5番の両サイドに赤と青が見えるなんてことは少ないはず。

これは4のただの紫線の時点で間にGセル分の隙間が開いているせいと考えられます。
5番は使っているBとRのセルの間にピクセルの境界があるので、その分離れています。
つまりどっちもRとBのセルの間に隙間があるわけで、これが大体同じの表示機器の場合、この２つは同じに色に見える、というわけですな。

5番の左右を入れ替えると白色の場合以上の黒色の隙間ができるため、決して紫線と同じもののようには見えないはずです。



これがわかったところで、で？って感じですが、、、この1/3ピクセルの単位を使ってなんかできるかもしれません。