AppMethodに挑戦(3)

ということで、Androidアプリのサンプル構築までは、
かなり覚悟をしていたのですが、、、



なんだなんだ！いきなりできてるやん！！！
これはちょっと感動だわ。。。
まぁ細かい動作はさておき、とりあえずHelloWorldはクリアかも。。
いやぁー、ここまで簡単だと、、いよいよいきなりなんか作らなければ。。。。
って感じです。
手始めに、、Localストレージのアクセスかな。。。
まだ仕組みすらよくわかってないので。(o^^o)

AppMethodに挑戦(2)

AppMethodに挑戦です。。
まず、、Installですが、、
結果的には、驚くほど簡単に終了、、、
なのですが、とにかくInstallするものが膨大のようです。
ProgramFiles以下は250Mちょいですが、、
Installはなにやら30分くらいやってた感じです。
そして、、最初は、、Windowsアプリもできるということなので、
ちょこちょこやって実行！
そして、コンパイル中のこの画面！

いやぁ～～～～なんとも懐かしいこと、この上なし！
しかも、、プロジェクトの、
Project1.cpp
Unit1.cpp
Unit1.h
Unit1.fmx
。。。。。。。。。。。。。。。。。まんまやん！！！

これはテンションあがります。
これから、TOOL類は、、C++CLRなんかやめて、こっちで作るかもですわーー。
まだまだスマフォの開発のサンプルを動かすまでは時間がかかるでしょうが、
とりあえずは、、うん。なんか、いけそう感満載です。

ってことは再び、、小躍りです～～～～(o^^o)

AppMethodに挑戦（１）

AppMethodなるものに挑戦です。
思えば、C++Builder1.0（1997年）の時代から、BCB6までは使い続けた、
たいへんなBorlanderな私であります。(o^^o)
停滞していた時期もありますが、クロスプラットホーム路線もきわまり、
ついに今年、Android開発までも含むものとなりました。
もともとJAVAなんてやりたくない私なので、BCB6以来、久々のC++のRADです。
さぁ、どこまでできるんでしょう。
そしてライセンス形態として、Androidのみならば無償という、AppMethodを試そうと思います。
この手のものは、HelloWorld！までが一苦労だと思うので、
そこまでの備忘録的な意味合いも含めて記述したいと思いますです。
気分はこんな感じです。(o^^o)！

ダイソーな件。

土日になると、よく、ダイソーに行きます。
毎週、何をそんなに買うものが？というと、

とりあえず、用がなくても行ったりするわけです。

それで、おもちゃになりそうなものを買ったりするわけです。

今日、まず発見したのは、ハカリ。
『およその重さ計量器』
なめてます。。。(-_-;)

でも秤量を見ると、1kg。
そーいえば、2,30グラムをだいたいはかるのに、先週、苦労しました。
そう、プロテインとかなんですが。
ということで、ひとめもりが20グラムだと使い物になりませんから、どうしようかと思いましたが、
スケルトンで構造が見えたので、改造することにしました。
で、分解してみます。







そう、バネが強すぎるので、よわよわなバネに取り替えます。
で、なんとなくパーツBOXからそれらしいのをチョイスして、交換してみます。


バネを付け替えた図です。となりに、付け替える前のバネを置いてみました。


そしたら、かりの盤面（紙）をつけて、50グラム、100グラムの印をつけます。
50,100グラムは１円玉でやりました。


あとは、イラレで盤面を書いて、プリンとして、貼り付けて、完成です。




完成！(o^^o)


以上、そんだけです。

jajavascriptを再学習の7【配列メソッドを騙して使う件】

まぁ、サンプルと結果を先にだして見ましょう。

---

結果

---

いやいや、なかなかどうしてこういう結果なのです。
本によると、『配列メソッドを騙して使う』となってるのですが、
そんなに騙してるとも思えません。
Array.pushをArray.push.callとして呼び出し、
thisをObjectを指定しているというだけなので、
javascriptのArrayは、ArrayじゃなくてObjectでもOKという仕様
と言ってしまえばそれまでな気もします。。

