下画面に色を塗ってGSPOITでタッチした場所の色を拾うプログラムを作ってましたが、 RGB(0,127,127)のように「8で割り切れない値」があると美味く読み取れない模様。 Six Rock Sixtyの時は気づかずスルーしてたようで。

なぜ誤差が出るのでしょうか(´・ω・`)

説明書に所々「内部では1555ビットで持っているので注意」とありましたが、その仕様でしょうか。 GSPOIT使うときは気を付けよう。

ダイレクトモードで GPSET 0,0,RGB(254,0,0,0):? GSPOIT(0,0)　が0 GPSET 0,0,RGB(254,0,0,1):? GSPOIT(0,0)　が0 GPSET 0,0,RGB(254,0,0,2):? GSPOIT(0,0)　が0 GPSET 0,0,RGB(254,0,0,8):? GSPOIT(0,0)　が8 見かけは256階調だけど実質32階調ってことだよね

0～255が指定できるとありますが実際には下位3ビットはグラフィック画面に描画した際に無効となっているようです。透明度情報も254～0を指定すると描画した際に0になります。

ふむ・・・下画面はちょっと仕様が違うという認識でよろしいでしょうか。皆様どうもです。

この仕様ですとプチコンmkIIで使っていたグラフィック画面をメモリーのように読み書きする方法は出来ませんね。

>みけらんジェロさん 上画面でも同様に下位3ビットが無視されているようです。 XSCREEN 0,512,4 DISPLAY 0 A=RGB(127,127,127) GPSET 0,0,A B=GSPOIT(0,0) DISPLAY 0 PRINT HEX$(A);" ";HEX$(B)

>>otta777さん 仕様上、不要な下位3bitが失われるだけなので それ前提で5+5+5+1bitデータとしてなら利用出来ますよ たとえばこんなのはどうでしょう I=54321 '今回格納する16bitデータ(0～65535) A=(I AND &H8000) '最上位bitをチェックしαへ代入 R=(I >> 7) AND &HFF 'シフトで位置合わせしANDで余分を G=(I >> 2) AND &HFF '消したのち5bit+ダミー3bitの B=(I << 3) AND &HFF '計8bitをRGBへそれぞれ代入 GPSET 0,0,RGB(A,R,G,B) '分解されたデータをGRPに格納

GRPからのデータ抽出は上記の逆を行います RGBREAD GSPOIT(0,0) OUT A,R,G,B I=(A!=0)*&H8000+(R << 7)+(G << 2)+(B >> 3) ただ、GPRリソースを無理にデータの保存領域として 使わなくとも3号は他にお手軽なデータの保存手段が ある上にGRPリソースは1枚500k程度とかなり大きいのが 悩みどころですね！ 自分もmkIIではお世話になったんですが 画像を表示すれば使用状況が目視で確認できるので MAPデータなんかを格納する際に重宝したんですよね～