□eを●●していたスレ

〜 FFXIを愛するプログラマのチラシの裏 〜

<< August 2017 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>

2009.10.27 Tuesday

スポンサーサイト

一定期間更新がないため広告を表示しています


| - | - | -
2005.02.20 Sunday

稼動

先日作ったマネージャを使って自分に与えられたメモリ管理を実行した。
とりあえず画像ファイル読み込んでイメージデータ(あるならCLUTも)だけをヘッダから参照して取り出してメモリへ格納するという単純なものですはい。
それが終わったら対応して作った描画ルーチンで画面へ描画。

・・・あれ、なんか画像壊れてね?

色々調べてみたところこの開発環境ではイメージ及びCLUTの先頭を64byteにアライメントしなければならない模様。
マネージャから作り直しかyp

どうでもいいですね

プログラマな人たちがこのブログ見てるとはとてもおもえなひのれすが、もしこのWINDめにやってほしいプログラムとか教えて欲しい技術や知識があったらコメントに書くなりメールなりしてくれれば出来るだけお答えします。

期限はキラナイガナーー

2005.02.15 Tuesday

記憶

最近ちょっと手を出していること、それは限られたメモリの管理。
そんな訳でメモリマネージャを試作してたりする。

PCでプログラムするときはwindowsがメモリ管理してくれてたからnewだのmallocだのを呼び出せば勝手にメモリ確保してきてくれたけど、実機だとそんな便利なもの無いから全く困ったもんですたい。

愚痴ってても仕方ないのでとりあえず何も見ずに制作開始。
試行錯誤の末、4時間後アドレスをチェーンする形のマネージャが完成。
なお、ここでは確保したメモリの一連の塊をオブジェクト、オブジェクト同士を連結(リンク)することをチェインといいます。

---------------------------------------------------------------------

typedef struct{
  u_int next;
  u_int size;
  u_short id;
}W_MEM_CHAIN;

---------------------------------------------------------------------

こんな感じの構造体でオブジェクトIDと次の番地、確保したサイズだけを正数で保存して、この連結情報を確保したメモリのヘッダとすることでIDとメモリの内容とをリンクすれば拡張性が高くなるんじゃないかと思った次第で候。
欠点は確保するメモリの容量がsizeof(W_MEM_CHAIN)分だけ増えちゃうってこととかIDで必要な情報を検索する場合のシークが、チェインしてる数が多いほど遅くなるってことかな。

処理的には次につながっているnext番地のオブジェクトは必ずメモリ上では昇順に連なるようになっており、空白メモリができた場合は以下の方法で空白メモリのバイトを計算し、求められているバイトサイズより空白が大きいならオブジェクトをその間に割り込ませてチェインを繋ぎなおすようにしている。

---------------------------------------------------------------------

#define W_START_ADDR (0x8000000) // 自由に使えるメモリ先頭番地

//-----------------------------------------------------------
// func : メモリ確保
//
// input : u_int 確保したいバイトサイズ
// output: u_int 発行ID
//-----------------------------------------------------------
u_int get_mem(u_int size)
{
  W_MEM_CHAIN* work = W_START_ADDR;
  W_MEM_CHAIN* temp, new_work;
  u_int empty_size;

  // オブジェクト間の空白容量を計算
  empty_size = work->next - ((u_int)work + work->size);

  // オブジェクト間に新しいオブジェクトを入れてチェイン再構成
  if (size + sizeof(W_MEM_CHAIN) <= empty_size) {
    temp = work->next;
    new_work = (u_int)work + work->size;
    work->next = new_work;
    work = work->next;
    work->next = temp;
    work->size = size + sizeof(W_MEM_CHAIN);
  }
  return ???; // ID発行は別処理。
}


なお、内容を入れるアドレスは

//-----------------------------------------------------------
// func : 指定IDオブジェクトまでシーク
//
// input : u_int オブジェクトID
// output: u_int 指定オブジェクト先頭アドレス
//-----------------------------------------------------------
u_int seek_addr(u_int id)
{
  W_MEM_CHAIN* work = mem_manager; // マネージャ先頭アドレス。
  while (work->next) {
    if (work->id == id) {
      return (u_int)work;
    }
    work = work->next;
  }

  return 0;
}

//-----------------------------------------------------------
// func : オブジェクトの作業アドレス取得
//
// input : u_int 指定オブジェクトID
// output: u_int 作業開始アドレス
//-----------------------------------------------------------
u_int get_work_addr(u_int id)
{
  //IDから先頭アドレスを求める。
  u_int addr = seek_addr(id);

  if (addr)
    return sizeof(W_MEM_CHAIN) + addr;
  
  return 0;
}

とか、こんな感じで求めるヨロシ。
戻り値が0の場合は失敗ってことで。
(なお、キャストに関してはコンパイラ依存な部分であり、ボキの脳内コンパイラではwarning0なので突っ込むな)

