初エラーレポート

VGS Chiptune musicがいつの間にやら100DL超えてました。
コメントを見る限り、私の音楽自体が好評みたいで、うれしい限りです。
ありがとうございます。

そして、初めてエラーレポートを１件頂きました。
Javaソース部分でSurfaceViewの使い方にマズイところがあるようです。
マズイですね、これは。
たぶん、Invader Blockの方にも同件の問題がありそう。
今日の夜には、調査＆対策したいと思います。

本当は、今から即効で対策したいところですが、Javaソースの入った開発環境には夜にならないと触れない・・・お出かけ環境にJavaソースを持ってくるのを失念してました。ソースが無くてもある程度推理できますが。
・SurfaceViewのrunで落ちている(NullPointerException）
・SurfaceViewのrunでやっていること
　(1) VGEのグラフィック更新（JNI）→AndroidBitmap作成
　(2) Canvasをlockし、AndroidBitmapを書き込み、unlock
で、NullPointerExceptionになるということは、(2)に問題がある可能性が高い筈。
SurfaceHolder.getHolderで取得したホルダーのインスタンスを、スレッド生存中に使い回しているのがマズイのかな？（ソースを見ていないから、ハズレの可能性も高いですが）
　
しかし、ソースを難読化しなかったお陰で、Java部分でバグがあればすぐに分かって便利。
Javaソースは全体の１％に満たない（99%はCでできている）から、仮に解読されても問題ありません。

1面完成

1面がとりあえず一通り完成。
現状、ステージ後半とボスが成分未調整で、かなり鬼畜な難易度です。
最高難度はこれぐらいでちょうど良いかも。
１面から飛ばし過ぎじゃないか？と思いましたが、最高難度は全面そんな感じであれば。。

しかし、低難度（Easy/Normal）はもっと調整が必要。
ちなみに、難易度はEasy/Normal/Hardの３種類。
ただ、Easy/Normal/Hardという呼び名が気に入らなかったので、
Beginner = Easy
Soldier = Normal
Ninja = Hard
という感じにしました。

東方の難易度に置き換えると、

Beginner = EasyとNormalの中間
Soldier = NormalとHardの中間
Ninja = HardとLunaticの中間
ぐらいのイメージ。
いわゆる弾幕STGではないから、一概に比べることはできませんが。


あと、細かいバグが未対策だったり、エフェクトを付けてない部分も多々あります。
システムも未だノータッチの部分も多数（スコアとかクリアとかコンティニューとか・・・）。
体験版（１面のみ）の完成はまだ遠い。
GW中に体験版が出せるかどうかは、依然として微妙。

αブレンド

自作ゲームエンジン（VGE）に、αブレンド機能を入れようかどうか、迷い中。
とりあえず、
(1)スプライトを特定の色でマスクする機能
(2)スプライトを1/2に縮小表示する機能
を追加で実装。

これらを準備することで、例えば、敵に弾が当たった時の点滅は(1)、空中の機体の影の表示は(1)+(2)という感じで機械的に作成することができます。（当初、ダメージパターンと影パターンをパーツ別に準備していました...）

影の表示は、２フレームの１回の間隔で影パターンを表示して半透明表示を実現しています。
つまり、錯覚を利用してます。
αブレンド（要するに透過表示機能ですね）を実装すれば、毎フレーム描画が可能。

ただ、毎フレーム描画するメリットといえば、画面のスナップショットを撮るのに失敗するのが無くなる以外にどんなメリットがあるのかと、考えると微妙過ぎて実装する気が起きない・・・という訳です。
決定的なメリットがあれば、頑張って実装すれば良いのですが。

逆に、αブレンドを実装しないメリットとしては、処理性能が良いということ。
αブレンドは色素（RGB）毎に平均値を取得する必要があるので若干重い。
ただし、平均値算出に要する演算処理は、αブレンドの方式にもよりけりですが、最もシンプルな方式であればAND演算、ADD演算、SHIFT演算だけ（＝一般的なCPUで処理コストが軽い部類の命令だけ）だし、αブレンド対応に伴う追加の分岐も発生しないから、パイプラインとの相性も良いです。なので、必要最小限に絞って使うようにすれば、性能面でのデメリットはほぼ生じない気もしますが。

使う or 使わないは別にして、とりあえず実装してみるのが吉な気がします。
ただ、Android用のエンジンにも手を入れなければ作れない（Android用のエンジンは16bitカラー、Windows用のエンジンは24bitカラーという違いがある）から、面倒なので、とりあえず後回しで。

DirectGraphic関連

Windowモードでもヌルヌル動くようになった・・・
処理性能が悪かったのは、メインループの処理シーケンスが不味かった模様。

(1) PeekMessage
(2) ゲームのメイン処理呼び出し（VGE-VRAMの描画）
(3) BeginScene
(4) VGE-VRAMをサーフェースへ転送
(5) EndScene
(6) フリップ(Present)

という順序で呼び出していたものを、


(1) PeekMessage
(2) BeginScene
(3) ゲームのメイン処理呼び出し（VGE-VRAMの描画）
(4) VGE-VRAMをサーフェースへ転送
(5) EndScene
(6) フリップ(Present)


という順序にしたら直りました。

どうも、DirectX関連の処理を実行しなくても、重い処理はBeginScene→EndSceneでサンドウィッチしないとマズイようです。

FullScreen対応

Windows版のフルスクリーンモードを実装。
640x480のフルスクリーンにして、240x320のVGEビデオメモリを中央（+200,+80）へ配置しました。

割と沢山隙間が開いています。
x1.5拡大して上下ピッタリにすることもできますが、敢えて拡大しない方向にしました。
このサイズがちょうど、スマホの画面と物理的に同じぐらいのサイズなので。

処理性能が重かった件も解決。
ようやく移動環境（ノーパソ）でヌルヌル動けます。

ちなみに、音声あり or なしのどちらでも、性能的な差異は無しでした。
ピスコラだと、22050Hz/Monoでも結構キツイ環境なんですが。

ピスコラも私の独自音声（VGS）も、仕組みはだいたい同じ（いわゆる、波形メモリ音源）ですが、ピスコラの場合、恐らく音階別の波形データをリアルタイム算出している（※推測）のに対して、VGSの場合、全ての波形（４パターン）＋音階（８０ぐらい）の１周期分の波形データ（約256KB）をメモリにストアしているので、波形計算を咬まない分、ピスコラよりも高速に動くことができる・・・という訳です（たぶん）。この他にも、エンベロープやら色々な計算に浮動小数点数を使っていない（小数点が必要な部分は32bit符号値の固定小数点数で処理している）し、パイプラインハザード抑止（分岐数を最小限にする／分岐は予測分岐でヒットし易い形にする）など、色々やってますが。
代わりに、表現性能は圧倒的に劣りますが。

重い・・・

ノートPC（Windows）で、Android用STGのWindows版をコンパイル→起動してみたら・・・重い。
重過ぎると思ったら、（４ヶ月ぶりぐらいに起動したので）バックで色々とアップデートが走っていたり、シングルCPUだったり、GPUがショボイなど、色々と要因がありますが、それを勘案しても重い。

タスクマネージャで確認したところ、ゲーム自体のCPU使用率はせいぜい20%ぐらい＋他ユーザプロセスを合わせても30%そこそこ。ただし、パフォーマンス（グラフ）で見ると100%張り付き。
ウィンドウ描画でヒィヒィ言っている模様。

全画面モードを実装すれば解消できそうです。
全画面モードならウィンドウ描画も無く、画面サーフェースを排他的に使えるので。
眠いので、明日（今日）直すか・・・

ちなみに、INVADER BLOCK 2のWindows版も同じような感じ。
ってことは、Windows版を折角ダウンロードしてくれたのに、重すぎて買って貰えなかったケースもそこそこあるかもしれない・・・まぁ、INVADER BLOCK 2は、販売の一連の流れを確認するのが最大目的だったので、販売数はあまり気にするところではありませんが。（そもそも、Windows版INVADER BLOCK 2のDL数は、国内で約50DL、海外で約30DL程度ですし）

demoplay(title)

タイトル画面のデモプレイが無事完成。

デモプレイを入れるの面倒ですが、これが無いと「アーケードゲーム」って感じがしません。
アーケードゲームではなく、Android用ゲームですが。
あと、画面キャプチャは、Windows版ですが。（※勿論、Android版も全く同じように動きます）

リプレイ自体、実装はとても簡単なんですが、ちゃんとテーブル設計しないと再生がズレるバグが発生するので厄介です。ただ、その辺りはSHOT01～SHOT03の開発で色々とノウハウを培っているので、今回は全く苦労しませんでした。

本当に苦労しなかったか否かは、完成してみないと分かりませんが・・・