本を読んだだけのときは、
lengthプロパティを追加してやらないと、
Array.push.callが失敗するのかと思いましたが、
設定しなくてもちゃんと動作します。（IE/CRM/FFX/OPR）

だから気分的には、こんな感じ(O^^O)


もっとわかりやすいサンプルとしては、こんな感じかな。。
配列にArray.pushした場合と、ObjectにArray.pushした場合。

 var abc = ["背負い投げ"];
 Array.prototype.push.call(abc,"出足払い");
 Array.prototype.push.call(abc,"横三角絞め");
 var def = {"得意技":"背負い投げ"};
 Array.prototype.push.call(def,"出足払い");
 Array.prototype.push.call(def,"横三角絞め");
 assertprop(abc,"abc");
 assert(true,"abc[0] = " + abc[0]);
 assert(true,"abc[1] = " + abc[1]);
 assert(true,"abc[2] = " + abc[2]);
 assertprop(def,"def");
 assert(true,"def[0] = " + def[0]);
 assert(true,"def[1] = " + def[1]);
 assert(true,"def[2] = " + def[2]);

画像を縮小する（平均化）する件。

アルファチャンネルにアルファチャンネルを重ねる件とも似通った話ですが、画像を縮小化する場合の処理を考えてみます。
簡単に考えるために、２ピクセルを１ピクセルにすることを考えます。
もちろん、□と■を平均化すれば、中間のグレイになるだろうことはだれでも予想がつきます。
では、R1G1B1A1とR2G2B2A2を平均するにはどうすればよいか。

正しい方法ではないですが、特殊解から一般解を導くとたいてい合っている！
という方法があります。
そうすると、
0ｘ00FFFFFF　と　0ｘFFFFFFFF　を混合すれば、、
0ｘ80FFFFFF　と　なりそうなことは容易に想像できます。
※または、0ｘ7FFFFFFF
ということは、、アルファの値は単純に平均をとるだけでいいような気がするので、
いいということにしましょう。

問題は、RGB部分のFFFFFFというところです。
これだけみると間違った方法をとってしまいそうなので、
別の特殊解を考えて見ます。そう、
0ｘ00FF0000　と　0ｘFFFFFFFF　を混合しても、、
0ｘ80FFFFFF　と、同じ結果となります。
当然と言えば当然で、アルファが０であれば、RGBが何であっても
表示上は何も無いので同じわけです。

さぁ、ここで、これらを黒地に置いた場合を考えると、
0ｘ00FF0000　→　0ｘFF000000
0ｘFFFFFFFF　→　0ｘFFFFFFFF

そうすると、前回と同じように、V1、α１、V2、α２とすると、
V1=100、α１=0
V2=100、α２=1.0
結果→α３=0.5、V3=100
とすると、どうやら、（V1α１+V2α２）/2　が、黒地に置いたときの実際の値と思われるので、
V3＝（（V1α１+V2α２）/2）/α３
　　＝（（0*100）/2）/0.5＝50/0.5＝100　という感じと予測できます。
V1＝100、α1＝0.5とすれば、
V3＝（150/2）/0.75＝75/0.75＝100　となり、V３=100、α３＝0.75となるので、
これでもあってるっぽいですね。

で、結論としては、
●αは単純に平均化するのみ
●RGBはそれぞれの要素に関して、αをかけたR´G´B´を足し合わせて平均化し、
平均化されたαで割り返す
となります。

アルファチャンネルにアルファチャンネルにを重ねる件（3）

で、前回、こんなことを書いたわけです。

--------------------------------------------------

●元ピクセル

値V1、α：alp1

●のせる方のピクセル

値V2、α：alp2

としたとき合成したピクセルの値（B）は、

A = (0xff * (1-alp1) + V1 * alp1) * (1-alp2) + V2 * alp2

alp3 = alp2 + alp1*(1-alp2)

B = (A - 0xff*(1-alp3))/alp3

--------------------------------------------------

