簡易毛筆にレイヤーを導入すれば自動混色の使いにくさは軽減できますが、その場合はレイヤーボタンを追加すれば良いという話ではなくてUI自体を一新する必要があると思います。 その場合は現在のver,2系を残したままver.3の新UI搭載版を作ることになるでしょうね。 「何でこんなUIなの？」というツールも制作者の意図を聞けば案外「なるほど」と納得できる場合があります。また、ツールによっては「特に深い理由はない」というものもあるでしょう。 例えばアクションゲームを作る場合に十字ボタンで移動、Aボタンでジャンプというのも1つの共通認識でしょうがそれに縛られていたら斬新なゲームは作れません。 したがって、既存ツールに似たものを作りたいのか新しいものを作りたいのかによって変わるでしょうう。しかし、後者の場合は独りよがりにならないような注意が必要だと思います。

裸コート(ただし、ピンクのぱんつを着用)とどちらがマシですか？

簡易毛筆はアナログ絵のようにリアルタイム混色が行えるためイエロー、マゼンタ、シアンの3色でフルカラー表現が行えるものの自動的に混色となるため使いこなすのが困難です。 したがって、UIを見てのように黒と任意の1色を切り替えて使用することを想定しています。 スーGRPエディタはよほど激しい処理落ちがない限りはブラシの種類を増やすことは問題ないと思いますよ。

私も同じ年にアカウントを取得しましたが、あの頃はちょうどtwitterが日本で普及しはじめた頃でしたよね。 といっても、たまにサイトの更新連絡をする程度でほとんどツイートをしておらず、まともにツイートしはじめたのはプチコンを始めてからですね。 当時の中学生トリオ（わぁい＠さん、バイカウントメルビルさん等）もすでに高校を卒業しているのを見ると時代の流れを感じます。

何だかんだでプチコン3号のお絵かきツールのデファクトスタンダードは（公式ガイドブックもある）Picsだと思うので簡易毛筆のブラシ描画速度は「同じ太さのPicsのブラシよりも速くする」というのを目標にして作りました。 （通常モードと水墨画モード2種類のモードがあるけど）毛筆ブラシオンリーという一点突破型ツールであるため毛筆っぽさでPicsに負けないというのも目標にしました。（にじみ、かすれ、重ね合わせに関してはどのツールのブラシにも負けてないと自負している） スーさんのスーGRPエディタはドット打ちに特化したツールでありドットの打ちやすさに関しては普通のお絵かきソフトと比べて別次元の使いやすさだと思います。 したがって、普通のお絵かきソフトとしても使えるようにUIを変えてそのドット打ちの部分がやりにくくなるのであれば愛用しているユーザーから不満が出るかもしれません。

簡易毛筆は基本的に（右利き専用ツールであるため）よく使う機能（ブラシと消しゴムの切り替えや太さ変更）は左手のみで完結するようになっています。 そして、設定等の最初に行ったらほとんど変更しないものはABXYボタンを使用するようにしています。（一般的なツールではよく使われる色変更ですが、簡易毛筆では基本的に単色絵もしくは単色＋アクセントカラーでの描画になると思われるためも左手操作ではなくXボタンを押すことにしている） 逆に誤爆防止のため間違って押してはいけないものは押しにくい位置にしています。（例えばキャンバスの初期化はL+Rという意図的に押さない限りはあり得ないボタン操作となっている） SIMPLE PAINTはあとから機能を付け足していったのでこの辺が不十分であり失敗でした。（常時60fpsがウリだったはずなのにプログラマブルブラシではそれができなくなったし）

みんなの目指す方向が同じではなくみんなバラバラだからこそ同じお絵かきツールなのに全く毛色の違うものが出来て楽しいです。 私のSIMPLE PAINTは「打倒！Pics」で開発開始しましたが、機能面が貧弱なのをカバーするのに「プログラマブルブラシ」「プログラマブルパレット」の導入を行いました。これはフォトショのカスタムブラシとは異なり簡易プログラミング言語によってユーザー自身の手で好きなブラシやパレット（UI）を作れるという画期的なものでした。（デフォルトで様々なプログラムブラシを用意してユーザーへの負担は無くし興味あるユーザー向けにブラシプログラミング講座も予定していた） しかし、処理速度面の問題、ボタン割り当て問題等の数多くの問題があり結局開発は凍結状態になりその後に作った簡易毛筆ではその失敗経験を活かしたものにしています。 コンセプトがぶれていたら上手く行かないということです

