Javaで3Dゲーム開発日記 part6 マルチスレッド対応とマップメーカー

ゲーム制作
スポンサーリンク
・描写関連のみ完全に別スレッド化!
本当は、頂点の座標変換&頂点ライト計算と、ピクセル描写部分とでもスレッド化できそうだったけど、
メモリの受け渡しが大変そうなので、諦めました。
※座標変換・光の計算を終わったデータのバッファだけで、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は、家の中とか、遺跡の中とかそういう整形された地形には欠かせない。
うん。

ゲームでも使えるように速度・メモリ重視っていうのが難しい。
考えてるだけで時間が過ぎていく。
でもアルゴリズムを考えてるときって楽しいよね。

コメント

タイトルとURLをコピーしました