しかし、ハタと気づくわけです。

または感じるわけです。

何かが美しくないと。(o^^o)

そうです。白（0xff）の上に画像を置いた揚句、

あとからその部分を取り除くような考え方をしているわけです。

じゃぁ、黒の上に置いたらどうなるか。

そうすると、0ｘFFの部分が０になるわけなので、

A = (V1 * alp1) * (1-alp2) + V2 * alp2

= V1 * alp1 + V2 * alp2　- V1 * alp1 * alp2(式1)

alp3 = alp1 + alp2 - alp1*alp2(式2)

B = A /alp3

と、こうなるわけですね。
式がそれっぽくなりました。

で、検算してみると、うん。正しいようです。


ここで、式を見てみます。
式2を見ると、最終的なアルファの値は重ねる順序に関係な無いことがわかります。
式1を見ると、最終的なピクセルの値は、順序と関係する事がわかります。
そりゃあそうです。
白100%の上に赤100%を乗せれば赤になるし、逆なら白になるに決まってますよね。

アルファチャンネルにアルファチャンネルにを重ねる件（２）

で、色が違うときの話です。
まず、サンプル。

では、重なり部分のR成分の計算。
0xff * 0.5 + 0xff * 0.5 = 0xff
0x80*0.3 + 0xff * 0.7 = 0xD9
では、重なり部分は、
(0xff * 0.5 + 0xff * 0.5) * (1-0.3) + 0x80 * 0.3=0xD9
うんうん。ここまではあってますね。

では、前回と同じように合成後のアルファを考えると、
0.3　+　0.5　*　（1-0.3）→0.65となる。
0.5　+　0.3　*　（1-0.5）→0.65.もちろん同じ。

0xff * 0.35 + A * 0.65 = 0xD9
よって、
0ｘD9-0ｘｆｆ*（1-0.65）→0ｘC5
これをRGB要素全てに適用すればできる。。ハズ。

また重なってない部分を考えると、
0.3　+　0　*　（1-0.3）　→0.3
0ｘｆｆ*0.7　+　A　*　0.3　＝　0ｘD9
A＝0xff、アルファ：0.3
うん。できてるな。(o^^o)

ということで、
●元ピクセル
値V1、α：alp1
●のせる方のピクセル
値V2、α：alp2

としたとき合成したピクセルの値（B）は、

A = (0xff * (1-alp1) + V1 * alp1) * (1-alp2) + V2 * alp2
alp3 = alp2 + alp1*(1-alp2)
B = (A - 0xff*(1-alp3))/alp3

となります。
地道に展開したらもしかして簡単になるのでしょうか。。。
やってみますわー。

っといましたが、かここであることに気付くわけです。
で、それは次回で(o^^o)

アルファチャンネルにアルファチャンネルを重ねる件。

アルファチャンネル付き画像に、
アルファチャンネル付き画像を乗せたときの結果が、

思わしくない状況に遭遇することがあります。

では、何が正しいのかをちゃんと考えてみます。
PHP画像合成のバグもこの範疇に入ると思われます。
ということで、計算しやすくするため、以下の画像を考えます。
これは、イラレで矩形を透過属性付きで作成したもので、
黒白はα=1、
右の赤の矩形はα=80%
左と中央の赤の矩形はα=40%

としました。

そして画面キャプチャをとって、ピクセルの値を調べた値を＃テキスト表示しています。


■白の上に赤40％→#FF9999。
R要素→　FF*60%+FF*40%　→　0xff
GB要素→　FF*60%+00*40%　→　153　→　0x99
よって、FF9999

■黒の上に赤40％→#660000。
R要素→　00*60%+FF*40%　→　0x66
GB要素→　00*60%+00*40%　→　0x00
よって、660000

■白の上に赤40％、さらに赤40％→#FF5C5C
さてここの考え方が、全てのポイントである。
GB要素→　FF*A%+00*40%　→　92　→　0x5C
よって、Aは36%である。
ということは、明らかに、60％*60%である。

