これからは家族でゲーム製作

**名前は開発中のものです。** · 2005/12/27(火) 22:12:40

家族ぐるみでゲーム作りしてるやついる？

**じいちゃん（´-`）** · 2006/01/16(月) 17:33:09

最近VC++6.0ﾀﾝの調子が悪いのじゃ。ちょっと前までは素直だったのに。
・・・ツンデレ病？ (*´Д｀)ﾊｧﾊｧ

>>ポチ
締め切りってのは、ぶっちゃけ自分自身への縛りだったのですが、
先走りしすぎたようですね。とりあえず６割ぐらい完成した段階で、
各自の状況に合わせて現実的な数字をだしましょか。

混乱させるようなことを書いてしまって、ごめ。 m(__)m

>>142
なんじゃこりゃああぁぁｗｗｗふがふが。
ドキュメント生成ツール？凄い。どこの天才が作ったんだ。
外人は凄いね。やっぱ肉食ってるヤツらは違うぜぃ。

こうして見るとﾍｯﾀﾞにｿｰｽ直書きはやぱ見にくいなぁ。

これはコメントとか付けるときのオススメﾌｫｰﾏｯﾄとかあるんですかね？
こう書くと、Doxygen様にはこう反映される、みたいな。
日本語説明ｻｲﾄ様とかチラっと見たけど、じいちゃんには何言ってるかさっぱりｗ
小父さんＧＪ！

ところで「Doxygen」は「どくしぃげん」て呼んでいいのかにゃ？ (：D)|￣|＿

**隣の小父** · 2006/01/16(月) 17:41:26

>143
じーちゃん、Doxygenのコメントの書き方はこの辺りを読んでくんろ
ttp://members.at.infoseek.co.jp/sakura_editor/comment-rule.html
ttp://freepg.fc2web.com/tool/topic_doxygen_002.html
ttp://yudoufu.velvet.jp/doxygen.html
プログラムの合作する時には便利だべさ＞Doxygen

**じいちゃん（´-`）** · 2006/01/16(月) 17:44:29

おお、読んでみまっす。どもありがとー。

**隣の小父** · 2006/01/16(月) 18:12:11

とりあえず、開発途中のライブラリをDoxygenに掛けたもの
http://www.geocities.jp/bigbrotherxlittlesister/doxygen_0_0_3/html/
一応、真面目に作ってるところを見せておかんとまずいと思うてな
でも正直なところ、このライブラリは使い物になりませんわ
DXﾗｲﾌﾞﾗﾘで作った方が幸せになれると思ふ

**名前は開発中のものです。** · 2006/01/16(月) 21:07:28

http://gamdev.gozaru.jp/w/00793_00000.html#content_1_4

**名前は開発中のものです。** · 2006/01/16(月) 21:09:33

ライブラリならDXよりはSDLがよさげ。

http://gamdev.gozaru.jp/w/00793_00000.html
http://www.tacoworks.jp/software/SDLdoc-jp/html/

**じいちゃん（´-`）** · 2006/01/16(月) 22:23:21

ひさびさに公式ページ？見たら、ちょっと更新されてるー。
書いた人、（・∀・）ｴﾗｲ!!

>>146
なんか凄そうですけど、DirectXわかんなにゃいから
なにがなんだか orz
でも乙。
コメントはそんな風に出るんですね。

>>147-148
紹介どもですじゃ。
速度が必要なｹﾞｰﾑではなさげなのでDXﾗｲﾌﾞﾗﾘに不満は全く無いのですが、
今ならライブラリの差し替えも比較的簡単に可能ですね。
私はLunaってのも気になってるよん。

**隣の小父** · 2006/01/17(火) 06:30:22

＞ﾗｲﾌﾞﾗﾘ
2Dに限定するけんども
1. DXﾗｲﾌﾞﾗﾘ
2. SDL
3. Luna
この三択ぢゃね
個人的にはDXﾗｲﾌﾞﾗﾘを押すけんども…

しかし、3Dをやってみたい欲求がｳｽﾞｳｽﾞ
ゲームの形まで仕上げるのには期間かかりそうぢゃがの

**隣の小父** · 2006/01/17(火) 08:01:18

SDL悪くは無いんだけんども、
日本語の敷居がDXに比べると若干高いのぢゃ
文字を殆ど使わないゲームならSDLという選択肢も
生きてくるのぢゃがな…

**隣の小父** · 2006/01/17(火) 08:33:00

2Dテクスチャを表示するサンプルコードなんだけど、
使いやすそう？それとも使いにくい？

void Render() {
　D3DDev.BeginScene();
　D3DDev.BeginSprite();
　g_TextureManager.Draw( "chip.bmp", x,y, 0,0,64,64 );
　D3DDev.EndSprite();
　D3DDev.EndScene();
}

**隣の小父** · 2006/01/17(火) 11:05:42

読み込むテクスチャの大きさを明示的に指定しなくても
済むような機構を作った。
実態は読み込むBMPファイルの大きさチェックやね。
PNGとかに対応は、まだ無理ｗ

ファイル名と座標と表示チップの位置を指定すれば、
後はライブラリがやってくれるのだが…
ミニゲームには大仰な機構かもしれないｗ

**じいちゃん（´-`）** · 2006/01/17(火) 12:42:26

小父さんゴリゴリ打ってるっぽいですね。
じいちゃんはちょっとWin32APIに飲まれて、燃え尽き症候群気味。

>>152のはよくわかりませんが、
自動で絵を読み込んでくれる機能が付いてるっぽくて使いやすそうな感じ。

