関数を作成するときに迷う・・・ ペン座標など起点からマイナス方向に行く場合とか GLOAD/Gsave関連の命令を絡める場合どっちで実装した方がいいのだろう？ また、マイナス方向に対応できるような座標スワップコーディング例を見てみたい。

私だったら大きさを意識して使うならば「起点x,起点y,幅w,高さh」、位置を意識して使うならば「起点Sx,起点Sy,終点Ex,終点Ey」としますね。 起点より終点の方が値が小さい場合はIFで判断して値をSWAPしてもいいし、MIN、MAX関数を用いてもいいと思います。 私がかなり前に作ったGBLEND関数は前者のような書式にしていますね。 https://miiverse.nintendo.net/posts/AYIHAAAEAAArVRTks7Xo1w 実はこれを使って2年半前にアルファチャンネル対応（加算、乗算、オーバーレイ等が自由に行えるもの）、レイヤー対応のお絵かきソフトを作ったものの速度が遅すぎてお蔵入りとなりました。（さすがに1桁fpsでは描いていてストレスが溜まるため） そのためjuhsyには期待をしています。

宗教みたいなものでどっちでもいいんだけど、 実際に使う分には幅の方が便利。 プチコン標準命令でも多くが幅採用してますね。 あのあたりのセンスは好きですね。 もっと言うとプチコンの場合は x,y より y,x の方が合理的でもあるんだけど、これを一貫して使うのはなかなか難しくて、x,y と y,x が混在するとかえってまぎらわしい←まぎらわしくなっちゃった人

マイナス方向へのドラッグへの対応ですが、ハトさんのエディタでマップチップを範囲選択するときは、タッチ開始座標がSX,SY、タッチ終了座標がEX,EYだとすると X1=MIN(SX,EX):Y1=MIN(SY,EY) X2=MAX(SX,EX):Y2=MAX(SY,EY) として、左上座標X1,Y1、右下座標X2,Y2に変換しております(*´▽｀*)

あ、おちゃめさんが既に書かれておりました（*ﾉﾉ）ｲﾔﾝ

徹底してくれればどちらでも良いけれど、趣味で言うとW,Hの方ですかね。 プチコンはもうちょっと徹底して欲しい。GCLIPとかGCOPYとか……GLINEはしょうがないかなぁ。グラフィック系は座標？って思ったらGLOAD/GSAVEは違うという。多分配列が絡むからでしょうけど。 というわけでプチコンもそこそこ曖昧なんで、あんまり気にせず作っちゃえばよいかと:p スワップはMIN/MAXでやるより素直にIF X2<X1 THEN SWAP X1,X2 …が速かったような記憶です。大体ループ外で処理するから高速化の対象外ですけどね。

W,Hがいいなと思ったら大体みんなそうだったみたい

絶対座標＋相対座標なのか、絶対座標＋絶対座標なのかの違いはあるので、 最初に点を決めてどのくらいの量を指定する場合はW,Hで、２つ点を決めるなら S,E なのかなというのも。 ペンで四角を引くなら、開始位置と終了位置がどちらもタッチパネルの絶対座標なのでS,Eのほうが書きやすいけど、 タイルパターンをカーソルで開始位置を選択して、終了位置まで移動して決定するなら開始位置とマイナスあり移動距離なW.H指定というのも。 画像関連だと画像データで幅と高さを扱うので W,H指定のほうがやりやすい感じです。 （保存するときに始点絶対座標から保存したい幅高さを加算して終点絶対座標を求める流れが多いはず）

皆様回答ありがとうございます お絵描きソフトjuhsyはフリーハンドの操作主体のため ペンの座標はsxsyexeyで、その直後の描画合成反映にsywhを使うことが多く データの受け渡しに混乱が生じてましたので質問させていただきました。 クリッピングを含めると起点終点->whサイズへの変換関数を作ったほうが便利ということがわかり現在作成中です。

プチコンだと結果的にタッチパネルの座標とスクリーン座標が同じなのでわかりづらくなるけど、 いちおう「タッチパネルから取得した座標」と「自作ソフトの画像データ操作の座標」と「画像を書くためのスクリーン座標」は別の世界というのが考え方です。（スクリーンもGOFSしたらタッチパネルとは位置が違う） 座標系が同じところがあるので、絶対座標でなんやかんやしたほうがコード量少なくなったり処理軽くできるというのがBASIC世界だけど、どこで考え方が別世界になっているかも意識すると楽しくなります。 ※相対座標と絶対座標の変換処理が早い遅いは、どうせ１回のタッチ処理で１回しか実行しないならそこまで速さ影響しないので、連続で何度も実行するならというのも。（人間がペンをタッチ・動かす・離す速度のほうが時間がかかるので）