OMRON LUNA フレームバッファ Twitter駆動開発
念のため使い方: tw/monosixel/でmakeしてできたバイナリをパスの通った適当なディレクトリにほりこんで、tw/lib/tw/app/render.rbを最新にさしかえ
2013-11-18 22:36:33@arakiken ありがとうございます。convert のメモリ消費量がキツい感じなので gdk_pixbuf がそれなりに軽ければ結構変わるかも? ぼちぼち試してみます
2013-11-18 22:40:41結論として NetBSDの rasops1 は激しくバグっているが どう直せばいいのかがよくわからん(´・ω・`)
2013-11-21 22:35:32@ao_kenji http://t.co/QxhXzFG5be ここの BIG_ENDIAN のときに MBL が右シフトで MBR が左シフト になってるのはバグというかtypoっぽいです
2013-11-21 22:38:28http://t.co/VLXlsUEIH4 ここの if else で nl = nlMiddle; while (nl--) と nl = nlMiddle + 1; while (--nl) を使い分けてる意味あるんだろか
2013-11-21 23:04:22ピッタリじゃなかったら端数が出るけど端数分は endmask のところで処理される というくらいの主張ということか
2013-11-21 23:10:46copycols() って行内編集時にしか呼ばれないから本当に正しく動いているのかどうかもよくわからんな(´・ω・`)
2013-11-21 23:15:18right-to-left のコピー(つまりオーバーラップしてるときの挿入)で最後の 1 word の部分の開始ビットがおかしいってことだよなこれ。コピーしてから文字書いてるとしたら、だけど
2013-11-21 23:38:28@tsutsuii がーん。そうなんですか? raspos_masks.hが変更されるならLUNA用のMBL/MBRマクロを自前で定義しなくてもいいのかな。
2013-11-21 23:36:13@ao_kenji NetBSD/sparc の bwtwo で試してたんですが、少なくともシフト方向を逆にしないとメタメタです。が、 rasops_mask.c の各マスクも uint32_t にしないとダメで、これは gcc4 だとダメなのかも(符号付きのシフトは未定義?)
2013-11-21 23:41:00@ao_kenji あと、hp300で本当にMSB側が右だとしたら、 startmask と endmask の値も逆向きにしないと端数分がちゃんと描画されないはず……
2013-11-21 23:42:391文字12ドットで3文字目が4文字目にコピーされる →左から24ドット目から1ワードの残りの8ドットが12ドット右にコピーされるはずが、さらに32ドット分左から余計にコピーしてるのかこれ
2013-11-22 00:03:57「m68kビットフィールド命令の変態5バイトアクセス(=1バイトの途中から始まる32ビットを取り出せる)」の変態加減を思い知る https://t.co/I6aLO7ggkj
2013-11-22 00:15:25@tsutsuii バイトの途中な上に、さらにダイナミックバスサイジングとページ境界MMUなのでここだけC++で書いてある。ここはたぶんうちのMBPでも実機に負ける
2013-11-22 00:40:35@moveccr つまり、 http://t.co/Q0eJOC2FoP ←こういう 1bpp 横スクロールで 32bit 単位コピーとかやられると泣けるということですね……
2013-11-22 00:43:56やっつけでとりあえず 1 word 減らしてみたけどまだなんかズレてる(´・ω・`) カーソル位置の文字は再描画されるのだとすると、左側の端数分の GETBITS()/PUTBITS() のドット数が多過ぎるということ? http://t.co/O14s7tQZS6
2013-11-22 00:27:24