SDLは日本語弱いのか（´・ω・`）

**隣の小父** · 2006/01/17(火) 13:35:07

>SDL
弱いんじゃなくて、ちょっとめいんどい
コード変換とかしないといけないかもしれないから
抵抗無い人にとってはSDL最強かもしんない

void Render() {
　D3DDev.BeginScene();
　D3DDev.BeginSprite();
　Fami::Texture.Draw( "chip.bmp", x,y, 0,0,64,64 );
　D3DDev.EndSprite();
　D3DDev.EndScene();
}

今はこんな感じのインターフェース
Lunaを模倣してみますた

**隣の小父** · 2006/01/17(火) 16:45:02

Easy3Dっていうライブラリを見つけた
3Dがぐりぐり動かせそうな予感…
http://www5d.biglobe.ne.jp/~ochikko/

**隣の小父** · 2006/01/17(火) 18:53:03

最新版のDirectX SDK には8.1のヘッダが一部入ってないのねorz
Includeフォルダ覗くと10っていう名前も見当たるし
そのうち8.1はサポートから外されるんだろうなぁ

**従兄弟@今日は自宅** · 2006/01/18(水) 00:04:43

じいちゃん、新しい開発環境が無償で配布されているよ。
開発環境を家族で統一しておけば、
容量が少なければプロジェクトファイルごと共有できて楽だよ。

Visual Studio 2005 Express Edition (もちろんVC++もあり)
ttp://www.microsoft.com/japan/msdn/vstudio/express/default.aspx

それからスクリプトの件、了解です。

処理の一部をスクリプトに追い出す場合、
まずはスクリプト化する処理を一つの関数 (メソッド) に
押し込めるのが始まりです。

お決まりのAPIだけを使ってその関数だけを書き換えれば、
変えたい部分を変えられるようにしておいて、
後はそのAPIを扱う最低限の機能だけを解釈できるようにする、
という手順を踏めば、かける手間も最小限で済みますよ。

**従兄弟@今日は自宅** · 2006/01/18(水) 00:18:42

>>154
一応、SDLの日本語表示について参考になりそうなページを。

ttp://tokyo.cool.ne.jp/sdl/index9.html

従兄弟はクロスプラットフォームのSDLを使いたいのが本音だけど、
ここまでDXライブラリで開発してきたなら、その延長でいいのでは。
じいちゃんのソースコードを読んだ限りでは
他のライブラリにも、その気になれば移植できそうだし。
(描画は「Draw」関数にまとめてあるし、Input関数は少ないし)

>>157
M$のライブラリはライフサイクルが短いですな。

ポチ · 2006/01/18(水) 00:28:53

クロスプラットフォームいいねぇ。
Unix系で自分の関係するゲームが動くとかうれしいよね。
意外なユーザーも増えそうだしｗ

従兄弟たんがｺｯｿﾘ再構築してくれてもいいワンｗ

**名前は開発中のものです。** · 2006/01/18(水) 05:09:07

どうも寝付けないのと、本業の進みが予定より少し早いのとで、
じいちゃんのソースを弄ってみたよ (w

http://gamdev.org/up/img/4405.zip

変更点は、WinMain()で

・InitDXLibrary()の返り値をbool型に
・LoadBitmap()に失敗したらその場で終了するように変更

したのと、

・CF_Systemクラスが「何でも屋」になりそうだったので、
　PlayerArrowクラスとLookAroundFrameクラスを分離
　(それぞれ矢印とフィールドを見回すときの枠のみ)

といったところ。
書き換えている最中に、変数名をいくつか変えたけど、
大丈夫かな?
(どれも、略していたのをやめただけ)

**従兄弟@今日は自宅** · 2006/01/18(水) 05:16:02

分類としては、こんなところでしょうか。
迷惑でなければ、分けたほうがよさそうなクラスを分けたり、
変数のスコープを限定したりと、
保守性を上げてやりたいと思います。

・フィールド関連 (移動時)
　CF_System (アクティブフラグの管理に限定)
　Field

・フィールドに描かれるオブジェクト (Drawメソッド付き)
　CMapControl (マップ全体)
　CPlayer (キャラクター)
　LookAroundFrame (見回す時に出る枠)
　PlayerArrow (キャラクター前の矢印)

・データ共有用?
　Extern
　Global
　Macro

・戦闘関連
　Battle

・まだよく読んでない
　CF_Input
　Struct
　WinMain

**従兄弟@今日は自宅** · 2006/01/18(水) 05:20:03

最後に、
変数名や関数名の書き方を合わせておくと後で楽だと思うのだけど、
どうでしょ?
とりあえず思いつくまま書くので、「それはやめて欲しい」とか
「他にもこうしたほうがいい」という意見があったら気軽に書いてね♪
(家族なので、遠慮せずにお互い作業しやすいようにしましょ)

1. なるべく略さない (Mou→Mouse, Pos→Position, Pal→Param)
2. ハンガリアンをやめたい (m_hGrap→Graphic or graphic)
3. 関数名は動詞+対象となる名詞で (ArrowDraw→DrawArrow)
4. 変数名は先頭が小文字 (m_nActiveFlag→activeFlag)

簡単に言うと、C#のソースコードのようなイメージです。
2に関しては、先に変数のスコープを限定したり
変数名の付け方をパターン化 (*Graphicならint型のハンドル、とか)
してからでないと、混乱するかな。
(私自身がハンガリアンが分からないので、なんとも言えませんが)

**隣の小父** · 2006/01/18(水) 05:30:42

>>158
Visual Studio 2005 Express Edition
isoしか無いみたいね
おじさんは、以前knoppix焼こうとして
PC付属の焼きソフトで起動ＣＤが作れない
問題にぶちあたったｗ
フリーな焼きソフトとかあるんかな？

**従兄弟@今日は自宅** · 2006/01/18(水) 05:33:29

>>160
いつの間にかSDLベースになっていて困惑するかも (w
実はVisualStudio 2005を使ってみたら直すのが楽で、
逆にSDLを使ってWindowsでUNIX (私のはFreeBSD) 用の
ゲームを作ればいいのでは、と思いました。

**隣の小父** · 2006/01/18(水) 05:37:48

>>163
1. IDEなしで手打ちしてるんで、長い変数名は苦手

2. m_hogehoge
はMSの作法なんで、それに従ってるけど
やっぱり、一見でスコープが分からなくなるのが
問題ですねぇ

3.4. に関してはUNIXの作法ですかね？

**従兄弟@今日は自宅** · 2006/01/18(水) 05:38:25

>>164
DaemonToolを使うと、各種ディスクイメージ (もちろんISOも) を
そのままマウントできて、便利ですよ♪

ttp://www.geocities.co.jp/SiliconValley-Sunnyvale/3115/DaemonToolins.html

一度焼いてから使いたい場合には、こちらがISOイメージに対応しているようです。

ttp://www.deepburner.com/
ttp://sekirei.air-nifty.com/blogtopia/2004/08/deep.html

**隣の小父** · 2006/01/18(水) 08:01:07

家族計画・歴史
>4 ポチ登場
>8 夫登場
>11 妻登場
>16 じーちゃん登場。父権発動でエロになると思いきや？
>18 息子登場
>23 息子の発言で、作るゲームジャンルは漠然とカードゲームという流れになる
>25 妹登場
>32-33 ポチに名前が付く
>36 従兄弟登場。家族計画の中で一番の熟練者
>38 ポチが餌（企画）を咥えて来る
>44 ポチがWikiに公式ページを作る
>50-51 画面の仕様が決まる
>53 じーちゃんがうｐ
>57 画面レイアウトうｐ
>65 じーちゃんがうｐ
>68 ポチが戦闘画面レイアウトうｐ
>69 謎な人が何かうｐ
>75 ポチがマップチップうｐ
>84 ﾏｯﾌﾟﾁｯﾌﾟ構造体
>86 ｲﾍﾞﾝﾄのｽｸﾘﾌﾟﾄ
>90 じーちゃんが合体想定プログラムのプロトタイプうｐ
>94 じーちゃんがうｐ
>99 隣の小父登場
>106 金魚登場
>128 Lua
>129 Ayame
>130 じーちゃんがﾏｯﾌﾟｴﾃﾞｨﾀうｐ
>131 Lamp
>142-146 Doxygenでドキュメント管理
>148 SDL
>156 Easy3D

**隣の小父@年金生活** · 2006/01/18(水) 09:49:42

>>167
www.daemon-tools.net
に繋がらない（´・ω・`）

