07/26 15:48 (@yunyundetective) @gorry5 @tokihiro_naito ですねー。あれは、VBlank単位で「スプライトレジスタの内容をバッファリング」してるんですよね。 (ga)

07/26 15:56 (@gorry5) フレームバッファの弱点としての遅延は、どのタイミングで「バッファのクリアを始める」「バッファへの描画を始める」「表示バッファの切り替えを行う」かが自前で制御できればかなり解消できるのだけど、フレームワーク側に隠蔽されてる環境が案外多いのよね…（苦笑 (kiri)

07/26 16:02 (@tokihiro_naito) @yunyundetective @gorry5 流石エミュ開発実績者はキッチリ把握されているんですねー！ (kume)

07/26 16:09 (@gorry5) 素直なOpenGL環境だと、VBlankが来てから「表示バッファを切り替え、CPUが演算処理を行い、フレームバッファのクリアを始め、バッファへの描画を始め、バッファ描画終了を待ち、次のVBlankを待つ」ことになり、演算から表示までに多くの時間がかかることになる (kezu)

07/26 16:09 (@gorry5) これを、VBlankが来てから「CPUが演算処理を行い、バッファへの描画を始め、バッファ描画終了を待ち、表示バッファを切り替え、フレームバッファのクリアを始め、次のVBlankを待つ」ようにすると、演算から表示までの時間を縮められ… https://twitter.com/i/web/status/1022378236934643713 (keze)

07/26 16:18 (@gorry5) @tokihiro_naito @yunyundetective エミュよりも前に、スプライトの高度な処理を行うにあたって「ブラウン管のビームが今どこにいるかを把握する」ということを覚えるようになるのです… :D (sami)

07/26 18:05 (@nnk_osn) ちなみにそのパッケージソフトで、カラー画像をランダムディザで２値化する処理（FAX送信するソフトだったので）はGORRY氏に元ネタ書いてもらった件。

07/26 18:05 (@nnk_osn) ハフマン圧縮とかは自分で書いたが、ランダムもオーダードもディザリングの資料が無かった。 (mizi)

07/26 18:39 (@gorry5) もも兄からもも来たる :D https://t.co/tQYjqEqyTg (robo)

07/26 18:45 (@zweisser) @gorry5 兄の尻の切り取り？（をひ） (gita)