勘違いして欲しく無いんですけど、丸コピした後にアレンジを加えて、アレンジ部分を強調するためにコピー元にした曲の名前を出すっていうのなら全然有りだと個人的には思ったりしてますん。 むしろ隠してない方が自分の判断で公開した責任はちゃんと被りますっていう姿勢が見て取れて、共感して擁護してくれる人が現れる可能性があるかも。 これはレトロゲームを元ネタにアレンジを加えたゲームを公開してる人にも言えると思うんですよね。 別に伏せ字にする必要は無いんじゃないかと。 タイトルを手がかりに調べればどういうゲームなのか分かりますし、評価したいと思った時により正確な評価をしてあげれるっていうメリットも生まれますし。

ある「目的」を達成するための「手段」のことを総じてツールと言ったりもしますな。 ツールにも色々な種類があったりしますけど、便利なものほど目的を達成するのが捗ったりするので 「急がば回れで」便利なツールを作る事が目的になったりもしますな。 また「大きな目的」が見つからない時とかに、とりあえず「小さな目的」がツール作成になったりもしますな。 よにまさんが目的を何に設定するかで変わって来ると思いますけど 道具（ツール）との付き合い方は、モノの作り方の方向性を大きく左右するので 早いうちに見極めしとくと後々迷わなくていいかもですね。 道具は使い倒してなんぼなので選り好みせず「使い方」に習熟して 付属の最低限のツールで何でもやっちゃうっていうのもアリかと。

何で丸コピだけで留まらずに公開までしたいんです？ 自分じゃあデータ作れない人から「ありがとう」とか言って欲しいんです？ 承認欲求を満たしたいんなら、もっと身近な人達との関係を大事にして困り事を察して力になってあげるようにしたらいいんじゃないです？ その方が本名や住んでる場所も分からない人にありがたがられるよりもっと充足すると思いますよ。

空気抵抗は考えない設定だと単純に、重心と、物体同士が衝突した点と重心からの方向の傾きによるベクトルが働く向きの計算が必要になるのかな？ 難しい難しい言うだけじゃなくてちゃんと考えてるんですね。 せいやさんのトピックに支援表明の報告入れておいた方がいいんじゃないです？

隙間問題ならSPDEFでスプライトのサイズを周囲１ドットずつ拡張して18×18で設定して使ってみたりしたらいいんじゃないです？ SPROTで回転させるとグラフィック画面上での周囲のドット情報も読み取られてるっぽい感じですし。

＞スーさん キムKENさんはプチコンWikiのことは既に知ってると思いますよ？ それに各人の見解をやりとりするのに最適なのはMiiverseの方じゃないんです？ キムKENさんの日記投稿なのにうぎゃ〜さんのコメントがまるで続きは他所でみたいな感じに見えたのでああいう風なコメント付けましたけど。 別に本人に高尚な意図なんてなくてもそう言う風に汲み取る人が居て話が転がっていけばひょうたんから駒みたくなったりしますし そういう風に前向きに捉えた方が面白いじゃないですか。謝る事なんて無いですよ。 で…、当たり判定に付いて誰か追加説明したいぞって人いません？ 個人的には当たり判定って重なり判定って言い換えてもいい様な気がするんですけど。

何気にお菓子を落として食べられなくなったりした経験って大事ですよね。 そういう時に「可哀相にねハイ新しいの」って簡単に与えられたりするとそれはそれで別の意味で可哀相かも。

白って全部のパラメータがMAXの色ですから基準に使うのに丁度いいとかなんですかね？ 色の数値に-1（整数型だと全部のビットが立ってる）を指定すると白ですし。 SPCOLOR命令やBGCOLOR命令を使う時も元の色のRGBの各数値が最大値で、○/255を掛け算したパーセンテージ表示になりますし。 掛け算じゃなくて足し算ならキャラクターの輪郭部分を残しつつ真っ白にしたりできるのに。

ふむぅ 上下左右の４つのポイントの情報をそれぞれ４つのビットに対応させて0~15の16パターンに分類して、予めBGキャラクターを連番で配置しておいて、パターン番号を基準になるBGキャラクター番号に足し算することで表示するBGキャラクターを決定してるんですね。 でも周りに配置されてるキャラクターとの関係性を見れないと分かり辛いので ２重のループを使うかして、点じゃなくて平面のデータにしなくちゃですよね。 配列を使うと範囲外エラーをどう回避するか悩みどころだったり。

