mattak's blog

人生を1ミリ進める

Why I create Unidux.

英語も頑張って書いてみるテスト。

Introduction

今日 Unidux v0.0.1 をリリースしました.

Today, I released Unidux v0.0.1.

僕は一般的にはオレオレアーキテクチャをつくるのは下策だとおもっているのだけど、

I think that it's not good way to create application architecture by oneself.

今回はその考えに反してアプリケーション・アーキテクチャを自作しました.

But at this time, I created handmade application architecture against the idea.

それには理由があります.

There is a reason to create application architecture.

Unity上でアプリケーション・アーキテクチャを具体的に実装したよい例を発見できなかったから。より正確にいうならば、疎結合で、データフローがわかりやすく、状態管理が複雑にならないアーキテクチャを採用した事例が見つからなかったです。

I couldn't find any good application architecture example. If more precisely say, I couldn't find loosely coupled, clear dataflow, not complex state management architecture.

細かい経緯は gotanda.mobile #1 でも発表しました。

Details was spoken in gotanda.mobile #1

speakerdeck.com

それから幾日かたち、Unidux v0.0.1をリリースしたというわけです。

Some day passed, so Unidux v0.0.1 was released.

アーキテクチャはまだ穴が多く改善の余地があるのですが、これからissueを地道に消化していこうと思います。

Unidux is still young and has may bugs, I will solve the issues step by step.

pull requestはいつでも待ってるので興味があればください.

Pull request is always welcome.

GeoHexの最適化

GeoHex v0.0.1をリリースした. ただロジック的にはgeohex4jのコピーに過ぎず、いくつかパフォーマンスチューニングの必要性があると思ってた。 その最適化した時のメモ。

計測

まずは各関数の実行時間を正確に計測する。 実行時間を計測するためのクラスを作成した。

gist.github.com

計測結果

10回ほど計測して平均値をとった。

function original (ms) optimized (ms) shrink time percentage (%)
AdjustXY 1.184e-05 1.1345454545454545e-05 95%
GetXYByLocation 0.0001939 0.0001600909090909091 82.5%
GetZoneByCode 0.008047 0.005785454545454546 71.9 %
GetZoneByLocation 1.872 0.0033481818181818183 0.18%
GetZoneByXY 0.003157 0.0028772727272727274 91.1%
Pow3 3.8473684210526316e-06 4.564593301435407e-06 118%
Math.Pow3 3.6705263157894735e-05 3.489952153110048e-05 95.1%
GetHexCoords 0.0006748 0.00052 77.1%
GetHexSize 9.73e-06 4.9e-06 50.4%

比較のために同じ計算値のMath.Pow3を表示している. 絶対時間が小さく、相対値が10％以内のものは誤差と考えてもよさそうだ。

3の累乗を計算する Pow3,Math.Pow3。AdjustXYなどがそれに該当する。

やったこと

全体のコミット差分はこちら

1. Debug.AssertをException throwに変更

一番効果があったのはこれだった。

Debug.Assert => throw ArgumentExpcetionに変更することでGetZoneByLocationが500倍近く高速化した。 一つDebug.Assertするだけで0.5msほどくってのがまるまるなくなった感じだ。

なぜこんなに重いのかが疑問だったが、とにかくこれが一番効果があった。

2. 計算式の削減

数値計算の基本で演算回数を減らすと高速化するので、式を変形してできるだけ演算回数を減らした。

3. 決まった数の定数化

GeoHexのレベルは予め範囲が決まっておりそのlevel値をもとに3の累乗を計算するので、これを事前計算して配列に突っ込んでおいた。

Math.Powをつかわず計算済みの値をつかうことでかなり高速になる。 GetHexSizeはこれにより2倍程度高速になった。 ただし配列へのアクセスが演算速度を下回っている場合に限るので、環境によっては対して変わらないかもしれない。

4. 割り算の削除

数値計算でもっとも重いのは割り算であるので、これを掛け算になおすように調整した。

5. Math.Floor Math.Ceilingの展開

正の整数であることがわかっているにもかかわらず、Math.Floorをしてしまっていたので普通にキャスト。 また正の整数をMath.Ceilingするさいに、shift演算と加算とAND演算に展開することで高速にした。

Performanceをとってみてもこれは確実に高速化に寄与していた。

6. 比較演算の&&の順序を交換

AND条件で左辺と右辺を交換しても意味的な変化がないものは、はじめの条件が高速なように変換した。 数値の場合、一致比較より順序比較のほうが一般的には高速なはずなのでこれに直す。

7. ループ内変数の外出し

正直あまり効果は計測できなかったが、ループ内の変数は外出ししておいた。 もしかしたらコンパイラがよしなに最適化してくれる部分かもしれない。

結論

パフォーマンスが必要な場面では、Debug.Assertは使わないようにしよう。

