だいぶ初期にこっちで公開してた自作簡易ペイントで落書きー 黒板のらくがきなイメージ、本格化を目指すならかすれたり粉がちらついたりした方が良いけど、簡易だからな！(

本題、転送が安定できるようになったのでパソコンで描いた絵を投稿！

当たり前だけどミーバースのヘッダーにコメントのやつは設定できないのねｗ あんま大々的にするつもりはないので、こちらにひっそりと。

さらにひっそりとプチコン周りの進捗を呟いてみる。曲のストックはコード進行などの勉強して少しずつ増やしてます。あんま凝ったのは修正が大変で労力も見合わないので、なるべくシンプルに他のハードでも移植できるくらいのクオリティでいい。 プログラムのウデマエはというと、BGマップデータから自動的に壁判定を発生するアルゴリズムは作りましたが、圧縮する段階で投げました。 その辺はほとんど出来てるのですが、細かいところのUIは投げてしまうのです…その辺作れる人憧れる…！

作りたいゲームのアイデアはちょくちょくメモっているのですが、なるべく自動化できないかアルゴリズムの開発からやっちゃう人間なのでしてね… どっちかというとツールのような使い方を好んでいます。

圧縮解凍アルゴリズムは幾つかのパターンに分けてて、無圧縮、指定連番、座標軸固定、余りの4つ。 そしてイベントフラグも挿入、こちらは壁判定と別にして座標圧縮の方が良さそうな感じ、とりあえずメモ。 圧縮先は文字コードに封入してテキスト形式、バイナリファイルを極力減らしたいのが一番大きかっただ… 壁判定は階層判定を入れ、1階層のみ2階層ありで分けて行う方針。最も効率の良い連番圧縮にて。 イベントフラグは座標圧縮、2文字にして1文字座標、1文字イベントID。 こういった方針で行ってます！

圧縮はマップデータを封入はできる段階、UI周りで投げてる状態。 解凍はできてないってところです。 圧縮にもマップID、最大座標、音楽、イベントフラグの封入、レイヤー情報といったのも混ぜたいのもあって、互換性の怪しいバージョン違いができるのを危惧している感じになってます。 そんなに難しい問題でないのでその内解決しますが、戦闘周りとか全くできてないのもあります。 まともに公開できるゲームはまだまだ先なので、待っててくだしあ。

BGマップもパソコンで作れたら楽そうですが、そうはいかなさそう。 模索はしばらく続きそうです…！

BGMもわざわざ指定しなくても良いようにDEFで決めたBGM命令も作ってたりしてます。BGM 曲番,動作という感じに分かりやすく。 この辺も圧縮解凍マップデータと連携する前提で組み立てたので、こういうのも封入したい所存…！

因みにイベントフラグの封入は、デバッグモードでA押してから何かしらのイベントを置くみたいなの想定してます。すげえむずそう…こういうアルゴリズムも作らないと気が済まぬ。 最低限度会話フラグ、アイテム、移動の判定を入れると大体いけそう。 いちいち自動壁判定をぶち込んでも二度手間かもで例外も多いから、たぶんバイナリファイルでL4(4番目のレイヤー)に壁判定、L5以降にイベントフラグになるかも？ 一番楽なのはBGMAP編集から直接出力、map編集で壁判定を作ることかもしれないと思ってきた。 そうしようかな…？

いろいろつぶやいてみて、MAP編集そのものを改変する結論に至りました。頑張る( `･ω･´ )

自身の忘備録的で上のコメが埋もれそうなので再コメ、一番上のコメントはパソコンから転送させたペンタブ絵の画像になってます。 圧縮解凍する上で一番気をつけないといけないのはエンターコード、勝手に改行してしまうデメリットあり。 エンターコードはCHR(10)に相当。 普通に頻繁に使いそうな順番なのが厳しいところ。座標は余程の場合でない限り10,0にはいれないが… 「10個配置する」という命令を行うような連番圧縮は避けないといけない。 対策としては文字コードにダミーを仕込む、2^4で16以上の連番に対応させる。bit0には必ず1、bit1には空白判定といった形に工夫を考えてます！

10は&B1010だから、bit0を1にしておけばエンターコードは使われない簡単な仕組みは出来上がる。 が、画像データで10が使われる可能性もある。こっちの場合は禁止データにする方が効率的かも？

(そういやBGって1024周期で繰り返す仕組みになってたんだった) これなら2bit分を終始コード、10防止コードに振り分けても問題なさそう 繰り返すけど、座標0,10には何も置かないのが一番だ！ 改造BGマップで座標圧縮は0,10は反映しない仕様にしようかな。

バイナリデータの圧縮度あんま分かってないので、検証してきま

座標は縦長横長で変化する仕組みにしたら座標がどうなろうと問題無かったわ

10個配置する、の対策はBitを1ずらす、改行コードは10と13だから、それ以外の数を配置するしかない 10と13のbitは1010、1101だから、底を一つ増やすだけでは区別がつかなくなる しかし、bit15に追加するとデータが大きくなる…どうしたものか 底が0なら0を追加、1なら1を追加すると改行コードは防げるけど、それも割と手間だったり（CHR$でテキスト圧縮する） 計算速度が同等ならその手法にしたい感じかな、要検証だね

底がゼロ→AND 1で0が返されるなら1になる、うむむ flag = （配列）and 1 If flag then （配列）= （（配列）<<1）or 1ってことになるな もっと効率よくしたいね

フラグ付けは配列が13以下なら、の条件つけて、14以上は問答無用で0とかでも良さそう

問題点な場所はbit3まででbit4以上は何も問題ないわけだし

101（5）で0を追加されると1010（10）になる、110（6）で1を追加されると1101（13）になって、1010に0、1を追加しようとも問題ないから、条件式は6以下、というよりも基本0で、5のときだけは1を代入する形でいいか

これも鑑みると圧縮式は for i=0 to max f=0 if (配列)==5 then f=1 (配列) = ((配列)<<1) or f next の過程で十分だな、後は配列内の座標とか情報抜き出しとかそういうのを調整

MML支援ツールを作り終わった後は、圧縮式の解凍に手を出しますー しばらく放置してたし それとフーリエ変換も勉強したい

少なくともマップデータ→圧縮データとして、その圧縮データはゲーム内や自前のマップツールとかで解凍して使える感じにしておきたい 圧縮データの出力先はバイナリファイルの方が良いなって結論になってる…！

自前のマップツールの出力先はゲームの基本データなどを記録するDEFスロットとマップデータ、敵データって方針 翻訳はまた別の形