＞うぎゃ〜さん 資料を提示して後はお勝手にってのは楽かもしれないですけど、一緒に考えるのって楽しくないんです？ 当たり判定についてもスーさんがザックリ端折ってるのはそう言う意図があっての事だと思うんですけど。 キムKENさんも遠慮しないで、知りたい事があるならもっと貪欲になった方がいいと思いますよ？ お行儀がいいだけのお人形さんって面白くもなんともないですし。

文字列のデータでステージ配置を記述するにしても、他の方法を使うにしても 必要になるのは「どのブロック」を「どの座標」の位置に配置するのか？っていう情報なんですな。 この場合「行」がY座標で「何文字目」っていうのがX座標に相当して 「文字キャラクター」がどのブロックかっていうことなんですな。 なのでスーさんの説明の補足なんですが、READ命令で読み込んだ文字列をY座標が同じ1ライン分のブロックのまとまりとして扱って MID$()命令とかの文字列操作系命令で1文字ずつ取り出して、X座標のどこにどのブロックを置くのかっていう情報を取り出してるんですな。 この仕組みさえ分かってしまえば別にDATA文を使わなくても、グラフィック画面からやDATファイルを配列に読み込んだりとかでも同じ事が出来たりするんですな。

壊せるブロックにナンバーが振ってあって、番号順に壊さないと扉の鍵が出現しなくて、アイテムを取りこぼすと徐々にブロックのナンバーが非表示になっていくゲーム みたいな？

＞HMFさん 理解できないんならコウランさんに分りやすく説明してくれるようお願いしてみたらいいんじゃないです？ コウランさんも自分でまだ気がついて無い核心部分を考えてみるいい切っ掛けになったりすると思いますし。 というかここまでで「消失点」「ズーム」「全く同じ位置の2Dと3Dでの比較画像」「自然対数」「計算の元にしてるのはXとYの座標情報だけ」というキーとなる情報が出てるので、それをヒントに色々調べてみるとかしてみればいいじゃないですか。 思考停止を伝えるだけのコメントされてもコウランさんも困っちゃうと思いますよ。 座標計算の処理がまとまればSPFUNK命令と合わせて色んな処理に組み込めるルーチン化できそうですね。

PRINT命令に使えるコンソール文字は、スプライトやBGの絵を持って来るのと同じ様な感じで、フォント用のグラフィック画面から文字コード（SPの定義番号やBGのキャラクター番号）に対応した絵をコピーして使ってるんですけど （PRINT CHR$(20363) で文字コード20363の「例」が表示されるみたいな） ひらがなやカタカナを漢字に変換するなら「読み」から該当する「漢字」への文字コードに変換する字引き的な処理が必要になると思いますよ。 ほしけんさんのツールの中身も多分そんな感じになってるかと。 別に文字コードを使わなくても表示したい文字を「"」でくくって文字列扱いにしてPRINT命令の引数にすればそのまま表示されるので システムフォルダの中の漢字一覧のテキストファイルを空いてるスロットにロードして、そこからコピペで持って来るのが一番簡単ですな。

ん？何で謝ってるんです？ 自分も似たような感じのプログラムを作ったことがあるので、面白そうだと思ってコメントしてるだけなんですけど 何か迷惑かけちゃったみたいですね…

立ちネコの歩行ドットだとこんな感じです？ もう少し猫背の方がそれっぽいかも。 ガントレットの手のひら側のSPもあると確かに使い勝手良さそうですね。

大まかな形を整えたいんならオートタイルのアルゴリズムを組み込んでみたらいいんじゃないです？

ここから元々の画像の色から同じ色をピックアップして、アウトラインを出してみたら 滑らかな線が出て来たりするんじゃないんです？ もしくは拡大した倍率と違う倍率で縮小して（例えば3倍に拡大したのを2分の１に縮小して）、更に同じ事を繰り返して少しずつ大きくしていったりしてみたら何か違ってくるかも。

ビット演算子を使えば出来るんじゃないです？ ANDやORやXORやNOTで四則演算をするような感じで。

遊びをどう捉えるかによると思いますけど、自分はプチコンもゲームだと思う派ですかね。 ゲームを作るゲームだと思えばルールは作る人そのものなので 自分探しゲームとでも言えなくもないかも。 年頃になるとよく自分探しの旅に出たいっていう気分になったりすることありますけど そういう人にはうってつけかも。 ツールとして見た場合もプログラム中で使いたい素材を作るツール→を作るツール→を作るツール…、あれ？何しようとしてたんだっけ？ みたいな脱線ゲームとして楽しめるかも。 序盤はエラーと戦う格闘ゲームですけど。