進捗 6

投稿日: 更新日:

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

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

広告

コメントをどうぞ(承認された後に公開されます。メールアドレスの記入は自由ですが、記入した場合でも一般公開されることはありません)

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中