異次元ワープロ2号機

他のブログに当てはまらない「その他」カテゴリ用ブログです。

独自圧縮フォーマット（ADE:ArrayDictionaryEncode）に関するメモ

メモ

説明は飛ばして、バリエーションを一通りまとめるだけ。
具体的な仕様はプログラムが全て（いつものやつ）

用語

分割数：配列1要素（32bit）をいくつに区切って使うかの数
塊：配列1要素を指定した分割数で区切った値1個のこと。4分割ならちょうど1byteになる
追加圧縮：ADEの別名。もとはSRD画像フォーマットの一部なのでそう呼んでいたが、後にADE単独で使うようにもなった
バージョン値：『SRD画像圧縮ライブラリ』のwiki記事を参照。&h23→&h20という変な順番なのは、ASCII文字として解釈した時それぞれ『#』、スペースになる値を付けたから

初期版ADE（バージョン値：&h23）

参照が成立しない値をそれぞれ1塊として記録していたので、ランダムに近いデータはとても肥大する。

NEW_ADE（バージョン値：&h20）

初期版から「参照が成立しない値」が連続した数を記録するように変えたため、ランダムに近いデータがほとんど肥大しなくなった。
『SRD画像圧縮ライブラリ』の2022/06/01の更新記録にある「PackBits的なロジックを加える」というのはこの変更のこと。
細かいことをいうと2バージョン存在する（参考：2022/06/10の更新記録）

ADC

手元には存在するが非公開の模様。
NEW_ADEとの違いは参照不成立連続数の表現が違う（参照成立時の参照位置が常に1塊の代わりに、0,連続数の2塊で記録）ことらしい。
おそらくNEW_ADEと比べて圧縮率の差が少ない以前に、デコーダのバグを発見できず修正ができなかったので没になった。

XADE

NEW_ADEデコーダをJavaScriptへ移植するにあたり、計算過程で出る値が必ず非負になるようにビット演算を乗除算に変更したもの。
ついでに、2の冪でない分割数*1を指定できるよう手を加えて実験したものの、圧縮率がほとんど優れていないのでこの変更点は没になった。
分割数が2の冪であるときの圧縮データはNEW_ADEと全く同じ。


ところで、初期の頃は月に複数回規格が変わるような有様なので、おちおち使えない感じでしたね。
今はめったに改定しないので安心して使えますね（？）

更新（大きな変更のみ）

  • 4/10…ADCとXADEの制作経緯がほとんど嘘なことが分かったので修正。

*1:この場合、プログラムの簡略化のため端数のbitは使わない（たとえば3分割だと10bit×3ごとに、あまりの2bitは未使用）

ATAMA_EXPLORERで使っている独自符号化の解説

メモ

確か、プチコン3号まとめwikiに掲載した記憶があるのだが
アーカイブをいくら探しても見つからないので、今後のアップデートで追加する符号種類を含めて軽くまとめておく

現在の最新の規格は2026-01-20に発効したバージョン『3.5(2026.1)』です

符号の種類

AC…ASCII Character

名前のまま。U+0000からU+007Fまでの文字は、シンプルに1オクテットで符号化する。
ただし、ETC・TTC・RLCで符号化できる文字列は、ACとして符号化してはならない。

NAC…Non ASCII Character

これも名前のまま。U+0080以降かつETC・TTC・RLCで符号化できない文字を符号化する。3オクテット。
当然のことながら、ACで符号化できる文字は、NACとして符号化してはならない。

ETC…Extra Token Character

特徴的な符号の種類で、プチコンのプログラムによく出現する"DIALOG"や"DISPLAY"などの単語を1文字であるかのように符号化することで、圧縮効果を発揮する。2オクテット。
頻出する英単語のほか、ひらがな・カタカナ*1と句読点も含まれる。

TTC…Triple-1 Token Character【バージョン3.5(2026.1)で追加】

ETC同様、頻出する単語を1文字のように表現するが、元が2文字の"IF"などがETCでは圧縮できないため効率向上を意図して作られた符号の種類。ETCの空き符号に無理やりねじ込んで1オクテットで符号化する。
名前は、2進数で表記した時に左の3桁が1になることに由来する。

変更履歴（符号の種類について）