**隣の小父@年金生活** · 2006/01/18(水) 12:13:13

>>158
Visual Studio 2005 Express Edition インストール完了（｀・ω・´）
本格的なIDEって、こんなに使いやすかったんだｗ
今までコマンドラインでシコシコやってたよ（´・ω・`）

**じいちゃん（´-`）** · 2006/01/18(水) 16:26:21

ｷﾀ━(ﾟ∀ﾟ)━!!!

>>161
朝早くから乙です。
変更してもらったとこ見ました！

CF_Systemはとりあえずなんでも入れちゃおうと思ってたんですが、
そうやって小さいｸﾗｽに分けちゃってもいいんですね。

長い変数名は、わりと好きなのでＯＫです。
略は極力やめるようにしまっす。

>>162
そんな感じの分類でＯＫです。
Extern
Global
Macro
Struct
は共有用のつもりです。さらに、

Prototype.h // 広域で使いそうな関数のﾌﾟﾛﾄﾀｲﾌﾟ書く
Func_01.cpp // 広域で使いそうな関数の実装書く

この二つを入れようかと思ってるのですが、いかがでしょか。
実はもっといい方法あります？

あと、CPlayerはこれから書き直すと思うので、
今はそっとしといてください ^^

**じいちゃん（´-`）** · 2006/01/18(水) 16:27:38

>>163
変数名やら関数名は、できるだけ合わせた方がよさげですよね。
んー、共同開発っぽくなってｷﾀｰ。

＞1. なるべく略さない
これはＯＫです。なるべく ^^ ね。

＞2. ハンガリアンをやめたい
ﾊﾝｶﾞﾘｱﾝは見よう見まねで使ってただけなので、未練は全く無いです。
でも、ｸﾗｽのﾒﾝﾊﾞ変数の頭につける m_ だけは残しといてほすぃかな。
m_nActiveFlag→m_activeFlag
m_hGrap→m_graphic
みたいな。どでしょ？

＞3. 関数名は動詞+対象となる名詞で
これはぜひやりたいのですが、じいちゃん英語わからんチンなので、
やりたくてもできないかも～ (T_T)

＞4. 変数名は先頭が小文字
これはＯＫです。

Visual Studio 2005 Express Edition
はちょっと気になってたので、この機会に試しに乗り換えてみたいと思います。
VC++6.0ﾀﾝは前世紀ぐらいに買ったやつですから、
そろそろ休ませてあげよかな。どもですじゃ。m(__)m

**じいちゃん（´-`）** · 2006/01/18(水) 16:29:29

>>168
激しく乙ｗ
まだ160ですけど、思ったより色々ありますね。
そろそろおにゃの子ｷｬﾗが欲しいよ欲しいよ。
あと、エロゲはあきらめてないぞ。
ｶｰﾄﾞの絵が超エロエロになる予定なんじゃ！

Visual Studio 2005 は週末あたりに挑戦してみます。
VC++6.0ﾀﾝと一緒に起動して、最適化競争とかさせてみたいｗ

**隣の小父@年金生活** · 2006/01/18(水) 17:17:18

＞ハンガリアンをやめたい
考えてみればDoxygenでドキュメント管理するので
m_やらg_やら小細工しなくても分かるのかもしれない

M$の作法が染み付く前はコーディングにUNIX風作法を取っていたので
サッパリと決別するのもいいのかもしれない

**じいちゃん（´-`）** · 2006/01/18(水) 17:48:41

m_ は見たときに一発でﾒﾝﾊﾞ変数とわかるのと、
ﾒﾝﾊﾞ関数内で同じ変数名を使いたくなった場合
class A {
　m_number;
　int SetNumber (int number)
　{
　　m_number = number;
　}
}
こんな場合に役に立つと思ったのですが、どでしょか？
私、こういうことがわりと頻繁にあるんですけど #-_-

g_ はできるだけ色んな所で使わない方向でいけば、
付けなくても、なんとかなるかなぁ。とかｵﾓﾀ。

ﾊﾝｶﾞﾘｱﾝぽい記述は、なんとなくカッコイイｗのと、
ｽｰﾊﾟｰﾌﾟﾛｸﾞﾗﾏのやねうらお様の本に「絶対使え」的な事が書かれてたので、
中途半端に使うことにしました。
やめることに関しては、未練は無いですが～

**隣の小父@年金生活** · 2006/01/18(水) 19:26:01

そうそう、よくあるね
そういった使い方は良くするよ
引数をメンバ変数に入れる時なんかね

void SetSize( int Width, int Height ) {
　m_nWidth = Width;
　m_nHeight = Height;
}

突き詰めると、UNIX作法とM$作法の確執かねぇ（＾＾；

ポチ · 2006/01/18(水) 21:05:54

処理系による方言のようなものだと思っていたワン。
それぞれの処理系にくっついてくるサンプルソースとか
その中で使われている作法をそのまま引き継いでるんじゃないかな？
たぶんwindowsでもGCCで作業してた人は違和感が無いのかも

と、MSCとBCCの違いに戸惑った私が言ってみるｗ

**じいちゃん（´-`）** · 2006/01/18(水) 21:14:17

あんま変わってないのですが。。
Prototype.h と Func_01.cpp を追加して、
ｳｨﾝﾄﾞｳの板を出す関数を入れてみました。

ttp://gamdev.org/up/img/4412.png
ttp://gamdev.org/up/img/4413.zip

WinMain()の中の、FameRateControl()関数の中をちょっとだけ変えました。
Struct.h に hGrapWindowBoard_01 を追加しました。
CMapControl の実装とﾍｯﾀﾞを別ﾌｧｲﾙにしてみました。
変更はこれだけっだったかな。

変数名はまだそのままなのですが、週末までにどうするか決めといて、
それから一気に変更しまっす。
あとコメントはまだ勉強不足でどう書けばいいのかわからないのですが、
これも週末になんとかしたいなと。

土日は大変そうだわぁ (;^_^)

