2011年04月

生成のコストってなんだろう

C#におけるオブジェクト生成のコストってなんだろう。
軽いクラスを生成するだけなら、ヒープに領域取る重さ(速度)だよな。
(とりあえず容量については今のところ考えないでおこう。
必要な分は確保して、足りなくなったらGCで回収されるだろうから)

1000万回使うなら、
1000万回×領域確保・・・①


生成する度に色々計算したりメモリを確保したりするクラスなら、
その計算コストや領域確保のコストってことだよね。

1000万回使うなら、
1000万回×(計算+領域確保)・・・②


で、この計算コストが嫌なので、コピーしてコストを下げようってのがprototypeパターンかな。
とはいえコピーなので生成はしてる。

1000万回使うなら、
1000万回×(内容コピー+領域確保)・・・③



クラスの内容が固定して変更されない場合は、
領域確保や計算コストが嫌なので、使いまわすって手段が使える。
1つのクラス1つのインスタンスしか使わないsingletonパターンや、
1つのインスタンスを使いまわすflyweightパターンなどかな。

本来の目的は、singletonは1クラス1インスタンスの保証だったり、
flyweightがメモリの節約だったりするのだろうけど、C#では生成コストも下げられそう。

1000万回使うとしても、
最初の生成+1000万回×参照のコピー・・・④


①、②、③はどれも生成してるので、領域確保のコストがある。
③は②に比べて計算コストがないので、計算部分だけ変わらない場合は計算コストが下げられる。

④は生成は最初だけなので、生成コストは非常に低く、メモリも使わないので、
内容がまったく変化しない場合は、使える。

といった感じか。

で、C#では生成にかかわるコストは、生成だけではなくGCによるコストもある。
大量に生成を行うと、大量に破棄をしなければならないので、そのコストは尋常じゃない、と。

①、②、③は、1000万回使うとなると、
1000万回×領域の破棄

④は1000万回使っても、
1回×領域の破棄

って感じなのだろうか。
まあ普通のことなんだけど、
ゲームでは、①、②、③のコストをうまくコントロールしないと、
ゲーム中で重くなるとかありそうで、色々考えないといけない。気がする。



Singleton的にやってみた

前回の記事(XNAテトリスで悩んでること)の解決策をSingleton的にやってみた。
いや、~~的であってパターンそのものじゃないと思うので、ご容赦願いたい。

Minoクラス
・IMinoInfoインターフェースを継承したクラスをセットする変
・ミノの位置
・ミノの回転方向
・ミノの回転・移動・落下などの処理
IMinoInfo.MinoBlocksプロパティを参照して処理を行う


IMinoInfoインターフェース
・IDプロパティ
ミノの種類ごとの番号
・MinoBlocksプロパティ
ミノを構成するブロック情報が入っているリスト

↓(継承)

Mino0クラス~Mino6クラス
・IDプロパティ
Mino0なら return 0; のように返す
・_minoBlocks
ミノを構成するブロック情報が入っているはず
・MinoBlocksプロパティ
_miniBlockの参照を返す

Mino0クラス~Mino6クラスはSingletonっぽいのを使って、それぞれのクラスが1つのインスタンスしか生成されないようにしている。

このようにMinoは、ミノの位置、方向、それぞれの処理を担当して、テトリミノ自体はIMinoInfoインターフェースを継承したインスタンスが1つしか生成できないクラスで表現している。
Minoクラス生成時にIMinoInfoをセットすることで、色々なミノに対する処理ができる。

ガイドミノ表示の際は、新しいMinoクラスを生成して、
落ちているMinoクラスのIMinoInfoをセットして、処理させればいけそうな。

コードにするとこんな感じ。

続きを読む »

XNAテトリスで悩んでること

今、XNA(マイクロソフト製のゲームフレームワーク)でテトリスを作っている。
で、テトリミノの表現と関連処理の実装のために次のようなクラスを作っている。

Minoクラス
・IDプロパティ(抽象)
・ミノを構成するブロック情報
・「ミノを構成するブロック情報」を生成するメソッド(抽象)
・位置情報
・方向番号
・落下とか回転とか移動の処理
・コンストラクタ
↑の「ミノを構成するブロック情報」を生成するメソッドを呼んで、
それをミノを構成するブロック情報に代入する

↓(継承)

Mino0クラス~Mino6クラス(棒ミノや四角ミノの種類ごとに1つ)

・IDプロパティの実装
棒ミノを表すmino0クラスなら、return 0;を返す 等

・「ミノを構成するブロック情報」を生成するメソッドの実装
棒ミノを表すmino0クラスなら、
方向0・・・ (-1,0 0,0 1,0 2,0)
方向1・・・ (0,-1 0,0 0,1 0,2)
方向2・・・ (-2,0 -1,0 0,0 1,0)
方向3・・・ (0,-2 0,-1 0,0 0,1)
といったようなデータを返す


といったような感じです。(自分だけ分かればいいやー(テキトー
落下ミノとしてmino0~mino6をランダムに生成して、それを落下させています。

で、ここでミノが落下する地点を半透明で表示する「落下ガイド」を実装したくなったので、
すでにあるこのminoクラスの落下処理を利用したいと思いました。

落下しているminoクラスをコピーして落下ガイド用minoクラスを作ればいいのかな?
と思ったんだけど、それでいいのか?と悩んでるところ。

なぜか。
「ミノを構成するブロック情報」を回転や移動させるたびにコピーする必要がある。
参照だけコピーしとけば軽いと思うけど、それならそもそも落下するミノを生成する時点での
「ミノを構成するブロック情報」生成処理もどっかから参照してくればいいんじゃね?
とか設計ダメジャンと考えてるなう。

(そもそもコンストラクタでブロック情報生成のメソッド呼んでるから、
 今のままじゃコピーといっても毎回生成しちゃうんじゃ・・)

そんな今日この頃。
分かりやすく書いてなくてすいません。頭の中がそのまま吐き出されてます。

とりあえず悩んでることだけでもまとめといたほうがいいと思って。
たぶん、これからの記事もそうなっていくかと・・。

色々まとめるためのブログを作ってみた

最近、ツイッターが生活の一部となって、飽きずに続けられています。
で、色々情報もまとめたいなというときが出てくるのですが、ツイッターでまとめようとすると情報が多すぎて、ツイート荒らし状態!になってしまいそうです。ということで、ブログを解説してみました。
ツイッターも連動してみたので、テストも兼ねて投稿してみます。
うまくいくかな?

2件目テスト

2件目テスト
記事検索
livedoor プロフィール
QRコード
QRコード

トップに戻る