ザビタン開発日記
2009 | 01
2008 | 01 | 02 | 06 | 12
2007 | 10 | 11 | 12
1月 20 (日曜日) 2008
21:29
ブライシンクロンマキシム!
 
さてさて。ウィンドゥの可変化。どうしたらええじゃろ?



おっとその前に。

サイズが変化した場合の挙動って、Windowsとか見てると何種類かが

あるのがわかるね。



  1. サイズが変化した時、クライアント領域が拡大縮小されるもの。メディアプレイヤーの画面とかがそう

  2. 内容そのものにまったく変化がない。単に見えてるか隠れてるかというだけ。スクロールバーが出現。メモ帳とかがこの部類かな?

  3. 上と似ているが左右だけとか上下だけとかが新しいサイズに合わせて変化。うーん。うまくいえないなぁ。コンソールとかPuttyとかがこの部類かな





うーーーん・・・どれから手を付けようかな。

とりあえず3番辺りをやってみるか・・・テキストビューアーの

改造という形でどうだろう。

 
name: @Guest  Comment:
1月 18 (金曜日) 2008
13:31
ザムザ復活!
 
・・・あれ〜?



「在来のインベーダの移植は無理!」

と切って捨てて新しいのを作ってたんだけど・・・・



なんか数箇所弄ったら動いてしまいましたとさ! (^^;

(ラッキー! 実はちょっとインベーダ作りに飽きてたので)



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



・・・つーことで、とりあえずははりぼて付属のアプリは

一通り新APIで動くってところかな。

(実はまだスクロールAPIがハンパなんだけど・・・)



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





リビジョン124
 
name: @Guest  Comment:
Referer  (1)
1月 17 (木曜日) 2008
13:07
ドッキングアウトだぁ〜!! (了解!)
 
えっと。開発日記じゃないんですがね。



このサイトではBWikiというPukiWiki派生のモジュールを使っているんですが

ちょっと実験的に新しいのを使ってみようかなぁと。



簡単に複数設置が出来そうなのがミソでしょうかねぇ。

ゴッチャゴチャに溜まりまくってしまったページ達をいくつかに

分離できそうな感じなので。(まだわかりませんが)





・・・・う〜む・・・・・・

ちょっとこの新しいモジュール、まだまだ問題が多いなぁ。

そんなわけで一時撤退・・・・(実験は続けるけどね)
 
name: @Guest  Comment:
1月 13 (日曜日) 2008
14:35
ジョリーと僕とで半分こ!(プッチーの分は?)
 
まいったなぁ〜。引数が多すぎ・・・・

そこでこうしてみました。



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を退避させてるのはシフト命令で影響が出るそうなので念のため・・・)
 
name: @Guest  Comment:
Referer  (1)
12:16
空間は存在しない! あるのは物質だけだ
 
いくつかの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・・・足りねぇ〜!!!!!











 
name: @Guest  Comment:
Referer  (1)
12月 23 (日曜日) 2007
13:16
「バードミサイル!」と言ってハザードを押すな!
 
久々に復習コーナー。



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



  1. キーボードが押されるとキーボード内にある回路が働き、割り込みが発生する(P130近辺?)

  2. 同時にI/Oポート0x0060にキーコードが送られてくるのでこれを受け取り、割り込み再開を通知しておく(P137)

  3. 受け取ったキーコードはメインFIFOに256を加算されて送られる(P256)

  4. 加算された値はメインループ内で分岐した後、改めて256を引き算して元の値に戻され、キーコードが渡る(p260)

  5. キーコードは渡されたメインループで文字コードに変換されて渡される(P345)

  6. APIにより、渡されたキーコード(もはや文字コード)を取得する(P486)



    まあざっとこんな流れだよね?



    ・・・って、ちょっとまって・・・・

    これだと生キーコード?を取得できないんじゃないの???

    全てあらかじめ文字コードに変換されてるし、そもそも、「離した時」の情報が受け取れないんじゃないの!????









 
name: @Guest  Comment:
11:07
5人? 2人でMAXじゃなかったの!?
 
さて。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



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





・・・もしかしたら助長かもしれませんが、まあとりあえずはこのあたりがあると便利かな〜なんて・・・(^^
 
name: @Guest  Comment:
12月 21 (金曜日) 2007
20:17
怪我の功名争い
 
「横道もいいとこ」とはじめた新インベーダーですが、プログラムそのものが

楽しいのとは別に、大改造した描画APIのボロをどんどん叩き出してくれます。

また、「こんなAPIがあったらもっと便利なのに・・・」なんてのも。



新インベーダーが完成することには、各APIももうすこしまともになってるかな??
 
name: @Guest  Comment:
12月 19 (水曜日) 2007
21:23
行き止まりだと解ったからいいんでありますよ!
 
はうあ〜・・・



やっとこさ方向がまとまってきた・・・

各APIもほぼ出来上がってきて、アプリ郡の改造も進んでるけど・・・



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



でもそれじゃくやしいので作り直しております <横道もいいとこ!
 
name: @Guest  Comment:
12月 15 (土曜日) 2007
12:46
こーほーかくほ〜 「うわーー!このぉ!」
 
なんとか管理の分離はできたしマウス直下のシートを設置することもできた・・・。さて問題は、アプリが作ったウィンドゥ。

シート・・・

シート内にはバッファがある。vramに直接データを書くのではなく、

まずこのバッファと名づけられたメモリに描画する。

で、それらを元に実際にvramにデータを書くのはシステムの仕事。

アプリが作ったシートにも当然バッファがあるんだけど、この場合、そのアプリの権限でのメモリ。まあこれはいい。



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



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



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



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



・・・まてよおぉぉ??

例えばだけど、これまでのシート。仮に100x100ドットだとするよね?

そーすると、どっち道、10000回メモリを書き換えないといけない。

シートを丸々2枚だと20000回の書き換えだから倍になっちゃうけど、

クライアント領域の座標の時だけは読み込む元を切り替えればすこしif判断が入るだけなのでそんなに遅くならない・・・ってふうにできないかな・・・



ちといろいろやりそうなので、例によってここいらへんにて妄想開始。
 
name: @Guest  Comment:
1 (2) 3 4 5 6 7 8 9 10 11 » 

PopnupBlog V3 Denali created by Bluemoon inc.