NAGIさんへ あのmkII用のポリゴン表示プログラムはやっていること自体はごくありふれたものなのですが、コードもアルゴリズムも独自手法のフルスクラッチであるため解説を書いているのですがそれでも分からない部分がありましたか・・・。 恐らくプチコン3号用のポリゴンプログラムでも私のmkII用ポリゴンプログラムのように環境光や光源の色まで考慮したものは発表されてないと思います。 むしろ、解説が全く参考にならない変態的な部分はモデリングツールを使わずに脳内だけでモデリングを行い頭で想像したモデルを元に直接mkIIへと数字を打ち込んでいくことだと思います。 さすがに152ポリゴンのアンドアジェネシスは脳内モデリングでは計算誤差があったみたいでわずかに隙間が空いていますが修正が面倒なので放置状態です。

初めて使うツールは別ですが、使い慣れたツールの場合は個人的にはメニューから機能を選択というのがあまり好きではなくSAIではすべてショートカットを使って描いています。 そのため私が作るツールも基本的にすべての機能をショートカットで使用できます。というか、メニューがありません。 GUIを作るのが面倒というのもあるけどツール自体がシンプルであるためどのボタンにどの機能が割り当てられているかさえ分かればいいのでメニューの必要性さえ感じません。 操作性はツールの命だと思います。とはいえ、自分が普段どんなツールをどのように使っていてどんな不満を感じているかで何がベターなのかが変わるしツールの性格（機能や用途）によって変わるため万人向け（誰が使ってもそこそこ使いやすいもの）を目指すよりも想定されるツールの使用者にとってベターなものを目指す方が結果的には良いものになると思います。

個人的にはすごい技術よりもその技術を使ってどんな面白いゲームを作るかという方が遙かに難しいことだと思います。 もちろん、高速化も何もない状態から行うのは難しいことですが技術というのは誰でも会得できる（その仕組みさえ分かれば難しくはない）のに対して面白いゲームを作るのは誰でもできるというわけではないためです。

ちなみにGIVERS-P3Dに使われているポリゴンエンジンは向きの違う三角形のスプライトを縦横拡大によって自由な形の三角形で表示を行うことでGTRIよりも高速になっています。 私が作った楕円表示プログラムもこれと同じ考えによるものですが、円は1つ定義するだけで良いので三角形と違ってすごく簡単です。 GRSさんのプログラムは動画でしか見てないのですが恐らくBG（GRP5）にPCでモデリングしたデータ（ラスタライズされたもの）をパーツ単位でGLOADしているのではないかと予想しています。（基本原理は私が昔ポケコンで作った超高速描画システムOPASと似たような感じ？） これで60fps出すのは難しそうですが試行錯誤で高速化したのでしょう。

変態的なテクノロジー（謎のテクノロジー）も大抵はその仕組みはすごく単純なものだったりします。 このしんいちさんのプログラムの元になった簡易地球儀QSPも仕組みが分からない人にとっては謎テクノロジーでしょう。 1ドット単位で3次元座標計算をしているといっても行列等を使ったりはしていません。リストを解析すれば分かるように非常にシンプルな計算で済ませています。 私が（プチコン3号より数10倍遅い）プチコンmkIIで作った3Dポリゴンを使ったレースゲーム（15fpsしか出なかったのでお蔵入りになった）や（プチコン3号より数1000倍遅い）ポケコンで作った擬似3Dゲームも謎テクノロジーに感じる人もいるでしょう。

3.5.2がリリースされてしばらく経つのに未だに旧バージョンを使っているのは現在配信されているプチコン3号が未だに3.3.2だからでしょう。 アップデートは手動なので最近買った人だとアップデートの仕方も分からないと思います。 それに3.5.0が不具合が多かったためか意図的に3.3.2のままアップデートしていない人もいるでしょうね。

簡易関数電卓QSPにこのトピックス内のサンプルプログラム＋αとOSもどきとして使うための説明を含んだマニュアルを強化したバージョンを用意しました。 ◎簡易関数電卓QSP ver.2.0のマニュアル大幅追加版【 2DC4VNNE 】 簡易関数電卓QSPのシステム部分は何ら変更はありませんが、（リスト末尾に記述の）マニュアル部分が大幅に強化されているためファイルサイズは10KBオーバーとなっています。 プログラム本体の30倍以上の超大作マニュアル（？）です。 分数計算関数などもサンプルプログラムとして追加しているためFRAC(1/2+1/3)で5/6という分数計算も可能です。あとフルバージョンに搭載のOSもどきとして使うための自作命令もいくつか掲載しています。 ちなみにフルバージョンのver.2.0はもう少し先になりそうです。

