jtwtw.com

XMLで階層構造で記述されたメモを、フォルダツリー風に整形して表示します。 階層は無制限、フォルダ名には配下のフォルダ数を括弧で表記。 メモは普通のエディタで記述します。記述ルールは以下のとおり。 ・ルートのタグは<top>にします。他に使用するタグは<c><o><t>の３つ。 ・<c>と<o>はフォルダ名、<t>は本文です。 ・<c>は初期状態で閉じたフォルダ、<o>は開いたフォルダを表します。 ・<t>にはHTMLのタグが使えます。 このルールに従って記述するとこうなります。 <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet href="tree.xsl" type="text/xsl"?> 食費比較 安いか高いかはカロリーを基準にしている 白米 一番安い。しかし同じ食べ方だと飽きやすい。 冷凍うどん 冷凍はかなり安く買える。素うどん続けても飽きにくい。 パスタ 乾麺自体はかなり安いが、素パスタで食べる訳にもいかない。 何か和えたりすると結局高くつく。 食パン 高い。同じ食べ方は飽きる。 これをブラウザで表示させると、 画像上がブラウザで開いた初期状態、下がクリックして展開した状態です。 このようにXMLを整形して表示させるため、別途フォルダ画像とXSLファイルが必要です。 フォルダ画像は適当に用意して[open.gif],[close.gif]という名前にします。 XSLファイルは以下の内容を[tree.xsl]という名前にして保存。 エンコードは[*.xml]、[*.xsl]共にUTF-8。他のエンコードを使用するならencoding="UTF-8"を変更。 ツールやwikiの使用が制限されるなど、環境が限定される客先での情報共有で役立つかもしれません。 ただし、複数人でxml...

欧米のソースコードはシングルバイトコード(ISO-8859)がよく使用されますが、ASCIIコードで無いコード、 つまり\x80～\xFFのシングルバイトコードが含まれている場合があります。 その多くはコメント部で使用されます。例えば人名やCopyrightの©記号などです。 これらの文字コードを含むソースに日本語のコメントを追加すると、全体で文字コードの不一致が起こります。 そのため、Doxygenでドキュメント生成しようとするとコード変換に失敗します。 ・ISO-8859の特殊文字(\x80～\xFF)を検出する方法  サクラエディタUNICODE版のgrepを使用します。 正規表現を使用し、検索条件を[\x{dc80}-\x{dcff}]とします。 ・対処法 コメント部で使用されていた場合、単純に削除するかスペースなどで置き換えます。 文字列中で使用されていた場合、内容を変える訳にはいかないのでバックスラッシュ(￥or＼)によるコード表記に置き換えます。 ・大量にある場合 スクリプトを書かざるを得ないでしょう。 日本語のコメントを付加する前であれば簡単なスクリプトで済みます。 (\x80～\xFFの文字コードをコード表記に変えるだけ）

Ver.1.0.7版を公開しました。 ・ ネットワークによる現在位置の測位 設定画面で切替ができます。   天候が悪く、GPSの電波が拾えない場合に使用して下さい。 GPSより精度は悪いですが、大まかな位置は把握できます。 また、ネットワークによる測位は通信料金が発生する場合があります。 地図上では、 ネットワークによる測位の場合に現在位置が赤く表示されます。 ・Googleマップの共有機能との連携 Googleマップで検索した場所の情報を、ホームコンパスへ送り込む機能です。 例えば、Googleマップのマイプレイス(お気に入り)を ホームコンパスで登録したいとき、少しだけ入力の手間が省けます。 マイプレイスを選択し、「この場所を共有」→「ホームコンパス」と選択すると ホームコンパスが起動し自動的に検索を実行します。 ただし、ホームコンパスで検索できない場所では連携が上手くいかなかったり、 全く別の場所を表示してしまう場合があります。

クォータニオンとボーンについての解説は省きます。 クォータニオンを使って回転を合成し、ボーン１にはボーン１の回転が、ボーン２にはボーン１とボーン２の回転、ボーン３にはボーン１とボーン２とボーン３の回転を与えます。 これにより、人間の関節やロボットアームのような複雑な動きを表現する事が可能になります。 クォータニオンによる回転の合成は、クォータニオンの積の計算によって求まります。 ただしOpenGL ESの場合、クォータニオンのままでは座標変換が行えないため、クォータニオンを座標変換行列に変換する必要があります。 ※動画キャプチャの都合上、端末(SC-01C)で遅回しして編集で早回し 全てのボーンが同じ原点を共有して回転してしまっています。 パタパタママ のようでもありますが、表現したい事はこれではありません。

OpenGL ES 2.0と同程度の処理をES 1.1で実装し、処理速度を比較しました。 全く同じ処理をしているとは言えないため、厳密な比較ではありませんが。 ※端末はSC-01C 左がOpenGL ES 1,1、右がOpenGL ES 2.0です。 オブジェクトを200個描画し、秒あたりのポリゴン数を計測しました。TPSはtriangles/sec。 予想に反し、OpenGL ES 2.0の方が処理性能が高くなっています。 OpenGL ES 2.0がプログラムシェーダだからと言って、処理速度が見劣りするという訳ではないようです。 このテストは平行光源を一つのみ配置して行いましたが、OpenGL ES 1.1では最大８つライトを配置できます。 OpenGL ES 1.1で８つの平行光源を配置して測ったところ、このような結果でした。 少し処理速度が落ちています。 一方、OpenGL ES 2.0で光源を増やせば、処理速度が落ちるのは自明です。 つまりどちらを採用するにせよ、光源は少ない方が処理速度は上がる、という事になります。

物体の質感を表現する。 ※動画キャプチャの都合上、端末(SC-01C)で遅回しして編集で早回し   側面はペイントでベタ塗りしただけの手抜きです。 １つ目は拡散光のみを表現したモデル、 ２つ目は環境光、拡散光、反射光を表現したモデルです。 反射光によって金属のような光沢感が表現され、絵がくるくる回るだけの状態よりは少しリアリティが増しています。 OpenGL ES2.0は、これらのシェーディング処理をシェーダプログラムで実装しますが、環境光と反射光のコードを追加した結果、フレームレートが60→40台に低下しました。 （動画は遅回しのため変化していません） 実際に追加したコードは僅か２、３行で、それも頂点シェーダ側です。それでもここまで速度低下を招くのは意外でした。 OpenGL ES 1.1よりも、上位のOpenGL ES 2.0の方が全てにおいて優れている、という訳ではないのかもしれません。同程度のシェーディング処理だとパフォーマンス的にどちかが優位なのか、比較検討する必要がありそうです。

テクスチャを貼れるようにする。 ※動画キャプチャの都合上、端末(SC-01C)で遅回しして編集で早回し   テクスチャとフラットシェーディングだけでもそれなりにリアルな絵になります。 繰り返し見てたら目が回りました。 カメラビューにこの矢印を重ねて、拡張現実的な道案内アプリなんてのもいいかもしれません。 更に空間認識技術で、GPSの測定誤差を補正してくれたり、 道路に誘導ラインが表示できるようになれば、地図アプリなんて不要になりそう。