12. GunBlade Ver 1.18 [2002.11.12]
11. GunBlade Ver 1.17 [2002.08.04]
10. GunBlade Ver 1.16 [2002.01.08]
09. 【番外編】GunBlade++ for Windows Ver 1.00 [2001.11.05]
08. GunBlade Ver 1.15 [2001.09.17]
07. GunBlade Ver 1.12 [2001.06.29]
06. GunBlade Ver 1.10 [2001.06.20]
05. GunBlade Ver 1.01 [2001.01.12]
04. GunBlade [2000.12.19]
03. 縦スクロールで撃ち落とす奴。 [2000.11.30]
02. ぐるぐる回って全部撃ち落とす奴。 [1999.12.11]
01. ２つ以上くっついてるブロックを消していく奴。 [1999.10.27]

・アンチエイリアスもどき実装。
　今まで気になっていた回転表示部分のがたがた具合が、ふと考えると改善できそうなことに気付いて実装。
　基本的には、Pictureクラス内で初期化時に静的に回転画像を生成する際に、元画像に対して縦横２倍のオーバーサンプリングを行ってから回転させて、その結果を縮小する際に画素情報の合成計算を行う、だけ。
　画像の輪郭内部については単純に隣り合う画素の色の合成を行う。輪郭部分は(あくまでも静的に回転画像を作ってるため)合成対象となる背景画像が無いので画素ごとのアルファブレンディング値として情報を保持しておくことにする。
　もともと、Renderクラス内の画像表示部分で画素単位で背景との合成を行っていて、アルファブレンディング計算を行ってるので、回転画像生成時に計算したアルファブレンディング情報も加味して処理する、だけで表示処理追加も完了。
　よって、改修前は、相当な処理の追加を覚悟していたものの、実にあっさりと実装完了してしまって、ちょっと表示抜け。

　縦横２倍のオーバーサンプリングなので、４階調のアンチエイリアシング処理になのだが、４階調でもやるとやらないとでは大違いで、処理結果はかなり変わった。
　とはいえ、所詮はちまちました画像しか描いてないので、実行画面を静止画像で取り込んで拡大して並べないとはっきりとした違いはわからない。普通に動かしてると「ちょっと画像のフォーカスが甘くなったかな」って感じるだけである。
　とりあえず、このやり方で望みの結果が得られる、ということがわかったのでそれでよしとする。

　オーバーサンプリング率を３倍(９階調)とか４倍(16階調)にする、という選択肢も残っているのだが、もともと実装していた24bitカラーのアルファブレンディング計算処理において、(当然ながら)25%,50%,75%だけはビットシフトと加減算だけで実現しているのに対し、その他の比率の計算は掛け算も使ってて処理負荷が跳ね上がるので、縦横２倍(４階調)が適当なバランスと割り切る。
　このくらいなら、今までの処理に対して多大な処理負荷増にはならないはずだし、これ以上やっても見た目が劇的に変わるとも思えないので。

　今まで画像単位のアルファブレンディング表示は実現していたけど、さらに画素単位のアルファブレンディング表示が実装された。とはいえ、私の知る限り、画素単位でアルファ値を設定できるペイントツールを知らないので、回転画像みたいに内部生成する画像にしか適用できないのが残念。
　かといって、画像の拡大縮小表示は動的に計算してるので、そこでオーバーサンプリングなんて高負荷処理をやる勇気もなし。

・もともとの想定範囲内の処理修正だったので、意外にもわずかな改修で大きな成果が得られた(ことにする)。がしかし、そろそろ増築に次ぐ増築でソースが複雑になってきた。またどこかで仕切りなおしをする必要があるかも。確か既に２回もクラスの大改修してるんですけど。

・というわけで、「プログラムを修正しながらあるべき姿にしていくのは誰にでもできることで、あるべき姿のプログラムを最初から書けるのがセンスのあるプログラマーだ」という(会社の上司による)お言葉が身に染みる今日この頃。

