[OSASK 594] Re: knimu1.

[n-hashi !Atmark! interlink.or.jp]

やっほぉ、<川合の旦那>
[2000年5月6日(土)]にもろた
【[OSASK 590] Re: knimu1.】への返答っ! 。

川合>>うーぐー、指名されてしまった。
川合>  だって、リリースしてから半日以内で確実にダウンロードしてくれる
川合>んだもん。今や、テスターとしては鏡のような存在です。

だってだって、やんないとすねそうなんだもん、川合さん(笑)

川合>  最初はマウスの話題です。
川合>  knimu0までは、マウス表示のアルゴリズムはこんなものでした。
川合>・実際の表示解像度とは無関係に832x630というVRAM構成にする（だか
川合>  ら、表示が640x480でも、VRAM上は832x630になっていた）。
川合>・こうすれば、16x16のマウスカーソルがVRAMの外に出ることはありえ
川合>  ないので、クリッピング処理をすべて省略してマウスカーソルの表示
川合>  ／非表示を制御した。

要するに絵より大きな机を用意したってことだね。で、三角定規（カーソル）が
はみ出ても大丈夫にした、と。でも、いつもは見えてるのは絵の部分だけだから
良い事にしようとしたけど、800*600という大きな机にしたら
机のほうまで見えるようになってしまって、隠れなくなった、と。
うむ、それが原因の800*600でのマウスカーソルの変な描画だね。

川合>  結局、knimu1でのマウス表示のアルゴリズムはこんなものです。
川合>・実際の表示解像度とは無関係に800x600というVRAM構成にする（だか
川合>  ら、表示が640x480でも、VRAM上は800x600になる・・・ここも640x4
川合>  80で処理した方がVRAMの未使用領域が増えるんだけど、処理は複雑
川合>  になる。640x480は主流にならないと思っているのであまり考慮して
川合>  いない）。

この場合、800*600が標準になっているけど、さらに大きな解像度を
サポートするとしたら、当然その解像度でVRAM確保ってことになるのかな？

川合>・マウスカーソルのクリッピングをちゃんとやり、指定された枠からは
川合>  み出さないようにする（デバッグのときのなごりで今はその枠が640x
川合>  480になっている。そのう、この枠は800x600に拡張されるので、knim
川合>  u0との表示上の違いはなくなる）。
川合>  ・・・ということで、マウスカーソルの表示アルゴリズムが変更され
川合>た、というのが第１の変更点です。

800*600表示で、画像部分までしかマウスカーソルが移動（表示）していなかったのは
コレのおかげだね。

川合>  マウス関係の変更点はもう一つあります。・・・それは、「厳密な重
川合>ねあわせ処理をするようになった」です。これが第２の変更点です。

私が書きわすれたほう(;^^)

川合>  knimu0でマウスカーソルをカウンターに重ねると、カーソルはカウン
川合>ターの下敷きにされてしまい、マウスカーソルは壊れてしまいます。こ
川合>れは文字表示ルーチンがマウスカーソルとの重ねあわせ処理を全く考慮
川合>していないせいで、マウスカーソルの処理としてはふさわしくありませ
川合>ん。

困ったさんでした。そういやバグ報告もしてないや。うーん、笊なテスターだ(^^ゞ

川合>  この機能を使ってカウントスピードを上げています。これが第３の
川合>変更点です。

要するにあのカウンターのスピードアップはずるをしていないんだ、ってことだね。

川合>  knimu1では、カウントを1増やすごとに画面表示することをやめまし
川合>た。カウント部分は単純な無限ループを構成していてカウントしかして
川合>いません。では、いつ表示するのかというと、こういう仕組みです。30
川合>ミリ秒ごとにシグナルを受け取るように細工しました。タスクはシグナ
川合>ルを受け取ると、そのときのカウント値を出力します。・・・と、それ
川合>だけのことです。人間の目には、30ミリ秒以下の書き換えなんて多分分
川合>からないだろうということでこの時間が選ばれています。

有無、わからんだろうなぁ、一桁まず見切れないもん。

川合>  30ミリ秒の間に1000カウントが行われるなら、それはknimu0を少し改
川合>造してカウントが1000の倍数のときだけに表示するようにすればいいの
川合>ではないか、といわれるかもしれません。確かにそのとおりです。タイ
川合>マーなど使わなくても、1000カウントに１度だけ画面に出力するプログ
川合>ラムなら書けます。しかし、そのプログラムをマルチタスクで100タス
川合>ク平行に走らせると、それぞれのカウンターが1000増加するには平均で
川合>30ミリ秒x100 = 3秒もの時間がかかり断続的な書き換えをしているのが
川合>明らかに分かります。タイマーシグナルなら、平行に走っているタスク
川合>数がいくつであってもシグナルは30ミリ秒に１度です。その時は、カウ
川合>ントの増える速度は当然落ちますが、全てのカウンターが十分に頻繁に
川合>書き換えられ、書き換えを間引いていることは人間には分かりません。

時間管理の厳密なタスクのような場合はどうなるの？問題でない？

川合>  また、マウスカーソルと文字表示が重なると重ねあわせ処理を行ない
川合>ますから、時間がかかります。そのため、タスク時間を余計に消耗する
川合>ことになり、カウントが遅れます。たとえば、タスク2のカウンタの上
川合>にマウスカーソルをおけば、タスク3との差が少しずつついていくこと
川合>でしょう（すぐには分からないので、１分以上待ってみてください）。

試してみました。結構差が出るね。でもバグ報告にも書いたけど、
ほっぽっといても差が出てます。
・・・もしかして私の「ズレ」ってコレのせいかな？

川合>>あと、knimuからだけど、マウスカーソルの動きがなんとなく
川合>>気持ちいいような気がします。（気のせいかもしれんが）
川合>  それは多分、気のせいです。OSASK ver.0.0とknimu0とでは、マウス
川合>処理に差がありませんから。

そか・・・うーん、ならマウスパッド変えたのが正解か(笑)

でわでわ

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/  氏名：もしかしたら橋　直行                                      _/
_/  E-mail:n-hashi !Atmark! interlink.or.jp,PXW06256 !Atmark! nifty.ne.jp             _/
_/_/_/_/_/_/_/_/_/_/_/_/_/-----平成12年05月06日(土曜日) PM08時24分_/_/