これは主観ですが、万能を目指せば目指すほど（機能を増やせば増やすほど）どんどん使いにくくなります。 そのためショートカットを用意して特定機能へのアクセス性を高める必要が出てきます。 その際にはショートカットが使いにくかったりとか誤爆したりということのないように注意しなくてはなりません。私が作っている簡易毛筆やSIMPLE PAINTもその辺を考慮していますが、まだ十分とは言えないのが現状です。 結局はスーさんがどんなツールを作りたいのかがすべてなので、汎用性の高いお絵かきソフトにしたいのかドット絵に特化したツールにしたいのかで決めればよいと思います。 単なるアンケートとしてこのトピックスを用意したのであれば私の意見は「操作性が悪くならなければ（操作が煩雑にならなければ）搭載を希望」という感じになります。

私は自分のポリシーを貫く派なので自分のツールの意図に合わない機能は実装しないことが多いのですが、それは個人の考え方次第なので問題はないと思います。 ただし、他の機能は快適に使えて特定機能のみ処理落ちするならばその旨を書いておいたほうがよいでしょう。（誤動作と考える初心者もいるかもしれないため） とはいうものの、機能を増やすことでメニュー階層が1段階増えたりなどの操作面の煩雑さが出てくるならば個人的にはあまり好ましく感じないですね。 これは私が作るツールにおける考えですが、特定機能を使うためには1アクセスで可能な状態が望ましく最悪でも2アクセスで可能にしています。 つまり、メニュー画面を用意するならばそれだけで1アクセスとなるためそこから1アクセスで特定機能まで行く必要があります。 要するに常に快適アクセスを目指しているということです。

どんな記述方法であっても自分が想定している通りに動けばそれは正解であり、いくらきれいな記述であっても自分が想定しているように動かなければそれは不正解です。 したがって、自分が何をしたいのかが分かっていれば記述方法は無数にあり正解も無数にあるということです。（つまり、そのIF A==B==C==D==E==F THEN ～という1文を見ても正解か不正解かの判断をすることはできない） 完全に動作原理を把握する必要はありませんが、もしも「ちゃんと思った通りに動いているかさえ分からない」というのであればその記述は避けた方がいいでしょう。 余談ですが、プチコン3号の演算は基本的に左側から順番に処理されますが、構文解析は右から行わるため自作関数を使ってIF A()==B()==C()==D()==E()==F() THEN ～という判定を行うと予想外の結果になる可能性もあるので注意しましょう

A==Bのような等号や不等号を行った比較演算はtrue（成立時）の場合は1の値を返しfalse（不成立）の場合は0を返します。そして、IFは条件式部分の値が0以外ならばTHEN以下を実行するためIF A==B==C==D==E==F THEN ～を見てみるとまずAとBを比較して0か1の値になりその値を変数Cと比較して・・・ということを行っています。 そのため仮に「変数A～Fの値が0もしくは1の値しか取らない場合でA～Fの値がすべて1になっているかどうかを判定したい」ならばこのIF文は正しく動作します。 私ならば「変数A～Fの値が0もしくは1の値しか取らない場合でA～Fの値がすべて1になっているかどうかを判定したい」という場合は IF A*B*C*D*E*F THEN ～と記述してしまいますが・・・。

さすがに速いですね。 私が作ったプログラムはあくまでQSPの範囲内での最速であり、しんいちさんが作ったこのプログラムはリアルタイム描画で最速、プチコンBIGで作ったものはプチコンBIGで最速ということでどれもが最速でどれもが正しいプログラムだと思います。 プチコンmkIIで作った1画面プログラム「簡易地球儀」ですが、mkIIではR=64で0.4fpsだったのが、プチコン3号のQSPでは12fps、このプログラムはで16fpsになったのはやはり感慨深いですね。

長くなりましたが、DEFで自作関数を作る場合には変数の「型」についてよく理解しておく必要があります。それはDEFで挙動不審になる場合は多くの場合はこのようにDEF内では代入された時点で型が決まるため想定した動作にならない場合があるためです。 原因を知らなければ「単なる原因不明の誤動作扱い」となってしまいますが、どのような場合があり、どのように対策すれば良いかを知っておけば難しいことは何もありません。 今回書いたことが皆さんの役に立てればと願っています。