・見た目を少し変える。
　プログラムとしては、前バージョンとほとんど変わらず。
　ただ、最近になって新技術(Photoshop Elements)を投入したので、Photoshopの使い方の習熟を兼ねて見た目を少しだけ描き直す。といっても、若干のフィルタをかけただけであるが。

・やっと趣味の範囲の値段になったPhotoshopとしてのPhotoshop Elementsだが、値段の安さの割に非常に多機能かつ親切設計でコストパフォーマンスは抜群に高いと感じる。

・長い間このプログラムを放置していた割には内容がほとんど変わっていない。本当は色々と試してみたいことがあるのだがなかなか時間が取れず、とりあえず手持ち最新バージョンを公開。

・コーディングレベルでの各種高速化。
　VC++なんかに比べると実行速度が遅いJavaではあるが、できるだけの努力をしてみようと色々とやってみる。

1)ループ内処理を外に出す。
　古典的手法であるが、実行回数の多いループの中の処理をできるだけ外に出す。おかげで、処理そのものの見た目がかなり長くなったりした部分もある。
　効果のほどは今ひとつよくわからず。

2)System.arraycopyを使用。
　そもそも、その存在を知らなかったarraycopyを、使える場所には使った。
　さすがにループで回してコピーするよりは速いはずなのだが、今回は適用箇所が非常に少ないのであまり目立った変化は無し。

3)forループの終了判定条件を0に絡める。
　0から9まで10回処理するforループは、0から9へ回すのではなく、9から0へ回す。
　こんなことで速くなるというのも嬉しくないのだが、現状の実行環境では１割くらい速くなるので仕方なく実施。
　ちょっとソースの見た目がわかりにくい(と私は思う)。慣れの問題とは思うが。

4)Staticな配列へのアクセスは、ローカルなauto変数(ポインタ)を介して行う。
　C言語的な感覚で、巨大な配列にアクセスするときにはStaticな配列にしておいてそれを直接アクセスしていたのだが、Java(というよりJVM)はスタックマシンだからローカル変数へのアクセスの方が高速であるとかなんとか本に書いてあった。
　ので、ローカルなauto変数でポインタを用意して、そこに配列のアドレスをコピーして、それを使ってアクセスするようにした。
　なんだかんだで、２割近く高速になったのでちょっとびっくり。

5)その他、細々とした高速化。
　色々やったけど、ほんとに速いかどうかはよくわからない。

　…と、実行時の見た目はほとんど変わってないけど、ソースコードはかなり激しく変わってたりする。特に、Render.java。

・コーディングレベルでの高速化はある程度できる、ということはわかった。が、しかし、それはあくまでも現状のJava実行環境では速くなった、というだけで、JVMが進化すれば意味のない高速化テクニックになるかもしれないし、最悪の場合速度低下してしまうかもしれない。
　ここら辺が、仮想マシン上で実行するJavaの弱みでもあり強みでもあるのだけど…。

・気が付いたら１年越しでバージョンアップを続けてきたappletである。最初のバージョンと見比べると見た目はかなり違うものになったけど、ゲーム内容はほとんど変わってない。
　この１年で、それぞれの部品としてのClassファイルはある程度固まってきたので、そろそろ新しいプログラムを書き起こしたいところだけど、暇は無し。

　Zipファイル展開してexeファイル実行するだけです。レジストリも触ってない(はずな)ので、いらなくなったらまとめて消してOKです。

　Win98(SE)/NT4.0/2000では動きました。
　起動には16bit以上のカラーモードが必要です。24/32bitカラーモードだと処理が重くなるので、16bitカラーモードでの起動を推奨します。

　一応動作確認はしてるものの、VC++でプログラム書くのは初めてなので全ての環境での動作保証はできません。

・VC++へ移植。
　なんだかんだで今まで避けて通ってきたC++。ちょっとVC++に触る機会があったので試しにJavaAppletを移植してみる。移植元はVer1.15。