2026-01-15

  • エンコード処理に課題*2があるため、RLCを追加する時期を未定に変更。

2026-01-20

  • RLC（Run-Length Character）を完全に規格から削除した。

勝手にFAQ

独自符号全体に名前は無いのですか？

初期から存在した符号の種類の頭を取って"ANETコード"という名前を考えているが、同じ読みの単語が既に存在するため正式には「名前がない」状態
プログラム名の一部を冠した『AT-ANETコード』を正式な名前に決定。

*1:このうち、半濁音とや行を除いた小文字を含んでいない

*2:たとえばETC定義済みの"BUTTON"という文字列が、BUT(2回繰返し)ONと表現できてしまうなど

プチコン3号用OSMレンダラもどきの開発を緩くまとめる

この記事は『OpenStreetMap - Qiita Advent Calendar 2025 - Qiita』の14日目の記事です

前提：プチコン3号とは

公式サイトを見る方が早いので（投げやり）
一言でいえば3DS用のプログラム開発環境（とても合法*1）です
smilebasic.com

4月 - 6月

4月30日。プチコン作品でおそらく*2初めて、osmファイルからウェイとノードの座標を取り出して地物の輪郭を表示した

若葉駅東口付近
座標の解釈に誤りがあるので、実は鏡映し（左右反転になっている）
Map data © OpenStreetMap contributors | Copyright and License | OpenStreetMap

※以下の各スクリーンショットは同ライセンスの地図データによる

なんやかんやありまして（開発中のつぶやきのツリー）

こんな感じになりました

6月6日に「SVG EDITOR」ver.1.0として公開
petitcom.mitsutan.dev

12月 - 記事投稿

6月時点では地物の表示だけで満足していたが、どうせなら表示だけじゃなくてマッピング機能を付けようという機運が出てきたので開発を再開

まずはPOIをマークで表示し、選択すると何であるかを確認できる機能を実装

画面座標から経緯度へ換算する式をあり得ない方法で求めながら（開発中のつぶやきのツリー）

タッチした座標に新しいPOIを作成する機能を実装

詳細の入力は、3DSという端末でやるにはヘビー*3なので、よくあるブランドをプリセットから選ぶ形にしました

コンビニ、スーパー、飲食店に加えて自動販売機のプリセットを作りました

ただし、これは手元のOSMファイルに書き込むだけの機能。プチコンの制約*4のため、OSMのサーバーにデータをアップロードすることはできない
そこで、変更点をLevel0L形式*5に整え、二次元コードとして表示。それをスマートフォンなどの他端末で読み取る、という少し面倒なやり方でサーバーへのアップロードを実装する予定です（記事投稿時点で、Level0L出力の手前まで実装完了）

実際のアップロードができたら、新しい記事で続報を書く…かもしれない

*1:カスタムファームウェアみたいなことをしないでいいので自信をもって他人と話題にできる

*2:日本語圏以外の情報は一部しか把握できていないので、海外に先駆者がいる可能性は否定できない

*3:処理能力的な問題ではなく、プチコンではまず日本語入力自体を自作・搭載する必要があり、プログラムの肥大に繋がるため

*4:任天堂機という環境の都合上、インターネットへのアクセスは専用の作品共有サーバーを除き不可能

*5:おそらくosc形式でも可能だが、先に知っていたのがl0lなのでそうした

来歴から今年の出来事までゆるく書いてみる

この記事は、Fediverse Advent Calendar 2025の3日目の記事です。
のえるさんのFediverseアドカレに書くのは2回目ですが、昨年は自分のFediverse来歴を書いていなかったので軽く書いておきます。
Fediverseに初めて来た日：2018年6月11日
Misskey系サーバーに初めて登録した日：2023年3月30日
今までに登録したサーバーは7個あり、サービス終了したものを除く5個*1はアカウントが現存しています。

長いこと、マストドン系が良いと考えていましたが、いまはMisskey系も良いなぁ*2と思っています。

今までに寄付したもの

1つのソフトウェアやサーバーより、全部を応援したほうがいいという考えもあり単発または短期間でいろいろなところにしています。
今年はお財布の余裕が無いのでできませんでしたが、来年はまたいくらかする見込みです。

今年の注目の出来事

