プライバシーポリシーとサポート情報 - お散歩コンパス ― 2024年06月06日 19:00
本アプリについて (About this app)
2024年6月 公開停止
MS Store管理者から地図表示不可の報告を受け、公開を停止しました。Windows Mobileの廃止により、役目を終えていると判断し、修正は行いません。
なお、アプリ搭載のWebView機能と地図サイトの間の互換性が失われたためと思われます。
2016年8月更新
本アプリは、散歩などに持ち歩くコンパスと傾斜計の機能を提供します。インターネットが利用できる環境では、今いる位置を中心に国土地理院地図を開くことができます。また、適宜、現在位置を記録することで、簡易ですが、経路を表示できます。
それぞれの機能の利用可否は、機器に搭載されるセンサの有無に依存します。すべての機能を利用するには、電子コンパス、傾斜計、GPS、および、インターネット接続が必要です。
現在位置の表示には、位置情報を使用します。使用を許可するには、Windowsの「設定」→「プライバシー」→「位置情報」の設定が必要です。
プライバシーポリシー (Privacy statement)
対象アプリ：お散歩コンパス
本アプリの製作者である The Fourteenth Lab (第十四工房) は、本アプリによって、お客様の個人情報およびプライバシーに関する情報を収集しません。
サポート情報 (Support)
ご質問や不具合のご連絡は、このページの「コメント欄」をご利用いただくか、「このブログについて」に記載の連絡先までお願いします。
あらかじめのおことわり (FAQ)
１）コンパスの北は、赤い針の方向です。方位は、電子コンパスとGPSから求められますが、本アプリは、電子コンパスの値を採用しています。試験用の機材と、手持ちのコンパス（デジタルでないもの、SUUNTOのA-30）と比べると、5～10度ほど差が見られます。また、電子コンパスは周囲の磁場に反応しやすいようです。
２）針のまわりの円の半径を、地図の右下に表示します。標準で500mですが、ズームイン、ズームアウトにより変わります。
３）針のまわりの円の上を回るのは太陽です。電子コンパスが機能しない場合でも、太陽の位置からおおよその方角がわかるようにとの趣旨です。大まかな近似計算で、日の出と日の入の時刻を求め、表示色を変えていますが、精度は高くありません。参考程度に願います。
４）電子コンパスや傾斜計のデバイスの存否をチェックしていますが、デスクトップPCでは、ダミーのデバイスがあるため、計測値が得られない場合があります。
５）地図表示は、緯度と経度をURLに埋め込んで、国土地理院地図を呼び出して表示しています。表示に際して、国土地理院地図には加工を施していません。なお、ウェブサイトの仕様の変更により、表示できなくなる可能性があります。
※国土地理院地図のウェブサイト
ズームイン「+」、ズームアウト「-」のボタンにより、縮尺を変更できます。それぞれ2段階です。地理院のタイル仕様のズームレベルでいうと、13～17（標準は15）の間です。
６）地図表示の縮尺などは、ウェブサイトのボタン等でも変更できますが、本アプリの表示は、変更内容と連動しません。「地図」ボタンを押すと、アプリの設定に戻ります。
７）メニューから「位置情報の表示」を選択することで、地図上にこれまで記録した経路を表示できますが、緯度、経度、距離の計算方法は、本アプリと地図では異なるため、正確には一致しません。あくまで、参考表示程度とご理解ください。
８）地図表示は、移動しても自動では追尾しません。「地図」ボタンを押して、適宜、更新してください。バックグラウンドでのバッテリ消費を控えたいとの趣旨です。
９）緯度と経度、およびその差分からの距離の計算は、「理科年表 平成27年版」、「地学部」の地球楕円体に関する計算式（定数は、測地基準系1980の値）をもとにしています。
１０）記録した位置は、ファイルに書き出すことができます。カンマ区切り形式のテキストファイルです。各行の項目は、順に以下の通りです。
・記録順
・日付
・時刻
・緯度
・経度
・高度
・前回記録からの経度方向の距離m
・前回記録からの緯度方向の距離m
・前回記録からの直線距離m
・前回記録からの方位（北が0度、時計回り）
Azure DevOpsのプロジェクトでVSTSからGitへの切替 ― 2022年06月23日 18:15
VisualStudioを用いた開発において、Azure DevOpsでソース管理をするとき、最近はGitを標準で勧めてくる。そこで、これまでVSTS(Visual Studio Team Foundation Services)で管理してきたソリューションについて、Gitへの切替を試みる。
最初に、Azure DevOpsでバージョン管理をGitに設定した空のプロジェクトを作成する。
ユーザ名とパスワードを保存し、リポジトリの場所を記録する。
VisualStudioを起動し、切替対象のソリューションを開く。オプションの「ソース管理」で、ソース管理プラグインを「Git」に設定する。
Gitグローバル設定を確認。ここでは、既定の場所を変更している。
Gitリポジトリ設定の「全般」を確認。
Gitリポジトリ設定の「リモート」で、先にAzure DevOpsで記録したリポジトリの場所を転記する。
ローカルにGitのリポジトリを作成。先に、Azure DevOpsでプロジェクトを作成しているので、「既存のリモート」を選択して、「リモートURL」を設定。
これで「Git変更」のパネルから、ローカルのソースのPushができるか、確認。
ソース管理プラグインはソリューション単位の設定であり、別のVSTSを用いているソリューションを開けば、これまで通り、VSTSのソース管理が動作する。VisualStudioの共通の設定として保存されるわけではない。
切替によりGitならではの制御が可能になるが、VSTSで不都合を感じてなければ敢えて移行する必要はない感じ。なお、Gitに切替てもAzure DevOpsのBoardsなどのサービス類は変わらず利用できる。新規作成なので空からのスタートになるけど。
ひとついいことがあった。
Gitに切り替えておくと、ローカルで運用しているGitHub互換のリポジトリに複写ができるようになる。remoteのリポジトリをAzure DevOpsとは別にローカル用に登録し、TortoiseGitなどのクライアントツールでPush時に選択すれば、複写を生成できる。VSTSの場合、「.git」のGit環境フォルダがあると、ソース管理プラグインをGitと認識するので、複数のリポジトリを選択して運用することができない。これを回避できる。
Vector (.NET, C#) で条件分岐 ― 2022年01月06日 16:06
C#プログラムにおいて、多量のデータ処理(画像処理)に .NET の Vector で高速化を試みる。MSの文書は簡潔なもので、理解のためには試行錯誤が必要。
画像の一点毎に処理する元のコード。BGRAのデータからPCCSの色相(Hue)の値を計算する。
行199のEqualsを処理したところ。Vectorに詰めた _Rvec と _cMax の値を比較している。元のコードでは、行120に当たる部分。
下のデバッグ画面の rEQcmax の値を見ると、最初の4つが -1 になっている。値が一致し、TRUE と判断すると、0以外の値(この場合、-1)に設定される。
なお、Vectorの要素は、デバッグ画面では8個分あるが、実際は4で動作している。
行203のConditionalSelectを処理したところ。先に値を設定した rEQcmax の内容に応じて、2つのVectorのいずれかの値を設定する。第2引数がTRUE、第3引数がFALSEの場合の設定値。元のコードでは、行122に当たる部分。
ここでは、rEQcmax の4つの要素がいずれもTRUEなので、hue1 (第2引数)の値が設定されている。
行209のConditionalSelectを処理したところ。ここまでに3つのConditionalSelectを処理した。これは、元のコードの if / else if / else に当たるもの。最初の条件に合致すると hue1、次の条件に合致すると hue2a、どちらにも合致しないと hue3a の値が設定されるように、組み合わせる。
ちょっとしたパズルの要領。
UWPでMonoGame - 仮想環境ではうまく動かず ― 2021年05月13日 18:48
リリースに向け、ネイティブにコンパイルし、テスト用の環境で動作確認を行うと、画面生成が妙に遅くなったり、止まったままになったりする。XAMLのページから、MonoGameのページに遷移するところ、または、その逆のあたりが怪しい。
別の環境、新しく作り直した環境、仮想環境でない実機、で試してみるが、問題なく動く環境とそうでない環境がある。当たっているKBの違いかと、これも試してみるが、不発。
このタイミングに依存するような不安定さは、やはり、ハードウェア周りかと、仮想環境のCPU周りを見直すと、「ハードウェアアシストによる仮想化をゲストOSで公開」の項が怪しい。これにチェックを入れると、少し動作が安定する。また、コア数が2よりも4の環境の方が安定する。
仮想環境は、開発に便利だが、ハードウェアに近い操作を行うDirectXなどのアプリでは、落とし穴があると言うことか。リリース版をBuildしてはじめて気がつくので、なかなか厄介。
HubSectionのDataTemplate定義内のRadioButtonやComboBoxの初期設定 ― 2021年04月19日 16:27
Hubで構築した設定パネル。設定のHubSectionにおいて、RadioButtonで設定を指定する。HubSectionは、DataTemplateで定義するので、x:Nameで指定した名前を使っては、RadioButtonなどの初期設定を行えない。
そのため、Bindを用いて、コードの値を反映させるのだが、XAMLの初期化時に、初期値（デフォルトの値）でもってCheckedのイベントが発生し、Bindすべき変数の値を、別の値で上書きしてしまう。RadioButtonのほか、ComboBoxなども同様。
ここは、Checkedのイベントの発生を、本来設定したい値をBindしてからにしたいところ。
巷の記事では、XAMLのTreeをたどって初期設定する力業なども紹介されているが、個々のコントロールのLoadedイベントを受けての処理で対処できそう(L.111)。
RadioButtonのLoadedイベントを受けるコードで、IsCheckedを設定して、roamingSettingsなどから読み取った値を初期値として設定(L.200)。その後、Checkedのイベントが発生するが、先ほど設定した初期値でのイベントなので、別の値で上書きされない。
UWPでMonoGame - 日本語表示でSurrogate Pairに苦戦 ― 2021年04月13日 16:14
MonoGameで日本語を表示する方法は、あちこちに記事がある。
MGCB EditorでSpriteFont定義に設定するProcessorをDLLとして作成。漢字やかなの入ったテキストファイルから一文字ずつ取り出し、FontDescriptionに登録。,NET Core 3.1のDLLのプロジェクトで作成したもので登録成功。
常用漢字について実施したもの。左の"Processor"欄で、作成したProcessorを登録する。規格が合っていないと候補に出てこない。実行には、そこそこ時間を要す。
それではと、難読漢字の入ったテキストファイルを取り込んでみると、エラー。
Surrogate Pair (2バイトのコード2つで一文字を表現)
をバラバラに登録しないでね、Char配列で渡してね、と。
それではと、先のForumでも触れられていた、FontStashSharp(SpriteFontPlus)を試してみる。コメントアウト済みだが、L.190あたり。LoadContent()では、フォントファイルを登録。
Draw()では、DynamicSpriteFontを定義して、描画(L.566-567)。Surrogate Pairは試さなかったが、日本語表示は問題なくできる。
問題は、配布Packageにフォントファイルを同梱しなければいけないこと。IPAフォントのライセンスを読むと可能ではあるが、サイズも大きくなるし、どうしよう。UWPでなく、WPFにすれば、システムフォントを読み込めるかも。そもそも、今まで使ってきたUDデジタル教科書体を使いたい。
結局、実行時に、Win2DでCanvasDeviceに日本語文字を書き込み(L.164)、Stream経由でTexture2Dを生成(L.182)することで対処。PutText()は縦書き表示のためのもの。
MGCB Editorで事前生成するわけではないので、実行時、それなりに時間を要する。ゲーム実行時のスコア表示などには向かないが、ゲーム開始前に作っておけば済むものなら使える。
UWPでMonoGame - GameからXAML Pageへの復帰 ― 2021年04月08日 18:42
UWPでXAMLのPage(GamePage)から、引数付きでMonoGameのGameを起動することができた。次は、Gameから元のXAMLのPageに復帰する。
Gameの終了は、Dispose()を呼び出せばよいようだが、UnhandledExceptionが発生し、アプリが終了してしまう。OnNavigatedFrom()に記述したデバッグ文が呼び出されているところから、XAMLのPageに戻ってはいる様子。
ログを見ると、Gameオブジェクトがなくなったのに、Mouse周りのイベントが刈り取られず、イベントの宛先がNullであると言っている(Disposeしたから当然だが)。これが致命傷になり、アプリの継続が不可になっている。
ちなみに、Exit()を呼び出すと、GamePageに戻ることなく、アプリが終了する。
本来は、MonoGame側の対処を望みたいところだが、何とか先に進めてみる。まず、Gameの終了をGamePage側から行うため、イベントを自作し、ゲームの終了をGameからGamePageに伝える。
そこで、GamePageを起動したMainPageにGoBack()で遷移する(L.70)。UIとは別Threadに居るので、Dispatcher.RunAsync() 経由。念のため、例外発生前に遷移指示を済ませる。
その上で、GameをDispose()する(L.84)。一つ前のSuppressDraw()は例外抑止に効果なし。発生するUnhandledExceptionは、ここのtry/catchでは拾えない。
UnhandledExceptionを拾うために、App.xaml.csにハンドラを登録(L.32,33)。2つ登録しているが、MonoGameの例外を拾うのは、CoreApplication.UnhandledErrorDetectedの方。
ハンドラの実体。CoreApplication.UnhandledErrorDetectedを受けるのは、CatchCoreUnhandledException()の方(L.133)。引数のargsには、Messageがないので、Propagate()で改めてThroｗ(L.147)。このあたりは、atmarkitの記事を参考に。
記事にあるように、VisualStudioのプロジェクトのPropertyで、条件付きコンパイルシンボルを設定しないと、Debugモードの実行では、アプリのハンドラの代わりにVisualStudioのデバッガが例外を捕まえるので注意。
すると、例外の実体が、NullReferenceExceptionであることがわかる。
こうして、UnhandledExceptionを受けとめると、例外でアプリが落ちることなく、GamePageから遷移したMainPageが無事に表示される。とりあえずは、これで先に進める。
UWPでMonoGame - Gameオブジェクトへの引数渡し ― 2021年04月08日 13:58
以前作成したXAMLベースのゲームアプリ(UWP)の使い勝手を改善しようと、ゲームエンジンの導入を考える。一度アプリ構築に使用したUnityが第一候補になるが、もう少し手軽で、XAMLページとの連携ができそうなMonoGameを試してみる。
MonoGameのUWP対応のプロジェクトを作成すると、生成されるコード群に、GamePage.xaml.csがあり、MonoGameの環境を生成するコードがある(L.40)。XamlGame<T>.Create() の部分。
最初の引数に parameter がある。設定のしかたは、"key:value"の形。複数ある場合は、空白で区切る。このあたり、MonoGameの文書に説明がなく、試行錯誤。
parameterの受け取りは、ゲーム本体のClass(Gameを継承)のConstrucorで行う(L.85)。Game.LaunchParameter（L.91）というCollectionに入っているので、foreachで取り出す。こちらは、Gameクラスの説明にある。
実際の活用は、App.xaml.csからGamePageを呼び出す処理を変更し、別に用意するMainPageを介してGamePageに遷移するようにする。この時、MainPage→GamePage→MonoGameに引数を渡す。こうすれば、MainPageにゲーム選択や各種設定などのUIを担わせることができる。
MonoGameで各種UIを作成することもできなくはないが、いろいろな部品は手作りになる。
最近のコメント