　…といっても、もともと環境依存な部分ってあまりなくて、作り直したのは最終的な表示イメージを作ってるRenderクラスと画像データをファイルから読み込んで管理するPictureクラスだけ。それ以外は単純にJavaソースファイルをC++でコンパイルが通るように書き直しただけ、で、なんともあっさりと動いてしまって拍子抜け。
　でも、音に関してはVC++のMFCの範囲内で鳴らすと音が重ならない(前の音の再生中に次の音が鳴ると、前の音が消えてしまう)ので、あきらめる。DirectSoundを使えばいいらしいけど、今回の目的は「C++に移植してみること」なのですっぱりと捨てる。

　あと、実行時の画面カラーモードによって処理を変える必要があったので、表示色を65536色(16bit)に落とす。Java版は24bitカラー、と言っても、私の描いたドット絵なんて16bitもあれば充分なので、見た目はほとんど変わらない。
　ついでに、動的な表示倍率変更機能もおまけで付ける。これに関してはStretchBltを使ってるだけなので非常に楽だし２倍表示にしてもほとんど動作速度が落ちない(環境もある)ので嬉しい。ここら辺はさすがVC++って感じだが、全く同じハードウェア構成のマシンで2000よりNT4.0の方があきらかに２倍表示モードの処理が軽いというのはどーゆうことか？
　それ以外は、ソースコードベースで移植したので動作は全く同じ(はず)。タイトル画面をちょっと変えて、操作説明表示も追加した、くらい。


　あっさり動いた、と言っても、そこはそれさすがに言語仕様の違いで引っかかった部分もある。
　以下、つらつらと書いてみると…。

　・C++は配列の要素数を取得できない。所詮はC言語だから仕方ないか。
　・Javaの習慣でコンストラクタから自分のコンストラクタを呼ぶと、どこかに別のインスタンスを作って捨ててるらしい(想像)。動作がおかしいけどコンパイルエラーは出ないためしばらく悩む。
　・constオブジェクトは厳密には定数扱いじゃない(らしい)ので、Javaのfinalみたいにswitch文のcase部に使えない。
　・staticなクラスが無い？Javaのように静的初期化処理を書く場所が無い。これはコンストラクタ無しでも静的な処理は動く(書ける)というJavaの方が特殊なのかも(便利なんだけど)。
　・参照するクラスは全て明示的に指定する必要がある。これは参照するクラスを勝手に探し出して使ってくれるJavaの方が特殊なのかも(ものすごく便利なんだけど)。
　・(少なくともVC++では)参照するクラスの指定は、クラス定義を書いたヘッダファイルをincludeするという非常にC言語ライクなスタイルなので、staticなクラス変数の実体定義だけはヘッダファイル以外の場所に書く必要がある、というのが非常に中途半端で美しくない。
　・関数の引数にクラスを使うと、どうしてもポインタ渡しになって美しくない。というか、Javaにはもともとポインタ演算子が無いので、ここの部分の変更に一番手間がかかった。
　・周期処理を動かすのにタイマーを使うのだが、OnTimerを使うとNT系OSで動かすとちゃんと動くものの、9x系OSだとぼろぼろだった(10Hzくらいでしかイベント発生しない)ので、仕方なく起動時にOS種別を調べて、NT系と9x系では違うタイマーを使うようにした。
　・newしたものはdeleteする必要があるというのはやっぱりめんどくさい。
　・ほとんどの型はJavaからそのまま使えたけど、String型はさすがにchar*に書き換える必要があった。CString型を使えばよかったのかもしれないけど、char*が使えるならそれで充分。って、文字列使ってる場所が少ないからそんなことが言えるのかも。
　・Javaでのabstract機能に(たぶん)相当するvirtual関数、定義書式が非常に美しくない、というか納得いかない。
　・constな関数の書式もなんか変。
　
　…とはいえ、Javaの言語仕様に存在してC++の言語仕様に全く存在しない機能というのは(今回の移植範囲では)なかったので、基本的には機能の置き換えだけで済んだ。

　以上、まだC++を使い始めて２週間の初心者モードなので事実誤認があるかも。

で、C++に移植して楽だと感じたこと。
　・sprintfは偉大である。
以上。