---------------------------------------------------------------------

こんな感じであとは処理をループにして、work->nextのアドレスがNULLなら(あらかじめnextはNULLクリアしてある)ループを抜ければ良い感じ。
もちろん最後まで大きなメモリの空白が無かった場合は一番最後にチェインするのです。

また、IDはチェインの順番ではなく作られた順に昇順に振っていき、開放されたIDはスタックにためておいて新たにオブジェクトが作られた場合にはスタックからIDを吐き出して発行する形にしているのでそこらへんは無駄がないと思われ。

あとは指定されたIDを早くサーチできるようなルーチンさえあればとりあえず動くんじゃね?しらねぇyp
一つ一つのオブジェクトにテクスチャまとめて数枚いれたりモデル数体入れたりすりゃそこそこ扱いやすいんじゃねぇのかね。
そうなるとテクスチャまとめたりするコンバーターとローダーも作らなきゃならんのか、めんど・・・

もうどうせ自分形式でメモリ管理するんだからやりたいようにやればいいです。
動けば勝ち。これプログラムの格言であり心理でげす。

なお、この記事を参考にして組んだプログラムにどんな損害が訪れようとボキは一切責任を取りません取れません。


−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

今回は初めてプログラマらしく行ってみたんだけど自分のレベルの低さにあきれ果てる今日この頃いかがお過ごしでしょうか適当に書くもんじゃねぇなもう疲れたよぱとらs(ry


PS:


リンク構造にしただけじゃねぇkじぇフォアウオアsぢyふぃアじゃだklsじぇfklうぇ

2004.09.27 Monday

プロマシアミッション第二章

プロミヴォン3箇所 クリアしましたが何か?

しかし発表前はあれ程楽しみで仕方なかったプロミヴォンでしたが、回を重ねるごとにどんどん苦痛が増えて仕舞いには矢が尽きて他の狩人に売ってもらう程やる気がなくなってしまいました。

だけどクリアしてルフェーゼってとこ行ったらとても綺麗だったyp

音楽がイイ!景色もイイね!!

ミッションの内容も、ジラートミッションは手付かずなのでわかりませんが今までのミッションとは桁違いに良くなってます。
っていうかこれが本当のファイナルファンタジーだ。
もったいつけるだけつけてくれたけど、

「この先に良いエサがありそうなので先に進もう」

自分的にはこの要素、ユーザーがこう思ってくれるのがRPGだと思います。
先の展開が読めたりストーリー面白くなかったりしたら止めるもんね。

そういえば最近のRPGはグラフィック過多だといわれてますが、僕自身は別にこれは問題ないと思っています。
むしろ問題なのはグラフィックに偏りすぎて他をおろそかにすること。

<クリエイター>             <ユーザー>
グラフィック綺麗でしょ♪  >  ストーリー糞
グラフィック綺麗でしょ♪  >  どこかで見たシステム
グラフィック綺麗でしょ♪  >  え、もう終わり?
グラフィック綺麗でしょ♪  >  ムービーだけですが何か?

<プロデューサー>            <責任者>
葉脈まで書き込んでます♪ >  まあ見えませんけど♪


グラフィックは芸術、ゲームはアミューズメント
コラボレーションは良いけれど芸術に食われちゃ面白いわけ無い罠

映像だけ作りたいならFFACも正解じゃないだろうか?なんて考えてしまう自分を自覚したこの瞬間、やっぱり自分はゲーム業界にとって特別な存在なんだと(ry

〜終〜

2004.08.24 Tuesday

でもんすとれーしょん

プログラミング・デモを作ろう。
ジャンルで言うと、そうメガデモ。

一口にメガデモといっても実は何のことだか分からないのでググッて意味を調べてみます。そしたら意味っぽいのが出てきました。

<メガデモ>
プログラミング・スキルの高さや、サウンドやビジュアル制作のセンスの良さをアピールするために作られたデモ用のプログラムのこと。3Dグラフィックスによるビジュアル・エフェクトを駆使した画像や、軽快なビートのサウンドなどを特徴としている。ゲームではないので、ユーザーが操作して楽しんだり、何らかの有用な結果を出力させたりするものではないが、最近ではグラフィックス性能のベンチマークの目的で作成されているものもある。らしい。

俺の場合はプログラム・スキルとビジュアル制作のセンスを出せればいいかな?とりあえずサウンドはフリーを色々引っ張ってきて選ぼう。

Q さーまずテーマを決めよう。
→昔から作りたかったデモ「四季」はい決定

Q どういうノリにしようかな。
→ピアノ調の静かな調べに乗せた緩やかでどこか寂しい感じ。はいけってー

Q どのくらいの長さがいいだろうか。
→2〜3分くらいでいいんじゃない?ケテーイ

さー大体決まった。
まずは音楽と画像の素材集め&制作だーーーーー
これが一番めんどくさいよ、たすけてママンびっくり

▲top