さてさて。ウィンドゥの可変化。どうしたらええじゃろ？

おっとその前に。
サイズが変化した場合の挙動って、Windowsとか見てると何種類かが
あるのがわかるね。

1. サイズが変化した時、クライアント領域が拡大縮小されるもの。メディアプレイヤーの画面とかがそう
   
2. 内容そのものにまったく変化がない。単に見えてるか隠れてるかというだけ。スクロールバーが出現。メモ帳とかがこの部類かな？
   
3. 上と似ているが左右だけとか上下だけとかが新しいサイズに合わせて変化。うーん。うまくいえないなぁ。コンソールとかPuttyとかがこの部類かな
   

うーーーん・・・どれから手を付けようかな。
とりあえず3番辺りをやってみるか・・・テキストビューアーの
改造という形でどうだろう。

・・・あれ〜？

「在来のインベーダの移植は無理！」
と切って捨てて新しいのを作ってたんだけど・・・・

なんか数箇所弄ったら動いてしまいましたとさ！　(^^;
（ラッキー！　実はちょっとインベーダ作りに飽きてたので）

そんなわけで新インベーダの開発は一旦凍結〜。

・・・つーことで、とりあえずははりぼて付属のアプリは
一通り新APIで動くってところかな。
（実はまだスクロールAPIがハンパなんだけど・・・）

横道はこれくらいにして、ウィンドゥ可変に戻らねば・・・

えっと。開発日記じゃないんですがね。

このサイトではBWikiというPukiWiki派生のモジュールを使っているんですが
ちょっと実験的に新しいのを使ってみようかなぁと。

簡単に複数設置が出来そうなのがミソでしょうかねぇ。
ゴッチャゴチャに溜まりまくってしまったページ達をいくつかに
分離できそうな感じなので。（まだわかりませんが）


・・・・う〜む・・・・・・
ちょっとこの新しいモジュール、まだまだ問題が多いなぁ。
そんなわけで一時撤退・・・・（実験は続けるけどね）

まいったなぁ〜。引数が多すぎ・・・・
そこでこうしてみました。

api_blockmove(int win,short x0,short y0,short xw,short yh,short xx0,short yy0,int blankcolor);



アセンブラで渡される値

   EAX        win

   EBX        x0 & y0

   ECX        xw & yh

   EBP        xx0 & yy0

   ESI        blankcolor

shortは0xFFFFまで。つまり65535まで。ウィンドゥの座標でこんな値はまあ、
将来は当たり前になるかもしれないけどね。少なくとも今＆BBLでは
10年はいらないだろうから・・・(^^;

さーて・・・これ、実装ではどーすりゃいいんだろう。これでいいのかなぁ・・・

 		PUSHFD		

		PUSH		ESI

		PUSH		EDI

		PUSH		EBP

		PUSH		EBX





		MOV		EDX,123

		MOV		EAX,[ESP + 24]		; win





		MOV		EBX,[ESP + 28]		; x0

		MOV		EDI,[ESP + 32]		; y0

		SHL		EBX,16

		AND		EDI,0x0000FFFF

		ADD		EBX,EDI			; x0 & y0



		MOV		ECX,[ESP + 36]		; xw

		MOV		EDI,[ESP + 40]		; yh

		SHL		ECX,16

		AND		EDI,0x0000FFFF

		ADD		ECX,EDI			; xw & yh



		MOV		EBP,[ESP + 44]		; xx0

		MOV		EDI,[ESP + 48]		; yy0

		SHL		EBP,16

		AND		EDI,0x0000FFFF

		ADD		EBP,EDI			; xx0 & yy0



		MOV		ESI,[ESP + 52]		; blankcolor



		INT		0x40





		POP		EBX

		POP		EBP

		POP		EDI

		POP		ESI

		POPFD

よおぉぉっしゃぁ！！！！！
これでどーーだぁ！！！！

（EFLAGSを退避させてるのはシフト命令で影響が出るそうなので念のため・・・）

いくつかのAPIを実装してて考えたこと・・・・・

たとえばblockmove。ある領域をドンと別の場所に移動させるAPI
なんだけど、じゃ、移動した後はどーするか？？

単純にあるパラメータを置いてその指定色で塗りつぶす・・・
まぁこれでもいいっちゃぁいいんだけど・・・

例えばだけど、シートのクライアント領域に「標準色」を
設けるってのはどーだろ？

・・・うーん。でもおんなじことかなぁ・・・


おぉ！いいこと思いついた！

「塗りつぶし」の引数を設ける。それによって空いてしまった
空間は塗りつぶすことができる。

で！

これを-1とかに指定すると、コピー元になにもしない。
つまり、blockcopyが成り立つじゃないか！！！　（＾＾


・・・げえぇぇぇぇぇ！！！
大問題発生！　レジスタが足りない!!!!
今ってこういう状態。

api_blockmove(int win,int x0,int y0,int xw,int yh,int xx0,int yy0,int blankcolor);

引数がええと・・・8つ・・・
EAX,ECX,EBX,ESI,EDI,EBP・・・足りねぇ〜！！！！！

久々に復習コーナー。

えっと・・・キーボードからの入力。

1. キーボードが押されるとキーボード内にある回路が働き、割り込みが発生する(P130近辺？）
   
2. 同時にI/Oポート0x0060にキーコードが送られてくるのでこれを受け取り、割り込み再開を通知しておく(P137）
   
3. 受け取ったキーコードはメインFIFOに256を加算されて送られる(P256）
   
4. 加算された値はメインループ内で分岐した後、改めて256を引き算して元の値に戻され、キーコードが渡る(p260）
   
5. キーコードは渡されたメインループで文字コードに変換されて渡される（P345）
   
6. APIにより、渡されたキーコード（もはや文字コード）を取得する（P486）
   
   まあざっとこんな流れだよね？
   
   ・・・って、ちょっとまって・・・・
   これだと生キーコード？を取得できないんじゃないの？？？
   全てあらかじめ文字コードに変換されてるし、そもそも、「離した時」の情報が受け取れないんじゃないの！？？？？
   
   
   
   
   

さて。BBLははりぼてから大きく仕様変更してしまったAPI郡がある。
ウィンドゥ関係だ。
以下が元々あったものを仕様変更したもの。

• api_openwin
  
• api_putstrwin
  
• api_boxfilwin
  
• api_point
  
• api_refreshwin
  
• api_linewin
  
• api_closewin
  

で、仕様変更によって直接ウィンドゥに書き込むことができなくなったのでブロック単位でメモリを転送するapiを1個追加してある。

• api_blocksend
  

で！　インベーダーをゴニョゴニョ作っている最中に、さらにこんなapiがほしくなったのであります。

api_blockget

blocksendの逆。ウィンドゥのある領域を変数に取り込む

api_pointget

blockgetのドット単位版

api_blockmove

アプリ側に変数を用意せず、直接ウィンドゥ内である領域を別の位置に移動させる。

api_scrollwin

blockmoveでも出来るが出来るだけコードを短くしてすこしでも反応をよくしたいので専用に設置

api_slidewin

横方向のスクロール。同上


・・・もしかしたら助長かもしれませんが、まあとりあえずはこのあたりがあると便利かな〜なんて・・・(^^

「横道もいいとこ」とはじめた新インベーダーですが、プログラムそのものが
楽しいのとは別に、大改造した描画APIのボロをどんどん叩き出してくれます。
また、「こんなAPIがあったらもっと便利なのに・・・」なんてのも。

新インベーダーが完成することには、各APIももうすこしまともになってるかな？？

はうあ〜・・・

やっとこさ方向がまとまってきた・・・
各APIもほぼ出来上がってきて、アプリ郡の改造も進んでるけど・・・

インベーダーの改良はムリ！！！

でもそれじゃくやしいので作り直しております　＜横道もいいとこ！

なんとか管理の分離はできたしマウス直下のシートを設置することもできた・・・。さて問題は、アプリが作ったウィンドゥ。
シート・・・
シート内にはバッファがある。vramに直接データを書くのではなく、
まずこのバッファと名づけられたメモリに描画する。
で、それらを元に実際にvramにデータを書くのはシステムの仕事。
アプリが作ったシートにも当然バッファがあるんだけど、この場合、そのアプリの権限でのメモリ。まあこれはいい。

問題はそのシートがウインドゥだった場合、タイトルバーやらだけはOSが管理しなくちゃいけないんじゃないかと思うわけ。

（たとえば今だと、シートのバッファ全てがアプリに管理されている。っということは、アプリ側からタイトルバーを壊したりができるわけ。これがどうしても出来ない。そういうふうにすべきではないかと・・・）

すぐに思いつくのが、ひとつのウィンドゥでシートを二枚使うこと。二枚をピッタリ重ねて一枚のようにする。で、後ろ側をシステムが管理してタイトルバーやらを書き込む。アプリが確保したバッファはウィンドゥのクライアント領域だけ！

・・・しかし、どうなんだろう。かなり描画が遅くなりそうな悪寒・・・

・・・まてよおぉぉ？？
例えばだけど、これまでのシート。仮に100x100ドットだとするよね？
そーすると、どっち道、10000回メモリを書き換えないといけない。
シートを丸々2枚だと20000回の書き換えだから倍になっちゃうけど、
クライアント領域の座標の時だけは読み込む元を切り替えればすこしif判断が入るだけなのでそんなに遅くならない・・・ってふうにできないかな・・・

ちといろいろやりそうなので、例によってここいらへんにて妄想開始。