signalskey.signal-st.com
信号機愛好家向けのテーマサーバーが今年3月、生まれました。
今のところアカウントは作っていませんが、地理という大きなジャンルでつながっているところに新しいサーバーができたのは、うれしい出来事です。

逆に、残念ながら終わってしまうものでいうと、『Mastodon Japan Server』の閉鎖が発表されましたね。
上記の通り寄付をしたところでもあるのですが、管理人さんが多忙で運営に時間が割けないというのはどうにもならないものです。いままでお疲れ様でした。

大発見？

misskey.io
しゅいろママに話しかけた最古の記録を発掘する。Misskeyが開発されるより前から知っていたという運命！
（余談ですが、ioにはノート埋め込みの機能がまだないのですね）

*1:ioのピン止めノートに列挙しているので省略

*2:絵文字リアクションの存在が大きいので、バニラのマストドンを普段使いすることはないかも

プチコン界隈がなかなかFediverseに来ない件

この記事は、Fediverse Advent Calendar 2024の2日目の記事です。

プチコンとは…
任天堂のゲーム機向けに発売されているBASICプログラミング環境
DSiウェアの初代「プチコン」（2011年）に始まり、現在販売されているのはSwitch用の「プチコン4」

本文中の「Fediverse」は基本的に狭義（≒ActivityPubで繋がっている世界）で用いている。

来ない人はどんな感じなのか

正確には1.の人は2.から4.のいずれかにも当てはまる

  1. 2019年以前の「初期」のマストドン・Misskeyブームでアカウントを作ったものの放置し、X（当時はTwitter）に戻った人*1
  2. Xの利用に抵抗があり移行先を求めているが、Blueskyを本命視している人
  3. 同、他の新興SNSを本命視している人
  4. そもそもXを利用することに問題を感じておらず、他のSNSに関心がない人

2.の場合、ブリッジを有効にすれば交流できる範囲内なので、それを周知していきたい
3.の場合、そのSNSに長所があると見込んで移住するのであれば仕方ない

問題は、4.の場合。

なぜ、主に利用するSNSをXにすることが適していると思われているか

  1. よく言われる凍結の影響を受けない（凍結を食らう人の多くはR-18な絵などを投稿する人で、それを扱わない人なら食らう確率が低い）
  2. 制作会社（スマイルブーム）の社長がXを利用しており、リプライなどで質問をするのに便利
  3. Switchや3DSからスクリーンショットを直接アップロードできるというメリットが「あった」（現在はSwitchのスクリーンショット投稿機能投稿先からXは削除され、3DSに関しては画像投稿ツールそのものがサービス終了している）
  4. Xを使い慣れており、不安定な事情を考慮しても新しい場所に移るのは見合わないと思っている

プチコンユーザーがFediverseを選ぶ利点など

  1. 公開範囲が投稿ごとに選択できるため、作品を告知するときはパブリック（公開）、ネタバレを防ぎたい制作中の様子や、広く見せるつもりがないプライベートな話はフォロワー限定にする、という活用ができる
  2. 分散型で、現に多くのサーバーが連合している*2こと。ユーザーがFediverseに集約されれば作品の告知を複数の場所に投稿する必要がなくなる
  3. Misskeyに関して、クライアントの一つに3DS（を含む古いブラウザー）に対応した「Citraskey」があり、スクリーンショット掲載に便利*3
    1. Misskey系以外でもXのようにAPIが閉鎖的ではないため同等のツールが生まれる余地がある
  4. （利点というほどではないが、縁の一つとして）Misskeyの開発者であるしゅいろママ*4はプチコンを経験している

Switchのスクリーンショット投稿機能がFediverse内のSNSに対応することはないのか


という声を見かけました。
確かにFacebookと運営会社が同じThreadsは、他のSNSよりは期待が持てそうです。実現すればプチコン界隈の標準SNSと言えるところまで来るかもしれません。
しかし残念なことに、今のところ対応SNSを追加する動きは見られません。（要望の声が多くなれば動くのでしょうか）

まとめ（るつもりだった）

いい総括を思いつきませんでした。とにかく1人でも多く来てほしい、それに尽きます。
なにより「作品をいろいろな人に見てほしい」といった使い方なら、連合ができないSNSに籠るのはもったいない、という気持ち。

