2D RPG 制作ツールを作ろうぜ（＾～＾）？
📅 2023-06-25 はじめに
「 ２Ｄ ＲＰＧ 制作ツールを作ろうぜ？」
「 なんで お父んが そんなこと しなければならないのか？
働けだぜ」
「 思いついたら やるんでしょ。
そこらへんの 凡人と同じよ」
「 👇 それより 作業用ＢＧＭ かけようぜ？ 気分を盛り上げないとな」
💿 Rockman ロックマン 11 [OST] Full Album
「 それは作業用ＢＧＭではなく、違法アップロード動画なのでは？」
「 👆 サイドＰＣを Ubuntu に差し替えたんで Steam を久しぶりに動かしてみたら、動いたんで驚いたぜ」
「 えっ？ ＲＰＧ制作ツールを作るのに 作業用ＢＧＭが ロックマン１１ でいいのかだぜ？？」
MAUI を調べろだぜ
「 👇 企画と アーキテクチャーを 長々と 説明しても あれなんで……
MAUI を調べようぜ？」
📖 .NET MAUI (環境構築からHallo, World!～Windowsアプリ編～)
「 プラン全部 飛ばしたな。もう作業か」
「 あんたのお父ん ノー・プランよ。
ウォーター・フォール・モデルの下流工程の 実装 という狭い範囲でしか仕事できないんだから。
あと 事務と経理」
「 それって 羨ましがられるらしいぜ。 いーな、コードばかりやってて、と」
「 なんか 知らん間に Windows の 開発者モード というのが オフ にされているらしく、
これを オン にして ビルド」
「 👆 これが MAUI を実行した画面か～。 なんなんだろうな これ？」
「 何も分からん。 ロードマップもない」
「 Click me を押したら ボタンを押した回数が出てくるぜ」
「 こっから ツールを組み立てていくの、気が遠くなるわね～」
「 タイトル画面なんか作らずに メニューがさっさと出てきたら 良くね？」
「 お父んがよく選ぶのは 家系二郎ラーメン、 塩ラーメン、 レモンサワー」
「 今日は ネギ・ラーメン にしようぜ？」
「 メニューって、そのメニューなの？」
「 👆 リポジトリ―は 作っておいたぜ」
「 ネギ・ラーメンは リポジトリ―の名前じゃなくない？」
使用フォント： 📖 たぬき油性マジック
「 👆 こんな感じの ファースト・ビュー でどうだぜ？」
「 縦スクロール・バーは 付けておいてくれだぜ」
「 いいのか よくないのか 分かんないから さっさと作って 動かしてみましょう！」
「 👇 アラートが出てきたぜ。ここ読めだって」
「 わたしが やりたいことを 説明してくれるのではなく、
マイクロソフトが 説明したいことを 説明してくるので つらいぜ」
「 画面にボタンを置きなさいよ」
「 👇 どこを読めばいいのか 分からない、ドキュメントとの戦いだぜ」
「 👆 様々な概念が分からなかったが作った、とりあえず これで」
「 じゃあ とりあえず マップを作る画面に進みなさいよ」
「 ？？」
「 画面遷移って どうやって やるんだ……？？」
「 👇 これでも読めだぜ」
「 うーん？」
「 👆 AppShell.xml というのを 何か設定しないといけない？」
「 👆 とりあえず 画面遷移は できたぜ」
「 どうやって ＨＯＭＥに戻るんだぜ？」
「 パンくずリスト が有ったらいいんじゃない？」
「 👇 パンくずリストのような機能は用意されているのではなく、自力で作らないといけないらしいぜ」
📖 .NET Maui Tabs with Breadcrumb Navigation
「 👆 作り方 分からんので とりあえず ボタンとラベルで」
「 じゃあ次は 戦闘を作る画面に進みなさいよ」
「 👆 同様だぜ」
「 じゃあ 残りも 以下同様で やってくれだぜ」
「 つら」
「 👆 .xaml ファイル増えてきて 邪魔なんだけど、置き場フォルダーは どう作るのが ベストプラクティス なんだぜ？」
「 👇 調べろだぜ」
「 👇 Qiita の素人記事読むぐらいだったら 公式読むぜ」
📖 Microsoft ＞ Upgrade your app with MVVM concepts
「 👆 こうすりゃいいのか」
「 MainPage.xaml も 📂 Views フォルダーに入れろだぜ」
エクスプローラーが要るんじゃないか？
「 お父ん。
プレイヤー・キャラクター編集画面に入る前に、
どのプレイヤー・キャラクターを編集するのか 選択する画面が 要るんじゃないか？」
「 あっ、そうか！
ほとんどの データ編集ページで リストが要るぜ！」
「 リストでいいの？
テーブルじゃなくて いいの？」
「 じゃあ エクスプローラー だ。
MAUI にそんなコントロール あるかな？」
「 👇 お父ん。コレクション・ビューと、テーブル・ビューを調べてみてくれだぜ」
「 だから 素人が書いた記事なんか 読まねーっつーの」
「 👆 なんか知らんが ListView より かっこいいのが CollectionView らしいぜ」
「 考えるの止めるの わらう」
「 👆 コレクション・ビューを使うべきか、テーブル・ビューを使うべきの判断方法が分からん」
「 ページネーション（Pagination；ページ割り）の機能は付いているのかだぜ？」
「 調べたいことが 出てこないのが マイクロソフトの ドキュメントなんだぜ」
「 マイクロソフトの Bing の人工知能に利いても MAUI がなんだか分かってないし」
「 じゃあ、ページネーションも 自力実装することにしよう」
「 そうであるなら、クリテリア（Criteria；判断基準）が必要だぜ。
どのような規則に従って整列しているか、
表示されているデータは 何件目～何件目までのデータか、
表示されているのは 何ページ目か、
昇順か逆順か、
フィルタリングされているか」
「 無いものを 自力実装するのが プログラマーだぜ。
必要だったら 片っ端から 実装していけばいいんだぜ」
「 迷ったら テーブル・ビューと コレクション・ビューの両方実装すりゃいいのよ」
「 ぬぎぎぎぎ！」
「 👆 こういう風に 途中に 検索ページを１枚 挟めばいいんだろ？」
「 デザインを分かってないエンジニアが作りがちな検索画面だぜ」
「 ぬぎぎぎぎ！」
「 動いているところを見ないと よく分かんないから、
明日は 動くところを作ってみましょう」
「 ライセンスが オープンソースの ２Ｄ ＲＰＧの素材 なんも 持ってねー ぬぎぎぎぎぎ！」
「 あっ！ ゲームとして利用するならフリーだが、素材集を ツールに同梱して そのまま再配布することを許可している素材が無いのか！」
「 当然よねえ」
Unity プロジェクトを作ろうぜ？
「 まあ 無いものは無いで 変数ｘ とでも置いておいて 解けるところから先に解くのが 数学だぜ」
「 それを問題の先送りと言う」
「 👆 テンプレートは ２D を選び、プロジェクト名は Negiramen Practice にして
プロジェクトを作成しようぜ？」
「 ネギラーメンでは、それが何だか 分かんなくない？
検索のサジェスチョンも汚すし」
「 聞き慣れてくれば イカしてくるぜ」
「 なんか最初から いろんなものが入っている……、ちょっと見てみるか……」
「 👆 多分 エディターなんだと思うんだが、この１つ１つを調べて行くか」
「 👇 お父んが作らなくても、すでに いいものがあるのでは？」
「 オープンソースだけで やりたいぜ」
「 👆 ちょっと ボタンを追加しよう」
「 👇 それで……、テキスト・ボックスって どうやって作るんだ？ 調べるか……」
「 Entry というタグがあるのか」
「 👆 それで こういうページ作るだろ。
ディレクトリー・パスを入れて ボタンを押すと……」
「 👆 Unity プロジェクトへ フォルダーや ファイルを送り付けるという算段だぜ」
「 Unity の外部で ゲーム・オブジェクトを作れるの？
Unity の外部で プレファブは作れるの？」
「 Unity に そういう ＡＰＩ があるか？ ということだな。
調べてみようぜ？」
「 そんなことを しようという人が少ないのか 記事が見当たらないな」
設定の保存を作れだぜ
「 毎回 📂 Assets フォルダーへのパスを入れるのが 面倒なんだけど？」
「 ユーザー・データとして保存したいよな。
最近流行りのファイル形式は何だぜ？」
「 👇 TOML 1.0 はどうだぜ？」
「 👇 Tomlyn を NuGET で入れてみるか」
📖 Tomlyn
MVVM
「 あれっ？」
「 このテキスト・ボックスの初期値って どうやって 入れるんだぜ？」
「 👇 お父んが さっき読んでいた記事に書いてあるだろ。 MVVM のところを読み直せだぜ」
📖 Microsoft ＞ Upgrade your app with MVVM concepts
「 👆 とりあえず 📂 Views 、 📂 ViewModels 、 📂 Models の３フォルダーを揃えよう」
「 👆 なんだか分からないが Model は ただのオブジェクトだろ。イミュータブルに作ったった」
「 👇 ViewModel は なんか複雑だな 説明を よく読も」
「 👆 ViewModel は Model と 変更通知プロパティ を紐づければいいんだろ？」
「 ビュー・モデルのデフォルト・コンストラクターは public 修飾にする必要があるぜ」
「 👆 View は ここまで書き足したぜ」
「 ボタンは コマンドで書き直す必要があるんじゃない？」
「 👆 ViewModel に コマンドを取り付け。
ビュー・モデルは MVVMアーキテクチャーの中で 雑用とか、アシスタント・ディレクターの役割を担当するんだな」
「 👆 View も更新。
イベントハンドラを消し、コマンドを追加」
ユーザー・データをどこに保存するか？
「 👇 いろいろなフォルダーに ユーザー・データは保存できるが、どこにするんだぜ？」
「 ユースケースによる。
２Ｄ ＲＰＧ を開発するような アクターは、
いつも 同じ部屋で 同じ１台のパソコンを使って １人で開発している、という状況設定を押し付けることにしようぜ？」
「 それ以上のものを要求するユーザーは ネギラーメン ではなく
もっと 金出して 高級な開発ツールを使えばいいのよ」
「 そりゃそうだぜ」
「 じゃあ LocalApplicationData だな」
「 あれっ？」
C:
└── 📂 Users
└── 📂 {ユーザー名}
└── 📂 AppData
└── 📂 Local
👉 └── 📂 Muzudho
└── 📂 2D RPG Negiramen
「 👆 他人のローカルＰＣに わたしの名前のフォルダーが ポコポコできるの 嫌なんだが……」
「 屋号、 サークル名、 ホームページ名など いろいろあるけど」
「 仕事で金取ってないし 屋号もおかしいしな」
「 サークル名が 一番良いのでは？」
C:
└── 📂 Users
└── 📂 {ユーザー名}
└── 📂 AppData
└── 📂 Local
👉 └── 📂 Doujin Circle Grayscale
└── 📂 2D RPG Negiramen
「 👆 Grayscale だけだと 何だか分からないので、
かなり長いけど Doujin Circle Grayscale にしよう」
「 ひねりのない 名前にするからよ」
「 👇 あれっ！ MAUI には AppData 下の LocalFolder にアクセスする正式な方法が無い！」
「 マルチプラットフォームだから Windows のフォルダーにアクセスするのが ナンセンスなんじゃないか？」
「 あっ、そうか～！」
「 MAUI は他の手段を用意しているのかしら？ 調べなさい」
「 👇 知らんことばっかりなら 調べればいいだけだぜ」
string mainDir = FileSystem.Current.AppDataDirectory;
// Example: `C:\Users\むずでょ\AppData\Local\Packages\1802ca7b-559d-489e-8a13-f02ac4d27fcc_9zz4h110yvjzm\LocalState`
「 👆 UUID を含んだ文字の羅列になるらしい」
「 それは ネギラーメンを何回実行しても同じディレクトリー名になるのかだぜ？」
string mainDir = FileSystem.Current.AppDataDirectory;
// Example 1回目: `C:\Users\むずでょ\AppData\Local\Packages\1802ca7b-559d-489e-8a13-f02ac4d27fcc_9zz4h110yvjzm\LocalState`
// Example 2回目: `C:\Users\むずでょ\AppData\Local\Packages\1802ca7b-559d-489e-8a13-f02ac4d27fcc_9zz4h110yvjzm\LocalState`
「 👆 同じだぜ」
「 今どき 合理的な解決方法 してんのねー」
「 👆 設定ファイルの保存の仕方は 覚え直した……。
やり方ぜんぜん変わってた……」
「 次は そのファイルを読み取る方法を 覚え直せだぜ」
TOML形式ファイルを読み取ろうぜ？
「 👇 もう１回 Tomlyn の調べ直し」
「 👆 これで Toml も読み込めるぜ」
「 👆 前に入力した内容も フォームが覚えてくれるようになったから 楽になったぜ」
「 先送りにしていた 変数ｘ は どうすんの？」
「 絵を描くツールも Windows Paint と、 GIMP しかないしな……
少し ネットで調べる」
「 👇 特許が取られてるかどうか 分からん」
📖 WOLF Editor 公式 ＞ 【ﾏｯﾌﾟﾁｯﾌﾟ素材はどういう風に作ればいいの？】
「 👇 ゲームの特許なんか調べてられん。 ページ開いて出てくるの、こんなんだぜ？」
「 じゃあ 訴えられて死ねだぜ」
「
真理は 避けられず
真実は 踏み込んだ者にしか見えず
真相は 勝手なものである」
「 ゲーム業界に首を突っ込みたかったら 死にましょう。
生きて帰るな。代わりに 徹底的に世界を破壊しなさい」
「 WOLF EDITOR のドキュメントが整理されているので、それ読む」
「 ピクセル・アートを描くのに 良い無料のツールって どんなのだぜ？」
「 有料のフォトショップしか 選択肢 無いのに……」
「 👇 こんなサイトがあった。後で調べよう」
「 マップ・タイルは 16 x 16 ピクセル・サイズが単位のようだぜ」
「 それを どれぐらいのサイズのキャンバスの中に 敷き詰めんの？」
「 マルチ・プラットフォームなのだから、答えはないぜ」
「 Nintendo Switch は、 1080 x 720 だそうだぜ。
これを 参考に試算しよう」
📖 Nintendo ＞ Switch ＞ Technical Specs
「 タイル数で言うと、 67.5 x 45 枚だな。スクリーン上に 3037.5 枚のタイルがあるぜ」
「 一層で？」
「 オブジェクト数が 多い気がするけど、 ＲＰＧ なら大丈夫なのかなあ？」
マップ・エディターの画面デザイン
「 👆 マップ・エディターって こんなレイアウトで いいのかだぜ？」
「 違うんじゃないか？」
「 👆 描画ツールが いくつかあるんだぜ」
「 描画ツールって どんなけ あるんだぜ？」
「 👆 分からん。これぐらいから 始めればどうか？」
「 境界線ペンの仕様が はっきり分かんないかしら？」
「 オート・タイルか。 説明が よく分かんないんだよな」
「 👆 お父んに 分かりやすいように まとめたぜ。
空間充填問題も セル・オートマトンも 好きだろ」
「 うわっ 二ム計算みたいなの 出てきた」
「 あー、はいはい、分かりました」
「 👆 こんな役割なのよ」
「 接続時だけでなく、切断時の再計算も大変そうだ」
「 👆 でも オート・タイルの仕様は 理解したな」
📅 2023-06-26 素材が何もない
「 👇 pixelart.com の使い方を練習する」
「 👆 あれっ？ 64 x 64 pixel のつもりで描いたのに でかいな……」
「 1216 x 1216 pixel あるわよ？」
「 じゃあ 使えないなあ」
「 👆 Save じゃなく、 Download すればいいのか」
「 じゃあ これを最初のマップタイルとして MAUI の画面に表示してみようぜ？」
初期設定
「 👆 初期設定として これだけ入力してくれないと つらい」
「 ほとんどの人は ディレクトリー・パスも入力できず 投げるんじゃないの？」
「 ファースト・ビューで ユーザーが入力できるのは、
自分の名前と メール・アドレスぐらいだぜ」
「 じゃあ ファースト・ビューのボタンを クリックするところまでは
設定無しで 行けるようにしよう。
そこで何か ボタンを押したら 初期設定画面へ」
「 👆 パンくずリストで どう表現したらいいんだぜ？」
「 サイト・マップのツリー構造を崩したくないから、
モーダル・ダイアログ・ボックス的に ページ遷移せず出てくる サブ・ウィンドウみたいにできないの？」
「 やり方分からん。調査だな」
📅 2023-06-27 モーダル・ダイアログボックスを作れるかだぜ？
「 👇 マイクロソフトのドキュメントって、スクリーンショットを使った説明が 圧倒的に足りないよな」
「 👇 じゃあ まず 普通のサブ・ウィンドウを出して、閉じるところまで やってくれだぜ」
📖 Opening a new window in MAUI
/// <summary>
/// ［ウィンドウ表示テスト］ボタン押下時
/// </summary>
/// <param name="sender">このイベントを呼び出したコントロール</param>
/// <param name="e">この発生イベントの制御変数</param>
private void TestShowWindowButton_Clicked(object sender, EventArgs e)
{
var secondWindow = new Window
{
Page = new StartupConfigurationPage
{
// ...
},
Width = 1200,
Height = 400,
};
Application.Current.OpenWindow(secondWindow);
}
「 👆 これで ウィンドウは ポップアップされるけど、もっと簡単な書き方無いかなあ？」
/// <summary>
/// ［ウィンドウ表示テスト］ボタン押下時
/// </summary>
/// <param name="sender">このイベントを呼び出したコントロール</param>
/// <param name="e">この発生イベントの制御変数</param>
async void TestShowWindowButton_Clicked(object sender, EventArgs e)
{
await Navigation.PushAsync(new StartupConfigurationPage());
}
「 👆 こう書くと 同じウィンドウで ページだけ スライドする演出付きで 切り替わるぜ」
「 戻るボタンも 付いてるし、こっちの方が かっこいいわよ」
「 ウィンドウを閉じるボタンは、どう書くんだぜ？」
「 👇 Navigation.PopAsync(); じゃないのかだぜ？」
「 ContentPage クラスを継承したコード・ビハインド には Navigation 書けるけど、
ViewModel のプロパティーである Command にはどこから Navigation 持ってくるんだぜ？」
「 👇 Backwards Navigation があるんじゃないか？
await Shell.Current.GoToAsync(".."); を試せだぜ」
「 おー、戻れたぜ」
「 戻ったはいいけど、次の画面に進みたかったんだけど」
「 グローバル変数で 進みたい画面を覚えさせとくかー」
「 構成設定の要求を ページ間に挟むのは でけた」
タイル・マップを Unity の Assets フォルダー下へコピーしろだぜ
「 👆 この画像を Unity の Assets フォルダーへコピーしたいけど……」
「 この画像のファイル・パスって どうやって指すんだぜ？
カレント・ディレクトリー どこよ？」
「 指せるからこその Resources ディレクトリーなんじゃないの？
Special Directory に無いの？」
「 Application.ImageDirectory を調べてみるかだぜ」
「 XAML の中にしか書けないらしい」
📅 2023-06-28 初期素材をどこに置くんだぜ？
「 👇 ワーキング・ディレクトリーの設定方法を調べた方がいいのでは？」
📖 How to change the Current Working Directory of Maui Blazor App
「 まず AppDomain.CurrentDomain.BaseDirectory が何を出力するか 調べてみてくれだぜ」
「 👆 bin ディレクトリーの方を向いていて、 Resources フォルダーなんか見にこないぜ」
「 じゃあ マップ・タイル画像は ネギラーメンの実行ファイルとは別に 配ったらいいんじゃないの？」
「 Git Hub にでも置いとけば 拾っていくかな？」
「 👆 とりあえず ここに置いておくぜ」
「 👆 さらに調整」
「 ツクラーは こんな設定 できないから ＲＭＵは 全部入りのパッケージで売るのよ」
「 ソフトを自分で選んで インストールして 設定するような
パソコンの正しい使い方をしたくないのが、 ツクラーだぜ」
「 ネギラーメンは ツクラーの思想とは おさらばだぜ。
ネギラーメンは ただの食材を ユニティーにコピーする トッピング・ソフト だぜ」
コピーしろだぜ
「 👆 さらに調整。
ハードコーディングしてしまったが、ただの Copy だぜ」
タイルを選ばせろだぜ
「 タイル・パレットを作ってみましょう。
この画像を MAUI に表示して、草原、砂漠、岩、海を クリックできるようにしましょう」
「 👇 このポップアップというやつは 画面上に 画像が浮くやつじゃないか？
試してみようぜ？」
📖 マイクロソフト ＞ ポップアップ
📖 Microsoft ＞ Popup
「 👆 なんの説明も無いが、このパッケージが要るのでは？」
「 👇 全然 ビルド通らないなあ。調べるか」
📖 .NET MAUI Community Toolkit Popup PopupHandler is incompatible
「 👆 こんなん書く必要があるのかだぜ、分からんって」
「 👆 思ってるのと違って モーダル・ダイアログボックスみたいなのが 出てきたぜ」
「 画面の真ん中じゃなくて、ボタンをクリックしたマウスの近くに 出せないの？」
「 分からん」
「 ポップアップではなく、サブ・ウィンドウにしろだぜ」
「 くそっ」
「 👆 サブ・ウィンドウを出すのは 前にやったんで」
「 そこに タイルの画像を表示しましょう！」
「 👆 こんな風に 絶対パス書いたら 画像出てくるかな？」
「 さっさと 試せだぜ」
「 👆 出たけど 画像サイズが さっぱり……」
「 そのサイズを ぴったり 合わせてくれだぜ」
「 👆 ウィトス（WIdth；横幅）と ハイト（Height；縦幅）を 指定すればいいのか」
「 なんか変なデバッグ用のツールバーと被ってるから 真ん中らへんに表示しましょう！」
「 👆 グリッドを使って真ん中へ」
「 画像にマウスカーソルを合わせたら、枠が出るようにしてみてくれだぜ」
「 オン・マウス・オーバー みたいなイベントハンドラが無いか 探してみるかだぜ」
📖 Mouse hover detection in .NET MAUI
「 MAUI は、スマホのようなタッチ・デバイスで使われることを想定していて、
デスクトップのようなマウス操作は 想定していないそうよ」
「 クソじゃないか」
「 マウス・カーソルの位置を取得できないか、調べてみてくれだぜ」
📅 2023-06-29 マウス・キャプチャーしてくれだぜ
「 👇 マウス・キャプチャー自体 どうやるんだぜ？」
📖 How to capture global touch events in MAUI app
「 MAUI には マウス・キャプチャーは無いのよ」
「 じゃあ Windows プログラミングかだぜ？」
「 👇 その前に ジェスチャーを調べてくれだぜ」
「 👆 なんか いっぱいある。
この PointerGestureRecognizer とか それっぽくないかだぜ？
👇 調べるか」
コマンドに引数をよこせだぜ
「 あれっ？ どうやって コマンドに引数を渡すんだぜ？」
「 👇 調べろだぜ」
「 👆 WPF みたいなものんか？」
「 👆 反応はしてるから、後は 引数を取りたいぜ。
もう少し調べるか」
📖 Microsoft ＞ PointerGestureRecognizer.PointerMovedCommandParameter Property
「 👆 パラメーターも コマンドなんだ」
「 いや、取れない」
「 👇 何か無いか」
📖 .NET MAUI Custom control with command and parameters
「 👆 このコマンドから、何か引数にアクセスできないか？」
「 コマンドは 実行することしか できないわねえ」
「 じゃあ コマンドを使っちゃいけないんだ」
「 👆 コード・ビハインド を使うと 画像上の座標を取ることはできるが……」
「 コード・ビハインドと ビュー・モデルと 何の関係があるんだぜ？」
「 👇 WPFの依存関係プロパティみたいなものがないか 調べてみるぜ」
📖 How to use DependencyProperty in Maui?
📖 Microsoft ＞ Bindable properties
📖 How can I bind a property to a view model in MAUI?
「 👆 コード・ビハインドから、ビューにバインドされてる ビュー・モデル 取れた……。
WPF の DataContext と同じ考えだ」
「 簡単ねえ」
「 画像上の座標 取れた……」
「 それを いったん ウィンドウ上の座標に変換して、
32 x 32 pixels サイズのタイルを囲む枠を 置いてくれだぜ」
「 👇 調べるか……」
📖 How to get MAUI UI element absolute coordinates
「 👆 画像の座標は取れるのか。だったら それ使えばいいんじゃ……」
「 じゃあ 次は 枠を描こうぜ。
MAUI の画面上に 矩形を描く命令 あるかだぜ？」
「 👇 これを読めだぜ」
「 👆 canvas って どっから出てきたんだぜ？
👇 調べるか」
📖 .net MAUI: how to draw on canvas
「 👆 赤い枠は出せたけど、位置調整が大変だ」
「 マウスカーソルは １ピクセルずつ動いて欲しいけど、
赤い枠は ３２ピクセルずつ 動いて欲しい」
「 じゃあ グリッド が要るんだ」
「 センタリングされていて、座標計算が めんどくさい」
「 左上が基準で いいんじゃない？」
「 👇 なんで Alignment じゃなくて Options って名前なんだ？」
「 👆 例えば こんな感じ？」
「 それっぽく なったわねえ」
入力透過
「 タイル・マップを クリックしたいのに、
その上のカーソルが 邪魔なんだが」
「 👇 入力透過を使えだぜ」
📖 VisualElement.InputTransparent プロパティ
「 よし、それでイケてるぜ」
マウス・クリックした座標から、カーソルの位置を算出しろだぜ
「 隣の砂漠をクリックしたら、タイル・カーソルがそこを指すようにしなさいよ」
「 👆 グリッドが ３２ピクセル固定で ハードコーディングして いけたぜ」
「 じゃあ そのタイルを マップ・エディター で使いたいけど、
マップ・エディターが まだ無いのよねえ」
「 じゃあ 明日から マップ・エディター だな」
📅 2023-06-30 ツール・アイコンが欲しいぜ
「 👇 ペンのアイコンの絵を描くぜ」
「 無くていいのに……」
「 気分が出る！」
「 👆 pixilart.com のツールに グリッドのサイズ指定が無いから 枠線 引いてしまう」
「 どの画像の 何個目のタイルを表示するのか 名前で指定できるようにしたくない？」
tool_box.pen
「 👆 カテゴリー名と、そのメンバーを ドット・シンタックスで指定して」
crop_image("tool_box.png", 0, 0, 32, 32)
「 👆 画像のロードまで やってくれるような」
「 じゃあ ＣＳＶ形式で記録したらどうだぜ？」
code , file , x, y, width, height, comment
tool_box.pen , tool_box.png, 0, 0, 32, 32, ペン
tool_box.eraser, tool_box.png, 32, 0, 32, 32, 消しゴム
tool_box.bucket, tool_box.png, 0, 32, 32, 32, 塗りつぶし
code , file , x, y, width, height, comment
adventure_field.grass , adventure_field.png, 0, 0, 32, 32, 草原
adventure_field.desert, adventure_field.png, 32, 0, 32, 32, 砂漠
adventure_field.rock , adventure_field.png, 0, 32, 32, 32, 岩
adventure_field.sea , adventure_field.png, 32, 32, 32, 32, 海
「 👆 例は こうだぜ」
例： C:\Users\むずでょ\Documents\GitHub\2D-RPG-Negiramen
└── 📂 Workspace
├── 📂 Assets
│ ├── 📂 CSV
👉 │ │ └── 📄 tiles.csv
│ └── 📂 Image
│ └── 📄 tool_box.png
└── 📂 For Unity Assets
├── 📂 CSV
👉 │ └── 📄 tiles.csv
└── 📂 Images
└── 📂 Tile Set
└── 📄 adventure_field.png
「 👆 ツール・ボックスのアイコン・ファイルの置き場所は
ネギラーメンの 📄 Workspace/Assets/CSV/tiles.csv でいいかな？」
「 他のフォルダーも けっこう いじるんだな」
「 その tiles.csv を作るエディターが欲しいわよね」
「 タイル・パレット編集画面、みたいなやつかだぜ」
「 どんな画面レイアウトだぜ？」
タイル・パレット編集画面を作ろうぜ？
「 👆 コメントを入力することを考えると、横に広く使いたいしな」
「 👆 こんな雰囲気で どうだぜ？」
「 配色が ＲＯＣＫＭＡＮ だな」
「 グリッドを引きなさいよ」
「 グリッド引くなら ループ文を使うのが鉄板だと思うが
ＭＡＵＩで ループ文があるのか 分からん……」
📖 MAUI equivalent to CSS background-repeat: repeat;
「 👆 Webみたいに 背景画像をタイルにしてリピートできるなら グリッドが作れるかと思ったが
それも無いみたいだし」
「 動的に XAML の要素を追加・削除する方法も分からん」
「 透明なキャンバスに 罫線引いて タイル・マップの上に 覆い被せりゃいいんじゃないの？」
「 それで行くか」
パンくずリストと、タイトル
「 👆 パンくずリスト付けたら もっさり したんだが、
ヘッダーと パンくずリスト を１つに まとめる方法 無い？」
「 タイトルバーに見えるところ、自動で付くのよねえ」
「 👇 ナビゲーションじゃないか？ 調べてみろだぜ」
「 👇 ソースの中には いじれそうなものは無かった。もっと探そう」
📖 How to customize the navigation title view of MAUI ContentPage
「 👆 初期状態は こう書いてるのと 多分 おんなじらしい。
これをベースに改造してみようぜ？」
「 👆 パンくずリストと ページ・タイトルを 同じ行に まとめたぜ」
「 スマホの画面には タイトル・バーが無いから、ページの中に作るのね」
「 ＰＣは クローム（※）が付くんだな」
※クローム … ウィンドウの枠。タイトルバーなどを含む
グリッドの線、引こうぜ？
「 👆 ひとまず ハードコーディングで 半透明の赤い色で グリッドを置いてみたが どうだろうか？」
「 まずは いいんじゃないの？」
「 元画像の 横幅、縦幅も 表示してくれだぜ」
「 👆 さらに細かく調整」
「 タイル画像が大きかったとき、スクロールできんの？」
「 この画面は ハリボテ なんで……。
動きを付ける段階になったら 調べるぜ」
「 タイルＩｄを表示してくれだぜ」
画像サイズを調べようぜ？
「 その前に １枚の画像にタイルが １００枚ぐらいなのか、 １０００枚ぐらいなのか、 １００００枚ぐらいなのか、
規模を知りたいぜ」
📖 WOLF RPG エディター(ウディタ)でゲームを作る3 ～マップチップとオートタイルを増やす～
「 👆 素材集の中を覗いてみないと 分からんな……」
「 👆 あれっ、思ってたより小さい……
横 332 × 縦 772 かだぜ？」
「 なんだ その 中途半端な数は？」
「 あれっ？ 枠が付いてある…… これは使用例のスクリーンショットか。
横 256 x 縦 608 のものもあるぜ」
「 なんだ その 中途半端な数は？」
「 横 256 x 縦 544 のものもあるぜ」
「 決まってないのでは？」
「 横はニゴロ（２５６）のようだぜ」
「 じゃあ 縦長 になるんだ。ポートレートだ」
「 １つのタイル・サイズは ３２ｘ３２ を最小として、
６４ｘ６４ とか ９６ｘ６４ とか 自由気ままに配置されているぜ！」
「 ６０８ は ３２ で割り切れるわねえ。１９よ」
「 素数だ」
「 どういうシステムなんだ」
「 じゃあ分かった、 256 × 608 を画面に表示してみようぜ？
👇 画像を作るぜ」
「 👆 ハリボテだが スクロールバーは 付けれるぜ」
「 お父んの思想と ウルフエディターの素材作成勢とで 相性が悪いの わらう」
「 意匠は 相容れない方が 著作権を差別化できて有利なのよ」
「 明日は このハリボテに 動きを付けていこうぜ？」
📅 2023-07-01 ページに引数を渡すにはどうやるんだぜ？
[http://www.example.com/index.html?name=banana](http://www.example.com/index.html?name=banana)
^^^^^^^^^^^^
「 👆 Ｗｅｂ系なら ＵＲＬの後ろに クエリー文字列を付けることができるが、
MAUI で画面遷移時に何かデータを渡すには どうやるんだぜ？」
「 👇 調べろだぜ」
「 👆 parameters で オブジェクトを渡せそうだな。
渡した先での 受け取り方も 調べるかだぜ」
「 👆 ビューモデルに フィールドがあるとして……」
「 👆 フィールド名を使って、オブジェクトを渡せるみたいだな」
PNG 形式画像ファイルのサイズを取得してくれだぜ
「 PNG 形式画像ファイルのサイズを取得してくれだぜ」
「 あれっ？ やり方が分からん……
👇 調べるか……」
📖 [C#]PNGの幅，高さのみをファイルから高速に取得する方法について
📖 【C#】PNG画像サイズの取得方法
「 👆 渡せるものと、渡せないものとがある。
調べるか……」
「 👆 QueryParameter アトリビュート（属性）をクラスに１個１個すべて書くのが確実らしい」
「 MVVM 実装してるだけで １日 終わりそうだ」
「 画面は 手戻り無しで １発で作らないと 時間が 厳しそうねえ」
「 要らん画面 作ったら １日は無駄になるな」
「 👆 変更通知プロパティの手順の順序を 間違えると 画面に出てこないから 正確にやるぜ」
「 👆 画像サイズに 動きを付けたぜ」
「 全部に動きを付けてくれだぜ」
「 つら」
GraphicsView はどうやってリフレッシュするんだぜ？
「 👆 グリッドは GraphicsView を使ってプログラム的に描画しているが、
これは どうやって再描画するんだぜ？」
「 👇 調べろだぜ」
「 👆 graphicsView.Invalidate(); を呼び出せばいいのか。やってみるかだぜ」
「 ビューモデルから どうやって graphicsView にアクセスするんだぜ？」
📖 Binding from view to GraphicsView property in .NET MAUI
📖 How to databind imageview with drawable in viewmodel?
📖 .NET MAUI: Dynamic behaviour of graphic elements when using MVVM
「 👆 同じ悩みを持ってるやつらが 見つからんなあ」
「 Drawable に変更通知プロパティを 仕掛けられないの？」
「 👆 ビュー・モデルから IDrawable 実装インスタンスの Draw をコールする方法も分からん」
「 ビュー・モデルから ビューに アクセスできないのかだぜ？」
「 調べてみるか」
「 ビュー・モデルは 変更通知プロパティ をビューに仕込んで連携できるだけだな」
「 ビュー・モデルの方から ビューのキャンバスを変更できないと グリッド・サイズを更新できなくない？」
「 👆 リソースに 引数を渡す方法って ある？」
「 👇 調べろだぜ」
「 リソースは スタティックなんじゃない？」
「 じゃあ GraphicsView を使って グリッドを描画するのが そもそも間違ってる？」
「 そうなのでは」
「 伸縮自在なラインを 固定長で１０００本ぐらい 画面に持たせた方がいいのかだぜ？」
「 👆 GraphicsView の横幅、縦幅は バインディングできるから、
ビューモデルから 縦幅、横幅の変更通知を送ったら IDrawing 実装インスタンスの Draw メソッドを呼び出してくれないかな？」
「 試せだぜ」
「 👆 なんらかのタイミングで Draw メソッドの dirtyRect 引数に矩形が入っているから、
あとは ビュー・モデルから 任意のタイミングで Draw をコールできれば うまくいきそうだが」
「 👆 画面を出した初回は 画像サイズが分かってるんで グリッドも合わせられるぜ」
「 グリッド・サイズは途中からも 変えたいのよ」
「 👆 グリッドの横幅が変更されたタイミングで
グリッドの画像サイズの横幅を 1px 伸ばしたったら、再描画が呼び出されるけど」
「 イケてないわねえ」
「 再描画が呼び出されるトリガーのうち、もっとも無難なものって何だぜ？ タグの変更トリガーとか無いのかだぜ？」
「 タグだって 変えられたくないわよ」
トリック・コード
「 👆 今回のプログラミングで最初のトリック・コードだぜ。
画像の横幅が偶数のときは 横幅を１伸ばし、
画像の横幅が奇数のときは 横幅を１縮めて 無限に振動させるぜ」
「 わらう」
「 グリッドのサイズを変えるたびに
グリッドの右端が １ｐｘ飛び出たり 元に戻ったりするんだけど」
「 トリックがバレないように修正する」
「 👆 トリック・コードのせいで 割り食って おかしくなっている箇所は
キャンセル・コードを書いて おかしなものを 隠すぜ」
「 不毛な戦い わらう」
「 トリック・コードなんか書くからよ」
「 グリッド・サイズを変えれるようになった。今日はここまでだぜ」
「 ＭＶＶＭの実装 時間かかるんだな、作る画面は 最低限の数で済むように 全体を考えないとな」
📅 2023-07-02 タイル・パレット編集ページを作っていこうぜ？
「 👆 グリッドの全体も ずらせるようにしたので、 位相 にも対応だぜ」
「 スクロールとかねえ」
「 線形代数の変換の王様、アフィン変換にも対応しろだぜ」
「 開発時間足りない。次へ」
「 👆 カーソルが グリッドに 吸着するようになったぜ」
「 これだけで 日曜日が終わろうとしている。時間がかかるな」
「 下側の タイル ０ ０ ０ ０ のとこに カーソルの位置を表示しなさいよ」
「 👆 はい」
「 お父ん。グリッド１ます の たて に 50000 と入れたら強制終了したぜ？」
「 👆 確かに。あのグリッド、ただの縦線じゃなくて 画像だからな」
「 テキスト・ボックスに バリデーション（妥当性検証）を入れなさいよ」
バリデーションを入れようぜ？
「 👇 何もかも やり方が分からん。覚え直しだ。 調べるか……」
「 👆 説明の通りコードを書いても IValidity のところで コンパイル・エラーになるの 分けわからんな」
「 この記事が クソ だということを伝えるボタンが無いぜ」
「 👇 文字数のチェックはできるみたいよ？」
「 もっと まともな方法を調べるぜ」
📖 RequiredStringValidationBehavior
📖 NumericValidationBehavior
「 👆 NumericValidationBehavior を調べてみるか」
「 👆 下ごしらえは XAML だけで終わるの 簡単だな」
「 １辺の上限が 16384 じゃなくて、
面積の上限が 16384 か？
ルート２ したら 128 で小さすぎないか？」
「 10000 x 10000 にしても動いているぜ？」
「 なんか限界 攻めたくないな。
グラフィック・カードの性能に依存するのかも知らん。
とりあえず 上限は 8192 にしよう！」
「 2 の 13乗に 意義を感じないわね」
「 👆 じゃあ 無難な 上限 2048 にして、
文句があるやつがでてきたときに 拡張用の設定ファイルを用意しようぜ？」
「 設定できるんなら それでいいよな」
「 👆 あれっ？ 色が変わるだけで 入力できてしまう？」
「 入力を拒絶しなきゃ、意味なくない？」
「 ビュー・モデルの方で 2048 以上を入力したら 2048 として扱うような処理がいるかもしれないな」
「 あっ、 0 を入れても フリーズしたぜ」
「 明日は バリデーション を みっちり やるぜ」
📅 2023-07-03 バリデーションを入れようぜ？
C:
└── 📂 Users
└── 📂 むずでょ
└── 📂 AppData
└── 📂 Local
└── 📂 Packages
└── 📂 1802ca7b-559d-489e-8a13-f02ac4d27fcc_9zz4h110yvjzm
└── 📂 LocalState
├── 📄 configuration.toml
👉 └── 📄 settings.toml
「 👆 settings.toml ファイルを作って、そこに グリッドのタイル・サイズの一辺の上限は 2048 だという設定を
書いておこうぜ？」
「 両端に太さが 2px のグリッドの線があるから、1px ずつ食み出るとして 2048 から 2px 引いて 2046 にすべきだと思うが」
「 上限値の理由に 意義がないのよ」
「 じゃあ 2046 !」
[tile]
# 一辺が 2048 ピクセルのキャンバスを想定し、両端に太さが 2px のグリッドの線があって 1px ずつ食み出るから 2px 引いて 2046
max_width = 2_046
max_height = 2_046
「 👆 １辺が 2048 ピクセルのタイルを作りたいやつは 設定を変えろ」
「 👆 バリデーションというのは ビューの色を変えるぐらいしか機能がないので、
ビューモデルでは 単に リミット・チェックを入れた」
「 入力された値は（弾かず）とりあえず受け取る、という思想なのね」
「 入力を受け取らないフラグ 無いのかなあ？ もっと探してみろだぜ」
「 疲れたんで とりあえず 次へ」
マウス・ドラッグに対応しろだぜ
「 お父ん。マウス・ドラッグして タイルを連続選択できないのかだぜ？」
「 作ってない機能は 存在しないぜ」
「 作れ」
「 ドラッグ アンド ドロップなのかな？
プレス アンド リリースじゃないかな？」
「 ドラッグ アンド ドロップって、
ファイルをつかんで アプリケーションの領域に落とすやつを言うのよ。
タイルの連続選択は プレス・アンド・リリース じゃないかなあ？」
「 今は タップした時点で カーソルの位置が決まっているが、
リリースした時点で カーソルの位置を決めた方がいいのかだぜ？」
「 もっさりしない？」
「 操作感は 統一的になると思うが」
「 タップしたジェスチャーは 捕捉できるが、
リリースしたというジェスチャーは どうやって捕捉するのかな？
調べるか」
「 👆 スワイプは 向きだけかあ」
「 👆 ドラッグ アンド ドロップは ファイルを落とすやつだしな」
「 👆 ポインター・ジェスチャーには 入りと 出があるのか。これを調べてみるか」
「 エンターは 画像と重なったところで、
エグジットは 画像の外と重なったところか。
マウス・ボタン押下とか、マウス・ボタン・リリースではないんだ」
「 タップは マウス・ボタン押下と マウス・ボタン・リリースのペアか？」
「 そうだぜ。
それも マウスを移動させずに マウス・ボタン押下と マウス・ボタン・リリースを
行わなければいけないぜ」
「 じゃあ タップは 従来の クリック に対応してるんだ」
「 マウス・ボタン押下と、 マウス・ボタン・リリースを 別々に捕捉する方法を探せだぜ」
「 MAUI には無いようだぜ」
「 マウス・ダウンと マウス・アップを検知する 何らかの方法はあるのかしら？」
「 タップで始まり、タップで終わるのでいいだろ」
「 ペン・タブレットで 必要になりそうな機能が MAUI に無いなんて
理解できないが お父んは そのような 理不尽や 意味不明を 越えていくのに長けているのだろう」
「 👆 カンペキは無いものだぜ。タイルの連続選択できあがり」
📅 2023-07-04 タイルを登録できるようにしろだぜ
「 タイルは 名前で管理するのか？ Ｉｄで管理するのか？」
「 現代は UUID が流行ってて URL は わけの分からない数字、文字の羅列になってしまったが、
UUID が真のＩｄなら URL 無くして UUID にすればいいものの、
そうならないのは 名前 からイメージできる姿があるからだぜ」
「 名前は アスキー文字にすんの？
ユニコードにすんの？」
「 こんな ネギラーメンで ユニコードが使えない環境のことを 本気で考えなくていいだろ。
ユニコードでいいんじゃないか？」
「 文字数は？」
「 本気で考えなくていいだろ。 ６４文字でいいんじゃないか？」
「 １～４バイトのユニコード文字が ６４個であることの意義は？」
「 無いけど……」
「 ツクラーが タイルに名前を付けようと思ったときの 文字数の分布は？」
「 データは無いけど……」
📖 Tiledによるタイルマップの作成とオブジェクトデータの取得を行う！：Cocos Creator
Tiled Cocos Creator
「 👆 誰も タイルに名前なんか 付けないのでは？」
「 アマゾンの商品名の長さは？」
📖 KRAFT Macaroni & Cheese Easy Mac Cups (12 x 2.05 oz cups)クラフト マカロニチーズ イージーカップ 12パック 海外直送
「 👆 適当にクリックしたが 英語表記、日本語表記をつなげて 重さや個数、海外直送まで入っているぜ」
「 ざっくり １００文字にしたら？」
「 そうするか……」
「 すると みんな タイル名に 検索のための情報を 詰め込みだすのでは？」
「 名前とは別に タグを付けれるようにするかだぜ？」
「 １つのタイルに タグは何個付けれて、１つのタグの長さは何文字までなの？」
「 これは再帰的な話しで、１つのタグに たくさんの検索の情報を詰め込みだす……」
「 タイル名を付けるの めんどくさくなって タイル１、 タイル２、タイル３ みたいな名前を付けるやつが
蔓延したらどうする？」
「 連番付けられるぐらいだったら、 Ｉｄ は こっちで採番してやるかだぜ」
「 １つのタイル・セットに、何枚のタイルがあんの？」
「 データは持ってない」
「 Ｉｄ だけ必須にして、それは自動で採番して、
１００文字のテキスト・フィールドに 半角カンマ区切りで タグを自由入力させたらどうだぜ？」
「 ４９個のアルファベットを タグで登録するやつがいて うざいかもしれない」
「 タグも 日本語で入力されたり、英語で入力されたり、表記揺れしたりするんじゃない？」
「 じゃあ カテゴリー・ツリーを予め こっちで定義して そのノードを選ばせる方式にして、
それ以外に 固有名詞 を自由に入れれる欄を置けばどうか？」
「 Ｉｄ欄と、１００文字のコメント欄の２つにしましょう！
検索のための仕組みは 後回しで」
「 👆 こんな感じで いいのかだぜ？」
「 動かしてみないと分かんないから それで 作ってみましょう」
C:\Users\むずでょ\Documents\Unity Projects\Negiramen Practice\
└── 📂 Assets
└── 📂 Doujin Circle Negiramen
└── 📂 Negiramen Quest
└── 📂 Auto Generated
└── 📂 Data
└── 📂 CSV
└── 📂 Tile Set
👉 └── 📄 map-tile-format-8x19.csv
「 👆 ファイルは ここに置いとくぜ？」
Id, Left, Top, Width, Height, Comment
1, 96, 64, 64, 64, 草原
「 👆 保存内容は こんな感じで いいかだぜ？」
「 とりあえず それで」
「 クエリー・パラーメーターで ビュー・モデルへ ＣＳＶファイルへのパスを渡したつもりなんだが、
コード・ビハインドの Load 時には ビュー・モデルに ＣＳＶファイルへのパスが入ってないな」
「 👆 書かれてる通りにやってるんだが……、あっ、スペルミスだ！」
「 👆 とりあえず ハリボテ で、１行追加 できるようにしたぜ」
「 コメントの文字数のバリデーション、
Ｉｄの自動採番、
既に追加されているタイルは コメントを表示、ボタンのラベルも［追加］から［上書］へ変更、
削除ボタンの実装、
ＣＳＶを固定レイアウトではなく、列名を見るように変更、
ＣＳＶのダブルクォーテーションのエスケープ、
少なくとも これらは 残っているな」
「 気の遠くなる話しだぜ」
「 じゃあ 睡眠へ切り替えよ。寝ろ」
📅 2023-07-05 マウス操作が分かりづらいの何とかしろ
「 MAUI がタップ操作にＵＩを寄せていて、マウスダウン、マウスアップ が検知できないの クソなんだが」
「 最初の１回目のタップで あんたが枠を出すから、これでいいんだと思っちゃって
そしたら もう１回 タップしなくちゃいけないって分かって 分かりづらってなるのよ」
「 選択が未確定の間は カーソルが アニメーションしたらどうだぜ？」
「 画面が チカチカ 動くのは オフィス・ソフトの分野では 非常識だぜ」
「 半透明な枠なら どうよ？」
「 👆 これぐらい はっきりと分かるぐらい 半透明にしてみるか」
Ｉｄを自動採番しろ
「 ＣＳＶファイルの中で１番大きなＩｄより １ だけ大きいのが 新しいＩｄだろ。
お父ん。実装しろ」
「 スキャンするのは カッコ悪いから 行が追加されたタイミングで 最大のＩｄを常に更新するかだぜ」
「 👆 Ｉｄは 増えるようにしたぜ」
登録されているタイルは表示しろ
「 登録されているタイルは 表示してくれだぜ」
「 タイルが １０００個 登録されていたら、
画面上には タイル １０００個 のスプライトを 表示しないと いけないのかだぜ？」
「 画面を開いたときと、
タイルを追加・削除したときに キャンバスを描きなおせばよくない？」
「 じゃあ 実際のタイル画像とは別に、
ワーキング（Working；作業中）なタイル画像を 内部的に持っておけばいいかな」
「 👆 Source に内部メモリーを指定できるのかだぜ？」
「 外部ファイルで十分なんじゃないの？」
「 作業中の画像は、
ネギラーメンのワーキング・スペース、
ユーザーの AppData、
ユニティの Assetsフォルダー、
どこに置くのがベスト・プラクティスだぜ？」
「 ユニティの Assets フォルダーには 資産じゃないものは 置きたくないわねえ」
「 ユーザーの AppData に ゴミを置きたくないぜ」
「 じゃあ ネギラーメンのワーキング・スペースかだぜ」
「 ネギラーメンを２重起動しなければ 問題ないんじゃない？」
例： C:\Users\むずでょ\Documents\GitHub\2D-RPG-Negiramen
└── 📂 Workspace
├── 📂 Assets
├── 📂 For Unity Assets
└── 📂 Temporary
└── 📂 Images
👉 └── 📄 working_tile_set_canvas.png
「 👆 こんな感じで テンポラリー（Temporary；一時的な）フォルダーを切ろうかな？」
第２の構成ファイル
「 ファイル・パスは ハード・コーディングするのか？」
「 いーや。ソース・コードの中に設定が書かれているのは メンテナンス 時の選択肢を狭めて良くない。
外部ファイルで全部 指定できるようにしたいぜ」
例： C:\Users\むずでょ\Documents\GitHub\2D-RPG-Negiramen
└── 📂 Workspace
👉 └── 📄 configuration_2nd.toml
「 👆 第２の構成ファイルだから、こんな感じでどうだぜ？」
「 じゃあ とりあえず それで」
[paths]
# ネギラーメン・ワークスペースの作業中のタイル・セット・キャンバスPNG画像ファイルへのパス
working_tile_set_canvas = "{negiramen_workspace_folder}/Temporary/Images/working_tile_set_canvas.png"
「 👆 ファイルの中身は こんな感じでどうだぜ？」
「 とりあえず それで」
「 👆 厳密に行くなら 構成ファイルに この１行を書き足しておきたいぜ」
「 そのファイル・パスは MAUI から編集できるようにするのかだぜ？」
「 非表示でいいだろ、こんな細かいの」
「 ユーザーが そのファイルに辿りつけなくない？」
「 AppData は 隠しフォルダー なんで」
「 じゃあ ネギラーメンを開発する お父ん や、
ネギラーメンを改造する人だけが 知ってればいいんだ」
「 configuration_2nd.toml は 隠さなくていいの？」
「 どこに 何が置いてあるかの 目録になるんで」
「 configuration_2nd.toml って名前だったら、じゃあ configuration_1st.toml は どこにあるんだ？
って探さない？」
「 ぐぬぬぬぬ」
例： C:\Users\むずでょ\Documents\GitHub\2D-RPG-Negiramen
└── 📂 Workspace
👉 └── 📄 user_configuration.toml
「 👆 user_configuration.toml にしよう！」
設定ファイルの中で変数展開
「 👆 設定ファイルの中で変数が使える仕組みを 簡易実装したところで 今日はここまでだぜ」
「 最初に作っとかないと あとで困るやつだし、
本筋の作業が進んでないけど いっか～」
「 なかなか 前に進まないな……」
📅 2023-07-06 タイル・パレット編集画面へタイル・セット画像ファイルへのパスを渡せだぜ
「 お父ん、タイル・セット画像へのファイル・パスをハードコーディングしてるだろ。
まず これを クエリー・パラメーターに置き換えて、
画面遷移元から タイル・セット画像へのファイル・パスを受け取る形にしろだぜ」
「 わかったぜ」
（カタ カタ カタ カタ ……）
「 でけたぜ」
「 次はその タイル・セット画像へのファイル・パスを読込んで、
そして
C:/Users/むずでょ/Documents/GitHub/2D-RPG-Negiramen/Workspace/Temporary/Images/working_tile_set_canvas.png へ出力しろだぜ」
「 やってみるぜ」
（カタ カタ カタ カタ ……）
「 👇 C# なら ImageIO 使えばいいのかだぜ？」
📖 画像ファイルを読み込み、Imageオブジェクトを作成する
using System.Drawing.Image;
「 👆 MAUI に System.Drawing.Image 無い」
「 マルチプラットフォーム化で 使えなくしているパッケージなのでしょう」
「 👇 現代では こっち読むのか。インターネット上の大量の記事が 無駄になったかも知れないなあ」
📖 Microsoft ＞ Image（コントロール）
📖 Microsoft ＞ イメージ（メモリー）
Assembly assembly = GetType().GetTypeInfo().Assembly;
using (Stream stream = assembly.GetManifestResourceStream("GraphicsViewDemos.Resources.Images.dotnet_bot.png"))
{
image = new W2DImageLoadingService().FromStream(stream);
}
「 👆 リソース・フォルダーの中の画像を取得する方法が 書いてるな。
今回は逆に 任意のディレクトリーの画像のメモリー・ストリームを取らないといけない」
public async Task<string> ReadTextFile(string filePath)
{
using Stream fileStream = await FileSystem.Current.OpenAppPackageFileAsync(filePath);
using StreamReader reader = new StreamReader(fileStream);
return await reader.ReadToEndAsync();
}
「 👆 このテキスト・ファイルの例を、画像に書き換えられないか？」
using Microsoft.Maui.Graphics.Win2D;
「 👆 このネームスペースが存在しないんだが？」
「 NuGet で取ってくるんじゃないの？」
「 👆 これかな？」
「 それはインストール済みだぜ」
「 👆 じゃあ このエラーは何だぜ？」
「 プリプロセッサ・ディレクティブを使って Ｗｉｎｄｏｗｓと Ｍａｃを分ける必要があるんじゃないの？」
#if IOS || ANDROID || MACCATALYST
using Microsoft.Maui.Graphics.Platform;
#elif WINDOWS
using Microsoft.Maui.Graphics.Win2D;
#endif
// ... 中略 ...
#if IOS || ANDROID || MACCATALYST
// PlatformImage isn't currently supported on Windows.
TheGraphics.IImage image = PlatformImage.FromStream(inputFileStream);
#elif WINDOWS
TheGraphics.IImage image = new W2DImageLoadingService().FromStream(inputFileStream);
#endif
「 👆 プラットフォームの違いを メソッドが隠蔽してくれたらいいのに……」
//
// タイル・セット・キャンバス画像の読込
//
var task = Task.Run(() =>
{
try
{
// 読込元（ウィンドウズ・ローカルＰＣ）
using (Stream inputFileStream = System.IO.File.OpenRead(tileSetImageFilePathAsStr))
{
#if IOS || ANDROID || MACCATALYST
// PlatformImage isn't currently supported on Windows.
TheGraphics.IImage image = PlatformImage.FromStream(inputFileStream);
#elif WINDOWS
TheGraphics.IImage image = new W2DImageLoadingService().FromStream(inputFileStream);
#endif
//
// 作業中のタイル・セット・キャンバス画像の保存
//
if (image != null)
{
// 書出先（ウィンドウズ・ローカルＰＣ）
using (Stream outputFileStream = System.IO.File.Open(workingTileSetCanvasImagefilePathAsStr, FileMode.OpenOrCreate))
{
image.Save(outputFileStream);
}
}
}
}
catch (Exception ex)
{
// TODO エラー対応どうする？
}
});
「 👆 MAUI から Windowsのフォルダーにアクセスできるけど、
マルチ・プラットフォームというメリットが無くなってしまうよな」
「 じゃあ Windows の利便性を失わせるかだぜ？」
「 ユーザーに AppData フォルダー下を いじらせるのは
隠しフォルダーの意義を失うわよ」
「 じゃあ Windows依存で進めるか～」
「 👆 PNG画像の書出しまで でけたぜ」
「 今は タイル・セット画像の方を MAUI に表示してるだろ。
それを止めて、こっちの 作業中のタイル・セット画像の方を MAUI に表示してくれだぜ」
「 分かったぜ」
（カタ カタ カタ カタ ……）
「 その差し替えも終わったぜ」
「 すでに登録済みのタイルは 半透明の青色で塗りつぶしておくと、
残作業が見えやすくなるんじゃない？」
「 やってみるぜ」
Microsoft.Maui.Graphics.IImage
Microsoft.Maui.Graphics.ICanvas
「 👆 あれっ？ 描画ができるのは IImage じゃなくて、 ICanvas の方だぜ？」
「 IImage を ICanvas に変換する方法がないか、調べろだぜ」
「 ググっても出てこないから デバッグライトするぜ。
IImage の実体は W2DImage らしいんだが、これも探しても出てこない」
「 Ｗｉｎｄｏｗｓの２Ｄイメージなんじゃないの？」
「 タイル・カーソルと同じように IDrawable を実装したクラスを作って、
XAML の GraphicView 要素の Drawable 属性で指定したらどうだぜ？」
「 あっ、そうか！」
「 IDrawable を実装したクラスと、ビュー・モデルが連携できないの
グローバル変数での連携が大変だぜ、どうにかならないの？」
「 👇 BindableObject というのが あるそうだぜ」
📖 In .NET MAUI, how do I pass variables to a GraphicsView.Drawable in a ContentView
📖 How to pass variable data into .NET MAUI GraphicsView canvas
「 覚えてみるかだぜ」
📅 2023-07-07 ＩｄをＢＡＳＥ６４にしようぜ？
「 Ｉｄ を ＢＡＳＥ６４ にしようぜ？」
「 メリットは？」
「 人は 整数を見ると １から順にソートしたくなる。
ＢＡＳＥ６４ なら ソートしようとは思わない。
Ｉｄをソートしようとする悲しい人類を救うことができる」
「 エビデンスは？」
「 無い。本番環境で実験だぜ」
「 やってみろだぜ」
「 👇 Convert クラスを使ってみるか」
📖 Convert.ToBase64String メソッド
📖 Converting string to byte array in C#
「 👆 Ｉｄを ＢＡＳＥ６４にしたぜ」
「 わらう」
「 👇 桁数が気になるわね。
1 は MQ== だけど、 1000 は MTAwMA== よ？」
📖 データ変換ツール
「 ３桁ぐらいの文字なら ４桁ぐらいに変換されて気にならないが、
４桁ぐらいの文字は ８桁ぐらいに変換されて メモリ効率は ２倍になって 悪くなるな。
だいたい、 １．３倍ぐらい メモリ効率は悪くなるぜ」
「 メモリ効率が１．３倍に悪くなることと引き換えに
悲しい人類がＩｄをソートしようとすることを防ごうと言うのね」
「 👆 Ｉｄが１０００に達したとき、ＢＡＳＥ６４にすると 改行されてしまうのは 悪しと見るか、
コーナーケースに合わせるとキリがないので これで良しと見るか」
「 １０００枚もタイルが含まれる タイル・セット画像を 利用するやつ、
そんなとこ 気にするでもなく ハードワーカーだろ」
「 ９９９枚もタイルが含まれない タイル・セット画像を 利用する人にとっては、
無駄なスペースが 空いていることの方が きにするでしょう」
「 あっ、Ｉｄ をマウスで選択できね。気になるな……。
選択可能なテキストで、かつ入力ができない リード・オンリーな設定できるかな……？」
「 👆 でけた。
フォント・サイズは きっかり スタイルで決まっているようで 任意サイズにはできなかったので
Entry 要素を広げたぜ」
「 ラベルの Ｉｄ と コメント の間に パディング 入れられないの？」
「 👆 入れれるぜ」
「 良くなった。ラベルの文字は 隣のセルと くっつかないようにしましょう」
「 👆 Ｉｄ だけだと オーラル・コミュニケーションで困るだろうから
タイルＩｄ と書いといてやろう」
「 そのＩｄって、 ひだり、うえ、よこ、たて から一意に決まらないの？」
「 例えば 128,32,96,32 を ＢＡＳＥ６４に変換擦ると MTI4LDMyLDk2LDMy だぜ。
これだったら ベクターを２つ 覚えておいた方がマシかも」
「 情報で構成されている Ｉｄ なんて、イケてないぜ。それは暗号だぜ」
「 あくまで 表示に ＢＡＳＥ６４ を使っているだけで、内部的には 整数なんで」
「 このタイルＩｄは、プロジェクトの中で一意なの？
それとも タイル・セット画像ファイルの中で一意なの？」
「 凝り出すと ＵＵＩＤ に行きついてしまう。
タイル・セット画像ファイルの中での ローカルなＩｄだぜ」
「 じゃあ タイルＩｄには タイル・セット画像ファイルのＩｄも 表示しないと
本当のタイルＩｄにはならないんじゃない？」
「 タイル・セット画像ファイルに Ｉｄを振ることが難しい。
プロジェクトの中での ローカルなＩｄなら 振れるだろうけど、
そのＩｄは 別のプロジェクトへ使い回せない」
「 プロジェクトに ＵＵＩＤ 振ればいいんじゃないの？」
「 ブランチして 開発が平行したら ノー・コントロール になってしまう」
「 じゃあ なんで タイルＩｄ なんか採番するんだぜ？
ファイル名、ひだり、うえ、よこ、たて が本当のＩｄなんじゃないのかだぜ？」
「 あるファイル内の中だけで使える、
ひだり、うえ、よこ、たて の情報を ３桁程度の整数に集約するのが タイルＩｄ だぜ」
「 その情報を ユーザーに提示する理由は？」
「 タイル１、 タイル２ のような タイル名 を ユーザーに入力させないこと、
1、 2 のような 連番 を ユーザーに入力させないこと、
これらの代替が タイルＩｄ だぜ」
「 意義はあるんだ」
「 しかし それは Ｉｄ の働きを持っていないのでは？
何かと言えば コード なのでは？」
「 内部的には Ｉｄ なんだが、表示上は コード だな。
じゃあ オーラル・コミュニケーションを考えて ラベルを変えるかだぜ」
「 👆 確かに タイル・コード にすると しっくりしたな」
「 しかし そもそも ＢＡＳＥ６４ は、 オーラル・コミュニケーション には向いていないのでは？」
「 諫言だぜ」
「 じゃあ ＢＡＳＥ６４の ６４文字に対して Apple とか、 Banana とか
プロナウンサブル（Pronounceable；発音可能）な単語を当てたらどう？」
「 インターナショナル（International；国際的）に通用するフォニックス（Phonics；発音）ってある？」
「 軍事か通信、航空あたりを調べれば 何か規格があるのでは？」
「 調べるか～」
「 👇 ナトー のがあったぜ」
「 はっきり 西側に寄り添うの わらう」
「 大文字と小文字は 区別しないのか～」
「 英語のフォネティックコードが人名なんで、大文字にかこつけて 大文字は英語にしたらいいんじゃないの？」
「 じゃあそれで。作ってみるか～」
「 大文字も 小文字も X-ray になるんだが」
「 違う所から 持ってきなさい」
BASE64 英単語 読み
------ --------- -------
A Alice アリス
B Boart ボート
C Castle キャッスル
D Drink ドリンク
E Elf エルフ
F Forest フォレスト
G Gold ゴールド
H Hotel ホテル
I Island アイランド
J John ジョン
K King キング
L Level レベル
M Madam マダム
N News ニュース
O Ork オーク
P Pond ポンド
Q Queen クイーン
R Room ルーム
S Soup スープ
T Talk トーク
U Uncle アンクル
V Video ビデオ
W Wolf ウルフ
X Xmas クリスマス
Y Yogurt ヨーグルト
Z Zebra ゼブラ
a and アンド
b big ビッグ
c clean クリーン
d damage ダメージ
e evil イーブル
f fake フェイク
g get ゲット
h hit ヒット
i ice アイス
j jump ジャンプ
k kick キック
l love ラブ
m magic マジック
n no ノー
o oily オイリー
p poison ポイズン
q quiz クイズ
r rain レイン
s solty ソルティー
t trendy トレンディー
u up アップ
v victory ビクトリー
w wind ウィンド
x xrated エックスレーテド
y your ユワ
z zenith ゼニス
0 0 （数字）
1 1 （数字）
2 2 （数字）
3 3 （数字）
4 4 （数字）
5 5 （数字）
6 6 （数字）
7 7 （数字）
8 8 （数字）
9 9 （数字）
+ + （プラス）
/ / （スラッシュ）
= = （イコール）
「 👆 ゲームに出てきそうな 短い英単語を 持ってきたぜ」
「 趣向を変えたんだな」
「 単語の先頭だけ切り取れば BASE64 に戻るぜ」
「 動かしてみましょう」
「 Madam get = = になるぜ」
「 BASE64 より さらに ６倍近く 長くならない？」
「 なりそう」
「 Ｉｄ １０００ で試しなさい」
「 👆 今の３倍ぐらいの長さにすれば 入りそう」
「 ユーザーは 何だこれは？ と思わないだろうか？」
「 思う」
「 あと、 BASE64 は、文字列連結しないのであれば 桁のプレースホルダーの = は省いていいそうよ」
「 ちょっと考えるぜ」
「 👆 欄外に書いたぜ」
「 ぜったい なんのこっちゃ なんだよなあ」
「 それがタイルの名前としての働きを持つと 認識できないのよね」
「 名前 という文化は廃止だぜ」
「 ディーエックス」
「 👆 どうしても 名前を書きたいやつは コメント欄に書け、と親切に 書いておくぜ」
「 （任意） も付けておいた方がよくない？」
「 任意 の意味が分からん人も いるそうだぜ」
「 あんまり 書きすぎると デザインの敗北……」
📅 2023-07-08 タイルを選択したら、照会しろだぜ
「 タイル・パレット上で 範囲選択したら、
そのタイルは すでに登録済みか、まだ登録されていないか、判定しろだぜ」
「 わかったぜ」
（カタ カタ カタ カタ）
「 前のトリック・コードは 奇数回実行すると働くが、偶数回実行すると働かないというバグを踏んだので
対応中」
「 トリックなんかに頼るからよ」
「 👆 登録したタイルの情報を 読み込むようにしたが、
全体的に動きが 怪しいので 調整中だぜ」
「 👆 タイル・コードと コメントの入出力は 動きが付いたぜ」
「 もう寝ろ」
📅 （2023-07-09 sun）タイルが登録されているとき、ボタンのラベルを追加から上書へ変更してくれだぜ
「 日曜日は 昼まで寝た」
「 タイルが登録されているとき、ボタンのラベルを追加から上書へ変更してくれだぜ」
「 分かったぜ」
「 👆 タイルが登録されているときは、ボタンのラベルを 上書 に変えるようにしたぜ」
国際化
「 その 上書 を、 Overwrite にしても ボタンの中に収まるの？」
「 多言語化か……。試してみるぜ」
「 👆 収まらないぜ」
「 じゃあ このアプリは 国際化に耐えられないわよ」
「 横幅が長い……。 海外人、どんな ＵＩ 使ってるんだぜ？」
「 日本人が ビューにたくさん項目を詰めるの こだわるの、
チャイニーズ・キャラクター文化だからなのかな？」
「 欧米の アイコン が、漢字相当なんじゃない？」
「 じゃあ、アイコンか 漢字かを選べるようにしたらいいのか……？」
「 👇 ガイドラインを読めだぜ」
📖 Microsoft ＞ Visual Studio のイメージとアイコン
「 👆 欲しいアイコンが無いし、似たようなアイコンばっかり いっぱいある」
「 👆 ペンが無難だと思う」
「 👆 しかし MAUI にも最初から ちょびっとだけ リソースが入ってるな」
「 MAUI 用のリソース集も どっかで配られてんじゃないの？」
「 👇 フォントでやるのが いいのか～？」
📖 .NET MAUIで、Emoji(絵文字)やIcon(アイコン)を打とう
📖 Google Fonts ＞ Material Symbols And Icons
「 👇 ボタンに アイコン・フォントを表示させるのは どうやるんだぜ？ 画像の方法はあるが」
📖 [.NET MAUI][Button] ボタンにイメージを表示する
「 👇 画像も 文字も アイコン・フォントも 方法を統一してくれたらいいのに……」
📖 Font Icons in Shell Tabs not showing
「 👆 あれっ？ 文字化けだ。 Windows 11 には Segoe Fluent Icons フォントは最初から入ってると 読んだが……」
「 お父んのＰＣ、 Windows 10」
「 マルチ・デバイスのプログラミングが ホストＯＳに依存したら 悪いんじゃない？」
「 👇 どこから Segoe Fluent Icons フォントを入手するんだぜ？」
📖 Microsoft ＞ fluentui-system-icons
「 👇 情報ではなく、フォントが欲しい」
📖 Microsoft ＞ Segoe UI font family
「 👇 ずっと前から シーゴーは Windows に入っているみたいだけど」
「 👇 シーゴーは 日本語フォントではない、という話しもあるわね」
「 日本語の設定のまま シーゴー を使えないのかだぜ？」
「 👆 フォントのような不確定要素を使うのは諦め、ビジュアル・スタジオ２０２２イメージ・ライブラリーから
ザムルを取ってくることにするぜ」
📖 Microsoft ＞ リソース ディクショナリのマージ
「 👆 リソース・ディクショナリーとして マージすれば 使えるか？」
「 👆 リソース・ディクショナリーの書き方を忘れたので 調べるぜ」
「 👆 あのＸＭＬタグに挟めばいいのか」
「 👆 ビジュアル・スタジオ２０２２イメージ・ライブラリーの Edit.xaml の Viewbox を、貼り付けるぜ」
「 そういう手間が要るんだな」
「 👆 ダメだ 仕様が旧い」
「 SVG形式にしたらいいんじゃないの？」
「 👇 SVG は、画像じゃなくて アイコン扱いなのか？」
📖 I can't set a .svg file as a maui app icon
「 📂 Resources/Images フォルダーは 何か特別な管理下にあるみたいで ふつうのフォルダーのようには扱えなさそうだぜ」
「 MAUI は、ファイル・パスという概念を 無くしたいのでは？」
「 スマホ・デバイスへの対応のために？」
「 👆 MAUI の最初に出てきた ロボット、あいつ SVG画像らしい。
あいつは 表示されて、
ペンを ボタンの上に表示できないの、何故だぜ？」
「 👆 なんで ペン がでかい？
そして SVG なのにラスタライズされてる？」
「 👆 さらに なぜ .svg ではなく .png にしないと画像が出てこない？」
「 自動で ラスタライズ されているのでは？」
「 👆 フォルダーを切って その中に入れると、パスでアクセスできなくなるのは 何故だぜ？」
「 👇 これを読めだぜ」
📖 Add images to a .NET MAUI app project
「 Android アプリがこうしてるから、 MAUI もこうしてる、というような 腰抜けの話しが 書かれているぜ。
クソじゃないか」
「 なんで Android アプリに迎合するのかしら？」
「 Microsoft が腰抜けだからだろ」
「 👇 これを読めだぜ」
📖 Images in subfolders not showing up on Windows but do on Android #8628
<ItemGroup>
<MauiImage Include="Resources/Images/XXXXXXXX/*" />
</ItemGroup>
「 👆 なんか こういうタグをどこかに書くと そのフォルダーがプロジェクトに認識されるらしいぜ」
「 それは どこに書くんだぜ？」
「 ファイルを開けまくって 消去法をしている途中で 2D RPG Negiramen.csproj に それっぽいコードを発見したぜ」
「 書き足してみましょう！」
「 👆 \* を、 \**\* に変えると、
直下フォルダーの任意のファイルではなく、
サブフォルダ―も下りて行って任意のファイルを 見てくれるようだぜ」
「 👆 また、 Android に迎合して、ディレクトリー名、ファイル名に 大文字や空白は使えず、
小文字英字、ハイフン、数字だけを使うようにするぜ」
「 👆 そして ディレクトリーは無視されるという クソ仕様により、
ファイル名だけで指定することになるぜ。拡張子は、ファイル名に .png と付いていても XAML には .png と指定するクソ仕様」
「 MAUI は、プラットフォームごとに 異なる画像ファイル形式で用意されても、
XAML には .png と書こうという MAUI の開発者の頭が残念なことに なってるのね～」
「 ラスター画像と ベクター画像の特性の違いも理解できないぐらい 知能が下がってるのかだぜ？」
「 👆 ファイル名が被りたくないので プレフィックス（Prefix；接頭辞）を付けるぜ」
「 インフラの出来が悪いと 要らんテクニックが使われてしまうな」
「 フォルダー下に、別の命名システムを持ったフォルダーを ぶらさげたいこともあるのに、
それが考慮されていないのは
MAUI の開発者が 開発の現場経験が未熟だろうから 全員クビになっても 不思議ではないわねえ」
「 👆 SVG形式画像を PNG形式画像に変換した後のものが ボタンの上に描かれるから、
テキスト・カラーを 白 にしても 白くならないぜ！」
「 当然だな」
「 MAUI お前 コンピューター・グラフィックスという 自覚 無いのかだぜ？」
「 MAUI の開発者も いずれ全員 クビになるでしょう」
「 👇 代替策を探さな」
📖 Specify the color of a SVG image in .NET Maui
「 👆 TintColor も効果なし」
「 MAUI の出来が悪いんじゃないの？ あんまり 期待できないんだから
トリックを使っていくことに なるんじゃない？」
「 じゃあ ツールチップ・ヒント の使い方を調べるか」
「 👆 ボタンは 横に広く使うように 妥協。
ツールチップ・ヒントも 組み合わせたので、
国際化は 少々横長のボタンと ツールチップ・ヒントで なんとかしてくれだぜ」
「 タイル名、または コメントを自由入力 というメッセージが ダサいから タイル名 だけでよくない？」
「 👆 すっきりさせたぜ」
多言語化
「 英語版、日本語版と どうやって切り替えるんだぜ？」
「 調べるか……」
📖 .NET MAUI : Write multilingual apps easily
「 👆 Xamarine の方法がそのまま使えるらしいが、それでいいのか もっと調べるか……」
「 👇 昔の Windows のやり方も 冴えてないしなあ」
📖 How to implement .NET MAUI localization
「 👇 この動画の人 センス有るな 調べてみるか」
📺 Localization in .NET MAUI - Adding Multi-Language to Your Apps
「 👇 サンプルまで 用意されてる」
📖 .NET MAUI Localization Sample
「 👆 サンプルは動くが、どうやって 📂 Languages フォルダーを作ったのか
手順が分からんな」
「 👇 ResXManager は 多言語化の鉄板ソフトなんで インストールしておこうぜ」
「 しかし ResXManager の画面は どこから出すんだぜ？」
「 👆 このリンク クリックしたら 何か出てくるかな？」
「 👆 昔ながらの場所に作られたが、そこじゃなくて
📂 Resources/Languages フォルダ―の下に置いてほしいんだぜ」
「 👆 サンプル見ると、単に ファイルを移動しただけに見えるな……
やってみるか」
「 👆 自動で ネームスペースも調整してくれるのかな？」
「 👆 ファイル名も Resources から AppResources に変えたろ」
「 👆 LocalizationResourceManager クラスを真似して 自分用に設定」
「 👆 アプリケーション起動直後に 文化を日本に設定。
わたしが日本語しか確認しないから 日本がデフォルトでいいだろ」
「 👆 TranslateExtension も真似て作り、自分に合わせて編集」
「 👆 ビューのコード・ビハインド、つまり ContentPage の継承クラスには
ローカライゼーション資源管理へのアクセッサ―を書いておくぜ」
「 👆 とりあえず AppResources.resx へ、 １件だけ 文字列リソースを 記入するぜ」
「 👆 MainPage.xaml に xmlns:app="～" を追加し、
Text プロパティへ {app:Translate LayoutTheScreen} と書いてみるぜ」
「 👆 実行すると、文字列リソースが 使われているな」
「 カルチャーを変更するドロップダウン・リストみたいなものが欲しいわねえ」
外国語を入力してくれだぜ
「 試しに 英語と 中国語のリソースも 作ってみてくれだぜ」
「 👆 ResXManager がインストール済みなのは確認できるんだが、
どこから実行するんだぜ？」
「 👆 あっ、いた！」
「 👆 ここまでくると あとは わかる」
「 👆 ニュートラル・リソース・ランゲージを 英語から 日本語へ 変えるぜ。
理由は 開発者が わたし１人だから」
「 悲しい話しだぜ」
「 👆 言語を追加するボタンがあるぜ」
「 👆 とりあえず イーエヌ・ユーエス（en-US；英語（米国））は 必須だろ」
「 👆 とりあえず ３つも足しておけば十分だろ」
「 アジアに寄ってんな」
「 👆 ばばばっと 翻訳して 空いてるとこ 埋めてくれる機能があるから
使おうぜ？」
「 👆 なぜか 英語しか 対応してくれなかった。 寄付が足りないとか？」
「 👆 AppResources.en-US.resx ファイルが増えてるぜ」
「 👆 ＩＳＯ言語コードを変えると」
「 👆 翻訳が完了だぜ」
「 📂 Languages フォルダーの中をサーチして、翻訳できる言語を調べて
言語を選べるリスト・ボックスが欲しいわねえ」
「 そのフォルダーに アクセスする方法が 見当つかないんだが」
「 👆 実行環境を見にいってしまうので、開発環境のプロジェクト・フォルダーの中とか見れないのでは？」
「 👇 じゃあ ビルド前のイベント を書いたらいいんじゃない？」
📖 Pre build Events in Visual Studio
「 そこで ベッタリ Windows 依存しそうだしな」
「 じゃあ ＩＳＯ言語コードは ハード・コーディングかな」
「 国旗って フリー素材であるの？」
「 👇 同じ問題に突き当たっている人がいるぜ」
📖 Is there a way to get a flag image from a C# CultureInfo?
「 👇 WPF で作った人はいるみたいだな」
「 こういう センシティブな素材は デジタル庁 が作って欲しいものだぜ」
「 国旗は後回しにし、ＩＳＯ言語コードのドロップダウン・リストを
ハードコーディングする方向で 次回 考えようぜ？」
📅 （2023-07-10 mon）日本語か、英語かを選べるドロップダウン・リストボックスを置いてくれだぜ
「 日本語か、英語かを選べるドロップダウン・リストボックスを置いてくれだぜ」
「 まず MAUI に ドロップダウン・リストボックスがあるのかどうかも 分からないしな。
調べないとな」
「 👇 マイクロソフトの記事、映像がなくて どんな画面が出てくるのか 分からん」
「 👇 ユーチューブで探せばいいのよ」
📺 How To Create Custom Picker Control (Dropdown Button) In .NET MAUI
「 👇 作ってみるのが早いか」
📖 ピッカー
「 👆 こう書けば」
「 👆 ドロップダウン・リストボックスが出てきて……」
「 👆 選べるぜ」
「 それが欲しかったのよ」
「 初期状態で ja-JP を選んでおいてくれだぜ」
「 👆 ピッカーに 最初に選択されている値を表示することは できないぜ」
「 じゃあ、値が最初に選択されていることを ピッカーでどう表現するんだぜ？」
「 マイクロソフトの社員の知能が欠如していて それはできないぜ」
「 👇 初期値を表示するのって HTML の Select タグの Option 要素の Selected 属性でも指定できるのに、
MAUI で 何でできないの？」
「 マイクロソフトの社員が欠陥だからだぜ」
「 マイクロソフトの社員が欠陥だというところまでは 事実と認めましょう。
それは置いておいて わたしたちは ピッカーに初期値を表示したいのよ。どうしたらいいのよ？」
「 ピッカーを使ってはいけないのでは？」
「 👆 ContentPage 要素に Loaded 属性を追加して……」
「 👆 コード・ビハインドで picker.SelectedItem = "ja-JP"; とでも書いておけば……」
「 👆 ページの表示完了時には ピッカーで ja-JP が選択されている、という状態にできるぜ」
「 XAML だけでは モックアップも作れないんだな」
「 MVVM に対応できんの？」
「 トップページは MVVM にまだ対応してないんで、これから対応させるぜ」
（カタ カタ カタ カタ）
「 あの １．５日 ぐらい 工数かかったやつ」
「 でけた。 さっきのイベントハンドラも コード・ビハインドも要らんかった。
MVVM だけでいけるぜ」
「 マイクロソフトの社員は欠陥じゃなかったんだな」
「 まだ 首の皮一枚つながったぐらいだな」
📅 （2023-07-10 mon）タイル・パレット編集画面も多言語化しなさいよ
「 タイル・パレット編集画面も多言語化しなさいよ」
「 あとから 多言語化しようとして レイアウトの変更が必要になったりしたら 大変だしな」
ramen-tabero-futsu2.png
「 👆 この アイテム・リソースも ハード・コーディングじゃなくて
どこかのファイルにまとめて、一元化したいんだが」
「 App.xaml に リソース・ディクショナリーを作って、それを読み込んだらどうだぜ？」
「 👇 テンプレートは リソースにできるが、 データは リソースにできないんじゃないか？」
「 ItemSource の使い方が分からん。調べても出てこないぜ」
「 この前の多言語化のときの おっさんの You Tube に なんか まとまってんじゃないの？」
「 👇 このおっさんは MAUI を作ったチームの中の人らしいぜ」
「 じゃあ その動画を しばらく視聴する！」
📅 （2023-07-11 tue）寝てた
Zzz
📅 （2023-07-12 wed）動画観るか～
「 動画 観るか～」
📅 （2023-07-13 thu）分かんね
「 👇 英語で 何言ってるか 分かんないんだが」
「 猿を１匹記録するクラスを作るんだけど、例が JSON なのよ」
「 じゃあ 真似して 言語を１つ記録するクラスを作るかだぜ」
Name,
ja-JP,
en-US,
「 👆 📂 Releases/Raw フォルダーの中に 📄 languages.csv ファイルを作ろうぜ？」
「 その１行に対応する Language クラスを 📂 Models フォルダーの下に作りましょう」
「 なんか無駄臭いクラスだな……」
「 👆 プロパティ１個 置いとけばいいのかだぜ？」
「 C# に、 CSV をシリアライズする仕組みなんか あるのかだぜ？」
「 👇 人気があるのは これかしらねえ？」
「 使い方を覚えるか……」
「 👆 NuGET でインストール」
「 Resources/Raw フォルダーの中にあるファイルって どうやって読取るんだぜ？」
「 👇 調べろだぜ」
📖 Microsoft ＞ Bundled Files
📖 Get Resources\Raw Path in .NET Maui
「 👆 None とか Remove って何だぜ？ 無いことになってんの？」
「 👆 ビルド・アクションを何か変えたらいいのかだぜ？」
「 👇 ビルド・アクションの説明はこれだが」
「 CSVファイルは どう配置すりゃいいんだぜ？」
「 👆 出力ディレクトリーにコピー を 新しい場合はコピーする に変えたら、何が起こるんだぜ？」
「 👆 なんで２つあるんだ？」
「 コピーをしなければ bin フォルダーの下に languages.csv はなく、コピーすると２つある」
「 Visual Studio のコンフィグ・ファイルは無いの？
インストール時に 作業ディレクトリーを設定できなければ、
設定ファイルの置き場所も 定まらなくない？」
「 アプリケーション・フォルダーに置いてくれないのかだぜ？」
ItemSource 分からん
「 じゃあ いったん、言語のリストは ハード・コーディングするものとしようぜ？」
「 ItemSource って 何を設定できるの？」
「 恐らく、ビューモデルの 変更通知プロパティじゃないか？」
「 👆 変更通知プロパティを ふつうに作って」
「 👆 ItemSource に バインドすれば うまくいくぜ」
「 どのページにも 言語ピッカー を置きたいときは、
どのページにも LanguageCollection 変更通知プロパティーを作ることになるの？」
「 そうじゃないか？」
「 👆 ロケールＩｄのリストなんか 途中で変わらないだろ。
セッターのないプロパティとして、グローバル変数のように利用できるように App クラスに定義しようぜ？」
「 👆 変更できない変更通知プロパティなら、グローバル変数を取得してても 不整合は起こらないだろ」
「 これを ビューモデルに置きまくるのか」
配色変更
「 👆 テキストボックスの白が目立つように 配色を変更し、
ロケールＩｄのピッカーを 右上に置いたぜ」
「 色を使いすぎてんじゃないの？ 青だけでも３色もある」
「 タイトルバーの色を 減らしてみるか……」
「 MAUI のスタイルシート的なものは どこにあんの？」
「 👆 📂 Resources/Styles フォルダーの下にあるぜ」
「 👆 色の主張を 抑えたぜ」
「 テキストボックスの白と黒も きつい 気がするのよね」
「 👆 ダーク・モードのことを考えずに いじってしまった。
どこか 壊してしまったかも知れないが 分からない。
勘弁しろだぜ」
「 👆 トップページの配色も 白が無くなるように ゲインズボロ という色をベースに敷いたが
ダークモードにしたら どうなるのか 知らん」
「 もう寝ろ」
📅 （2023-07-14 fri）登録済みタイルがどれか分かるようにしてくれだぜ
「 登録済みタイルがどれか分かるようにしてくれだぜ。 例えば……」
「 👆 こんなふうに」
「 タイルは 重なって登録されることは あるのかだぜ？ 例えば……」
「 👆 上図 ４～９」
「 あるある。 タイル・セットは それ自体が パレットのような配置をしているのよ」
「 タイル・セットと パレットは 意義を分けたいな……」
「 👆 ロジカルには こうなるはず」
「 上図の ７ を範囲選択するの 難しくない？」
「 ゲリマンダー（Gerrymander）みたいな形や、飛び地が必要かどうかも 洗い出したいぜ」
「 ひとまず 矩形だけでいいのではないか？」
「 じゃあ 被りは有りで 話しを進めるかだぜ」
「 👆 なんか ファイルにいっぱい保存されているぜ」
「 同じ矩形を 何個も登録してるわねえ」
「 ファイルのバリデーターを作るべきだが、とりあえず 手作業で直せだぜ」
「 👆 Excel で CSVファイルを開いたら 文字化けしてるんだが……」
「 BOM付きの UTF-8 じゃないと Shift-JIS と判定されてるわよ」
「 👆 BOM 付きの UTF-8 にしたら 文字化けが直った！」
「 👆 こういう感じのデータを、エディター上で どう表示するかだよな」
IDrawableインターフェース実装クラスの Draw関数にビューモデルからどうやって値を渡すんだぜ？
「 👆 IDrawableインターフェース実装クラスの Draw関数にビューモデルからどうやって値を渡すんだぜ？」
「 👇 これを読めだぜ」
📖 In .NET MAUI, how do I pass variables to a GraphicsView.Drawable in a ContentView
📖 How to pass variable data into .NET MAUI GraphicsView canvas
「 👆 なんだか分からないが 束縛可能プロパティ の書き方のパターンを なぞろうぜ」
「 👆 さっきの IDrawing 実装クラスは、リソースとして ContentPage に読み込まれて……」
「 👆 GraphicsView 要素で使われているな」
「 👆 それを いったん、こう書きかえるぜ」
「 これでいいなら ビュー・モデルの変更通知プロパティを、
IDrawable クラスの束縛可能プロパティに 渡すことができそうねえ」
「 👆 ビュー・モデルに 変更通知プロパティを書いて……」
「 👆 ビューで 変更通知プロパティを束縛」
「 👆 IDrawing 実装クラスは 束縛可能プロパティに値が入ってくるんで
グローバル変数を１つ 取り除くことに成功だぜ」
「 IDrawing 実装クラスから グローバル変数を取り除いていきましょう！」
「 つら……」
（カタ カタ カタ カタ）
「 ヌル参照例外が出て 動かなくなった つら……」
「 さらに まずいことに 線の太さが ０ になり、
for 文で 横に ０ 移動しながら 縦線を引く 無限ループに陥った……」
「 束縛プロパティの初期化が始まる前に Draw メソッドが呼び出されているのでは？」
「 どっちが頭で どっちが尻尾問題で、
IDrawable 実装クラスのプロパティが、ビュー・モデルのプロパティーを上書きしてくることはないだろうか？」
「 Way を指定したらいいんじゃないの？」
「 👆 そもそも 変更通知が届いてないぜ」
「 グローバル変数が いつ変更されたとか、ビューモデルには 分からないからな」
「 グローバル変数を 使わないようにしたが、束縛プロパティが 渡せていないぜ」
束縛プロパティを練習しようぜ？
「 👇 GraphicsView の Drawable クラスの Draw 変数へ、プロパティを渡すだけのサンプル・プログラムを組んでみようぜ？」
📖 Git Hub ＞ Muzudho ＞ MAUI-BindableProperty-Practice
「 👆 しばらく 練習するぜ」
「 👆 Binding したら 動かないぜ」
「 Bindable なプロパティなのに Binding したら動かないなんてことが あるのかしら？」
「 👇 よく読んでくれだぜ」
「 👆 確かに 変更前と、変更後の値を取れて 気が利くが、
そういうの 自動でやってくれるわけじゃないのかだぜ？」
「 いや、取れてないぜ。 Binding したものは 取れてない」
「 👇 もっと調べろだぜ」
📖 Binding not working on custom BindableProperty
「 GraphicsView はビュー・モデルを持ってないから Simple30 を Binding しようとしても持ってないんで、
親コンポーネントのビュー・モデルを指せ、ということらしい」
「 どうやって」
「 👇 もっと調べろだぜ」
📖 .NET Maui Binding a contentview to parent ViewModel MVVM
📖 ContentView
「 ContentPage 使ってるのに、 ContentView の説明されても 利用できないぜ」
（カタ カタ カタ カタ）
「 よし、分かった！」
「 👆 ビューの コード・ビハインドに、
バインディング・コンテキストを公開する パブリック・メソッドを書くぜ」
「 そんなことをしていいのかだぜ？」
「 ＭＶＶＭが 崩壊したんじゃないの？」
「 👆 ビューの ContentPage 要素に、 x:Name 属性を付けて、その値を thisContentPage とでもしておくぜ」
「 👆 これで MainPageVM プロパティが公開されてるんで、そのメンバーにアクセスできるぜ」
「 この記事の ２回目の トリック・コードだな」
「 👆 ViewModel はこんな感じ」
「 👆 線も引けてるぜ」
「 バインディング・コンテキストを公開しているのが 気になるなあ」
「 👆 グローバル変数を減らし、 BindableProperty を使って GraphicsCanvas の Drawable 属性のクラスの
Draw メソッドに プロパティ値を渡すことに成功したぜ」
「 ViewModel を public にするのは心理的抵抗がある。
公開するのは interface にして、プロパティだけ公開しろだぜ」
「 かしこいな」
📅 （2023-07-15 sat）タイル・セット上を矩形で塗りつぶしてくれだぜ
「 タイル・セット上を矩形で塗りつぶしてくれだぜ」
「 キャンバスで描画するのか、画像オブジェクトでピクセルを直接描画するのがいいのか」
「 インプレース（In-place）で クロップ（Crop）と コピー（Copy）を１ステップでできないと
実行速度が遅くなるんじゃないの？」
「 画像は Microsoft.Maui.Graphics.IImage というインターフェースに抽象化されていて、
とても 高速に画像を描画することを指向しておらず、
マルチ・プラットフォームで一番性能の低いマシンで動くように考慮されてる護送船団方式の雰囲気を感じるぜ」
「 性能 上げたけりゃ MAUI なんか使うなだぜ」
「 ぐぬぬぬぬ！」
「 この IImage インスタンスは あくまで 画像ファイルを指さしているだけで、
描画をするときは GraphicsCanvas を使えという思想なのかもしれない」
「 画面の描画前に 画像の前処理を 終わらせておきたいことなんて
いっぱいあると思うのに
キャンバスを用意してから 画像処理しなくちゃいけないのね」
「 画像処理 したけりゃ MAUI なんか使うなだぜ」
「 ふむむむむ！」
「 じゃあ 画面上に キャンバスを２層に重ねて表示することにして、
元画像を下レイヤーに、作業用レイヤーを上レイヤーに置いて
作業用レイヤーに いろんな加工をしていくことにしようぜ？」
「 キャンバスの練習を先にしておいた方が いいんじゃない？」
「 👇 リポジトリ―は作っておいたぜ」
📖 GitHub ＞ Muzudho ＞ MAUI-IDrawable-Practice
「 変更通知プロパティを バインディング しただけでは
Draw は呼び出されないのか」
「 GraphicsView に Draw メソッドの呼び出しを要求するの、どうやればいい？」
「 👇 読めだぜ」
「 👆 GraphicsView 要素に x:Name 属性を使って名前を付けて……」
「 👆 コード・ビハインドで GraphicsView 要素の Invalidate( ) メソッドを呼び出せば いいわけかだぜ」
「 ビューモデルで Invalidate( ) メソッドは呼び出せないのかだぜ？」
「 画面の更新は ビューモデルの仕事では 無いのでは」
「 👆 よっしゃ ２Ｄ描画にも 慣れてきたぜ」
１つのキャンバスで何でも描画するのと、複数のキャンバスに分けるの、どっちが得？
「 お父んは タイル・カーソルと グリッドと タイル・セット画像を 分けて 置いているが、
そのようにするのと、１つのキャンバスの上に全部描くのとでは、どっちが得なんだぜ？」
「 何も考えなければ １つのキャンバスの上に全部描くのが お得だぜ」
「 グリッドを分けた理由は？」
「 グリッドは ヴィジブル（Visible；可視性）を オン・オフ したいときがあるだろ。
フラグ１個だけで できるというメリットを生かしたい」
「 ライフ・サイクルに似た考え方か」
「 じゃあ カラード・マップ（Colored Map）のキャンバスも １つ用意したいわねえ」
Draw が呼び出されるのが Loaded より早い
「 GraphicsView の初期設定をする前に Draw が呼び出されているぜ」
「 👇 イベントの呼び出し順序の話しは 書いてないなあ」
「 あっ、違うぜ」
「 束縛プロパティの 返り値の型の指定を 間違えていた」
「 設定ミスは エラー・メッセージを出してくれないからなあ」
「 👆 薄いグレーを被せてみたが、
どうやっても 視認性が悪くならないか？」
「 もとの画像の 明度を下げてみたら？」
「 👇 明度を下げるとか 上げるとか 説明無いぜ？」
「 ピクセルに アクセスする手段 無いの？」
「 👇 スキア・シャープ（Skia Sharp）というものが あるそうだぜ？」
📖 .Net Maui - Create ImageSource from pixel data
「 何だぜ それ まだまだ勉強か……」
SkiaSharp を調べようぜ？
「 👇 リポジトリは作っておいたぜ、勉強しろ」
📖 GitHub ＞ Muzudho ＞ MAUI-SkiaSharp-Practice
「 👆 とりあえず SkiaSharp をインストールするか」
「 👇 スキア・シャープの使い方の説明が無いぜ」
「 👇 サンプル・プログラムを直接読めだぜ」
📖 SkiaSharp/samples/Basic/Maui/SkiaSharpSample/MainPage.xaml.cs
「 GraphicsView じゃないんだ」
「 👇 画像処理っぽいことしてるが、学習コストが高そうだ」
📖 Understanding SkiaSharp and Maui Coordinates
「 👇 ここに ピクセル単位でのアクセスの仕方が書いてあるのでは？」
📖 SkiaSharp ビットマップ ピクセル ビットへのアクセス
「 まあ、午前中に独習してきた GraphicsView は使わないというのは 分かったが……」
「 将来的にやろうとしていることを考えると、 GraphicsView では限界がくるんじゃない？」
「 👆 SkiaSharp.Views.Maui.Controls をインストールしてみようぜ？」
「 👆 xml の namespace として
xmlns:skia="clr-namespace:SkiaSharp.Views.Maui.Controls;assembly=SkiaSharp.Views.Maui.Controls"
を書き足すぜ」
「 👆 これで skia:SKCanvasView を使えるようになったはずだぜ」
「 使えなかった。エラーが出た」
「 👇 SkiaSharp.Views.Maui.Core はインストールしてんの？」
「 👆 どれをインストールすりゃいいのか 分からんな」
「 👇 コマンドラインからやってみるか」
dotnet add package SkiaSharp.Views.Maui.Core --version 2.88.3
「 👆 なぜ文字化けする？」
.NET Core の文字化けに対応しろ
「 👇 ダメ元で 試してみるか」
// NuGET のパッケージ・マネージャー・コンソールの文字化けに対応を期待したが効果なし
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
「 👆 ダメだった」
📖 パッケージマネジャコンソールにおける dotnet コマンド出力の文字化け
dotnet --help
「 👆 ヘルプも文字化けしている」
PM> chcp
現在のコード ページ: 932
「 👆 マイクロソフトの S-JIS ではダメだ」
PM> chcp 65001
Active code page: 65001
「 👆 コードページを 65001 に変えたったが ダメだ」
マイクロソフトのスキアを入れてみようぜ？
「 👆 方法も無いし、 Microsoft.Maui.Graphics.Skia でもインストールしてみようぜ？」
「 もう 思考が停止してるの わらう」
「 インストールしたところで 何も起こらん」
「 思考をしなさい！」
キャンバスではなく、イメージの方を調べようぜ？
「 👇 描画回りは 対応が遅れてるのかも知らん」
📖 .NET MAUIによるクロスプラットフォーム2D描画(その1)
「 👇 MAUI は SkiaSharp をベースに使ってるんだろう」
「 👇 キャンバスではなく、イメージの方に ピクセルにアクセスするメソッドがあるんじゃないの？」
「 👆 イメージは バイトに分解できるのか」
「 じゃあ バイトは イメージに 構成できるのかだぜ？」
「 👇 調べろだぜ」
📖 ByteArrayToImageSourceConverter
📖 MAUI: How to draw image from byte[] on MAUI
「 画像は バイトに分解できるけど、 バイトは 画像に構成できないのか」
「 👇 じゃあ バイト配列を 直に PNG画像として出力すればいいんじゃないの？」
📖 Create a PNG from an array of bytes
「 ファイルの書出しと 読込みたいな 重い処理やるんだったら なんのための画像処理か 分からんが……」
「 MAUI で画像処理しようとするのが 間違いなのでは？」
アホな記事ばかり
「 👇 公式の記事を なぞってるだけじゃないか。アマチュアのコピー記事が」
📖 Handling Images With .NET MAUI Graphics
「 真実に対して 怒るなだぜ」
「 明度を下げたいとか、特定の色だけを抽出したいとか、そういう知能はないのかだぜ、記事を書くやつは？
知能だけではない 意志も無い。
インターネット上のアマチュア記事は 公式のダウングレードばかり 情報を増やさない。
筆を折れだぜ」
「 スキアシャープのエラーを取るしかなくない？」
再び SkiaSharp を調べようぜ？
「 👆 とりあえず、NuGET で 正しい SkiaSharp をパッケージ単位でダウンロードして
アセンブリを使えるようにするところからだぜ」
「 👆 だから この SkiaSharp パッケージを入れておくだけで 充分なはずなんだが」
「 👆 だから この SkiaSharp に SkiaSharp.Views は入ってないようだぜ」
「 👆 SkiaSharp.Views パッケージもインストールしてみるかだぜ」
「 👆 だから この SkiaSharp.Views には SkiaSharp.Views.Maui は入ってないようだぜ」
「 👆 似たような名前のパッケージが並んでいて困るが
とりあえず SkiaSharp.Views.Maui.Core パッケージを インストールしてみるかだぜ」
「 👆 SkiaSharp.Views.Maui.Core には SkiaSharp.Views.Maui.Controls は入ってないようだぜ」
「 👆 じゃあ SkiaSharp.Views.Maui.Controls パッケージを インストールしてみるかだぜ」
「 👆 ビルドは通ったぜ」
「 👆 実行すると 立ち上がる前にエラー」
「 その理由を調べなさいよ」
「 UnhandledException というのは ライブラリが 例外が起こっているのにキャッチせずに終了したということだぜ」
「 だから、その理由」
「 カタストロフィック（Catastrophic；大災害的）な フェイラー（Failure；失敗）だぜ」
「 なんのことだが 分からんな……」
「 👇 同じ不具合に突き当たっている人がいるわよ」
📖 [BUG] MAUI: SKCanvasView crash, unable to display SKBitmap directly #2139
「 👆 どこにも説明が無いが 謎のコードを書き……」
「 👆 実行するとこまでは イケた」
「 ようやく 画像処理のスタートラインに経ったな」
「 じゃあ SkiaSharp のサンプル・プログラムを真似たろ」
（カタ カタ カタ カタ）
「 👆 文字が出た」
「 じゃあ 文字の代わりに 画像を表示してみなさいよ」
SkiaSharp で画像を表示しろだぜ
「 👇 画像の用意の仕方が分からん」
「 👇 SKBitmap なら、ストリームから作れるんじゃないか？
SKImage は、SKBitmap を読込むメソッドを持っているだろ」
「 そのサンプル・プログラムが欲しい」
「 👇 Xamarine の利用者は SkiaSharp に詳しいらしいぜ」
「 知らん世界だ。真似するかあ」
「 👆 おー、描画できたぜ。
基本的にラスター画像は SKBitmap で記憶しておいて、
表示するときは SKBitmap を SKImage でラッピングすればいいわけだぜ」
「 じゃあ あとは ラスター画像の容量で 画像処理できるな」
「 もう寝なさい」
📅 （2023-07-16 sun）画像の明度を下げてくれだぜ
「 画像の明度を下げてくれだぜ」
「 愚直に １ピクセルずつ 変更するコードなら すぐ書けそうだが、
並列処理に有利な コードの書き方が 分からんな……」
「 👇 これを読みなさい」
📖 SkiaSharp ビットマップ ピクセル ビットへのアクセス
「 マイクロソフトの記事の コード・サンプルのリンク クリックしても
コード・サンプルが置いてないの 何でなんだろな？」
「 実行速度の検証は iOS、 Android、 UWP で行われていて、 Windows が含まれていないのは何でだぜ？」
「 Windows 上で Windows 向けのプログラム書いたら有利なの明らかだからよ。
UWP というのが Windows なのよ」
「 unsafe 使って uint のポインター型を使うのが そら早そうだが、
unsafe を使いだしたら C# というより C言語だしな」
「 画像処理の高速化というのは アンセーフなものでは？」
SKBitmap FillBitmapUintPtrColor(out string description, out int milliseconds)
{
description = "GetPixels SKColor";
SKBitmap bitmap = new SKBitmap(256, 256);
stopwatch.Restart();
IntPtr pixelsAddr = bitmap.GetPixels();
unsafe
{
for (int rep = 0; rep < REPS; rep++)
{
uint* ptr = (uint*)pixelsAddr.ToPointer();
for (int row = 0; row < 256; row++)
for (int col = 0; col < 256; col++)
{
*ptr++ = (uint)new SKColor((byte)col, 0, (byte)row);
}
}
}
milliseconds = (int)stopwatch.ElapsedMilliseconds;
return bitmap;
}
「 👆 先頭から末尾まで 色を置き換えながら シーケンスしてるだけだ やってることは簡単だ
真似るか」
「 👆 じゃあ今後、ネギラーメンでは アンセーフなものも 使っていくことにするぜ」
「 int 型のメモリ・レイアウトは red, green, blue, alpha で確定かだぜ？
環境により異なるかだぜ？」
「 ビッグ・エンディアン、リトル・エンディアンが関わってくるかどうか 知らないぜ？」
ここでのコードでは、バイトが赤、緑、青、アルファの順序であり、色の SKColorType.Rgba8888 種類と一致していることを前提としています。 これは iOS と Android の既定の色の種類ですが、ユニバーサル Windows プラットフォームでは使用されないことを思い出してください。
「 👆 環境によって異なるそうよ」
namespace MauiApp1;
using SkiaSharp;
/// <summary>
/// 明度を下げる
/// </summary>
internal static class ReduceBrightness
{
// - インターナル静的メソッド
/// <summary>
/// そうする
/// </summary>
internal static SKBitmap DoItInPlace(SKBitmap bitmapInPlace)
{
IntPtr pixelsAddr = bitmapInPlace.GetPixels();
int width = bitmapInPlace.Width;
int height = bitmapInPlace.Height;
unsafe
{
uint* ptr = (uint*)pixelsAddr.ToPointer();
for (int row = 0; row < height; row++)
for (int col = 0; col < width; col++)
{
// ビッグ・エンディアンか、リトル・エンディアンかの違いを吸収してくれることを期待して
SKColor color = new SKColor(*ptr);
// RGB値が減れば、暗くなるだろ
*ptr++ = (uint)new SKColor(
red: (byte)(color.Red * 0.7),
green: (byte)(color.Green * 0.7),
blue: (byte)(color.Blue * 0.7));
}
}
return bitmapInPlace;
}
}
「 👆 なるほど、
ビッグ・エンディアンか、リトル・エンディアンか、環境の違いを吸収しようとすると
ちょっと 遅くなるのか、まあいいか」
「 👆 明度を下げることはできたが、再描画のたびに どんどん暗くなって 真っ黒になる。
コードを書く位置を ミスった」
タイル・パレット編集画面のタイル・セット画像の明度も下げてくれだぜ
「 タイル・パレット編集画面のタイル・セット画像の明度も下げてくれだぜ」
「 GraphicsView と、 SKCanvasView の結局どちらも 用途に応じて使い分けることになるの
学習コストと、脳への負荷が高いな」
「 フォルダーの整理も大変だ。
MAUI のフレームワークに従うものと、
SkiaSharp という異質なものを どう配置しよう」
「 FeatSkia みたいなフォルダーを作って
そこに放り込めば？」
「 ミュージシャンみたいだな。
そもそも Skia って何だ？ 調べるか」
「 👆 元は 会社名らしい」
「 👆 SkiaSharp.Views.Maui.Controls パッケージをインストールすれば、必要なものは 自動的にインストールしてくれるようだぜ」
「 👆 MauiProgram.cs に builder.UseMauiApp<App>().UseSkiaSharp(); って書く必要があるの、
探さないと見つからない 分からんと思う」
「 👆 画像処理は とりあえずお試しに FeatSkia フォルダーを作って そこへ入れよう」
「 👆 ビューに ネームスペース
xmlns:skia="clr-namespace:SkiaSharp.Views.Maui.Controls;assembly=SkiaSharp.Views.Maui.Controls"
を追加して」
「 👆 SKCanvasView 要素を配置」
「 今回、Touch イベントは要らないんじゃない？」
「 👆 ビューモデルには、 SKBitmap を格納できるようにしておくぜ」
「 👆 描画処理は、ただビットマップを描画するだけにするぜ」
「 コード・ビハインドに 画像処理をベタ書きするのが、 MVVM の思想では イケてないんだろうな」
「 👆 ページの読込完了時に、画像読込と、明度を下げるのを 済ませてしまおう」
「 👆 そして実行。 位置とサイズが合ってないな」
「 👆 位置とサイズを調整」
「 明度を下げたタイル・セット画像の上に、
半透明のグレーの画像を置いているけど、
その２枚は MAUI によって どうブレンドされているの？
加算合成なのか、乗算合成なのか」
「 👇 これを読めだぜ」
📖 ブレンド モード
「 半透明のときの説明は無いな」
「 選択領域か、そうでないかが 明確に見分けられなければ いけなくない？」
「 👆 角丸の矩形でどうだぜ？」
「 暗い場所が残ってると 残差業が残ってるみたいに感じるじゃない。
選択されていないところを 暗くして、 選択されているところは 元の色調にしたら いいんじゃないの？」
「 じゃあ 元画像 は どこかに残しておかないといけないのかだぜ」
「 カラード・マップ（Colored Map） は色分けだろ。
色で分けろよ」
「 👆 青が 暗くなってしまうなあ」
「 青値は 多めになるよう 補正を掛けたら？」
登録タイルの削除ボタンを作れだぜ
「 登録タイルが こんな ぐちゃぐちゃ しているのが悪いんだ。 削除できるようにしよう」
「 追加ボタンと 削除ボタンが こんなに近くにあるのは 悪いデザインでは？」
「 👆 これぐらい 離したらいいかだぜ？」
「 削除ボタンだけ 左に持っていったら？」
「 削除したいときに 不便なのでは……」
ボタンに押した感じを付けれないの？
「 MAUI のボタンって 反応しないから 押した感じがしないけど
ボタンを押したという演出を 付けれないの？」
「 そんなものは ボタンには最初から付いているものと 思っていたぜ」
「 👇 記事を読めだぜ」
📖 【.NET MAUI】Buttonにアニメーションを付けて表示をカスタマイズする
📖 Microsoft ＞ AnimationBehavior
「 👆 名前空間を書いて」
「 👆 ボタンに ビヘイビアを書いたが、アニメーションする様子は無いぜ」
「 👆 この書き方で いけてないのかだぜ？」
「 👆 チェーンにした方がいいのか？」
「 ダメだ ボタンは アニメーションしないぜ」
「 👆 XAML をどう書いても ボタンはアニメーションせず クソだったので
コード・ビハインドに コードを書くことにしたら アニメーションしたぜ」
「 なぜ XAML の設定では アニメーションしなかったのか 謎のままだぜ」
ボタンの上をマウスがホバーしたときに、ボタンの色を変えれないの？
「 ボタンの上をマウスがホバーしたときに、ボタンの色を変えれないの？」
「 👇 ご存じの通り MAUI は マウス操作ではなく タップ操作を前提とした設計なんで マウス・ホバーなんて無いぜ」
📖 Mouse hover detection in .NET MAUI
「 デスクトップ・アプリとしての 体験が 悪い……」
「 👇 ジェスチャーでなんとかならないのかだぜ？」
📖 Implement PointerGestureRecognizer #9592
「 ボタン毎に ジェスチャー付けるの クソ めんどくさいが やってみるかだぜ」
Colors.xaml に定義されている primary という名前の Color インスタンスはどうやって取得できるんだぜ？
「 Colors.xaml に定義されている primary という名前の Color インスタンスはどうやって取得できるんだぜ？」
「 👇 これを読めだぜ」
📖 How to find a resource with key in code behind? [MAUI]
「 いくつかあるディクショナリーのどこかにあるから 探索しろということかだぜ」
namespace _2D_RPG_Negiramen.Models
{
/// <summary>
/// リソース・ヘルパー
/// </summary>
internal static class ResourcesHelper
{
/// <summary>
/// 探す
///
/// <list type="bullet">
/// <item>TODO ★ 実装をもっと書いてほしい</item>
/// </list>
/// </summary>
/// <param name="key">リソースのキー</param>
/// <param name="resource">見つけたもの</param>
/// <returns>見つかった</returns>
internal static bool TryFind(string key, out object resource)
{
if (App.Current==null)
{
resource = 0;
return false;
}
// 愚直な探索
foreach (var resourceDictionary in App.Current.Resources.MergedDictionaries)
{
if (resourceDictionary.TryGetValue(key, out resource))
{
return true;
}
}
resource = 0;
return false;
}
}
}
「 👆 じゃあ これでいいだろ」
「 👆 マウスのホバーで色変えるぐらいのことで ジェスチャーのコード 書くことになるの うんざりするが
仕方ない」
「 👆 イベントハンドラは こんなもんでいいだろ」
「 そういえば ボタンにマウスカーソルが被さった時の カーソルの見た目の変更も やり方が分からないな」
「 👆 マウス・ホバー時の色味を落ち着かせて、 画面の配色のコントラストも落とすように 変更したぜ」
「 ネギラーメンという名前なのに 青が基調でいいのかだぜ？」
「 青は 集中力を高める色という俗説もあるし、 まあいいだろ」
「 👆 マウスカーソルが ボタンに被さると ボタンが少し 明るく見えるとか １個１個 設定しないといけない
これは大変だ」
"Tile Set" ではなくて "Tileset" なのでは
「 Tileset は １単語として よく使われているようだぜ」
「 じゃあ リネームするか～」
「 タイル・パレット編集画面 という名前は 実態に合ってんの？」
「 タイル切り抜き画面だよな」
「 英語にすると Tile Crop Page ぐらいかだぜ？」
「 意味が伝わるだろうか？」
「 まだ タイル・パレット本体も無いし、
タイル・パレット編集 と言われても 分かんなくない？」
「 とりあえず 文字数が減るのは嬉しいから リネームするか」
TilePaletteEditPage ----> TileCropPage
文字列リソースにはどうやってアクセスすんの？
「 あれっ？ C# スクリプトから 文字列リソースを取得するには どうやったらいいんだぜ？」
「 LocalizationResourceManager を直で呼び出したらどう？」
var text = (string)LocalizationResourceManager.Instance["Add"];
「 👆 こんな感じで いけたぜ」
「 👆 ローカライズしたら という改行コードが そのまま表示されてしまった！」
「 インジェクション対策だろう」
「 👆 \n でも <br> でもダメ」
「 しゃーない いい感じのところで改行するのは 諦めよう」
ウィンドウ・サイズってどうやって設定するんだぜ？
「 MAUI って デスクトップ上のウィンドウの位置 という概念も無いよな」
「 デスクトップ・アプリではないんで」
「 👇 記事を読みなさい」
📖 .NET MAUI でウインドウサイズを指定する方法(Windowsで実行した場合)
「 そんな Win32 みたいなコード 書くのかだぜ？」
（カタ カタ カタ カタ）
「 書いた。 うまくいった」
画面遷移から戻ってきたときに呼び出されるイベントハンドラはあるかだぜ？
「 Loaded は最初の１回しか呼び出されないらしい。
画面遷移で 戻ってきたときに呼び出されたいときは どうすんだぜ？」
「 とりあえず いろんなイベントハンドラ実行したら NavigatedTo が それっぽいかな」
（カタ カタ カタ カタ）
「 よし、いけた」
「 ブログの編集画面が なんか重くなってきたので 次の記事へ飛ぶかだぜ」
「 よっしゃ」
次の記事
📖 次の記事： 2D RPG 制作ツールを作ろうぜ（＾～＾）？ ＜その2＞
光速のアカウント凍結されちゃったんで……。ゲームプログラムを独習中なんだぜ☆電王戦IIに出た棋士もコンピューターもみんな好きだぜ☆▲(パソコン将棋)WCSC29一次予選36位、SDT5予選42位▲(パソコン囲碁)AI竜星戦予選16位
Crieitは誰でも投稿できるサービスです。 是非記事の投稿をお願いします。どんな軽い内容でも投稿できます。
また、「こんな記事が読みたいけど見つからない！」という方は是非記事投稿リクエストボードへ！
こじんまりと作業ログやメモ、進捗を書き残しておきたい方はボード機能をご利用ください。
ボードとは？
コメント