SUZUKI PLAN blog - 妄言郷

2018年4月7日土曜日

東方VGS Lite (3)

東方VGSをオーバーホールするこの機会に、一部機種でバックグラウンド再生時に音飛びするあの問題の解消を試みました。

まず、この問題が発生する原因を簡単に解説します。

VGSでは、波形メモリ音源エミュレータが短い間隔で波形データ（PCM）を生成し、それをOSの音源ドライバへ逐次的に書き込むことで音を再生していて、音飛びはこの波形データ生成処理が遅延することで発生します。そして、アプリがバックグラウンド状態に入るとOSがアプリのCPUプライオリティを引き下げることが原因で波形データ生成処理が遅延します。

これを回避するため、AndroidにはWakeLockという仕組みがあります。東方VGSでは、バックグラウンドに入る時にPARTIAL_WAKE_LOCKというCPUプライオリティを維持するWakeLockを取得することで、CPUプライオリティを引き下げられないように要求していますが、それが一部機種で効いていないことが原因で「バックグラウンドにした時に音飛びする」という問題が発生していました。

それ効かない原因としては、WakeLockの権限の取り方が誤っている（アプリ側の問題）か、OSがアプリのWakeLock要求を無視している（OS側の問題）が考えられますが、WakeLock#acquire自体は成功しているので、後者が原因だろうと思っています。

ここまでが既に分かっていたことです。旧東方VGSでは、このアプローチで問題解決を試み続けていた訳です（最近は全くノータッチだったけど）。ただ、疑わしいと思いつつ、結構大変だった為に試せなかった方式があって、それは音源ドライバのAPIをOpenSL/ESからAudioTrackに変更するというものです。

そして今回、この変更を試みたのですが、かなりアッサリとバックグラウンド再生時の音飛び問題が解消されました。

オーバーヘッド的には、OpenSL/ESよりもAudioTrackの方が重いです。

ただ、OpenSL/ESの場合、バッファリングと再生の処理を全てネイティブスレッド（Cスレッド）で動かしているので、JavaスレッドのCPU使用率が上がらないため、OSが「CPU使ってないならWakeLock要らないよね?」的な感じでWakeLockを無効化させていたのではないかなと。対してAudioTrackの場合、バッファリングはJNI経由でJavaスレッド、再生はJavaスレッドのみで実行されるので、JavaスレッドのCPU使用率が上がるため、音飛びがしなくなったと。

ひとまず、一番大きな問題を解消できたので、後は細かい所を片付ければリリースできそう。

（今日中にはリリースできるかも）

2018年4月5日木曜日

東方VGS Lite (2)

ランドスケープ用のデザインを雑に作ってみました。

VGSだと割と面倒だし、どうせバックグラウンド利用が大半だからと Portrait 専用にしてましたが、ネイティブUIだと楽ですね。

画面構成要素としては、LandscapeもPortraitも全く同じで、

・上半分のヘッダー、ピアノ、コントローラの領域を PlayContainer
・リストのタブ（TabLayout）とリスト（ViewPager）を ListContainer
みたいな形で定義しておき、Landscapeの時はそれらを左右に並べるだけという感じ。
（5分で作れました）

2018年4月4日水曜日

Android版東方VGS Lite（開発中）

東方VGSのAndroid版が新しいAndroidで動かなくなったという報告を頂いたので調べた所、VGSではなくネイティブUIで作り直してしまった方が手っ取り早そうだったので、作り直し中。
旧来の東方VGSはそのまま残しておき、東方VGS Lite（別アプリ）として公開予定です。
完成度は7割前後なのですが、ここから先が長い...
でも、4月中にはGooglePlayで公開できるかと思います。

2018年3月14日水曜日

サーバサイドのお勉強

スマホのソシャゲで使えそうなアカウントサーバを作ってみました。
~~https://github.com/suzukiplan/simple-account-server~~
https://github.com/suzukiplan/simple-ap-server