ようするに、アルファ：40%の画像の上に、アルファ30%の画像を載せたときの
アルファは、
30%　+　40%　*　（100-30）%　→　30+28　→　58%　となる。
逆にすると、
40%　+　30%　*　（100-40）%　→　40+18　→　58%　となり、やっぱり同じである。

シンプルな話なんですけどね。。。。。。(o^^o)
ただし、サンプルは同じ色のアルファだけ変えたサンプルなので、
色が違うときは、、、次回で。（－＿－；）

jajavascriptを再学習の6【無名関数】と再帰

ということで、無名関数いきましょう。

 window.onload = function(){
  assert(true,"onload!!!");
 };

 var ninja = {
  seoi:function seoinage(){ assert(true,"ninja 背負い投げ!"); },
  ohsoto:function (){ assert(true,"ninja 大外刈り!"); }
 };
 ninja.出足払い = function(){ assert(true,"ninja 出足払い!");  };
 ninja.出足払い();
 ninja.seoi();
 ninja.ohsoto();
 assert(true,ninja.seoi.name);
 assert(true,ninja.ohsoto.name);
 assert(true,"------------END------------");

まぁこんな感じなわけですが。。

６行目７行目はそれぞれninjaObjectのプロパティとして関数を設定していますが、
前者は名前付き、後者は無名関数です。
それは、nameプロパティを表示させた結果(4)(5)を見ればわかるとおりです。

ただし、この【seoinage】という名前の関数、nameプロパティとして参照する外の用途
があるのかといわれれば、、ほとんどない。
なぜなら、関数の中からしか、この名前は参照できないからだ。
よって、再帰的に使う時には、その用途がある程度の話である。
（－＿－；）

あと、現実的に使うかどうか別にして、
９、10行目と(1)の表示を見ればわかるとおり、日本語もOKっすね。

---

ということで、無名関数のサンプルで、こんなノリのやつが本にはかかれていたわけですが、

 var ninja = {
  chop:function (n){
   return (n>1)? ninja.chop(n-1) + "-chop" : "chop";
  }
 };
 assert(true,ninja.chop(4));

しかし、、まぁよくないサンプルとしてはいいのですが、、
プログラム的には、あまりに美しくないわけです。
せっかく【ninja】というobjectを定義（生成？）しておきながら、
そのプロパティとしての関数の中で、また【ninja】を参照するという。。。
本では、色々な使い方の中でよくない理由を述べてるのはいいのですが、、
いや、これ、それ以前の問題！くらいの認識を持たないとダメだよね。。
で、結論としてはもちろん、

 var ninja = {
  chop:function chopper(n){
   return (n>1)? chopper(n-1) + "-chopper" : "chopper";
  }
 };
 assert(true,ninja.chop(4));

そう、こういう風に関数に名前をつけましょうという話でした。
もちろん、arguments.calleeという話題も無いわけじゃないが、それはそれで。(o^^o)

PHPの画像合成のバグ

PHPで画像の合成なのですが、、 もちろん、
imagesavealphaと
imageAlphaBlendingを設定して、
imagecopyしたものを、
imagepng したわけですが、
こんな結果です。
●１

●２

●３


全て、中央の画像に右の画像を合成したものが左の画像なので、
本来は全て同じハズです。
違いは、中央の画像のα＝0のピクセルのRGBの値が３つとも違い、
上から、0ｘ000000(黒)　0ｘｆｆ0000（赤）　0ｘｆｆｆｆｆｆ（白）です。
要するにBLENDするときに、α＝0の部分ももってきてしまって、
BLENDした挙句、αの値の平均でもとっているのでしょうかね。
どっちにしても、ダメっすねー。
まぁきちんと解明してみますです。(o^^o)
とりあえず、こういうバグがあるということでした。

---

追記
本来はこうあるべきというの作成。

上段がイラレで作成、
下段が自前のプログラムで作成。
残念ながら、僅かな誤差がありましたが（3Fと40とか^^;）、
基本的にはあっています。