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

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

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


うーーーん・・・どれから手を付けようかな。
とりあえず3番辺りをやってみるか・・・テキストビューアーの
改造という形でどうだろう。
 
30日を過ぎたBlogにはコメントできません。
2008年1月18日(金曜日)
13:31
ザムザ復活!
 
・・・あれ〜?

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

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

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

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

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


リビジョン124
 
30日を過ぎたBlogにはコメントできません。

リンク元  (1)
2008年1月17日(木曜日)
13:07
ドッキングアウトだぁ〜!! (了解!)
 
えっと。開発日記じゃないんですがね。

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

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


・・・・う〜む・・・・・・
ちょっとこの新しいモジュール、まだまだ問題が多いなぁ。
そんなわけで一時撤退・・・・(実験は続けるけどね)
 
30日を過ぎたBlogにはコメントできません。
2008年1月13日(日曜日)
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を退避させてるのはシフト命令で影響が出るそうなので念のため・・・)
 
30日を過ぎたBlogにはコメントできません。

リンク元  (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・・・足りねぇ〜!!!!!





 
30日を過ぎたBlogにはコメントできません。

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

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

  1. キーボードが押されるとキーボード内にある回路が働き、割り込みが発生する(P130近辺?)
  2. 同時にI/Oポート0x0060にキーコードが送られてくるのでこれを受け取り、割り込み再開を通知しておく(P137)
  3. 受け取ったキーコードはメインFIFOに256を加算されて送られる(P256)
  4. 加算された値はメインループ内で分岐した後、改めて256を引き算して元の値に戻され、キーコードが渡る(p260)
  5. キーコードは渡されたメインループで文字コードに変換されて渡される(P345)
  6. APIにより、渡されたキーコード(もはや文字コード)を取得する(P486)

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

    ・・・って、ちょっとまって・・・・
    これだと生キーコード?を取得できないんじゃないの???
    全てあらかじめ文字コードに変換されてるし、そもそも、「離した時」の情報が受け取れないんじゃないの!????




 
30日を過ぎたBlogにはコメントできません。
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


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


・・・もしかしたら助長かもしれませんが、まあとりあえずはこのあたりがあると便利かな〜なんて・・・(^^
 
30日を過ぎたBlogにはコメントできません。
2007年12月21日(金曜日)
20:17
怪我の功名争い
 
「横道もいいとこ」とはじめた新インベーダーですが、プログラムそのものが
楽しいのとは別に、大改造した描画APIのボロをどんどん叩き出してくれます。
また、「こんなAPIがあったらもっと便利なのに・・・」なんてのも。

新インベーダーが完成することには、各APIももうすこしまともになってるかな??
 
30日を過ぎたBlogにはコメントできません。
2007年12月19日(水曜日)
21:23
行き止まりだと解ったからいいんでありますよ!
 
はうあ〜・・・

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

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

でもそれじゃくやしいので作り直しております <横道もいいとこ!
 
30日を過ぎたBlogにはコメントできません。
2007年12月15日(土曜日)
12:46
こーほーかくほ〜 「うわーー!このぉ!」
 
なんとか管理の分離はできたしマウス直下のシートを設置することもできた・・・。さて問題は、アプリが作ったウィンドゥ。
シート・・・
シート内にはバッファがある。vramに直接データを書くのではなく、
まずこのバッファと名づけられたメモリに描画する。
で、それらを元に実際にvramにデータを書くのはシステムの仕事。
アプリが作ったシートにも当然バッファがあるんだけど、この場合、そのアプリの権限でのメモリ。まあこれはいい。

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

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

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

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

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

ちといろいろやりそうなので、例によってここいらへんにて妄想開始。
 
30日を過ぎたBlogにはコメントできません。
1 (2) 3 4 5 6 7 8 9 10 11 » 

PopnupBlog V3 Denali created by Bluemoon inc.