・描写関連のみ完全に別スレッド化!
本当は、頂点の座標変換&頂点ライト計算と、ピクセル描写部分とでもスレッド化できそうだったけど、
メモリの受け渡しが大変そうなので、諦めました。
※座標変換・光の計算を終わったデータのバッファだけで、1更新当たり2MBぐらいになりそう
あと、まだ世間的にはデュアルコアが主流だと思うしうん。・アクティブレンダリング
「アクティブレンダリング – Javaでゲーム作りますが何か?」をみながら実装。
いや、実装してから分かるけどぜんぜん違う。
やばい。データの描写中によるpaintComponentのちらつきが全然なくなった。
ティアリング?が残っているから、ちらつきが全くなくなったわけじゃないけど。
今までは
本当は、頂点の座標変換&頂点ライト計算と、ピクセル描写部分とでもスレッド化できそうだったけど、
メモリの受け渡しが大変そうなので、諦めました。
※座標変換・光の計算を終わったデータのバッファだけで、1更新当たり2MBぐらいになりそう
あと、まだ世間的にはデュアルコアが主流だと思うしうん。・アクティブレンダリング
「アクティブレンダリング – Javaでゲーム作りますが何か?」をみながら実装。
いや、実装してから分かるけどぜんぜん違う。
やばい。データの描写中によるpaintComponentのちらつきが全然なくなった。
ティアリング?が残っているから、ちらつきが全くなくなったわけじゃないけど。
今までは
synchronized public void paintComponent(Graphics g) { super.paintComponent(g); if(!isShowing()){ return; } g.drawImage(solid.getBufferedImage(),0,0,this); Toolkit.getDefaultToolkit().sync(); }
ってやっておいて、タイマでthis.repaint();しまくってたけど、
アクティブレンダリングはぜんぜん違う。アクティブレンダリングばんざい!
・SoftGround(勝手に呼んでる)の対応
←こういうの
実際の実行した画面。(紫が法線)
テクスチャは、U反転・V反転・右に回転(1回~3回)といろいろ対応。
これで、洞窟とか平地とか、滑らかな地形は作れそう。
次は、HardGround(これも自分で勝手によんでる)というのを対応させたい。
←こういうの
こっちは難しそう。
1つのブロックに3つの面があれば実装できそうだけど、
壁に当たる部分は凹んだり凸ったりすることもあるから、
カリングの問題でサーフェイスを、先に単純に張っておくってことも出来ない?
でもHardGroundは、家の中とか、遺跡の中とかそういう整形された地形には欠かせない。
うん。
ゲームでも使えるように速度・メモリ重視っていうのが難しい。
考えてるだけで時間が過ぎていく。
でもアルゴリズムを考えてるときって楽しいよね。
コメント