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の開発で色々とノウハウを培っているので、今回は全く苦労しませんでした。

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

移動開発環境

Androidコンパイル環境の移動開発環境を準備しようと思っていたけど、スッカリ忘れていた。。。
というより、Android SDK自体が重過ぎる。
とりあえず、Eclipseを使っていないから大分マシな方ですが。
しかし、Android SDKだけでもかなり重い上に、NDK、Ant、Cygwinも軽くは無い。

でも、無理してAndroid SDKの移動環境を作る必要は無いかもしれません。
私の場合、VGE上で動作するようにWindowsで開発すればよいだけなので、チープな環境（ノート）に無理してAndroidのビルド環境を作る意味が無いであろう・・・と、思います。

体験版公開までやらなければいけない作業は、
(1) タイトル画面作成
(2) スコアシステム作成
(3) 1面後半（中ボス後）作成
(4) １ボス作成

一応、どれも実機が無ければ作成できない訳ではない。
上記(4)の作業については、実機が無いと調整が難しいですが、大枠についてはWindowsオンリーで問題無い（ハズ）。

ちなみに現在、(1)を作成中。

残作業は、デモプレイの画面を付けたりする作業など。

デモプレイというのは、タイトルで暫く放置しておけば勝手に始まる、STGでお馴染みのアレ。

デモプレイを入れる目的は、HowToPlay（遊び方）を短時間で端的に使えるため。

HowToPlayは言語差を考慮してこのデモプレイのみ。

デモプレイを付けるには、リプレイ機能を一通り作らないといけないから、やや大変です。

体験版では、リプレイ機能自体は使用不可にしますが。

体験版は、パーミッション不要にしたいので、ファイル保存系の機能は全般的に入れない予定。

あと、どうでも良いですが、タイトルは、Atomic Laser→NOKOGI Rider（ノコギライダー）に変更。

しかし、シューティングっぽくないタイトルだ・・・レースゲームと勘違いされそう。

販売する国と地域

開発中のSTGを販売する国／地域をどうするか・・・という問題があります。
消費間接税が色々と厄介なので。

日本の場合は問題無いです。
日本の消費税は、基準年度の課税売上が1,000万円を超えない限り、課税対象とはならないので、まず、問題にならない筈なので、まず気にする必要はありません。（そこまでの収益を上げるには、100円の収益のゲームなら10万本以上・・・だから、まず無理ぽです）
万が一、必要になっても、日本での手続きならちゃんと意思疎通ができるから問題ありません。
（確定申告ぐらいしかやったことありませんが）

問題は、海外の消費間接税。
例えば、欧州の付加価値税（VAT）は、年間売上が10,000€を超える場合、海外の事業者でも支払う必要があるようです。確か、日本の消費税は、海外の事業者が日本で販売した場合、非課税になったと思いますが。

物理的なモノの取引であれば水際（＝税関）でチェックが働くから、制度上問題ありませんが、電子商取引の場合、物理的なモノが無いから、完全に事業者側の自己申告に頼るしかないので、制度上問題があります。つまり、善意者の過失を防ぐ手段が無いことが問題です。例えば、国内の取引であれば、（自国の）法律を知らないでは済まされませんが、消費間接税については相手の国の法律によるものなので、どちらかというと知らない方が普通です。

ちなみに、Appleの場合、（EUのVATが問題になるのは有名な話しなので）Appleがその辺りを代行してくれるようですが、Googleの場合、その辺りのことは、各デベロッパに○投げという契約になっています。
どっちが正しいのかは微妙。
取引の公平性という観点で、Appleのやり方が正しい気がしますが。
というより、そうしないと税の面でクリーンな取引は不可能なんじゃないかな・・・と、思います。

さて、どうしたものか。

Invader Block 2 was uploaded in SOFTPEDIA

Invader Block 2（Windows版）が、SOFTPEDIAさんという海外サイトで配布開始されたようです。
http://games.softpedia.com/get/Freeware-Games/Invader-Block.shtml

Download.comの紹介文は私が書いたのですが、上記はSOFTPEDIAのライターさんが紹介文を書いてくれました。意思疎通する程度の英語を書いたり読んだりするのは概ね問題無いのですが、英語圏の方の感覚にマッチした書き方は分からないので、助かります。
「アルカノイド＆スペースインヴェーダーにインスパイアされたファンゲーム」
とのこと。
なるほど。

アップロードから数分程度しか時間が経っていないのですが、もう、15本ぐらいDLされたようです。
これで、ちょっとは海外でも（Android版が）売れるかな。
まぁ、売れる売れないは別として、色々な国の人に遊んで貰えるだけでも嬉しいものです。

スクリーン仕様変更

開発中のSTGのスクリーン仕様を大幅に変えることにしました。
私が開発しているゲームエンジンは、「240x320の仮想ビデオメモリ領域をアスペクト比を保った状態で最大限に拡大し、画面中央に配置する」という仕様です。

Androidの場合、最も画面領域の小さい機種が240x320（QVGA）だという事情もありますが、個人的にQVGAが一番ゲームが作り易いし、ちょっと粗い感じの画面が好きだという事情が一番大きいです。もちろん、その部分の仕様は変更しません。

仕様変更するのは、「画面中央に配置」という部分。
具体的には下図のような感じに仕様変更します。

端末画面の縦横比が４：３（VGAやQVGAなど）の場合、画面目一杯拡大される形になります。
しかし、現状、市場に流通しているAndroidは、殆ど１．５：１（iPhoneと同じ比率）です。
１．５：１の画面の中に４：３の仮想スクリーンを、アスペクト比を保った状態で最大限に拡大すると、必然的に画面の上下にBLANK（余白）が発生します。

そして、そのBLANKを上下に均等分配していたものを、下に纏める形にします。
もちろん、仕様変更前の方がカッコイイんですが、背に腹はかえられぬ事情があります。

BLANK領域にも当然ながらタッチ判定があるのですが、現状仕様だと、プレイ中に誤ってHOMEボタンやRETURNボタンを押してしまう可能性が高そうだったので。つまり、誤ってホーム画面に戻ってしまったり、ポーズしてしまう誤操作が、かなりの高確率で発生してしまいます。（今日、昼休み中のテストプレイで数回、発生）

INVADER BLOCK2のように、左右移動だけなら発生することはほぼ無いですが。
しかし、開発中のSTGは、上下移動はよくするので、目を瞑れない程度のレベルで誤操作してしまいます。

という訳で、画面下にタッチ用の余白を確保することにしました。
まぁ、iPhoneの勢力からして、Androidの主流が再び４：３に戻ることは無いだろうと期待しつつ。

っていうか、そもそもボタンを画面下に持ってくる設計がそもそも微妙な気がしますが。
ハードウェアのボタンは画面上でも全然困らないです。
ゲーム以外のアプリでも、ボタンが画面下にある所為で操作ミスすることがありますし。

そういう操作ミスをし易いアプリを操作する場合、基本的に逆さまにして操作していｒ...
・・・これを書いていて気付いたのですが、画面を上下逆表示する機能があれば、良いんじゃない？という神が掛かったアイディアを思いつきました。（ちなみに、重力判定は重いからoffにしているので、ソフトウェア的に実装する必要があるから、若干面倒ですが、無理ではないです）