　これが、初めて作ったWindowsアプリケーションなので自分のプログラムのアイコン描くのも初めてでちょっと嬉しい。
　あと、やっぱり全般的な動作はNT系OSの方がきっちり動いてるように見える。

・溜め撃ちシステム実装。
　前々から検討していた"溜め"による攻撃力アップ。元々押しっぱなしを許可してる操作系なので、"溜め"には「ドラゴンセーバー」方式を採用。調子に乗って反動までつけたら、気分はもうすっかりグ○ナダ。
　攻撃方法も最初は誘爆弾にしようかと思ってたが、ゼロ距離射撃で死亡するので、貫通弾を採用。
　こーゆうシステムを導入すると、色々欲張ったプレイになるので、とたんにクリアが難しくなったり(^^;。

・プロポーショナルフォントの実装。
　起動シーケンスとか、画面に表示させてみたのだが、いつまでも昔ながらの等幅フォントも味気ないなー、ということで、生まれて初めてプロポーショナルフォントを作ってみる。
　って、フォントデータそのものはほとんど何も変わらなくて、フォント管理クラスを１個新規に作ってフォント幅データを持たせただけ、だけど。
　でも、クラスというからくりがあるおかげで、こーゆう場合にはデータ置き場と処理の実装場所に悩まずにすかっと書けるので便利だなー、と感じる。

・Audioファイルの起動時読み込み。
　Audioファイルの起動時読み込みは以前からやっているのだが、起動時に読み込み処理を書いても実際に読み込みが行われるのは最初に鳴らしたとき、で、気持ち悪かったのでなんとかそれを回避。
　正しくはどうすべきかわからなかったのだが、MediaTrackerに登録できるのは画像ファイルのみみたいだし、よくわからないので、起動時の読み込み直後にplay()とstop()を立て続けに実行することによって、ばれないように読み込ませるという卑怯な手段を採用。
　でも、実行環境によっては一瞬音が鳴ってしまってばればれだったり。

・methodの追加と整理。
　実行の見た目はほとんど変わってないけど、Renderクラスのmethodを整理した。と言っても、やっぱりまだ美しくないソースなのだが。
　ついでに、半透明を実装したときに、一番最初に某氏に見せたら「サターンの半透明処理みたいで汚い」と言われたのだが、確かに新規に描画モードを追加したらちょっと見栄えが良くなって、さすが某氏は絵描きだけあってつっこみが鋭いなー、と思ったり。
　他にも、過去の残骸methodをばっさり削除したり、バグ^H^H正しくない仕様が紛れ込んでいたので書き換えたり、無駄な処理を省いたり、色々。

・Netscape 6.1で動作が不安定
　少なくとも、NT4.0にNetscape 6.1でローカルな環境で動かすと、あるとき突然画面更新が止まって、音だけ鳴って処理が続くという現象が発生。Java Consoleを見ると例外が発生しているのは確かだけど、原因がUnknownだし場所もわからないのでさっぱりわからない。
　とりあえず他の環境では起きない現象なので、Netscapeのせいにしてしまう。

・溜め撃ちによる武器の使い分けが、いまいちエレガントでないのだが、固定砲台に漫然と通常弾を撃ち込み続けるよりはまし、なので、これで妥協。

・ソースファイルはかなり整理したけど、そろそろ増築も限界っぽい。

・全般的な処理高速化。
　実は、Ver1.01からVer1.10に移行したときに、こっそり省かれていた機能として背景描画があった。機能上は問題なかったが、実装すると処理負荷が重たくなってあきらめていたのである。
　それも含めて、今まで静的な物体を動的に描画していたのを、静的に描画する機能をClass Renderに実装することにより解決。
　これで、全般的に処理速度が上がるとともに、こーゆうゲームなら背景をどれだけ凝ったものにしても処理負荷は変わらなくなった、はず。
　というわけで、見た目は変わってないけど、動かない物体の描画方法は大きく変わった。

・２倍サイズ描画モード。
　今まで、試験的に実装しては、あまりにも遅くてあきらめていたモードだけど、試しに公開。もっと高速で賢いやり方があるのかも。
　でも、CPUクロック1.2GHzマシンとかだと２倍描画でも速すぎる。

・その他細々とした変更。
　物体に影もどきを付けたり。古典的な方法だけど、処理負荷が低いわりにはそれなりの見栄えになるので。

・見た目はあまり変えてないけど、内部処理で無駄なものをがんがん省いていったので、少しは処理速度が上がった。

・画面描画を全面入れ替え。
　今までの２次元ポリゴンによる描画から、ドット絵の描画に変更。某Appletを参考にして、画素情報を全て自前で管理して表示画面の生成を行うことにしてみる。
　Java AWTのグラフィック命令は使えなくなって汎用性は下がるけど、自分で画像を生成するおかげで透過率指定描画でもなんでもありありの世界になって嬉しい。やっと念願の半透明描画が実現。
　それ以外にも、回転拡大縮小描画やラスタスクロール等、好き放題実装してみる。

　…という新たな画面描画Classを作ったので、まずは載せてみる題材としてまたもやGunBlade。ほんとは新規に何か作りたかったのだがそんな暇もなし。
　画面描画がまるっきり変わったにも関わらず、変更が必要だったのはほんとに描画に絡む部分だけ、それも引数を変えるだけでほとんどそのまま動いてしまった。
　全ては、Classという得体の知れない塊をそのまま引数として渡せてしまうという言語仕様のメリットなのか？内部で実際にどんなデータが渡されて、どう処理されてるのかさっぱり見えないのが気持ち悪いが、何も考えなくていいというのは割り切ってしまえば楽かも。
　とは言え、所詮は後付けで処理のすげ替えを行ったので、無駄な部分も無きにしもあらず。本当は新しいClassにあわせた設計にすべきなんだけど、試験運用的なバージョンなので妥協。で、かなり汚いソースになってしまった。
　というわけで、新方式の描画Classの実用試験も兼ねて、なので、やりすぎってくらい画面表示で遊んでみる。

・描画形式をポリゴンからドット絵にしたので、久しぶりにドット絵描き。
　今回は8ドットと12ドットと16ドットのフォントを描いたり、デザインを試行錯誤したり、なかなか楽しかったのだが、これも気がすむまでやろうとすると永遠に終わらない作業なので適当に切り上げる。

・効果音を付けた。
　本当はVer 1.02の時点で効果音は付けてたんだけど1.02は非公開だったので…。
　試しに鳴らしてみるとどんなだろう、ってレベルなのでかなり適当。

・どーでもいいけど(よくない)、実質上finalなmethodは明示的にfinalと宣言してみる。
　『Javaの格言』とかを読むとfinalと明示することによってコンパイラの最適化が期待できると書いてあるが、効果のほどはよくわからなかった。

・threadのwait時間をキー入力により可変にしてみ。
　が、処理系によって激しく挙動が違う。Windows上のNetscape4.7xとか時間計測がかなりいい加減である。もともとWindowsの時間精度も10msecだったと思うけど、その上で10msec以上の精度を期待するのが無茶か？でも、IEだとNetscapeよりはましな精度な気がする。
　やっぱり一番ちゃんとした時間精度で動いているように見えるのはAppletviewer。

・画面まわり処理をごっそり入れ換えたにもかかわらず、修正個所は驚くほど少なかったのでびっくり。
・ドット絵描画にしたので、今までのポリゴン描画とはまた違った雰囲気になる。昔のバージョンと比較してみるとなかなか面白い。まぁ、色々と表現方法を試行錯誤するのは楽しい。趣味の世界だし。

・Class Plateをさらに拡張して陰影付き（のような）描画モードを追加。

　２次元ポリゴン管理用に作ってきたClass Plateをちょっと機能拡張して 陰影付きっぽく描くモードを実装。
　光源方向は固定だし、大した計算はやっていないが表示処理負荷が上がるのは確かなので、 負荷を比較するために前作をベースに実装してみた。
　あまりにちまちまとした図形に適用しても嬉しくないので、 ほんとは次に作るプログラムから実装するつもりだったけど、 どんな風に見えるのかという確認も兼ねて。

　…というわけで、表示処理を拡張しただけなので ゲーム内容はほとんど変わってません。
　敵の動きを若干直したのと、得点が100万点を越えると表示上は0に戻ってしまって 悲しかったので得点表示を１桁増やした、だけ。

・なんかあまり変わったように見えないけど、Ver1.00と比較すると 見た目はかなり変わって、処理速度はちょっと落ちた。

・グロ○ダーを作る。以上、終わり。

　前作でやっと一通りの材料が揃ったので、今までの習作と違って 真面目にゲームとして作成。
　個人的に思い入れのあるジャンルである戦車ものである。 グロ○ダーをベースにグラ○ダ的操作系を導入。…と言ってしまうとそれで終わり なゲーム内容、である。

　プログラム的な新しい要素としては、Javaのガベージコレクションを信用して newしまくる、という作りにしてみた。各面毎の敵オブジェクトに関してのみ、 であるが。
　それも絡んで、敵クラスの処理を束ねるために今回初めて抽象化クラス というものを使う。これにより一気に敵関連処理の修正・追加が楽になった。

　クラス単位での追加修正が楽なのと、システムの骨組みを前作から流用したおかげで コーディングそのものはびっくりするくらいのペースで進んだ。
　とりあえずこーゆう振る舞いの物体を追加しようと思い立って、30分くらいで 実装できてしまうというなんだか不思議な感覚。今まで使ってた言語とはちょいと 違うなぁ、ということを初めて実感した。

　そんなこんなで、物体毎に個別のクラスを用意していったので、クラス数は 22まで膨れ上がった。Javaで遊び初めた頃、本に載ってるサンプルを眺めては 「なんでこんなにクラスをばらばらにするかなー、読みにくいなー」と思ったものだが、 結局こうなってしまうのね。
　ソースとは別にクラス関連図みたいなものがないと他人が書いたプログラムを読むのは 難儀しそうであるなぁ。

　で、今回実感したJavaの便利さとして以下の２点がある。

・モジュール追加が楽。
　javacがmakeに近い仕事もやってくれるので、クラスを追加したときも単にメインの クラスのコンパイルをjavacにお願いするだけで参照しているクラスを勝手に探して コンパイルしてくれるし、タイムスタンプのチェックも行うので変更したソースのみ コンパイルしてくれる。
　ささいな事だけど、クラスをじゃんじゃん追加していってもコンパイル用のスクリプトは 一切変更しなくて済む、というのは個人的お遊びプログラムを書くときは楽である。
・エラー表示が親切。
　コンパイル時のエラー表示も親切であるが、それよりもありがたいのが 実行時のエラー表示である。
　実行時に異常停止しても、どこのモジュールのなんてMethodで何が起きたか、 まで表示してくれるのでデバッグがとても楽である。

　こーゆう細かい部分の使い勝手がよい、というのはJavaという言語が 最近作られた言語だからだろうなぁと勝手に思ったり。

・クラスの継承というからくりはモジュール追加修正する上で とても嬉しい（今さら）。

・多角形を組み合わせたものを１つのClassで管理して、 ソフトウェアスプライト的に使う。

　と、前回のプログラムを踏まえて当初の目的はこれだけだったのだが、 それを実装する題材としてまたもや撃ちもの、しかもスクロールっぽいもの にしたので、
・場面展開、というかオブジェクトの生成タイミングと位置を記述して 状況を管理する。
　とか、
・途中で『Javaの格言』という本を読んで、Classの外からの変数アクセスは全て method経由にしちゃったり。
・なんだかんだでClassを独立させていくと、必然的にClassの継承を 行う必要がでてきたり。

　さらに、

・ちゃんと実行時間を計測して、できるだけCPUパワーに依存せず一定速度で 動かしたかったけど、実行環境によって時間計測精度がまちまちである程度 妥協した。

・前回、前々回のプログラムでブラウザを終了させると、どうしてもThreadが 生き残っていたのを、JDKのドキュメントのサンプル通りに直してやっとThreadが ちゃんと解放されるようになった。

・試しに、三角関数等の数学関数を全てテーブル化して整数引数で使えるようにしてみた。 精度は落ちてるはずだけどゲームだから問題ないし、角度は整数の方が使いやすいので 本採用。速度的なメリットは不明。

・例によって、ほとんど動きが出来上がってから、Class構成の見直しをかけた。今回は 真面目に書き直したので、動きはそのままでプログラム構成全面改訂ということが ２回ほど発生。おかげで、Class構成的にはあまり不満は残っていない。 当然これがベストってわけでもないが。

・文字表示に関しては、前々回はGIFイメージ、前回は標準フォント、とやってみて、 どっちも一長一短だったので、今回は完全にプログラム内部でデータを生成して管理。 外部ファイルに依存せず、環境によって配置が変わることもない、そのかわり見栄えは いまいち、というものになった。まぁ、配置まできっちり自前で管理できるし、 ベクトルデータだから回転拡大縮小もできるのでこっちの方が嬉しい。

・今回もまたもや実行環境によって挙動が違う問題が発生。実は前回も同じ問題は 発生していて、よくわからないまま暫定回避していたのだが、今回はもう少し状況が 特定できた。何故かNetscapeCommunicatorで走らせるとrepaint()直前の描画命令が いくつか捨てられる、ように見える。appletviewerやIEだと問題ないので、 結局画面外にダミー描画を繰り返してまたもや暫定回避。

・最終的にClassの数が16個、と増えたのでjarファイルに固めてみる。どれだけの 処理系でjarファイルを受け付けてくれるかよくわからないが、最近のブラウザだと 問題ないようだ。

・真面目に変数アクセス用methodを全部用意したり、Classの継承も使ってみて、 ちょっとだけ今風のプログラミングのありがたみがわかったような気がする。

・ゲームとしては不完全な出来だけど、プログラム要素としては入れたいものは 一通り実装したので今回はここで終了。こり始めるときりがない。

・高速化も考慮せずに作ったわりには処理速度の問題は発生せず楽に作ることができた。 これはひとえに最近のCPUの非常識なまでの高速化のおかげであろう。 あまり労せずにこんなプログラムが作れるとはいい時代になったなぁ、と思う。 しかも言語環境一式無料だし。

・行き当たりばったりで作ったわりには、最終的にはそれなりにまともな構成になった (と信じる)。適当に作っていても途中でソースコードが正しい構成を主張し始めるので それに従っていくとClass構成はあるべき姿に収まっていくように感じた。ほんとは、 最初からあるべき姿で設計すべきなんだろうけど、まぁ趣味のコーディングだし 試行錯誤段階である。

・自立して運動する物体を実現するClassを作って、物理パラメータを 変数として持たせる。
　物体の各種振舞いをmethodとして記述する。

・と、いうことを踏まえて、さらにシューティングものが作りたい、というわけで、 これまた古典的なゲームを題材に選ぶ。
　既にあるゲームを実装するのは、仕様を考えなくていいぶん楽なので、こーゆう 練習用のプログラムを書くにはぴったり。
　画面上で動いているものは全て前述のClass１つでまかなっている。これはこれで プログラムを書くのが楽でよいなぁ。

・ついでに、前回はパスしたキーボード入力も実装してみる。
　が、ここに落とし穴があって、実行環境依存の動作の違いが出て、それを 解決するのにしばらく時間がかかった。
　AppletViewerで動かすと、さっぱりキー入力イベントが発生しない、 という問題は、初期化時にrequestFocus()を呼ぶことにより解決。
　Netscapeで動かすと、最初にApplet上でマウスクリックを １回やってからじゃないとキー入力を受け付けない、のは起動時に強制的に １回クリックさせてから開始する仕様にしてごまかす。

・ほとんど動きが出来上がってから、publicにすべきデータとprivateにすべきデータの 間の線引きがどこら辺にあるのかわかったような気がするが、後の祭。 美しくないソースになったなぁ、と思いつつ次回への教訓とする（ほんとか？）。

・文字表示は今回はめんどくさいので、標準のfontを使って表示。
　これがまた環境(ブラウザ)によって文字幅が変わって困るのだが、 これをなんとかするのは大変そうなので保留。
　IEで実行すると文字位置表示が気に入らないが、いいや。

・たぶん、正当な作り方としては、インスタンスは使うときにじゃんじゃん作って、 廃棄はガベージコレクションにまかせるべきなんだろけど、 どうしても貧乏人根性の抜けない私は静的領域を確保して自分で管理した。
　やっぱり、作りっぱなしでほったらかしにしておくというのは気持ち悪いのだ。 ガベージコレクションはちゃんとやってくれるんだろうけど、どうもねぇ。
　でも、それを期待した作りにすると、もっとシンプルなソースになるはずなので、 そのうち試してみるのもいいかも。

・画面効果については、多すぎても少なすぎても見栄えがよくない、 ということを思い知る。今の状態の見栄えがいいか、っていうと 当然そんなこたないのだが。
　さらに、とある問題は凄く安直な方法で回避したが、見てわかんなきゃ それでいい、というのもまた真理。

・物体の衝突判定は、距離だけ、といういい加減な方法だが、見た目あんまり 違和感が無いので、これまたわからなきゃそれでいい、のだ。

・前回と違って、割とまじめな作りにした、つもり。
　だけど、美しくない部分が多々あるので、もうちょっとちゃんと作らなきゃなぁ。

・この手のプログラムでは定番の最適化は色々やってみたけど、果たして効果がそれほど あったのかというと、疑問。
　さすがに、三角関数をテーブルで持つとこまではしてないけど(^^;。

・スレッドを１つだけ生成して、周期処理を行う。昔のパソコンだとV-Sync割り込み先を ぶんどるだけで簡単に周期処理が出来てたのになぁ。
　ほんとは、昔ながらの60Hz処理にしたかったのだが、今のマシン(OS)で表示レートを 60Hzにしても意味が無いので周期は適当。

・イベントリスナを使ってマウス入力を受ける。

・仮想GRAM的バッファを内部で持って、キャラクターコードを敷き詰めて描画する。 8Bit時代のPCG搭載パソコン的な古典的使い方。
　これが、思った以上にCPUパワーを消費することがわかって、これまた古典的な 描画更新の際に、変化したキャラクターだけ書き換えるという手法を使う。
　従って、今のCPUパワーにものを言わせてお大尽な組み方でも楽々動くかという 淡い期待は崩れ去る。

・16x16のキャラクターコード対応Imageは１枚絵で （こんなの(描きかけ)）読み込んで、読み込み後に ImageProducerを使って各キャラクターに分割する。一応、MediaTrackerも 使ってみる。

・透明GIFファイルを読み込んで描画することにより、Imageの重ね合わせを行う。 場面転換処理で使ってみたが、こればかりは全画面書き換えなので、 要PentiumII/300MHzと言わんばかりの強烈に重い処理となる。

・上記のことを実装したその上に載せるアルゴリズムとしては、かなり簡単そうな 某パズルを採用。落ちものパズルですらないので、ほぼ最低限の処理で済んだ。

・とりあえず以上のことが確認できればいいので、グラフィックは最低限の 書き込みにとどめた、ので見た目は（も）結構手抜きっぽい。
　とはいえ、デジタル８色しか使えなかった以前の環境から比べて、フルカラー中256色 という夢のような世界なので、アンチエイリアシングの真似事はやってみる。
　久々にマウス片手にドット修正、という作業をしたが、 これはこれでとても楽しい。使いやすいグラフィックエディタD-Pixedに感謝。

・こーゆうCPUパワーを湯水のごとく使う作り方は、如何に今のご時世のCPUとはいえ JAVA仮想マシン上で走らせるには無理がある（って、だいたい予想してたけど）。
　次からは正統な（？）作り方をする、かなぁ？

・作成したClassは１つだけという、かなりいい加減な作り方なので、もうちょっと 機能が洗練できてくれば、機能単位でClassを構成するべき、なのだろうなぁ。