ただし、飽くまでも試作です。
実用的かは未知数。
現在の本職はクライアント畑の人間なのですが、サーバのことも把握しておこうかなと思いまして。要するに単なる興味本位です。

まずは、アーキテクチャ設計。

アカウントサーバというと、Web時代のソシャゲであれば、メアド（ID）とパスワードで作るのが一般的ですが、スマホ向けということで、POSTすれば自動生成され、アプリ側では preference / userDefaults にそれを記憶して使うのだろうと思います。この辺は実際にスマホのソシャゲを幾つか遊んでみた限り、だいたいそんな感じだろうと想像で作成。

初回起動時（アカウント生成）

自動生成されたIDとtoken（パスワードに相当するもの）を用いてログインするイメージは下図のような感じ。

ログイン

DBですが、アカウント情報というとRDB一択だろうとは思いつつ、スキーマ定義が面倒臭いというただそれだけの理由で MongoDB（NoSQL DBMS）にしてみました。MongoDBというと、どちらかというとログ用途というイメージなのですが。

どうしてもHiRDBなどのRDBじゃないとマズイのであれば、置き換えは割と簡単にできます（実際、試しにMariaDBに置き換えてみたのですが、コードの書き換えよりもスキーマ定義等の下準備の方が面倒だった）。なので、まぁこのまま良いかなと。

DBがMongoDBだから速いので、キャッシュとか要らないのではないだろうかと思ったのですが、実測してみた限りRedisの方が最大10倍ぐらい早かったので、Redisでキャッシュ（Read cache）も作ってみました。なお、Write cacheは現時点では実装してません。アカウントの情報更新量が多いとかで必要であれば、RabbitMQを使う感じでしょうか。

最後に言語。
言語の定番は PHP かな？と思いつつ, TypeScript + Node.js で。
理由としては、
・豊富なパッケージ（使おうとしたミドルのパッケージが全てnpmにあった）
・情報を見つけやすい（≒情報が多い?）
あたり。

サーバサイドの言語事情はよく分かりません。Goとかも興味ありましたが、習得するのも面倒だしNode.jsなら少し知っているから楽なので。実のところ、TypeScriptにする必要すら無い（＝ダイレクトJSで良い）んじゃないかなと思ったのですが、modelの定義にclassが使えるのが便利だし、tscも色々良い感じになっていてコンパイル手間も無いに等しい状態だったから、ダイレクトJSはやめておきました。

ひとまずこんな感じで、ユーザ登録、ログイン、ユーザ情報参照、ユーザ情報更新といったアカウントサーバの基本的な仕組みを作ってみました・・・が、コレ、実用に耐えられるシロモノなんですかね？正直良くわからないので、誰かコレでソシャゲ作ってサービスインしてみて下さい。（責任は取らない）

2018年3月5日月曜日

NES emulator for iOS

先日作ったnes-emulator-androidをiOSにも移植。
https://github.com/suzukiplan/nes-emulator-ios

機能レベルでAndroidと同等にすることを目標にしてますが、この記事執筆時点ではサウンドキャプチャ機能が未実装です。（save stateとload stateが未実装であることはAndroid版と同じ）

一応以前、コア部分にLaiNESを使ったiOS用のインタフェースも作ったのですが、若干（というかかなり）作りが悪かったので、内部実装はかなり書き直しました。恐らくインタフェース的には実用に耐え得るレベルになったと思います。

あと、今回のnes-emulator-iosはcocoapodsでの配布もするようにしたので、Podfileに

pod 'NESView', '~1.0.0'

と書くだけで利用できます。
まぁ、利用するとそのアプリのライセンスをGPL3.0（か互換性のあるOSSライセンス）にする必要があるので、事実上商業利用不可みたいなものですが。

なお、READMEに補足してますが、ライセンス調整版（※ただしコア無し）というものも一応あります（そちらは private repo なので一般公開していませんが）。

2018年2月17日土曜日

NES Emulator for Android - version 1.5.0

