えｒいのだめみたいだよ・・・・イマジン滾りすぎてる人が多いので通報されちゃうかも・・・(；´Д｀)カワイイのがいいかも

実はサークル描画の実装方法がイメージできてない

なぜみんな・・・・HSV色相環を描きたがるのだろう・・・・ かなりGUIとして大きくなりがちですし わりと操作が特殊なので導線が乱れそうな感があるのだが 純粋に理由が知りたい・・・

自分が作るとしたら、たとえ技術力があっても 「あ」「は」「ん」「や」をくぐもった声のみ認識し、言ってもいないナレーション文を自動生成しタイピングするソフトを作ると思います。 「あ・・・・」堪えきれずに漏れたその声は次第に荒さを増してゆく・・・・ ・・・・とかなんとか

なんかオフセット弄くればラスタースクロールとか作れるかな・・・・うねうねのやつ・・・

RGBチャネルに32bit配列使うのが帯域がもったいないと考えてしまう末期

切り出しもcopy+オフセットループで取得したほうが圧倒的に速いか・・・・

えー遅いのかー、juhsyでは1-3のGRPページでんでん使ってないのでいいかと思ったんだけどなぁ・・・・でもまぁ足りないメモリが空きますし、サウンドユニット非搭載環境でも高速化の道がひらけたので良しとします(ブラシ要素を真面目に全計算してたので)

色履歴ほしい・・・・orz

ドット絵は禅 お絵描きは快樂

わーい

つまり、可視ビットをムリヤリ立てるとRチャンネルはこういう表示になる ヤダ・・・丸見え・・・

あ、いいアイデア思いついた! GRPリソース大量に消費しちゃうけど。 分離したARGBをgloadで変換せずにgloadで保存するのさ！（RGBバッファとして使用） これならシフト配列も簡便に取得できるし、 切り出し合成の手間がかからない！ 汎用性のある方法じゃないけど、少なくともjuhsyのいくつかの問題点をいっぺんに解決できそう！＼(^o^)／

これの応用でPCの入力をリアルタイムでキーコードと文字コードから音声に変換して音声で制御というのは現実的ではないのだろうか？、petitmodemより速度が必要になるとも思えないのではあるのですが・・・

もやもやー(*´∀｀*)

画素ごとに配列処理して合成してgloadに流し込むというのを配列［w*h］をforで廻してという手法がめたくそ遅くて辛いっす。エアブラシ64*64であっという間に要素4,000オーバー

しんいちさんはどう改造しましたか？

そうですね、ループシフトの場合はみ出た部分が次の行頭に移動してしまうので、そこだけ一行上下する必要がありますが。

UNDOしたい領域は描いた後にわかるが 画像は描く前のが欲しい矛盾

速度面で見た場合ストロークが終了した直後から次のストロークまでに行われる速度はそんなにピーキーではないものの全画面はやはりコストが高い感・・・(全画面がjuhsyでなぜうまく言っているのか不思議だ) UNDO処理自体はある程度の遅延(60FPSである必要がない)は許容できるので、別スロット保存も考えられますね。