*1:名前は挙げないが、傾向として古参ユーザー（初代からプチコンに触れている、プチコン以前にプログラミング経験のある人）が多い

*2:単に分類上「分散型」であればBlueskyも同じだが、主要サーバだけでMisskey系のio、マストドン系のmstdn.jpやpawooなどがあり、加えて数百もの個人・小規模サーバーが繋がっているのはAT Protocol圏と大きく異なる

*3:Switchの場合、内蔵ブラウザー機能がアクセスできるサイトを制限しているため、素直に使うことはできない

*4:氏を付けるのは硬い気がするのでこう表記している

自作カスタム絵文字のライセンスについての再周知

SNS

2023年にMisskeyサーバー「のえすきー」*1に登録しました6個のカスタム絵文字（埋め込み投稿を参照）については、ActivityPub対応のSNSのカスタム絵文字として自由にインポートしていただいて構いません

*1:当該サーバでのハンドルネームは「御子神ニャオハ」ですが、idは他のサーバと同じShionAmasatoです

分散型SNS（主にActivityPub）に関するメモ書き

SNS メモ

※定番のいつの間にか中身が増える記事です

この記事は使い方の解説や初めてのアカウント作成する人向けではありません。
そのような良い記事はたくさんありますので一読することを勧めます。ごく一部を紹介します。
note.com

略語

AP…ActivityPub（マストドンやmisskeyなどが使っているSNS間の通信規格です。これが同じなら違う名前のサービスでも繋がれます）
ATP…AT Protocol（Blueskyの通信規格です。APとは別なので直接繋がることはできませんが「ブリッジ」というものを使うと交流できます）

LTL…ローカルタイムラインの略です。一言では説明が難しいので、冒頭で紹介している記事をおすすめします。
BT,RN…ブースト,リノートの略です。両方ともかつてのTwitterでいう「リツイート」の機能です。

略語以外の用語

連合

異なるサーバー間の繋がりを指します。
つまり、Misskeyにある「連合なし」投稿は異なるサーバーと繋がらない＝同じサーバーの人しか見られない投稿です。
そのほか、マストドン系では「連合タイムライン」という表記に現れていますが、最近のバージョンでは言い回しが変わっています。

フォーク

「派生」という意味合いで、あるソフトウェアから分岐して開発されているソフトウェアです。ちょっと機能が追加されている物から、だいぶ使い勝手が違う物まで幅があります。
例えば、マストドンのフォークには「kmyblue」や「Fedibird」があります。特にFedibirdはLTLを意図的に無効化していて「だいぶ使い勝手が違う」部類に入ると思います。

ブリッジ

異なる通信規格間の「変換サービスのようなもの」です。より正確には「別の通信規格の身代わりを作り、投稿やフォローや削除などの行動が自動的にコピーされる」サービスです。少数の「お行儀が悪い」例*1を除けばオプトイン（能動的に登録しなければ無効）です。
具体的なサービスの例として「Bridgy Fed」などがあります。

なお、複数のブリッジに登録することは、当然「身代わり」が複数できることになりますのであまり勧めません。

絵文字リアクション

しばしば「スタンプ」と間違われます。これに対応したソフトウェアはmisskeyが有名ですが、フォークの説明で触れたkmyblueやFedibirdでも使うことができます。
なお、絵文字には『👍』などのUnicode絵文字と『偉業』などのカスタム絵文字があります。
Unicode絵文字は（絵文字リアクションに対応した）どこのサーバーでも付けることができますが、カスタム絵文字は基本的*2にそのサーバーに登録されている物しか使うことができません。
そのため、好みに合う絵文字があることもサーバー選びのポイントになります。
また、サーバーによっては自作したカスタム絵文字を登録すること*3ができます。

小ネタ

自分の過去記事

ij-wordprocessor-2nd.hatenablog.jp
タイトルで「プチコンユーザー」と書いていますが、同じ趣味の人を探す方法を紹介した記事です。

*1:Xの投稿を断りなくコピーするbird.makeupというものがありました

*2:Fedibirdなど一部のソフトウェアは、他サーバーから付けられたリアクションに「相乗り」することができます

*3:例えば、有名サーバーの1つ「Misskey.io」では一定額の支援（寄付）をしている人に申請する権利が与えられます