**隣の小父@年金生活** · 2006/01/19(木) 08:17:05

Doxygenにコメントが反映されるようにしてみた
やっつけだから、完璧じゃないけど
コメントのつけ方の参考にしてみてちょーだい
ttp://gamdev.org/up/img/4417.zip

**隣の小父@年金生活** · 2006/01/19(木) 09:13:36

>>178
じーちゃん乙！

話は外れるけんども、このページ↓を作ったのは、わしなんじゃが
http://gamdev.org/w/?%5B%5B%A5%DE%A5%C3%A5%D7%A5%A8%A5%C7%A5%A3%A5%BF%5D%5D
じーちゃん、マップエディターのソースＰＬＺ！
弄ってみたいのぢゃ

**隣の小父@年金生活** · 2006/01/19(木) 12:43:34

＞命名規則
変数名の変更についてですが、
大幅に変えるとバグの元になるだけなので
MS作法で行くのが吉だと個人的には思とります

**名前は開発中のものです。** · 2006/01/19(木) 15:40:01

>>178
じーちゃん、乙です。
いつもながら、いい仕事しますね (^^

>>168
従兄弟はゲームを作りに参加するのが初めてなので、
少なくとも熟練者ではないですよ (^^;
むしろ家族のみんなのソースを読みながら、
勉強させていただいています。

>>163
変数名について聞いたのは
主に自分の書き方を家族に合わせたかったからなので、
私もなるべくハンガリアン記法を使うようにしますね。
(間違えてたらコッソリ直しておいてくださいな)

それと、今ある変数名を例に使ってしまったので、
これではじーちゃんが書いた部分を書き換えたい、
と言っているように見えてしまいますな。
少なくとも既に書いた部分については、>>181に賛成です。
(紛らわしくてごめんね。>>家族のみんな)

**名前は開発中のものです。** · 2006/01/19(木) 15:43:32

>>166
あらためて考えてみると、従兄弟の書き方はJavaそのものなのかも。
フラグには「bool finished;」のような変数を使い、
「bool isFinished() {return finished;}」のように
メソッド名の「is (boolの場合) 」や「get (それ以外) 」のような
規則で役割を決める、という感じかな。

考えてみると、ハンガリアン記法を使わなくても混乱しないのは
他の部分で制約を設けているからかもしれない。
(グローバル変数を使わない、ポインタは特定のデータ型のみ、とか)

C++で共同作業をしたことはほとんど無いので、
勉強になりますた。

**名前は開発中のものです。** · 2006/01/19(木) 15:51:25

ついでなので書いておくと、変数名を後から変えたくなったり
クラスをスーパークラスとサブクラスに分離したくなったりと、
機能を変えずに構造を変えたくなった場合には、
「リファクタリングツール」というのを使うと便利ですよ。

ttp://www.slickedit.com/content/view/125/83/
ttp://www.refpp.com/download.htm

従兄弟は下のを使っていますが、例えば変数名を変えたい場合には
変えたい変数名を選択して「右クリック→新しい名前の入力」で
全ての変数が安全に変更されるので、便利ですよ。
(同じ名前で別のスコープの場合やコメント内、他の変数の一部の場合には変更されない)

以上、チラシの裏ですた。

**じいちゃん（´-`）** · 2006/01/19(木) 19:34:57

>>179
ご丁寧にどもありがとです m(__)m
/// と //! の違いがいまだによくわからないのですが、
とりあえず説明に /// を使っとけば、ある程度反映されるんですかね。
もうちょっとよく見てみまっす。ども。

>>180
日曜日からほとんど変わってないのですが、ﾏｯﾌﾟｴﾃﾞｨﾀです
ttp://49uper.com:8080/html/img-s/106462.zip
上で書いたように、マジで未完成ですよ～。
質問あればどぞー ^^

>>従兄弟ﾀﾝ
お、そろそろ修羅場は脱出ですかな？
変数名はとりあえずﾊﾝｶﾞﾘｱﾝもどきで行くんですかね？
私の書き方はかなり自己流入ってますので、それはそれで混乱をまねくかも。
どっかにわかりやすい基準てないのかなぁ。
あったら即乗り換えるんですが。

基本的に私は適当に書いてるので、ガンガン指摘してもらってけっこうですよ～。
マジでマジで。

ﾘﾌｧｸﾀﾘﾝｸﾞﾂｰﾙなんてあるんですね。
まあ>>184のは英語ｿﾌﾄらしいで、じいちゃん使える自信は全く無いのですが orz

**隣の小父@年金生活** · 2006/01/19(木) 21:10:43

>>185
じーちゃん乙であります！
明日からマップエディタのコード追いかけてみるかのぉ。

コメントは
/// は関数や変数の一行上に、

//!< は同一行の右側に書きまする。

/*!
*/
や
/**
*/
もあるでよ

>>184
従兄弟殿は本格的で実践的な知識を大量にお持ちで凄いですじゃ。

おじさんは、タスクシステムの実験をしとりました。

**隣の小父@年金生活** · 2006/01/20(金) 07:46:17

じーちゃんのマップエディタを弄っております。
骨組みから変えてしまうかもしれないので
03からブランチすると思います。

**じいちゃん（´-`）** · 2006/01/20(金) 09:53:37

おー、じいちゃんのコードは原型が残らないぐらいにしちゃっていいですよ。
がむばって下さい。

ところで「ブランチする」って、なにをどうするって意味ですか？

**隣の小父@年金生活** · 2006/01/20(金) 10:41:36

ブランチというのは、枝分かれのことです。
じいちゃんのコードは引き続き開発していくとして、
それとは別バージョンとして、おじさん版を開発していくってことですたい。

**じいちゃん（´-`）** · 2006/01/20(金) 11:06:24

小父さんのを正式版にするってのはどうですか？

**隣の小父@年金生活** · 2006/01/20(金) 11:37:26

なんと！！
一度ブランチして、再度融合でもしましょうか？
多少時間かかると思うけんども

**隣の小父@年金生活** · 2006/01/20(金) 11:39:49

今やってるのは、
1. ウィンドウ単位でのクラス化を推し進め
2. DDBクラスを自前のものと差し替え
です。
次は
3. おじさんには無く、じいちゃんのコードにある機能をコミット
ですか。そんな感じです。

**じいちゃん（´-`）** · 2006/01/20(金) 11:53:55

マップエディタは一人で作ってもいいと思うので、
ぜひおまかせしたいのですが、いかがでしょか？

じいちゃんのDDBは開放したときとかの挙動に難があるっぽいので、
差し替えたのは大正解かと。

ｳｨﾝﾄﾞｳ単位でのｸﾗｽ化はやるべきでしたか。
書いてる内に CMapEditorｸﾗｽがどんどんどんどん長くなっていくから
どうしようかと思いながらやってました ^^

てゆか、小父さん既にマップエディタ作ってあった感じですね。
ｴﾃﾞｨﾀのﾃﾞｰﾀはどんな感じにすべきかご意見ありますか？
じいちゃんは

'm' 'a' 'p' '\0' の４バイト、Widthの4バイト、Heightの４バイト、ﾁｯﾌﾟ配列
って順にしようと思ってたのですが、他に必要なのってあります？

**隣の小父@年金生活** · 2006/01/20(金) 12:14:38

了解です
おじさんは、マップエディタ担当ですね
猫でも分かるを見ながら頑張りまつ
力尽きたら、バトンタッチするかもｗ

マップデータフォーマットは、それでいいかと
おじさんは、前はデータをセーブする前の段階で
精魂尽き果てまつたｗ

**隣の小父@年金生活** · 2006/01/20(金) 12:24:32

【役割分担】
じいちゃん：　メインプログラマー　ゲーム本体の開発
従兄弟殿：　サブプログラマー　じいちゃんと一緒にゲーム本体を開発
隣の小父：　サブプログラマー　じいちゃんのソースコードを元にマップエディタを開発
ポチ：　グラフィックデータやゲームシステムなど、その他雑用とアドバイス

こんな感じですかね。

他にやりたい人がいれば、どんどん挙手挙手！

**じいちゃん（´-`）** · 2006/01/20(金) 12:25:14

おお、引き受けてくださいますか！
ﾏｯﾌﾟｴﾃﾞｨﾀは今はあんま急いでませんので、ゆっくりでいいですよ。
切りがいいとこまでできたら見せてね～。

Chip構造体もちょっと変えたいなと思ってたんですが、
いかがでしょか。

Struct Chip {
　BYTE byImage; // 絵
　WORD woBitFlag; // ﾌﾗｸﾞ
　WORD woEvent01; // ｲﾍﾞﾝﾄ1
　WORD woEvent02; // ｲﾍﾞﾝﾄ2
　BYTE byEtc; // 念のため ^^
};

WORD woEvent02 を増やしました。
これで合計8バイトになって、
なんか区切りがいいよな気がするんですが、どう思います？

**隣の小父@年金生活** · 2006/01/20(金) 12:25:33

忘れてた…
夫殿はバトルシーンの開発でしたね（汗

**じいちゃん（´-`）** · 2006/01/20(金) 12:26:25

うはｗじいちゃんがﾒｲﾝｗｗ
なにかの冗談みたいだ。

**名前は開発中のものです。** · 2006/01/20(金) 12:34:52

>>196
ファイルのヘッダにバージョン情報か、Chip構造体のサイズを入れておくと
将来的に拡張しやすくなると思いますよ

**じいちゃん（´-`）** · 2006/01/20(金) 13:58:43

>>199
それ、いただき！どもです m(__)m

念のため、Chip構造体のｻｲｽﾞも入れましょ。

"map"の4バイト、Widthの4バイト、Heightの４バイト、
Chip構造体のｻｲｽﾞ4ﾊﾞｲﾄ、ﾁｯﾌﾟ配列

の順にしましょう。
ﾊﾞｰｼﾞｮﾝ情報はｴﾃﾞｨﾀのヤツですよね。それもいるかな？

**隣の小父@年金生活** · 2006/01/20(金) 14:00:55

>>198
オープンソース開発では、
沢山コード書いた人が偉いのです

だから、じいちゃんが一番偉いのですよ

**名前は開発中のものです。** · 2006/01/20(金) 14:55:32

とりあえず従兄弟は、峠を越えたようです (笑

>>194
リンク先を拝見しました。
まさに適材適所ですね♪

>>201
完全に同意です♪
従兄弟もどこまでもじいちゃんについて行きますとも (^^

・次の改造予定
現行バージョンではField関数とBattle関数で
シーンごとに各フレームを処理し、
呼び出す関数はフラグで入れ替えていますよね。
これを改造しようと思っています。

抽象クラスSceneを継承する形でFieldとBattleをクラス化し、
Field関数とBattle関数を「processFrame」に改名し、
Sceneクラスの抽象メソッド「processFrame」をオーバーライドさせます。

シーン切り替えのためフラグを入れ替えている箇所を、
FieldオブジェクトとBattleオブジェクトを入れ替えるようにすれば、
メインループ内では「processFrame」の呼び出しだけで済むようになります。

こうすることで、今までは
フラグとシーンごとの関数と条件分岐を別々に管理していたのを、
実質的にフラグの管理だけで済むようにできるはずです。
後々メンテナンスしやすくなるのと、Battle以降を開発しやすくなるので、
改造してしまっても構いませんか?

**名前は開発中のものです。** · 2006/01/20(金) 17:37:32

>>200
ファイル形式自体のバージョン情報というつもりでしたが、
将来的にチップ配列以外の情報(例えばマップ名やスクリプトなど)を
追加したとき、ローダが旧形式のファイルと区別できると、
特にチームで開発する際、何かと便利です。

ヘッダがmapで始まるなら、４バイト目にバージョン番号を入れても
良いかもしれません。しかし、もし余力があるのなら、
「チャンク形式」でエンコードすることもお薦めしておきますね。

**従兄弟** · 2006/01/20(金) 21:08:28

>>202
説明だけでは分かりにくいと思うので、
今晩実際に改造したものを上げますね。

とりあえずFieldとBattleをクラス化したもの
ttp://gamdev.org/up/img/4424.zip

/*---------------- 以下は変更点 ----------------*/

Battle.cppのクラス化 (CBattle.h)
Field.cppのクラス化 (CField.h)

・WinMain.cppの変更点
　メインループ前にCBattleとCFieldの初期化
　メインループ内のField()とBattle()を
　　field.ProcessFrame()とbattle.ProcessFrame()に変更

・CField.hの変更点
　インスタンス変数の頭に「m_」を追加
　Field()→ProcessFrame()
　Field_Init()→Init()
　Draw_Field()→Draw()
　Move_Field()→Move()

・クラス名およびファイル名の変更
　CF_Input→CFieldInput
　CF_System→CFieldSystem
　LookAroundFrame→CLookAroundFrame
　PlayerArrow→CPlayerArrow

**従兄弟** · 2006/01/20(金) 21:13:34

>>204
もとにしたのは小父さんの>>179のソースです。

**じいちゃん（´-`）** · 2006/01/21(土) 00:20:52

前々から思ってましたが、
変数名は大文字少ない方が見やすいな～なんて、
>>204を見て、改めて感じてしまった。

>>従兄弟ﾀﾝ
峠越えましたか。おつかれ～。
従兄弟ﾀﾝがやりたいことは少しずつ把握してきました。
なんてゆうか、どんどんムチャが利きにくい感じになってきてますねｗ
じいちゃんそういうのあんま考えたことないので、どうなるか興味津々。

ガンガンやっちゃって下さい♪
じいちゃんはとりあえず絵を動かすとこを中心にやってみます (`･ω･´)

>>203
んー、説得力ある感じ。
mapの3バイト、ﾊﾞｰｼﾞｮﾝ情報の1バイト、Widthの4バイト、Heightの４バイト、
Chip構造体のｻｲｽﾞ4ﾊﾞｲﾄ、ﾁｯﾌﾟ配列
の順にしましょか？小父さん意見よろ。

**じいちゃん（´-`）** · 2006/01/21(土) 00:23:25

さっきVC++2005を落として入れてみたのですが、
なぜかﾌﾟﾛｼﾞｪｸﾄが作れない orz

Visual C++ 2005 Express Edition と Microsoft Platform SDK を一緒に使う
http://www.microsoft.com/japan/msdn/vstudio/express/visualc/usingpsdk/
たぶんこれは必要なんですよね？
全部やったはずなんだけどなぁ。

**名前は開発中のものです。** · 2006/01/21(土) 01:26:43

原因不明のバグに悩まされ、まだ改造が終わりません (汗
朝までには終わるようにしますので (w

>>206
変数のスコープを限定したりすると、たしかに無茶が聞きにくくなりますね。
(バランス取りが難しいですね)
もしアクセスしたい部分があるのにうまくいかないときは、
言ってくれればそこを書き直しますので、気軽に声をかけてくださいな。

>>207
従兄弟はtheSpoke版の2005を使っているので、
Express Editionのことは分からなかったりします。
紹介しておいてごめんね、じいちゃん。

**名前は開発中のものです。** · 2006/01/21(土) 05:00:47

ようやくバグの原因が分かりました（｀・ω・´）
ヘッダをincludeする順番の問題だったようです。
(相互に参照するので互い違いでなければならなかった)

ttp://gamdev.org/up/img/4431.zip

…というわけで、改造済みのソースを揚げてそろそろ寝ます。
今回の改造点は、以下の通りです。
(シーン管理機能が出来たので、今度はシーンを作り始めようかな)

**従兄弟の変更点** · 2006/01/21(土) 05:02:47

・Struct.hにあった__System構造体メンバーの
　「int nSceneControl; (シーンを表す変数) 」を
　Grobal.hの「CSceneSwitcher g_sceneSwitcher」に置き換えた。

　そのため、今まではBattle, Field, WinMainで
　「g_Sys.nSceneControl = S_FIELD;」のようにフラグを入れ替え
　メインループのswitch文で分岐させていたのを、
　「g_sceneSwitcher.SwitchToField();」のように指定し、
　メインループでは「g_sceneSwitcher.ProcessFrame();」と
　実行するだけで済むようになりました。

　例えば「g_sceneSwitcher.SwitchToBattle(player, enemy);」
　のように戦うキャラをその都度指定できるようにするなど、
　シーンごとに管理するデータも渡せるように出来ます。

　シーンを追加する場合には、CSceneクラスを継承した
　サブクラスをCSceneSwitcherクラスに登録します。
　# 「ProcessFrame()」は必ずオーバーライドして下さい。
　# 初期バージョンでのField()やBattle()関数にあたるので。

**従兄弟** · 2006/01/21(土) 05:05:29

続けて失礼します。

バグをつぶす過程でExtern.hを無効にして各ファイルで
直接extern定義していますが、後で直しておきますので。

ちなみにソースは、
従兄弟の中ではこんな分類になっています。
(左端のツリー図)

ttp://gamdev.org/up/img/4432.png

**隣の小父@年金生活** · 2006/01/21(土) 06:50:34

>>206
typedef struct {
　union tag {
　　DWORD v;
　　BYTE c[4];
　}
　long width;
　long height;
　long chip_size;
} MAPDATA_HEADER;

こんな感じかな…

**隣の小父@年金生活** · 2006/01/21(土) 07:50:38

昨日はウィンドウを表示するところまでで
精魂尽き果てますた
今日はDDBとBitmapの解析を進めまする

http://www.geocities.jp/bigbrotherxlittlesister/MapEditor_03b/html/

**隣の小父@年金生活** · 2006/01/21(土) 09:54:46

要点整理の為、メモりまする。

GDI周りのクラス

DC //WinControlを継承している
http://www.geocities.jp/bigbrotherxlittlesister/MapEditor_03b/html/DC_8h-source.html

DDB //DCを継承している。BMPのロードはここでやってる。
http://www.geocities.jp/bigbrotherxlittlesister/MapEditor_03b/html/DDB_8h-source.html

DIB
今回は割合

DIBSection
DIBとDDBを継承したもの

**じいちゃん（´-`）** · 2006/01/21(土) 10:41:20

外が雪景色で超綺麗だよ@東京
しかしながら、二人とのｽｷﾙの差に愕然となり、
じいちゃんの心はドス黒くなってたり。

あー、がんばろ (`･ω･´)

>>従兄弟さん
悲しいかなじいちゃんにはパッと見よくわからんので、
ちょっと勉強しまっす。
クラスってそんな風に使うのね・・。

>>小父さん
ﾏｯﾌﾟｴﾃﾞｨﾀ進んでるようですね。
基本的なところからじいちゃんと全然違う組み立て方にビビってるよ。

>>212のはそれでいいと思うのですが、
なぜ共用体になってるのか (DWORD vの意味がわからずorz) と、
int ではなく long を使ってるのはなぜですか？

**隣の小父@年金生活** · 2006/01/21(土) 10:47:08

>>215
intは処理系依存なのでlongを使って32bitを明確にしています。
char[]の他に４バイトを纏めて扱えると都合がいいかなとか
思ったり（余計なお世話？ｗ）

**じいちゃん（´-`）** · 2006/01/21(土) 10:52:14

うはｗじいちゃん今までなぜかlongが処理系依存だと思ってた orz
DWORD v は今のとこ使い道は決まってないってことですかね。

両方とも了解しました。ありがとー。

**隣の小父@年金生活** · 2006/01/21(土) 11:47:50

/// マップデータ・ヘッダー構造体
typedef struct {
union _tag {
DWORD v;
BYTE c[4];
} tag;
unsigned long width;
unsigned long height;
unsigned long chip_size;
} MAPDATA_HEADER;

ちょっとミスってたorz...

**じいちゃん（´-`）** · 2006/01/21(土) 12:11:20

>>218
OK把握です。
一応聞いときたいんですが、
>>196のはどの環境でも8バイトってことでいいんですかね？

**隣の小父@年金生活** · 2006/01/21(土) 12:16:51

>219
>>196
バイナリデータに構造体を当てはめただけだと、
処理系依存になります。
４バイトアラインがコンパイラ依存の筈です。
ですので、シリアライズ、デシリアライズをする必要が
あると思います。

**じいちゃん（´-`）** · 2006/01/21(土) 12:30:54

ごめ、シリアライズ、デシリアライズがわかんないのですが、

IT用語辞典
http://e-words.jp/w/E382B7E383AAE382A2E383A9E382A4E382BA.html
これによると、
シリアライズ　→　データをファイルに保存
デシリアライズ　→　ファイルを(復元して？)読み込む
でいいんでしょか。

～バイトアラインでググったら、なんか悲喜こもごも色々出てきた。
みんな環境で苦しんでるらしいですねｗ

読み込む前にChip構造体のｻｲｽﾞ計って、想定と違う場合は
どうにか変換するんでしょか。じいちゃんにはわからず・・ (：D)|￣|＿

構造体のﾒﾝﾊﾞの順番とか、変数の型とかは好きに変えちゃってもいいですよん。
たぶんあんま大きなﾏｯﾌﾟにはならないと思うし。

**隣の小父@年金生活** · 2006/01/21(土) 12:41:08

バイナリの構造体をそのまま使うと、
CPUに都合がいいように最適化されているので、
ぴったり８バイトにはならないことがあります。
ですので、人力プログラミングで調整してあげる
必要があります。

**隣の小父@年金生活** · 2006/01/21(土) 12:49:29

う～ん実は、数年前まではC++のオブジェクト指向
全然駄目だったんですよ～
人間、やれば覚えられるもんだなとｗ

**じいちゃん（´-`）** · 2006/01/21(土) 12:49:52

>>従兄弟さん
じいちゃんアフォなので、とりあえずコンソールでテストしてみました。
つながりはこんな感じでしょうか。
ttp://gamdev.org/up/img/4435.zip

これだとほとんどの変数（ｵﾌﾞｼﾞｪｸﾄ？）を CSceneSwitcher が持つことになりそうですね。
ｼｰﾝ同士の変数の受け渡しとかは、 Switch～() を挟んで引数で渡せそうな感じ。
こんな組み方もあるのねぇ。

あと、ﾎﾟｲﾝﾀ同士の代入がちゃんとｷｬｽﾄされてるのになぜかｴﾗｰが出たので、
C++のｷｬｽﾄに変えたいんですが、この記述でだいじょぶでしょか？

>>222
んー、難しそう・・。
変換中は読み込みがちょっと遅くなるかもですね。
でも狭いﾏｯﾌﾟなのでだいじょぶかな。

人力プログラミングでググったら謎のアーティストが出てきたｗ

**じいちゃん（´-`）** · 2006/01/21(土) 12:51:45

>>223
じいちゃん実は去年からC++始めたので、
まだ STLすら一個もわかんね ┐(´ー｀)┌

おぶじぇくと指向とかでざいんぱたーんとか、なにそれ？

**名前は開発中のものです。** · 2006/01/21(土) 20:22:35

>>215
雪、綺麗でしたね (^^
私も同じく東京からです。

私はじいちゃんとは逆に絵を出して表示するのが苦手なので、
「スキルの差」は高低ではなく種類の差だと思いますよ。

>>216-217
たしかintもlongも、他の型も言語レベルでは処理系依存だったかと。
(「long>=int」だったかも)
Windows用コンパイラではどれもlongが32bitなのかな?

>>220-221
シリアライズは「直列化」と訳されるとおり、
プログラム中のデータをバイトの配列 (これが直列) に変換することです。
ファイルに書き込むにはシリアライズする必要があるので、
書き込むところまでセットで指す場合が多いですね。

マップデータの受け渡しのための直列化でしたら、
処理系依存を気にするよりは、
テキストファイルなどで保存してしまうのはいかがでしょうか。
こうしておけば保存はprintf()で済みますし、
今後もコンパイラの仕様変更を気にせず済みますし。

**従兄弟** · 2006/01/21(土) 20:23:53

>>224
おお、改造乙です♪
少ししたら読んでみますね。
エラーが出たのは、どのコンパイラでですか?

>>225
私もC++を始めたのは2ヶ月前なので、STLは一つも分かりません (w
ただJavaを使っていたので、何とか書けていますが。。
ちなみにシーンをCFieldやCBattleといったクラスに関連付けたのは、
ステートパターンというデザインパターンの一種です。

**隣の小父@年金生活** · 2006/01/21(土) 20:27:36

>226
longも処理系依存でしたか…間違えてました（汗
（Win以外では動かさないという前提で）windows.hの型を使うか
それよりも型を独自に定義するべきなんでしょうね
（処理系によって分けたりできるように）

**名前は開発中のものです。** · 2006/01/22(日) 00:03:55

>>224 (じいちゃん)

> つながりはこんな感じでしょうか。
そんな感じです。
こういうシンプルなサンプルを用意すると分かりやすいですね。
今度から構造を変えたときにはそうしようと思います。

> これだとほとんどの変数（ｵﾌﾞｼﾞｪｸﾄ？）を
> CSceneSwitcher が持つことになりそうですね。
シーン関連はそうなりますね。
どのシーンに入るか、そのシーンにどういう引数を渡すか、
といった内容はCSceneSwitcherの外で決めることになるので、
すっぱり分けてしまった方が役割分担が分かりやすいのではないかと。

> ｼｰﾝ同士の変数の受け渡しとかは、 Switch～() を挟んで引数で渡せそうな感じ。
狙いはその通りです。
引数渡しにしてグローバル変数を使わなければ
中で使われている変数が一目で分かりますので。

> あと、ﾎﾟｲﾝﾀ同士の代入がちゃんとｷｬｽﾄされてるのになぜかｴﾗｰが出たので、
> C++のｷｬｽﾄに変えたいんですが、この記述でだいじょぶでしょか？
私の環境でも直していただいた方でエラーが出ないので、
変えてしまってくださいな。
わざわざ調べていただいて、ありがとうございます。

**隣の小父@年金生活** · 2006/01/22(日) 11:17:12

「猫でもわかる」を見ながら、色々実験してます。
本格的なＷｉｎアプリを作るのは初めてだったりｗ

**じいちゃん（´-`）** · 2006/01/22(日) 12:04:36

私もｵｰﾊﾞｰﾗｲﾄﾞの実験してます。
本格的にｵｰﾊﾞｰﾗｲﾄﾞ使うのは初めてだったりｗ

switch()文で分けるよか、綺麗で汎用的っぽいんですよねぇ。

>>229
ｻﾝﾌﾟﾙはじいちゃんが勝手にやったものですから、
従兄弟ﾀﾝは気にせずガンガン改造しちゃってかまわないですよ。

警告が出たのはVC++6.0ですじゃ。
ただなぜか出たり出なかったりするので、よくわからず。
ｷｬｽﾄを変えてからは出てないっぽいですが。

**隣の小父@年金生活** · 2006/01/23(月) 08:22:06

下位機能をライブラリとして、まとめ中～
時間かかるなぁ…orz

**隣の小父@年金生活** · 2006/01/23(月) 11:19:38

WINアプリ製作に慣れる為に
メモ帳を作っとりますｗ

**じいちゃん（´-`）** · 2006/01/23(月) 19:07:14

とりあえずｍじいちゃんが昨日やってたの
http://49uper.com:8080/html/img-s/107222.png
メニュー出してます。
分岐ありまくりで、かなり複雑になりそうな予感。
なんていうか、こういう動きの少ないｹﾞｰﾑはﾒﾆｭｰが占める割合が大きいですね。

ぶっちゃけ　主役＝メニュー　のような気がしてきたYO

小父がんばってますね。
メモ帳って、自分で作れるのね。
ああいうのはｳｨﾝﾄﾞｳｽﾞ様が用意してくれるものだとばかり思ってました。

前に聞くの忘れてたんですが、
タスクシステムってどうですか？気にはなってるんですが、
ｹﾞｰﾑで使えるかどうかがよくわからないので、まだ試してないんですよ。
超複雑そうなので、このｹﾞｰﾑで使う気はサラサラないですけどー。

**隣の小父@年金生活** · 2006/01/23(月) 19:44:39

>234
じーちゃん乙！
ゲームらしい画面になりましたね

>>メモ帳
Win32のエディットコントロールをウィンドウに貼り付けるだけですｗ
でも、ウィンドウにテキストを打ち込めると、ちょっと感動ｗｗ

>>タスクシステム
タスクシステムは、>>210で従兄弟殿が作ってくれた
シーン管理と、ほぼ同じ実装です。
ですので、無理にリアルタイムゲーム用のタスクシステムにせずとも
シーン管理クラスでやればいいかと・・・

おじさんは、やねうらお大先生のタスクシステムを参考にしてます。

**隣の小父@年金生活** · 2006/01/24(火) 09:11:35

バグが出て治らないので
低層から再構築することに…orz

**じいちゃん（´-`）** · 2006/01/24(火) 19:10:52

ちょっと停滞中～。
じいちゃんも昨日バグりまくりで、キレてｹﾞｰﾑに逃げちゃった。
お姉チャンバラ以外に面白いよｗ

>>235
＞ウィンドウにテキストを打ち込めると、ちょっと感動ｗｗ
あるあるｗ
ﾀﾞｲｱﾛｸﾞとか出せるとなんか凄いうれしいよね。

＞ﾀｽｸｼｽﾃﾑ
関数ﾎﾟｲﾝﾀみたいになるんですかね。
優先順位の高いほうから実行するとかいう噂は聞いたことが。
ヘタに使うとメチャメチャになりそうな予感。

ポチ · 2006/01/24(火) 19:55:00

>>小父様へ
今ごろになって書き込むのもなんだけど
マップエディタの保存形式について提案というか要望があるワン。
x00,チップ番号,拡張用,イベント番号、という配置で
BMPで保存する形式にできないかしら？
チップやイベントの数が256上限になるけど十分じゃないかと思ったりｗ

読み込み時は
マップの広さはそのままBMPのwidthとheightで左上から
ピクセルごとに処理していく感じ。チップ番号はじいちゃんが
振付けてくれてるものをそのまま流用。

イベントはいい案（形式を決めてスクリプト化したい）が降りてこないので
マップのイベント番号で分岐内部処理。

マップチップ以外のデータを持たす場合(マップ名等)別ファイル内でマップBMPを指定する
形になるとおもう。

**じいちゃん（´-`）** · 2006/01/24(火) 20:28:15

ポチきたー。
その方式だと、32bitのﾋﾞｯﾄﾏｯﾌﾟっぽくなるのかな？
x00てのは8bitﾌﾗｸﾞでしょうか。
各数字は256まででもなんとかなるっぽいです。
ﾍｯﾀﾞはwidthとheightの二つがあればよし。

この方式にする、利点はなんでしょか？

**じいちゃん（´-`）** · 2006/01/24(火) 20:43:26

ぜんぜん進んでないんですが、うｐします。
ちょっとﾒﾆｭｰ出してみました。
ttp://gamdev.org/up/img/4466.zip
絵は>>234です。

また長大なswitch()文で色々処理してます ('A`)
いまだに移動しかできないのですが、バグありましたら報告よろ。

Extern.hとGlobal.hはｺﾝﾊﾟｲﾙするときのつながりがよくわからないので、
おもいきって無くしてみました。
ｸﾞﾛｰﾊﾞﾙの変数が使いたい場合は、そのファイルの上に直接 extern することになるはず。

ﾒﾆｭｰｸﾗｽ追加しました。
変数名とかﾏｸﾛの名前とか変えたのあるかも。

ﾒﾆｭｰしんどいよﾒﾆｭｰ・・。

ポチ · 2006/01/24(火) 22:01:31

>>239
32bitじゃなくてOKです。D3Dの中でアルファ付で処理してたための記述でふ。
単純にRGBでデータを持たせてしまえっていう姿勢です。

この方式にする利点は
ずばり、人間がみて一目でマップデータがわかる！（まて
あまり深く考えてないですが
データをベタ書きのBMPにすることでlongとかintとか悩まないで済む事かなｗ
自分が作るときは大抵この方式かTEXTでCSVで吐き出すもので。
TEXTやBMPだと大抵どのOSに持って行っても使えるって事もありますね。

拡張用のbitデータに高さを持たせて
擬似３Dにしようかな～とか妄想なんてしてないですよ～？ｗ（｀・ω・´）

**隣の小父@年金生活** · 2006/01/25(水) 04:39:08

>>238 >>239 >>241
そうすると、
DDBじゃなくて、DIBでマップデータを持たないとダメですね
DIBSectionでもええんですけども

マップエディタは、まだまだ全然出来てないので
今のうちなら仕様変更可能でっする

【メリット】
データを文字通り目で確認することが出来る
エンディアンを、それほど気にしなくて済む

【デメリット】
上限が255に制限される
簡単にエンドユーザーに書き換えられてしまう