スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

[ --/--/-- --:-- ] スポンサー広告 | トラックバック(-) | コメント(-)

ライブラリの方針が見えた( ゚д゚) 

漠然と新しいライブラリを作りつつ、特徴付けに悩んでいました。
まぁ、公開する気はないので、結構気楽なんですがw

で、Lunaとかの多機能ライブラリを参考に、
必要な機能はゴリゴリ入れていくわけですが、
同じような物を作るならLunaを使えばいいわけで。
必要な機能が入りつつ、どんな特徴を付加していくのか、と。

決めた方針は、ユーザーフレンドリー
ライブラリ作るなら当たり前じゃね?とか思うかもしれないけど。
Lunaは多機能で、色々な事が出来る代わりに、使いにくかったりする部分もあります。

▼ こんなところに気をつけて行こうと思う。
・フレームワークは基本的に隠蔽して、機能ごとに、SystemSetup,Init,Main,Termを使ってもらう。
・オブジェクト周りはマネージャを経由しないで生成可、内部でのリスト管理のみで。
 - マネージャが入ると把握する必要のあるクラスが2倍近くなるので。。。
・描画は基本的にクラスのメンバ関数で完結、単純描画だけはグローバルに。
・2Dはマトリクスじゃなく、直に座標指定でも描画出来るように(DX8のSpriteみたいな感じ)
・豊富なデバッグ用機能。
 - グラフィカルに色々見れたり、値をいじれたりさせたい。
  無駄でもいいから、使いたくなるぐらい格好良く、エンボスつけたりとかw


つまり、直感的だといいな、と。
2D描画したい→CpPrimitive2D(or 単純描画関数)使えばおk
テクスチャ貼って2D描画→CpTextureとCpSprite2D使えばおk(さすがにテクスチャは分けたい)
モデル描画したい→CpModel(+CpTexture)使えばおk

で、まあ公開しない強みとして、
機能欲しくなったら後でつけるわw
そんな感じで~
[ 2008/06/15 00:28 ] ライブラリ開発 | TB(0) | CM(0)

Zodiacライブラリ途中経過 Ver.0.20bぐらい? 

時間が無いながらもコツコツ進めております。
目標としては割とシンプル(広く対応する必要がないので)に作る。
そして、細かい便利機能を追加して、
エフェクトとかのパラメータをいじっては実行を繰り返すのをやめる。
あの辺の調整は地味に時間とられるので、その辺サクっとやりたい。

で、現在のライブラリ進行度合い

▼Aries(メインシステム)
・ウィンドウが出ますよー
・HTMLログが吐き出せる
・ヒープ管理システムですよ
・数学関連関数群
・3,4次元ベクトルクラス
・行列クラス(DirectXのが早かったからラッパーに)
・ファイルを扱うクラス
・文字列処理(検索・挿入・削除あたり、日本語対応)

▼Capricornus(描画システム)
・デバイス周りの基本システム
・ウィンドウモード切り替え対応
・色の管理クラス(キーフレームアニメーション対応)
・描画基底オブジェクト作成

さて、じわじわ進んでますが、するどい人はちょっと見ると分かると思います。

描画できない事が('A


あ、画面のクリア色をアニメーションさせて楽しむ事はできますよ

うん、次はプリミティブクラスだなぁ。
基本的には四角と三角ぐらいでいいんだけど、色んな形状出して遊びたいなー。
何より、円とかの基本形状が関数一発で出るのは、開発初期で便利。
とりあえず弾飛ばしてみるのとか、四角より丸のがちょっとそれっぽいし。

そんなわけで、色々やってみることにします。


あ、仕事もちゃんとしてますよ
[ 2008/06/10 22:22 ] ライブラリ開発 | TB(0) | CM(0)

DirectX描画考察 

ちょっと前からDirectXの描画システムをコツコツ作っています。
さて、簡単に流れを追ってみる、詳細はぐぐってくれ

1.D3Dオブジェクトの作成。
2.d3dppを投げてデバイスの作成。

3.バックバッファのクリア
4.pDevice->BeginScene();
5.DrawPrimitiveとかで描画
6.pDevice->EndScene();
7.pDevice->Present();

ここで分かりにくいのは4,6,7。
5で描画指示してるのに、何をやっているんだ?と。

7.はダブルバッファリングなんで、フリップでもしてるんでしょう。
4と6は調べてみる事にしましょうか。
BeginScene: シーンを開始する。
分かるわ( ゚д゚)

内部で何やってるかが知りたいわけで、この辺の情報少ないなぁ。
Beginでエントリー開始して、5.で描画エントリ、Endで描画開始だろうか。
そうするとPresentは描画終了まで待つはずなので、Endの後はCPU処理した方がよさげ?
SetRenderTargetとかで切り替えても平気なんだよなー、順番と対象は完全に保持されてるのかな。

そんなわけで、効率を考えるなら、
バッファのクリア→Begin→描画→End→更新処理など→Presentがいい気がします。
実際計測したわけじゃないのでなんとも言えないですが。
シェーダーのように描画結果を必要とするものはBegin~End何度も呼ばないといけないかもしれんね。
[ 2008/05/22 00:50 ] ライブラリ開発 | TB(0) | CM(2)

文字出力の罠 

今日は自作ヒープ管理クラスのメモリダンプ作ってたわけですが、
以前のを移植しただけなのに、なぜか上手く出力されない。

というより、ログ出力のうち、一つの文がどうしても出力されない。

つまり、

ArLog::Out("%c\n", ((char*)pMemory)[i]);
みたいに書いても、改行すらされないわけで。

で、関数の中追ってみたら、出力文字列が何もない。
小一時間悩んだ結果。

%cに0x00が突っ込まれたら出ないんじゃね!?

0x00が終端として認識されるので、 0x00 \n 0x00となっていて、\nは出ない。
という結論でした。

0x00を0x20(SP)に置き換えたら問題無く出力できました。
バイナリを文字出力する時には気をつけようというお話。
[ 2008/05/02 23:41 ] ライブラリ開発 | TB(0) | CM(0)

メモリ管理システムを考えてみる 

何でメモリの管理なんかやるのかというと、
まず、通常のメモリ確保が遅い
ある程度プログラムやってる人なら分かると思います。
最近は性能向上でマシになってきたけど、大量にやると著しく落ちます。

第二の目的として、メモリリークの可能性を無くす
C言語は基本的に自分で解放しなきゃいけないです。
そこで、解放忘れがあったら、警告を吐いた後に解放してくれるようなのを作る。

で、まあやる事としては、
1.使うメモリを一括で確保
2.各ブロックにヘッダー情報をつける(サイズとか)
3.リクエストがあったら切り分ける

大したことはやってないですね。
強いていうなら、断片化が問題になってきそう。
でも、メモリコンパクションとか重そうだからどうするかなーとか。
個人レベルだったら、そもそもそんなに使わないんでいらないかな('A
ただ、空き領域の連続はもったいないので繋げます。

そんな感じで今度実装しよう、時間ができたら_no |||
[ 2008/04/08 23:57 ] ライブラリ開発 | TB(0) | CM(0)
プロフィール

poro

  • Author:poro
  • プログラマやってる人です。
    絵とかも好きだったり、
    何か作りたいとか最近考えているらしい。
ブロとも申請フォーム


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。