HSPを少しずつ進める。

何事も放置すると、忘れたり、鈍ったりするわけで。
少しずつでもHSPのプロジェクトを完成に近づけなければ。

そもそも、何を作るかすら決まっていないけどな！

さて、今日の目標は、１０年前には無かった（はず）module機能についてだ。
追記：過去のソースコードに、#module が記述されていた。ただ、それだけで、modfuncなどは使ってなかった模様。

とりあえず、インスタンスを作り、モジュール関数をコールし、
いわゆる、セッターやゲッターの動作も確認できた。

一通りやった(つもり）なので、早速実践。
ゲームには必須である、画面のフェードイン/アウトアウト機能をmoduleで作ってみる。

基本は、過去に deffunc で作ったものをコピペ…する予定だったが、
目に余るコードだったため（笑）、１から作り直す。

とはいえ、ゲームプログラマなら、
簡単なフェードシステムのコード書くのに30分も掛からないはずだ。

というわけで、出来たものを実行っと。

　う　ご　か　な　い　！

いや、そんなはずは。
ちまちまとミスはあったが、そんなレベルではない、何かが違う。

試しに module外のメインループに移すと、きちんとフェードしている。
ということは、moduleが独立空間であるがゆえに、何かしらの障害が発生しているということだ。

さて、なんだろうか？
もしかして、module内では、gsel や gcopy などが使えない？
ありえそうだが、マニュアルには、そういうことは、一切書いてない。
さらに、付属のサンプルでは、思いっきり、moduleの中で、gcopyしてる。

まったくわからん！

が、独立空間という観点で見たときの問題が、もう１つあるじゃないか！

ゲーム作りの鉄則として、後から変更がありそうな部分は、define で一括で変更できるようにする。
Windowsのゲームだと、画面サイズなどが真っ先に定義される。
今回も、
#define screenW = 1280
#define screenH = 720
と定義している。
が、定義している箇所は、当然、#globalだ。

module内の gcopyは、

gcopy 1,0,0,screenW,screenH
になっている。

全くエラーは出てないが、これが悪いんじゃね？
というわけで、変更。

gcopy 1,0,0,screenW@,screenH@

ビンゴ！うまく表示されたわ。
うーむ、module内で全く定義せずに使用している変数は、
エラーを出さず、0として使われてるようだな。

マニュアルでは、module内から globalを参照するのは推奨しないとされている。
スクリーンのサイズを取得する変数や関数があるだろうか？

…あった。

画面の描画エリアXサイズ
ginfo_winx
画面の描画エリアYサイズ
ginfo_winy

定数をこちらに置き換えて、動作することを確認。
ま、なければ、セッターで画面サイズ渡せば良いだけか。

こういうのが、やってて面白いところだな。

追記：
#define の後に、global をつけることで、全module対象になるんだと！

#define global screenW 1280

これが正解の書き方ということだな。

再びHSPを始めたんだが。

過去に、HSPを使って商品を２つ作ってリリースしたことがある。
2006年頃、もう１０年以上前だから、HSP1.0だろうか？
もっともメインじゃなくて付録的な位置づけの作品だったが。

一応そのソースを持ってきたが、現在の HSP3.5では、互換性が無かった。
当たり前だが。

まあ、色々便利になっているし、サンプルやドキュメントが格段に整備されているので、過去に触れていたということもあるが、１０分程度で画面は表示できた。

module 辺りを中心にいじってみる。
うまく使えば、オブジェクトっぽいものが表現できると思われるが…。

module内に作成した関数、modfunc にアクセスする方法が
module関連のドキュメントで全く触れられてないのが残念すぎる。

モジュール変数とかコンストラクタとか、
だいたい一定のルールの記述方法なのだが、なぜモジュール関数(modfunc)だけ、

val = funcname(modVal)

という方式にしたんだ…。
ルールに従ったら、

val = funcname@modVal
val = funcname modVal

辺りが妥当なところじゃないか？
せっかく module関連をまとめたドキュメントが用意されてるのに、
これ説明しないでどうするよ…。

結局、moduleのサンプルコード見て探し出したが、
初見殺し過ぎる…。

Googleフォトの日付がおかしい。

2017年10月21日（土）にイベントがあり、動画と写真を撮影した。
その日はそのイベントでしか撮影していないし、
そもそもGoogle端末ではないので、自宅PCで手動でGoogleフォトにアップロードした。

すると、写真は、10月21日のタグがつき、動画は10月20日になった。
は？

Googleフォトは、静止画と動画でタグが分かれるようだ。
動画の間に写真を撮ったのに、綺麗にタグが分かれている。

つまり、10月21日に静止画を配置し、動画はその次のタグにまとめられている。
タグと日付が紐づいていて、タグが１つ戻ったので、日付も１つもどって、10月20日になった。

とかいうクソなプログラムじゃないだろうな、おい。

ちなみに写真も動画も、Googleフォトのプロパティでは、ちゃんと10月21日になっている。

Androidカメラとバーコード

以前作っていたカメラアプリを、最新の自前フレームワークに対応させて復活。

と言っても、カメラのプレビュー映像が表示されるだけだが、
Androidでカメラ使ったアプリの開発経験があれば、それだけでかなり大変だと分かるはず。

で、これをバーコード読み込みに対応させるのが今回の目的。
元々は、秋葉原で購入したUSBのバーコードリーダーを800円でゲットし、
OTGケーブルで接続して使っていたのだが、
カメラでさっと読み込みしたいじゃない？

幸い、GooglePlayサービスに、バーコード読み込みのAPIがあるってことだし、
試してみることに。

実際に、カメラアプリを作ったことがあれば、
http://dev.eyewhale.com/archives/1372
ここをさっと流し読みするだけで、３０分でできるはず。

まあ、実際には、足りないSDKをダウンロードしたりの時間も含まれるわけですが。
（API21、Android5.0以上じゃないと使えないっぽいです）

で、早速組み込んだアプリを実機テスト。
実機テストでおなじみの nuuX4の登場です。

いやあ、想像していたのより、さくさく読めますね。
バーコードの読み取りが成功する度に、コールバックが呼ばれるので、
ずっとバーコードをかざしていると、毎フレーム呼ばれます。
なので、自前で排他処理とかが必要。

とか、そんなのは、どうでも良し！
もっと深刻な問題が！

ネット検索すると、同じようにGooglePlayサービスでバーコード読み取りしている人はたくさん居て、皆、読み取りがすごいと、感心しているのですが…。

これ、超高性能カメラ専用APIだった！？

サンプルでは、デフォルトで背面カメラをしているのだが、
私は、正面カメラ（自撮用、フロントカメラ）で読み込みたいのです。

しかしこれが全く読み込めない。
極たまに１フレームだけ読み込めるときがあるので、プログラムが間違っているわけでは無いと思う。

実際に表示されるプレビュー映像を見れば分かるのだが、
フロントカメラの場合、バーコードの線が潰れて読み取れないような映像になっている。
バックカメラ二すると、ものすごく綺麗なプレビューが表示されて、さっと読み取れる。

nuuX4のカメラは、相当良いものだ。
バックカメラは1300万画素だし、フロントカメラも500万画素ある。
この画素で潰れて読めないとか、ありえなさ過ぎる…。

カメラの設定かもと思ったが、用意されているカメラの設定APIには大したものがない。

https://developers.google.com/android/reference/com/google/android/gms/vision/CameraSource

プレビュー解像度は、1920x1080にしているし、オートフォーカスも trueだ。
後はマクロ撮影があればいいのだが、カメラが対応していても、APIがない。

バーコード関係なく、nuuX4標準でついてるカメラアプリでも、フロントカメラは同じように潰れているので、もはや設定ではどうしようもないのかもしれないが、
そうすると、このGooglePlayサービスのバーコード読み取りAPIは、1300万画素程度ないと、使えないということか？

読み取れないって人がたまにいるけど、もしかしたら、この問題と同じなのかもしれない…。

AndroidStudioでプロジェクト

少しXenkoを触っていたけど、再び、AndroidStudioに戻ってきた。
Ver3がリリースされたって聞いたからなんだけど、プレビュー版で、安定版ではなかったので、Ver2.3.3にアップデートしただけにしておいた。

docomo withで、Android7の機種を手に入れたので、最新の機能も試してみたい。
まあ、6すら満足に触ってないけどね…。

というわけで、またフレームワークのところからいじりはじめた。
2D仕様になっていたのを OpenGL仕様に作り変えている、その続きから。

テストアプリを作るところまですら行ってない。

Activity切り替えとか、そんなに必要としていない機能も作ってるからなぁ。
まあ、カメラアプリを作るには必須なんだけど。

Androidでまともなアプリを作ろうと思ったら、Activityにstatic変数を使わないのは当然として、メンバー変数もなるべく使っちゃダメっての読んで、極限まで減らしたところ。

さて、何ゲー作るかな。

Xenko / その４

Microsoft Build tools を更新したら、エラーが減ったけど、
まだまだ大量のエラーが出ている、というのが前回の内容。

で、そのすぐ後に解決したんだけど、記事にしていなかったので、今さら解説。
解説するほどのことでもないんだけど。

出ていたエラーは、「あんたのDirectXのバージョンと合わないんだよ！」的な内容。
ツールで調べたところ、このPCの(オンボードの)グラフィックボードは、DirectX10.1まで対応しているらしい。

Xenkoは、DirectX9.0からさポートしているようだし、そういう意味ではまったく問題ないはずなのに、バージョン違い系のエラーが出ている模様。

で、

デバイスマネージャー ⇒ グラフィックボード

から、ドライバの更新をしてみたところ、なんと更新があるではないか。
そして、Xenkoを起動。

…できた！

というわけで、エラーが出ている人は、グラフィックカードのドライバ更新を試してみましょう。

実際に、Xenkoでサンプルゲームを動かしてみたけど、動作はこのPCではギリギリと言ったところ。

ただ、作り方の解説が少ないので、ここから先が苦労しそう。

Visual C# / その３

前回、VisualC#の基本的な罠に色々掛かってしまったわけだが。

その辺を回避したら、サクサク作れる。
オブジェクト指向などは、Javaで散々やってきているので、
C#独特の解放（デストラクタ）周りの、ガベージコレクトを何とかすれば良い。

それも、基本形は公開されているものをコピペでOK。

Javaで作っていた各種ツールを移植しようと思ったが、
基本部分を作ってから出ないと、気がすまないので…。

まずは、実行ログを出力テキストエリアと、結果を効率よく表示するための、
タブ切り替えを設置。
ファイル読み込み/書き込みのユーティリティは既に作ったので、
ソレを利用して、ツールのオプションを自動保存する機能も追加。

これらも、そこまで悩むこともなく、追加できたので、ようやくツール本体へ。
ツール本体を作成するには、画像の合成が必要だが、先に作っていた独自イメージクラスで基本はOK。
塗りつぶし処理を追加するくらいでできた。
（Javaでいうところの、Paint が、Brushになっている程度）

そこで、１００枚程度の細かい画像パーツを１枚のテクスチャに敷き詰める処理を移植。
Javaでは、独自にクイックソートAPIを作成していたが、C#でのその部分は、LINQを使って楽をする。

サクッと単純移植した結果、１枚の生成に３秒かからないくらい。
これ、Javaとそんなには違わない。
だがしかし、アルゴリズムに改良の余地があることは分かっていたので、それを実装した結果…。

50ミリ秒。

そんなもんさ！
いくら、頑張って最適化しても、ちょこっと速くなればラッキー。
もちろん、そのちょこっとが必要なときもある。

だが、大抵は、アルゴリズムの改良の方が効果的なのだ。

５０ミリ秒より速く…はできないだろうなぁ。