MapboxでUnity3D対応をしたいので調査...

ただの個人的なメモ書き

手がかりをさぐる

同じことを考えている人はいるはずなのでとりあえず検索してみる。

github.com

Qtで同じことをやっている人はいるようだ。 これを真似すれば良さそう。

どのファイルをいじればいいのか?

commitログを眺める。

$ git log --oneline
efca99c [Qt] expose NorthOrientation
...
69465c9 [Qt] Add a Qt wrapper aroung mbgl::Map
d10cfd0 [ci skip] [android] Main loop integration
69465c9 [Qt] Add a Qt wrapper aroung mbgl::Map
d10cfd0 [ci skip] [android] Main loop integration
fd64b14 [glfw] Main loop integration
c31c91e [core] Add foreign main loop integration support to mbgl::RunLoop
bd5fabd [tests] Adapt tests for rendering on the main thread
1676934 [core] Render from the main thread
0f37b67 [core] Do not use std:: namespace for log2()

[Qt] というタグがついてるコミットが対象っぽい.

masterとの差分ファイル一覧を出す

$ git diff --name-only HEAD...qt-app
Makefile
android/MapboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/views/MapView.java
android/MapboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/views/NativeMapView.java
configure
gyp/common.gypi
gyp/http-qt.gypi
gyp/linux.gyp
gyp/mbgl.gyp
gyp/osx.gyp
gyp/platform-qt.gypi
gyp/qt.gypi
include/mbgl/map/map.hpp
include/mbgl/platform/default/glfw_view.hpp
include/mbgl/platform/qt/QMapboxGL
include/mbgl/platform/qt/qmapboxgl.hpp
include/mbgl/util/run_loop.hpp
platform/android/jni.cpp
platform/android/native_map_view.cpp
platform/default/async_task.cpp
platform/default/glfw_view.cpp
platform/default/run_loop.cpp
platform/default/timer.cpp
platform/qt/application_root.cpp
platform/qt/asset_root.cpp
platform/qt/async_task.cpp
platform/qt/async_task_impl.hpp
platform/qt/http_context_qt.cpp
platform/qt/http_context_qt.hpp
platform/qt/http_request_qt.cpp
platform/qt/http_request_qt.hpp
platform/qt/image.cpp
platform/qt/qmapboxgl.cpp
platform/qt/qmapboxgl.qrc
platform/qt/qmapboxgl_p.hpp
platform/qt/run_loop.cpp
platform/qt/run_loop_impl.hpp
platform/qt/timer.cpp
platform/qt/timer_impl.hpp
qt/main.cpp
qt/mapwindow.cpp
qt/mapwindow.hpp
qt/qmapboxgl.gypi
scripts/linux/configure.sh
scripts/osx/configure.sh
scripts/osx/install.sh
scripts/osx/setup.sh
src/mbgl/map/map.cpp
src/mbgl/map/map_context.cpp
src/mbgl/map/map_context.hpp
src/mbgl/map/map_data.cpp
src/mbgl/map/map_data.hpp
src/mbgl/util/thread_context.hpp
test/api/annotations.cpp
test/api/api_misuse.cpp
test/api/custom_layer.cpp
test/api/repeated_render.cpp
test/api/set_style.cpp
test/fixtures/util.cpp
test/miscellaneous/map.cpp
test/storage/http_error.cpp
test/storage/http_retry_network_status.cpp
test/test.gypi

変更されたディレクトリ一覧を出す

$ git diff --name-only HEAD...qt-app | xargs -n1 dirname | sort | uniq
.
android/MapboxGLAndroidSDK/src/main/java/com/mapbox/mapboxsdk/views
gyp
include/mbgl/map
include/mbgl/platform/default
include/mbgl/platform/qt
include/mbgl/util
platform/android
platform/default
platform/qt
qt
scripts/linux
scripts/osx
src/mbgl/map
src/mbgl/util
test
test/api
test/fixtures
test/miscellaneous
test/storage

一つ一つファイルの変更をみていく

Makefile - qtのビルドオプションが追加されただけ

MapView.java - めっちゃ長い. タップイベントやら諸々が書かれてる

NativeMapView.java - 微修正. リネーム等なされているようだ

configure - printの設定が追加されただけ

gyp/linux.gyp gyp/common.gypi - フラグ変更のみ

gyp/qt.gypi gyp/platform-qt.gypi gyp/http-qt.gypi - 新規追加

gyp/mbgl.gyp - qt用に設定追加

...

こっちのソース見るほうが早いかも...

GitHub - tmpsantos/qmapboxgl: Mapbox GL for Qt

疑問点

  • UnityのTextureにmapboxのレンダリング結果を貼り付けることができるか？
  • MapBoxのタッチイベントをUnityに移譲することができるか？
  • Unityでnative c++のソース (mapbox gl のcore部分) をビルド連携可能か？

