なにも３号ばかりではなくて従来のｍｋIIを拡張してほしいの (;^_^A
１）関数の定義
２）カナ文字入力
３）ファイルアクセスの確認
４）モジュール
５）ポリゴン
６）ＳＤカードへのアクセス（無理は承知）
７）高速メモリアクセス（需要はあるのか）
１）関数の定義
ブロック構造を持たないＢＡＳＩＣ言語では無意味に横長になる。
これを抑えようとするとトリッキーな事を行う。
挙句の果てにＧＯＴＯ文でグチャグチャになる。
悪循環です。
画面が小さいので
ＰＡＳＣＡＬ言語の様な
begin
end
で無駄に２行消費したくないし、
Ｃ言語の様な
｛
｛
｝
｝
括弧が蔓延するとカッコアレルギーに陥る
Ｃを初めたとき憂鬱でした… (((( ;°Д°))))
本題に戻して
ＶＢＡ風の関数自作がよいと思います
N-BASICには人気がなかったけど FN関数 ってのがあった (すこし便利)
FUNCTION SPLIT(STR$,N),F$,B$ 'ここで宣言したらローカル変数
LOCAL A '演算用ローカル変数宣言
A=N+1
F$=MID$(STR$,1,N)
B$=MID$(STR$,A,999)
RETURN
FUNCTION END
呼び出しは
SPLIT("ABCDEF",3),F$,B$
PRINT F$,B$
実行結果は
ABC DEF
文字列"ABCDEF"を３文字目で分割して各変数に代入する例です｡
自作関数が簡単に作れると曜日計算(ツェラーの公式))や経過日数(グレゴリウス暦)等の
面倒な計算式をリスト中に並べなくてすむのでスッキリします｡
もちろんプチコンならスプライトとBGの当たり判定も簡単に表現できます
BGHIT ( スプライト番号 ）, BGレイヤ ,BG x座標 ,BG y座標
なんて作れば スプライトと衝突しているBGが簡単にわかるので
ゲーム作成がカナリ楽になると思います。
BGHITは良い例ではありませんが、こんな感じって思ってもらえれば程度です（矛盾満載です）
Ｃ言語の様な面倒な宣言もなく手軽に使えるのでは？
プチコンでも TMREAD文 で行ってるので無謀ではない。
グローバル変数の扱いは参照だけに縛ります。
下手に代入できるとバグの温床になるので…
これなら初心者にも扱い易いと思う。
短縮するために論理演算やビット演算を多用するより遥かに解りやすくて素敵
(*⌒∇⌒*)
２）カナ文字入力
別にローマ字入力したいと言ってるわけではなくって
下図のように赤い線を入れてもらうだけで物凄く入力が楽になります。
もしくは母音を赤色にするだけで大変助かります。
文字を探すのが大変なんです (ﾉ_･｡)
ケメロ配列（難解）でなかったことに感謝しています
３）ファイルアクセスの確認
保存する度に確認するのはセキュリティ問題で分るんですが
１回承認すれはプログラム実行中は２回目以降無効にするオプションが欲しい
ＬＯＡＤ命令にはあります
所詮、頻繁に承認画面が出たら警告文を読まずに押しまくるので無意味です。
ＭＥＭ＄より融通が効く巨大ファイルが…データベースソフトが…人工知能が…
辞書学習が…漢字表示を行うと一気に実行時のリソース不足解消が…（これに関しては打開策はあるけど）
４）モジュール
サブルーチンが貯まってくるとアペンド機能で連結するのがシンドイ。
通常マージ機能（アペンド）が装備されている場合デリート機能が対であるはずなんですが…
プチコンのDELETE文ではなく DELETE 10-100 と入力すると 行番号10-100が削除されます
数行なら手動で削除するが
500行削除するのに気を失う…そして消しすぎる…UNDOない…(ノ◇≦。)
・ある程度サブルーチンができたら、パッケージとして配布、活用が期待できる
・メンテナンスが楽になる
・9999行の縛りがなくなる（メモリが許す限り制約なし：でもMAX 65536行）
結局、複数のファイルを扱うことになるので先の自作関数とローカル変数をクリアしないと
ダメなんですが…他にもプチコン自体の大規模な設計変更が必要と思われます…
５）ポリゴン
スーファミでＦＸチップ搭載したスターフォックスみたいな感じで表現できたら満足。
Ｎ６４レベルになるとプチコン上でモデリングは至難の業だし、
モデリングできなきゃ～意味ない。無用の長物です。
ＡＭＩＧＡが三角形ポリゴンをハードで描写してたように空間の三点を指定すれば
勝手にポリゴンを表示する。さらに、座標指定はX,Y,Zをパラメーターで指定して
立体的な映像が表現できる。カメラアングルやポリゴン群の回転が指定できると素晴らしい
もちろん行列演算の関数を装備してね。（ＭＡＴ：PC-8001でアスキーから出てたな～）
ハードウエア仕様に直結するのでよくわかんないけど、スーファミ時代の仕様だから
ＤＳに搭載されてないはずはないと思う。
（ＡＰＩ叩くだけと、勝手に想像：ＤＳソフト１本しか持ってないのでよく解らな～い）
労せずともマリオカートが作れてしまう…
６）ＳＤカードへのアクセス
ＤＳｉウェアなのでブロック内のみのアクセス縛りだと思うけど…、
せめてプチコンリソースの読み込みだけでも許してくれないかな～
７）高速メモリアクセス
三次元処理を行ったとき速度が欲しかったんで配列変数にテーブルを作ったんですが、
全く速くならんかった…。厳密に測るとＳＩＮ関数の方が速いんです。
昔の常識が現在のＣＰＵパワーが追い越したことを実感しました。
グラフィックの処理を行うのにワークエリアとしてＧＲＰリソースを使うんですが、
これが思ってたより遅いんです。
ビットマップをやり繰りしてるから遅くなるのは解るんですが、仮想メモリを直接高速に
アクセスする方法は無理なんでしょうか？
仮想メモリ限定のＰＯＫＥ、ＰＥＥＫ、ブロック転送、論理演算等々の高速関数…
１）～３）は以前から思ってたことで、差ほど無理難題だとは思えない。
それ以外は有ったらいいな的希望
ポリゴンに関しては３ＤＳならＧＰＵを搭載してるんでモット高度な事が出来るんだろーなー
開発が３号にシフトしてるんで夢物語なんですが、３号で解消されていることを祈ります