先日公開したCycloaをAndroidで動かしたライブラリを色々と更新しました。
https://github.com/suzukiplan/nes-emulator-android
現時点の最新バージョンは1.5.0。

主な機能追加内容としては、以下3つ。

マルチtick送信（n倍速）に対応
映像と音声のキャプチャインタフェースを追加
ステートセーブ/ロードのインタフェースを追加

この他にも色々と細かい修正はしていますが。
これらの機能を全てテストアプリで触れるようにしておいたので、大分テストアプリの画面のガジェット感が上がりました。

1. マルチtick送信（n倍速）

これは普通のエミュレータでもよくある倍速プレイとかですね。

tickの内容を流すことでリプレイ再生することもちゃんとできるようにしておきました。

2. 映像と音声のキャプチャインタフェース

これは普通のエミュレータにはあまり無い機能ですが、映像と音声をキャプチャするというもの。例えば、プレイしている内容をライブストリーミングに流したりといった機能を作る時に役立ちます。

もっとも、実際に配信するにはこれだけだと不十分で、別途MediaCodecを使ってエンコードして、ライブストリーミング・プロトコルでの配信する機能を（これはAndroidの標準機能ではないので自前で）実装する必要があり、少し大変ですが。

3. ステートセーブ/ロードのインタフェース

Cycloaにはステートセーブ/ロードの機能は無いので、NES Emulator for Android側のインタフェースのみですが、とりあえず作っておきました。余力があれば、Cycloaにステートセーブ/ロード機能を追加した魔改造バージョンをforkして作るかもしれません。（作らないかもしれません）

ここ一週間でもりもりアップデートしてましたが、これで私が当初作ろうと思った機能は（少なくともインタフェースレベルでは）一通り揃ったかなという感じ。

2018年2月13日火曜日

Kotlinで100行以内で書けるファミコンエミュレータ

前回の記事で書いたnes-emulator-androidというライブラリをjcenterで公開しました。

jcenterに公開したので、Android projectの build.gradle の dependency 区に

implementation 'com.suzukiplan:nes-emulator-android:1.2.1'

と1行追加してあげるだけで、Androidアプリで簡単にファミコンエミュレータを動かすことができます。

Androidアプリでファミコンエミュレータを動かすには, nes-emulator-android の NESView という View派生モジュールを使います。
NESView は通常のAndroidのViewと同様に、レイアウトXMLで配置できます。

（レイアウトXMLの記述例）
<com.suzukiplan.emulator.nes.core.NESView android:id="@+id/nes_view" android:layout_width="match_parent" android:layout_height="match_parent" />

ファミコンの表示解像度は256x240pixel（アスペクト比16:15）なので、ConstraintLayoutを用いて配置してあげても良いですが、Viewを配置したレイアウト内へ自動的にアスペクト比を保った状態で最大限に拡大してセンタリングした状態で表示されます。（余った領域は黒く塗りつぶされます）

このNESViewに対して、

    nesView?.load(romByteArray)

とすればROMファイルをロードできます。

そして、

    nesView?.tick(keyP1.code, keyP2.code)

とすれば1フレーム実行することができます。

NESView#tickを実行すると自動的に垂直同期の待機が行われ、また、サブスレッド（非UIスレッド）から実行できるので、これを連続的に実行してあげればゲームが動きます。

実際のNESViewを用いて実装したエミュレータアプリの本体コードが以下にありますが、Kotlinで100行未満で記述できることが分かります。
https://github.com/suzukiplan/nes-emulator-android/blob/master/test/src/main/java/com/suzukiplan/emulator/nes/test/MainActivity.kt

なお、このNESViewを用いて作成したアプリはGPLv3またはGPLv3と互換性のあるライセンス（Apache v2, MIT, 修正BSD等のOSSライセンス）で公開する必要があるので、ご注意ください。（OSSで公開されているエミュレータのソースコードはだいたいGPL系なので）

登録: 投稿 (Atom)