ドキュメントも禄に無いのにご利用ありがとうございます！ オーバーフローについては 30文字10,000行で500kくらいですんで、断片化考えても多分大丈夫じゃないかなーと楽観してます。 それよりパフォーマンスの劣化の方が危ないかも…きっと３号は速いから大丈夫だと信じていますが。 ただ変換→即実行の場合メモリが減ったまま実行になってしまうので、変換に使った変数や_OUT_$を実行前に空の文字列代入するようサンプルに書いておけばよかったかも…

@START PRINT RND(5); GOTO @START このプログラムでなんで300回やっても出なかったか検証してみるといいよ！

名前が載ってるとちょっとうれしい:) フィルタ楽しいですねー。 FC風、色数が違うのでーとおっしゃってましたけど使ってみるとレトロな感じになって面白いです

- 複数行コメントアウトほしい(#IF 0とか) - デバッグ版とリリース版で処理を変えたい(assertとか) - ファイル1つにするためにライブラリコピペするの面倒 - 高速化のために展開するの自動化したい …っていうのをなんとかしたくて作りました。 具体的な使い方は PIPP.PRG を実行しますと - スロット1に元となるプログラム - スロット2に中間プログラム - スロット3に生成されたプログラム が読み込まれてますので、色々見比べていただければ。 特にスロット1のEXAMPLE.PPPを読んでいただけると、大体の使い方がつかめるのでは無いかと思います。

プリプロセッサ的なものを作りました。プログラムにプログラムを埋め込んでプログラムを生成するプログラムを生成するプログラムです:p PHPとかテンプレートエンジンのようなものを想像するとよさげです。 P/PP v0.1.0 【 D343XJJY 】

うまくいったようでよかったです！ というか混乱させてしまってすみません…135は打ち間違いです、カッコわるい； 一応今更ですが僕の作ったのRGBとHLSの変換はこんな感じっす 【 C3ANEJ4X 】 wikipediaの式を割とそのままなんですが、絶対値を使った彩度の式はなかなかトリッキーですね。 変形したら納得したけれど、何やってるかはわかりにくい… バージョンアップ楽しみにしてます:)

ってあれなんで135って書いてるんだろう… 今出先なんでかえって確認します、すみません！

0度が赤、60度が黄、120度が緑って進みますが、Gが31のときってもう黄色ですよね。 つまり0と31は前後の領域と重なってます。 だから各領域31段階必要で31x6=186段階、0から始まるから185までになります:）

HSL(円柱モデル)ちょっと試してみたんですが、RGB[0-31]と1対1かつ整数にしようとすると H[0-135] L[0-62] S[0-31]な範囲でうまくいきました。 Lも31までにしたかったんですけど、どうにもうまくごまかせない… まだPCでしか試してないんですが、今晩プチコン版も作ってみようかと思います。

ちょっと遅くなったけどパレットを使うやり方、画像サイズで考えると256x128分の処理になります。 (16bit 65536色 から透明色を除くと32768色=256x128) なので64x64の場合はその場で処理するほうがいいですねー。

512x512の画像をグレイスケールに変換するサンプルです。 【BXVQQ34J】 FC変換処理もこの方法＋作ったパレットをファイルに保存で高速化できないかなぁと。

僕も色合いよく弄るので、色相・彩度・輝度あたりがあるとほっとします:) なんか地味になって彩度あげるのがよく。 RGBをHSLに変換してからそれぞれ数値いじってからまたRGBに戻すって感じですかね。 あともしメモリに余裕があるようでしたら、GLOAD/GSAVEを使ってある程度高速に処理できるかもしれないです。 具体的にはGRPが1面と、PAL%[65536],IMG%[512,512]がぐらい。 1ピクセルずつ同じ計算式で変換していくタイプの処理限定ですけども… (セピアとかはできるけどぼかしたりは無理) ちょっと簡単なサンプルつくってみます。

あ、UI_ROLLBACKで巻き戻す前にUI_CANCEL処理してないからタッチ中にUI_ROLLBACKするとおかしくなる可能性が。 実際にはUI_ADDされるまで以前の領域は破壊されないので、サンプル程度だとバグらなかったけども。

あ、セーブミスで古いのあげちゃった… 110行目の PN_OVERLAY_CLOSE を UI_ROLLBACK に変更してください><

タッチ操作は作るのが面倒なのでライブラリ化したくて試作中。大体仕様は固まったところ。 P/UI v0.1.0【DR83D3AV】 スプライトやBGが使えないシーンで動いたり重なったりはしない条件…ちょっとしたツール想定。 現状骨組みだけで部品は仮のものを少し作っただけなんだけど、見た目かんがえるとやっぱ手間かかるっす。

>まげさん 画像と同じサイズの二次元配列を作ってから読み込めば大丈夫だと思います。 VAR F$="DAT:TEST.DAT" VAR A%[1,2],B%[1,2] SAVE F%,A% LOAD F$,B% :'A%と同じサイズじゃないとType mismatch 扱いにくいしバージョン間のことも考えると、P/RECVはSAVE"GRP0:xxx"で保存するように変更かな…。 画像の部分保存、対応して欲しいなあ

仕様変更でバグってますね…。 牽制というか、今まで自動で変換してくれてたのが、厳密になった感じでしょうか。 おかしくなるデータについては一旦配列に読み込んだあとGLOADで描画すれば問題ないと思います。 P/RECVは512x512の時はSAVE"GRP0:xxx"で画像保存、それ以外はDATで保存だったんですけど、 整数型配列の場合は2ピクセルずつ詰めて保存しなきゃいけないようです…ようは16bit整数のバイト列にしなきゃいけないようで。 (幅が奇数の時は1ピクセル分ダミー入れる) P/RECV2なら456行あたりでその判定やってますんで、常に512x512扱いにして凌いでいただければ。 この仕様にするなら16bitで詰め込んでくれるGSAVE/GLOADが欲しいなぁ。

パレットの個数に制限が特に無いようなんで、α無視すれば15bit=32768個分の計算＋GLOAD分の時間で色変えられるなーと思って試してみた。 旧3DSで0.5秒くらい、512x512ピクセルちまちまやるよりは早そう。 事前に計算しておけば(更にファイルに保存しておけば)一発でエフェクトかけられるのがちょっと便利かなー

パレット使えば色調補正高速で出来るかなテスト。 【D3ENYXDY】

効果があったようでよかったです！ もともと最初のバージョンでバンディングが…と言われて追加した機能でしたので:) 写真の場合は有効にしておく方が大体いい結果になるかと思います。