こわいですね~(^^;

おはようございます。

今朝2時前から3時過ぎまで、当サイトが攻撃を受けてたようです。

不正なアクセスの試みは1500回にものぼりました。

たまに受けてるっぽいのは、知ってましたが、ここまで大規模なのは、はじめてです。

みなさんもお気をつけください。

わたしは設定の見直しをしました。

さすがにこわくなりました(^^;

どこのどいつじゃ~~~!!
と調べたら、ドイツのIPアドレスでした。

だじゃれだって分かりましたかね?(*´∇`*)

怪しいサイトなのか、踏み台なのか分かりませんが、とにかく自分のサイトは、がんばって守りましょう(* ̄∇ ̄*)

シェアしていただけるとうれしいです。

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

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

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

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

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

○描画処理の違い(2)
しかし、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を扱う際の注意点

音楽や動画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が発生する確率が高かった。(他の要因もあるかも。他も修正しているので)
3周目に突入すると、異様に遅くなり、最後はメモリを食い潰してしまった。

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

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

シェアしていただけるとうれしいです。

シューティングゲーム編 JavaFX対応

こんばんわ!

シューティングゲーム編、JavaFX対応が完了しました!

簡単に一言で言いますが、大変だった( ´▽`*)

当ホームページでも公開しました!
シューティングゲーム編のページから
SKK3_1_FX.zip
を探してください♪

話がちょっとずれるような感じですが、
大変さを、お伝えする必要がある。
わたしは そう感じています。

第4弾。
3Dにしようと思っていましたが、
JavaFXに変更します。

大変というか、JavaFX、そのものをお伝えしていく必要性があるかと思っています。

ここだけの話、JavaFXがなんぼのもんじゃ~!と思ってました。

しかし、しかし、ありですわ。いいところもあり、わるいところもありますが、慣れるしかないですね。
とりあえずは慣れた( ´▽`*)

大変だったところは、また、別の機会に書けたら・・・と思っています(忘れなければ)

とりあえずは、JavaFX対応版SKK、見てみてください!

シェアしていただけるとうれしいです。

いろいろと検証中です( ̄  ̄*

こんばんは!きんです!

いろいろと検証しています。
しかし、なかなかうまくいかない(^^; 正直に言う( ´▽`*)

あまり言葉が先行するようなことは したくないですが、JavaFXの検証をしています。
しかし、うまくいかないですね。
でも、やっと、見えてきました。
今までと同じことができると思ってたけど、そのままでは できなさそう。
ひねくらないと、できなさそうです。

しかし、ひねくった分、重くなるような気もして(JavaFXでは)、いろいろと考えて、やる意味あるかな~と思ったりもします。

JavaFXを使おうが、Java2Dを使おうが、できればいいんじゃないのか?!と思ったりもします。

そして、軽いなら、Java2Dでいいんじゃないの?とか思ったり。
パフォーマンスで比較するなら、良い方を選びたいですよね。

でも、最新ではないんですよね。

いろいろと悩んでいます。
最近のJavaではメモリ量もかなり消費するようになってて(Java6から比べて1.5-2倍くらいは消費してるっぽい)、ちょっとな~・・・って気がしています。

いろいろ悩んでいますが、進んでいきたいと思っています。

みんなが使えるものを、模索していきたいと思います。
言い過ぎだと思っていますが、ロジックとして、考え方として、利用できるものを追いかけていきたいと思います。
やはり、どれだけ応用していけるか。そこだと思っています。

シェアしていただけるとうれしいです。