久々に復習コーナー。

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

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判断が入るだけなのでそんなに遅くならない・・・ってふうにできないかな・・・

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

そーいえば、ウィンドゥの扱いがちょっと変化したのでapi_openwin関数をちょっと改良しないといけないなぁ・・・

えっと。現在は

• EDX = 5
  
• EBX = ウィンドゥのバッファ
  
• ESI = ウィンドゥのX方向の大きさ
  
• EDI = ウィンドゥのY方向の大きさ
  
• EAX = 透明色
  
• ECX = ウィンドゥの名前
  

・・・ふむ・・・こんな感じだよね？
う〜む・・・レジスタが足りない・・・
おっし。じゃ、EBPを属性として、ビットごとにっていうことにしよっか。（つーかそれしかないでしょこれじゃ）

• EDX = 5
  
• EBX = ウィンドゥのバッファ
  
• ESI = ウィンドゥのX方向の大きさ
  
• EDI = ウィンドゥのY方向の大きさ
  
• EAX = 透明色
  
• ECX = ウィンドゥの名前
  
• EBP = ウィンドゥの属性
  

• bit0: 0ならウィンドウじゃない。1ならウィンドゥ
  
• bit1: 0ならタイトルバーを持たない。
  
• bit2: 0ならフレームを持たない。
  
• bit3: 0ならフットバーを持たない。
  
• bit4: 0なら固定ウィンンドゥ。1なら可変
  
• bit5: 以下リザーブ（将来のために）
  

・・・こんなところかな・・・
おぉ！　リザーブだって！　なんかカコイイ！！　　←バカ

・・・あ"〜・・・そっかぁ。バッファの扱いかぁ・・・・
現在の状況だと、新しいmake_window関数はシステムとしてバッファのメモリを確保しちゃうんだ。
こりゃまずいよなぁ。アプリはあくまでもアプリ用のメモリ内でバッファを確保せんといかんわけで・・・
うーん・・・どーしよう・・・・

田んぼチャージャー・・・・　（ボソっ）

えっとぉ〜。ちょーっと問題が出てしまったでゴンス。

今のBBLはシートの重ね順がはりぼてと違う（つーか、追加されてる）
そのための除外処理が甘かったようだなぁ。

    sht_mouse    ←なにがどうなっても最上位にいないといけない

    sht_menu     ←なにがどうなってもこの位置に

    sht_tbar     ←       〃



    さまざまなシート



    sht_back    ←なにがどうなっても最下位にいないといけない

しかし、今の状態だと新しいアプリを起動したりした時（新しいシートというかウィンドゥが加わった時）この順列が狂ってしまう。
bballがsht_menuの上に来たりしてはいけないのでする！

えーっと・・・そうなると・・・

まず、はりぼてだと、構造体SHTCTL内に256個のsheets・sheets0があるよね。
shtctl_initで初期値を設定している。256個のsheets0に「未使用だよ」とマークし、さらにtopを-1としている。これがシートが一枚もないという状態。
sheet_allocで未使用のsheets0を探して使用中だよとマークして確保する。
しかしまだこの状態だと、この確保したsheets0の高さは-1。つまり非表示の状態。それだけしかやっていない。裏を返すと使用中にシートが何枚あろうと、表示していない限りはtopは-1のまんま。
出来上がったsiheets0を、sheet_updown関数に通すことで始めて表示が行われる。sheet_updown関数は高さの変更だけではなく、表示・非表示の制御も行っているのだ。
top変数もまた、この関数内で制御される。

・・・っということは・・・・・
マウスやメニュー等、一度設定したらもう二度と高さが変更されないシート。これらが設定される前と後でtop変数の扱いを変えたらどうだろう？？


・・・いや。これはこれで。
それより、アプリ関係（つまりシステム以外）のウィンドゥの高さを専門にあつかう関数を新設してみた。どんなもんじゃろ・・・？

いけた〜♪。

WindowsやMACみたいに、窓の下の可変ポイントをつまむと
びよ〜ん！

ウィンドゥの大きさが変えられる〜！！！！

・・・ような感じに見えるだけです・・・・・orz

まだ心臓部をまったく搭載していないんですよ。

つか、こんな「見た目」だけでもオイラのようなタコにはきつかった〜。

試行錯誤の連続であやうくソースがごっちゃごちゃになりかけました。（いや〜。SVNって偉大だなぁ（＾＾；

いよいよ、実際にウィンドゥが伸縮できるようなエンジンに手をつけます。・・・つか、早く完成させないと・・・そろそろ飽きてきた・・・・

ちょっと思ったのだが、現在のはりぼての設計だと、ウィンドゥを作ったりする場合の数字があいまいだと感じ始めた。

・・・っというのは、たとえばオイラが100x100のウィンドゥを作りたくて命令を書いたとする。その場合、100x100の、オイラが自由にできる領域が出来上がるよね？

でも、その場合、タイトルバーやウィンドゥの枠、フッター等がこの100x100に入り込んではいけない・・・というか、まずいと。

それはOS側が一括で管理し、統一できないとまずいような気がしてきた。

そんなわけで、そういう部分にちょっと手を入れてみよう。

いやなに、そんな御大層なことじゃない。単に「100x100のウィンドゥをくれ！」と命令すると自動的にタイトルバー等を付加した状態の窓ができあがると、そんなところ。

・・・ウィンドゥサイズの可変化・・・

してみて〜！！！

・・・でもかなりハードルが高そうというか大掛かりになってしまいそうだなぁ・・・

とりあえずここいら辺りでゴニョゴニョしてみるか。