raspberry piで自宅の湿度と温度を監視したい

モチベーション

最近部屋が乾燥していて朝起きると喉がカラカラになってしまう・・ 湿度計も温度計もないのでraspberry piで自作してみる. ついでに測定したログを監視サービスにポストするようにした.

設定全般

us配列で入力しにくいので、keyboard 配列を変更 /etc/default/keyboard

XKBMODEL="jp106"
XKBLAYOUT="jp"

Raspberry Piを買ってみたのでRaspbianのインストールとか初期設定とかとか | メモ帳代わりのブログ

$ sudo aptitude install vim
$ sudo reboot

計測

make-motion.hatenablog.com

上記ブログを参考にcで書いた。

データのpost

記録した温度と湿度はdatadogのAPIにpostするようにした。

qiita.com

qiita.com

API Reference

最終的にこんなスクリプトを書いた

実行して問題ないことを確認

$ sudo aptitude install libcurl4-openssl-dev
$ gcc -o dht11 dht11.c -L/usr/local/lib -lwiringPi -lcurl
$ sudo ./dht11

結果

f:id:mattaclj:20160314003642p:plain

概ね何もしないと

  • 温度: 17度
  • 湿度: 39%
  • 不快指数: 61 (何も感じない)

ぐらいだった。エヤコンつけて温度を上げると(18度くらいで) 湿度が1%ぐらい減る。 水に濡らしたタオルをエヤコンの上に干してみたり、ドアノブにかけてみたりしたが湿度は0.5%程度しか影響しないようだ。。

matome.naver.jp

上記サイトによると冬場の適切な湿度は 45% ~ 60%のようだ。 一般的に湿度が40%を切ると乾きを感じてくるようなので、もう少し湿度を上げる工夫が必要そう。 またエアコンで温度を上げると湿度が1%程度下がるというのも観測できた。

できれば50%ぐらいに湿度たもちたい。 もう冬場すぎるけど、この際加湿器買おうかなぁ・・。

余談

c/pythonじゃなくてrubyで書きたい。 pcのノリでanyenv => rbenv => ruby 2.2.4をinstallしてみたらビルドするだけで数時間かかった。 こだわりなければ、おとなしくc か systemにpreinstall済みのpythonで書くのが面倒なくてよさそう。

Unreal Engine 4はじめました

簡単な成果物

f:id:mattaclj:20160204221514p:plain

TPSで鬼ごっこするゲームをつくってみた

感想

Blueprintすごい

プログラムを一行も書く必要がなくてもある程度のゲームが作れる。 代わりに条件分岐も、イベント処理もすべてBlueprintで行う。 Blueprintは、Unityにおけるscriptのような立ち位置。 ロジックはすべてblueprintでやる。

楽で誰でもとっつきやすいのは++ 複雑な処理になると自由度が少ないのは-- 自由に使いこなすのには何度かゲームを作って見る必要ありそう。

GUIが軽い

ライトニングのベイク処理が別になっていて軽いイメージ。 コンパイルしないとstatic objectのライトマップは更新されない。

クラッシュ

Mac Book Pro 13inch retinaで作業してると頻繁にクラッシュして辛かった。 ファイルを作るだけでクラッシュ、フォルダを作るだけでクラッシュ・・・

ただ Mac Book Pro 15inch retinaで作業する感じ問題なかったので、単に環境に問題があっただけかも知れない.

チュートリアルは動画で！

文章を読んでも正直画面上のどの部分をいじればいいかパッと理解できないことも多々ある。 チュートリアル動画を何度かやるのがとっつきやすくてよい。

シーンファイルはバイナリ

同時編集は辛そうだ。 プロダクションで使ってる人はどうやってる感じだろ。 ただパーツと部品はファイル分けていけそう

テンプレート便利

プロジェクトを作る際のテンプレートが完成度高い。 そのジャンルのゲーム作る上ではとっつきやすそう。

アセット

そんなに充実してない感。 並んでる商品のクオリティは高そう。お値段も高め。 プロユースという感じ。

ファイルフォーマット

音声はwav モデルはfbx

Unityと比べるとあれがない、これがない、変換面倒って感じたりする。

UI

Blueprintのデザイナ画面で組める Widgetという単位で画面上に追加できる。 基本の要素は整ってて、きちんとアンカーも効くので困ることは今のところない。

2016-01 ハイライト

要約: 走った

  • 84km
  • 16 run
  • 週3-4ぐらいの頻度
  • 1回あたり6kmがメイン

評価

  • [◎] Running => 目標値の2倍達成
  • [✕] 英語 => Chatty 1回
  • [△] 腹筋 => 9/31回
  • [◯] リリース => Autum
  • [△] 寝る時間 => 就寝は早くなったが9時縛りはきつい
  • [✕] 金 => 特別出費がいたい。