タグ: シューティングゲーム編

おはようございます！

ただいま、第４弾、JavaFX対応版、シューティングゲーム編を執筆中です。
楽しい本に仕上がるといいな～と思っています。

そろそろモジュールの公開をしていきたいと思っていますが、もう少しお待ちを～♪
本を仕上げていく中で、最終チェックを行っていきます。

話は、一周年・・・になっていきますが、
当サイトを開設して、１年となったようです！

そっか～１年かぁ～。この頃も第１弾をやってたのか～・・・と、思い出してきます。何もかもが、手探りのような状態で、やってきた１年。こんなことをやっていいのか・・・思わないでもない日々（自分に才能があるのか？と思わないでもない）。

でも、数年はやってみよう！と、思い立った。すぐに結果や何かが変わるものではない。今もまだ、その途中の中です。
今も昔も思い悩む日々。そこは変わらないかなぁ～・・・。

２年目、よろしくお願いいたします（＿ ＿*

ちなみに、今のところの結果は、びみょうかな。
まだまだ努力が必要な状況です。
がんばります！＼（￣▽￣*／

Graphics2D版とJavaFX版の違いについて

○描画処理の違い（１）
Graphics2D版では描画エンジンを自前で作成していた。
JavaFX版では、描画はJavaFXの仕組みの中で描画している。
（元々、処理速度低下にならないか懸念していたが、結果は問題なし）

○軽量化
Graphics2D版では、Componentを継承した部品群は利用せずに、
独自のオブジェクト（スプライトオブジェクト）を作成し、
Objectを継承していた。
Componentを継承した部品を多用すると、メモリの面、スピード面で、
不利と感じていた（検証はしていない）。

そのため、必要な機能のみに絞ったオブジェクトを作成することで、
軽量化を図っていた。
それが できた（実現できた）という背景もある。

○描画処理の違い（２）
しかし、JavaFX版ではその方法（独自オブジェクト管理）が使えないことが分かる。
JavaFXでは、Canvas－GraphicsContextで、
似たような仕組みを作ることは可能だが、同じではなかった。
回転／拡大縮小が、そのCanvasp全体に対して行われ、
途中の座標変換計算が、すべてサマリされた状態になるだけの模様。

Graphics2D版では、回転させて描画、また別の回転させて描画ということが可能だったが、
JavaFXでは、これができない。軸が全体的にずれてしまう。

自前で描画することを断念。
Nodeオブジェクト（Graphics2D版ではComponentに相当）を継承させ、
描画をJavaFXに任せる方式に変更。

○JavaFXアプリケーションスレッド
JavaFXでは、描画はJavaFXスレッドの中で自動で行われる。（最大1/60秒）
また、JavaFXスレッド以外から、JavaFXへのセッターメソッドなどを利用して値の変更を行うと、
Exceptionが発生する場合がある。

定期的な処理が必要な場合、定期的に呼び出されるタイマーを作成し（JavaFX用の）、
JavaFXスレッド上で処理を行う必要がある。

〇参考にさせていただいたサイト
http://krr.blog.shinobi.jp/
軽Lab。非常に参考にさせていただきました。
ありがとうございます（＿ ＿*

音楽や動画GIFを扱う際の注意点

javax.sounndパッケージではMIDIやWAVEを取り扱うことができる。
動画GIFはjava.awtの辺りで取り扱っていたと思う。
（何年も前に試してたので、記憶が・・・）

この動きのあるものは、実は、裏でスレッドとして動いている。
スレッドで動いていることを知らないと、思わぬ落とし穴に遭うことになる。

スレッド自体は、動きを実現するために（画像を変更する／音楽を鳴らすために）
存在しているものと思われる。
（そういう仕組みであることを知らなかった…）

MIDIオブジェクトなどを、closeせずに、
そのまま次のオブジェクトを生成すると、元々のMIDIオブジェクトが生き残ったままとなる。
スレッドも残ったままとなる。（複数スレッド存在する状態となる）

スレッドと対象オブジェクト位が残る分には、問題ないレベルかもしれないが、
それに関連する（紐ついた）オブジェクトも生きていると判断され、GC対象とはならずに、他の多数のオブジェクトがメモリから消えない状態となる。
つまり、メモリリーク状態となる。

深刻になると、OutOfMemoryErrorが発生する。

実はSKK3.1FXを作成する際に、分かったことである。
つまり、SKK3.1（Graphics2D版）も同様の現象が起きている。
（問題は出にくいが、修正する予定です）

SKK3.1FXでは、実際にOutOfMemoryErrorが発生した。
JavaFX版は、メモリ消費量がGraphics2D版に比べて、高い傾向にある。
（こちらは別途、覚え書きを書くかも）

そのためJavaFXは、OutOfMemoryErrorが発生する確率が高かった。（他の要因もあるかも。他も修正しているので）
３周目に突入すると、異様に遅くなり、最後はメモリを食い潰してしまった。

まとめると、
スレッドが作成されているもののクラスの取り扱いは注意が必要である。
ちなみにJavaFXでは専用のスレッドで管理しているため、改善しているものと思われる。

（もう少し追記）
javax.sounnd等はJavaFXの仲間ではない。Javaの拡張機能の模様。
独自のスレッドを作成している。