お絵描きツール「PETIT BRUSH」を3.1.0に対応させました。(ver1.2.1) 公開キー【428XN8HV】 漏れがあったらご指摘ください。

私プチコンは3号が初めてなんですが、これまでもこんなこと（後方互換性のない更新）がザラにあったんですかね…？ β版じゃあるまいし、二度と勘弁してほしいんですが。

まってました！これで色々描ける…

大変すぎる調整本当にありがとうございます 疲れで倒れないように、ゆっくり休息もとられてくださいね　本当にありがとうございます

今回の件だと、その気になればある程度の互換性保てるかなーとは確かに思いますね たとえば、いきなりSPHIDEをしてたら SPSET、SPHIDEの2命令に展開して実行 もし、その次、つまり内部的にSPSETされた状態でSPSETをしたら 設定されてる内部パラメータをいったん待避してSPCLR、SPSET、そして待避したパラメータを書き戻す感じに展開 当然、今回エラーになるケースでは重くせざるをえないかと思います エラーにしてしまうのとどっちがいいかは迷うとこですけどね 動くには動きますけど、重くしてる原因に気づけないわけですし

対応、お疲れ様でした。「自分で作る」というプチコンの性質上、なんとなく本体のバグにも寛大になりがちですが、「商売」として考えるなら、こんなに欠陥だらけの商品というのは、確かに問題ですね。ジェットコースターの安全バーが外れてフッ飛ばされたのに、「次で対応します」って言われてもねぇ…。

ユーザの方にはお待たせして恐縮です。ぜひまたバリバリ描いて（そしてもしまだエラーが残ってたらご報告）くださいませ。 …というように、それまで活用していた他人のプログラムでエラーが出た場合、それを自分で解析して修正して使い続けるなんてのは普通無理ですよね。 せっかく公開キーを使ってプログラムを集めるという楽しみが用意されているのに、もうこれからは「落としてもどうせ動かない」「そのうちまた動かなくなる」という不信感が常につきまとうようになってしまったわけです。 こんなのは作る人にも使う人にもマイナスしかない。 完全な互換性という形でなくてもいいですが（例えばOPTIONを1行追加すればXSCREEN/ACLS/SPCLR時に全スプライトを自動でSPSETする、とか）、落としたプログラムを安心して資産として使い続けられるようにちゃんと考えて頂きたいです。

他のプラットフォーム（例えばアップルとか）はアップデート前には、デベロッパー向けにお試し版ライブラリやOSを公開しますが、プチコンは全員がデベロッパでありユーザですから、それも難しいというねぇ（^^;

どうせVMみたいなもんなんだから、例えばWin8で動かないソフトをゲストOSとしてのXPで動かすように、3.0.2相当の3号を別口で配布してもらえばいいんじゃないすかね。 ファイル共有はスマブのサーバを経由すればできそうだし。 eShop上の枠を取るのにお金がかかるとかは知らん。

前に投稿させて頂いた事に被るんですが、3.1.0に3.0.2のそのままを同梱してくれてれば、ここまで言われなかったかなぁと考えたりします。 過去１バージョンはOPTIONで切り替えれます、次のバージョン出すまでの移行猶予期間だから速やかに対応してね、とか。 まぁ「プログラムサイズが倍になった！」って文句は言われますでしょうけど(^^;

開発者向けの猶予期間としてはそれでも十分なんですが、ユーザにとってはそのうち使えなくなることに変わりないですよね。 メンテが終わった公開キーは結局ゴミになってしまう。 同梱でも別口でもいいですが、後方互換性が保てなくなった最後のバージョンの実行環境は、何らかの形で選べるようにするのがいいと思います。

>メンテが終わった公開キーは結局ゴミになってしまう。 それは結論を急ぎすぎだと思うのです 作者が放置してても、落とした誰かが修正してしまえばOKですし 修正版を第三者がUPすることを邪魔する要素も特にありません もっとも、動きませんと言うだけで直そうって人が少ないのが悩ましいとこですが…

なるほど、色々勉強になります。 確かに同梱しようが、別口でしょうがユーザの立場からしたら困ることには変わらないし、「無いものは作る」の精神でカバーもできますね。 少しズレれてる気もしますが、ユーザはプログラムを何時まで使えるか、開発者がプログラムを何時の段階まで保守するかなど、プログラムを公開することには、人それぞれ色々な考えと想いはあるのだなぁと、そんな事を考えました。

自分のプログラムですら億劫なのに、他人のプログラムまで直してやろうというのは相当な物好き（失礼）だけかと思うので、誰かが直せばいいというのは楽観的に過ぎるんじゃないかなぁ。 少なくともプラットフォームを提供してる側（スマブ）の態度としては間違いだと思います。 ホントに作者がメンテを放棄したかどうかを確認できないまま勝手バージョンをforkさせるのも抵抗があるでしょうし。

事実上はどうあれ建前上は教育ソフトですからねぇ。 教育ソフトでの「プログラムのあり方」は勉強不足で、何を元に判断すればいいか、私は知らないのですけど、動かないのは困るのは確かで。 さすがに「バージョンが変わったから直してみよう」とかそういう教育はないのでしょうが。 事前のアナウンスがありましたが、直し方の提示がされていないことや後方互換が保証されていない訳で。 後方互換が保証できなかった事に、正当な理由があるかもしれませんし、そうでないかもしれません。 「綺麗事だ」と言われるのを覚悟で書くと、こういうネガティブ要素を次世代で活かしてくれて、面白いものに繋がれば、とか、そんなことを言ってみます。 自分個人の事だけですと、適当に書いた部分が見事にエラーになったので、ポジティブに言えば自分を見直せてラッキーで、ネガティブに考えると面倒くさいなぁと。

事前のアナウンスとは言うものの、特定の命令が廃止されたとか書式が変わったとかならともかく、処理の前後関係で出るエラーを事前に100%検証するなんて不可能ですしね。 この仕様変更を前提として、今後こんな素晴らしい拡張を予定してます！みたいな具体的なビジョン（要するに納得に足るだけのきっちりした事情の説明）があれば、まだ少しはポジティブに捉えられるかもですが。うーん。無理。

なんか、場違いな議論の方向になって申し訳ないと思っております。 「仕様変更の具体的なビジョンがわからん」のは同意。拙い理由は思いつきますが、実際の所どうなんでしょう。 次に影響度多い仕様変更がされるのであれば、今回よりかは慎重にして欲しいなぁ(^^;

素晴らしい拡張…ねぇ スプライト関連だとネイティブコードで空きを探してくれるだけでも十分だとは思うのですがこれ以上となると… 指定した範囲内で使ってるスプライトの管理番号を配列で返すとか SPVARを大幅拡張して、要素8の配列変数なんてしょぼくれたものじゃなくユーザー定義の構造体が使えるようにしてしまうとか

えっ 「空きを探す機能」のための仕様変更だったの…？ つまり、楽になる何かを実現するために、楽だった他の仕様を潰しただけ？ それで納得しろと言われてもちょっと… まあ、終わったことをいつまでもうだうだ言ってても始まらんので、「次回はもっと慎重にやってほしい」（というか次回がないようにしてほしい）というのを強くお願いしたいですね。

ええ、公式の説明では「空きを探す」ための仕様変更です 今までって、未初期化のスプライト型変数(仮)を操作しちゃってたわけですし、もし現状維持だったとしても動作保証できないものに違いはないわけで、正直仕方ない変更なのかなーと思いますよ こっちが気をつけられるとしたらそういう曖昧な仕様に依存することを回避することくらいですかねぇ

元々SPSETはスプライトを使用するときに最初に使うようにヘルプに記載されています。今回動作に問題が出たプログラムはそれが守られていない行儀の悪いプログラムです。仕様変更と言うよりも本来の動作をするようになっただけです。

当初のヘルプに反してSPSETだけで勝手に表示する仕様は「お行儀がいい」んですかね？ そして他人のプログラムを指して行儀がどうと不躾な指摘をするあなたのお行儀は自慢できますか？

なんか機械翻訳みたいな文になってしまったので書き直しときます。 当初のヘルプに反してSPSETしただけで勝手に表示する仕様が「お行儀がいい」とでも思っていますか？ 行儀の悪い仕様に合わせて書いたプログラムの行儀が悪くなるのは当たり前です。 そして公開の場で他人の作品を捕まえて「行儀が悪い」などとあけすけな指摘をするあなたの考える行儀とは何ですかね。

私は仕様の隙を付いて1文字でも短縮させて1画面プログラムを作ったり、少しでも高速化してポリゴン表示などの重いプログラムを作っていますが、これも決して「お行儀が良い」とは言えません。 自分で行儀悪いと思っているからこそそういう仕様の隙を付く使い方は行儀が悪いと感じます。 そんな私でもエラーで動かなくなった他人のプログラム（公開キー）を「ゴミ」と言うことはさすがにできません。 前置きはこれくらいにして本題に戻すとプチコンは初代からSPSETはスプライトを使用する際に最初に記述することになっていてプチコン3号でも当初からヘルプではそのようになっていました。 最初に使わなくてもエラーにならなかったのはエラーチェックが不十分だったためで今回はそれを厳格化して本来のSPSETの仕様にしただけです。

当初はヘルプにはSPSET時はSPHIDE状態になるようなことが記載されていましたが、これは「SPSETはスプライトを表示させるための機能である」というのを初心者に分かりやすくするため発売直前に仕様変更をしたけどヘルプの修正が間に合わなかっただけだと推測されます。 エラーチェックが不十分だったというのはユーザーからしてみるとバグであり今回はそれを修正しただけに過ぎません。 例えばプチコン3号は「変数を宣言が必須となるBASIC」だと仮定（プチコン3号はOPTION STRICTで選択が可能ですがあくまで仮定の話です）した際に宣言無しでもエラーが出ない状態だったらどうでしょう？ 宣言無しでもエラーが出ないため宣言しない状態で使っていてエラーチェックを厳格にしてエラーが出るようになったらダメなんですかね？ これは例え話の部分以外は社長のツイートを元に書いています。

ゴミという表現が不適切なら撤回しますが、自力で修正する術を持たない使い手側にとって、動かなくなったプログラムがSDカードの容量を食うだけのお荷物でしかないことは間違いないでしょう。 当然ながら、私のプログラムも動かない期間の間はゴミ同然だったと捉えています。 修正の事情と経緯は私も認識していますので、改めてご説明頂く必要はありません。 ここで議論していたことは、もっと穏便にやれなかったのかという話です。 ヘルプの誤記や例え話に対して敢えて指摘するなら、そんな状態のままリリースするな（＝β版でもないのに）と私は言っています。

もうひとつお話しておくと、エラーチェックが不十分だったというのは方便だと私は考えています。 おそらく以前のバージョンでは、内部的にスプライトはすべて初期化された状態にあったのでしょう。 （理由としては、SPSETが表示を兼ねている仕様と同様、初心者が悩む要素を減らすためです） しかし、その状態では「空きがない」ので、「空きを検出」する機能を追加することもできない。 考慮の末、初代/mkIIと同様（こちらは私は知りませんが）、「SPSETするまではスプライトは未定義状態」とすることに「仕様変更」したのだというのが私の推測です。