11/03/26 17:11:30.81 npmu6kKT.net
>>846
>>1の書き込みとスレッドの中身を見る限り、このレベルからやっても
良いように感じましたが・・・
>>1さんもC++のプログラミングは初めてって書いてますし
>>848
確かにこのままソース書いていくのは難しいと感じてました
どんどん大きくなっていきますからね
とりあえず
URLﾘﾝｸ(gmdev.xrea.jp)
このアップローダが、この板でプログラムを作っている方々が
使用しているアップローダのようです
今後はここにソース置きましょうか
>>849
common.hみたいなヘッダを作成して
#include "WINDOW.h"
extern Window window;
として
WINDOWクラスにアクセスする必要があるクラス全部に
インクルードしたら良いんですね
851: ◆UUwiUCL1P6
11/03/26 18:14:33.03 pvmCllah.net
>>850
gmdevにDirectInputの.h/.cppを置きました。
URLﾘﾝｸ(gmdev.xrea.jp)
＞common.hみたいなヘッダ
そうです。自分専用のマクロとか定義とかの置き場にヘッダ作りますよね。
そこに入れておいてください。
ついでに↓もお願いします。
#define ARRAY(a) (sizeof(a)/sizeof(a[0]))
配列の要素数のマクロです。
置いたソースですが現在の自分のソースからいろいろはしょって整形しているので、
部分的に文法がおかしくなったりで、エラーがでるかも知れません。
それはすいませんがうまく直してください。
852: ◆MBbNHCnf2M
11/03/26 18:47:47.52 npmu6kKT.net
>>851
すごく見やすいソースですね、大体の感じは理解出来ました
GameInput.cppのunsigned int GameInput::index;で
静的でないメンバーはクラスの外側で定義できませんと出たので
ヘッダの宣言でstatic付けときましたけど、staticにして大丈夫ですか？
それと、DATA_MAXが未定義だったので、適当に#define DATA_MAX 256
と、とりあえずしておきました
以上でコンパイルできました
これからじっくりとソース見ていきたいと思います
853: ◆MBbNHCnf2M
11/03/26 18:59:27.28 npmu6kKT.net
今ソース眺めてたら
enum { DATAMAX = 0x100, };ってあるけど
これがDATA_MAXかな？
854: ◆UUwiUCL1P6
11/03/26 19:15:55.16 pvmCllah.net
>>852
index は static です。付け忘れました。
>>853
DATA_MAXです。記述ミス。
入力ワーク回りで間違い多いのは、現在その部分は環状リストで可変長で実装しているので、
急ごしらえで変更したためです。
一部、ヘッダにあって実装されていない関数(JoyPush等)は実際にゲーム中で使用する関数です。
これはGameInput.cppとは別ファイルにした方がよいです。
GameInput.cppはいったん完了するとほとんどいじらなくなります。
ライブラリィ化してもいいかも知れません。
855:名前は開発中のものです。
11/03/27 19:06:12.75 7F6awSJl.net
>>825
> InitとFreeの中身は対称(確保⇔解放)になる事が多いです。
なんでコンストラクタとデストラクタ使わないの？
856: ◆UUwiUCL1P6
11/03/27 22:08:40.18 In3d1Uaw.net
>>855
インスタンスを作成しないからです。メンバーは変数も関数もstaticだけです。
インスタンスを作成できないように、privateでコンストラクタを記述しておくべきですね。
857: ◆MBbNHCnf2M
11/03/27 22:25:46.92 rtEoqdWq.net
ここ二日でDirectInputについては大体理解できた気がする
今頃気が付いたけど、DirectInputって今後非推奨なのか
858:名前は開発中のものです。
11/03/27 22:49:20.93 7F6awSJl.net
>>856
いや、だからインスタンスを生成しないのはなんで？って話だったんだけど。
まぁプログラム中で１回だけしかやらないなら、 Init()/Free() 呼び忘れや２重呼び出しも
そうそう起こらないだろうから、コンストラクタやデストラクタ使ってもそんなにおいしくないの
かもね。
859: ◆UUwiUCL1P6
11/03/27 22:58:33.14 In3d1Uaw.net
>>858
Cで作り始めてからC++にしたのでグローバル関数が自分的にしっくりきたという理由です。
合理的な理由はとくになく、個人の好みの範疇を出ないです。
>>857
続きをおきました。
URLﾘﾝｸ(gmdev.xrea.jp)
ゲーム中で使う関数の使い方さえ変えなければ、実装はDirectInputでなくともよいかと思います。
860:名前は開発中のものです。
11/03/27 23:12:17.94 BpzKp4Cl.net
「趣味の範疇」なら何回もつっこまれないと思うけどなぁ
自分も「えー」って思ったし
861: ◆UUwiUCL1P6
11/03/27 23:39:29.93 In3d1Uaw.net
>>860
クラスのないCで作ってから、あとでclass{}で括るとこんな感じになりますよ。
そこからC++ならではの形に作り変えるまでに至らずというところです。
＞◆MBbNHCnf2Mさん
この先こんな感じで趣味っぽいところが満載なので自分流に変更するなり、
他の意見を参考いただくなりで、そこは適当にやってください。
ウィンドウ表示⇒コントローラ入力と来たので、次は描画＆ファイル読み込みですが、
ここから私としてはタスクシステムをご提案になります。
すごーく突っ込みが入るテーマのようなんで少々気が重いです。
862:名前は開発中のものです。
11/03/28 00:17:25.15 Dt+tXZ6j.net
>>861
わかってるならやめとけばいいのに。どうせ必要性もないんだろ？
やるなら自分でわかってる範囲の突っ込み所と、それでも敢えて押し通す意義（必要性）を
最初にひととおり明示しておけば、繰り返しツッコミが入ってグダグダになるのは避けられる、
かもしれない。
863:名前は開発中のものです。
11/03/28 00:29:53.10 iY/f3p70.net
RPGの描画や更新なんてすることもタイミングも決まりきってるのにタスクシステムなんか何に使うんだよw
上の人も言ってるけど、まずどういうものを作ろうとしててそのためにこういう技術が必要だというのを
はっきりさせてくれ
864: ◆MBbNHCnf2M
11/03/28 00:30:16.73 +ECkFPgj.net
>>861
自分的には分かりやすいので、全然問題ないです
まあ、細かい実装はそれぞれのやり方があるでしょうからね
私なんかCにしてもC++にしても言語仕様も十分に理解しないまま
やってるので、基本的に何でも参考になります
本当はちゃんと勉強した方が良いんでしょうけど
タスクシステムは、確かにこの板のスレ見ると荒れてますね
そもそも、タスクシステムの定義自体が曖昧というか
人によって微妙に違う感じですね
タスクシステムは一度勉強してみたかったので、ちょうど良かったです
865: ◆MBbNHCnf2M
11/03/29 22:24:52.26 o6OtSixI.net
どうやら風邪をひいてしまったようで、喉が痛い
ところで話は今までの流れと急に変わりますけど
今時のRPGってアイテムのデータはどのように持ってるんだろう
昔なら、アイテム番号だけを持ってて（ゲーム全体で256個までなら1バイト
65536個までなら2バイト）、その番号からアイテムデータを参照してたけれど
例えば、武器にランダム性があって、ショートソードに+1とかの強さの幅がある場合
アイテム番号1がショートソード、アイテム番号2がショートソード+1みたいな
のだと無駄にアイテムデータ増えるからあり得ないかな
昔だと、メモリも少ないし、データをセーブする媒体の容量も少ないから
アイテムのインデックスだけを持っていたけれど、今はデータ全体を
そのまま持っているのかな
866: ◆MBbNHCnf2M
11/03/29 22:28:15.54 o6OtSixI.net
多分、基本となるデータのみ存在していて、入手時にそのデータ元に
ランダムで性能を確定させて、そのデータを全部を持ってるのか
867:名前は開発中のものです。
11/03/29 23:19:08.33 W0uoKekZ.net
これだ！っていうデータ構造なんて無いんじゃないかな
ゲームごとにチューニングする必要があるわけで
パフォーマンスに余裕があればリレーショナルデータベースとか使っちゃうのかな
868:名前は開発中のものです。
11/03/30 00:26:46.80 jEpUZgct.net
アイテムのインスタンスに持たせた方がいいんじゃないかなぁ
手持ちの装備を強化できるようなシステムが追加したくなった場合とかやりやすいし
869:名前は開発中のものです。
11/03/30 01:14:37.31 fixmLHL7.net
>>865
仕様に沿って素直なコードを組むのが最強。
リソース制約が顔を出しにくくなった「今時」ならこれでいいでしょ。
"Premature optimization is the root of all evil."
870: ◆MBbNHCnf2M
11/03/30 20:18:14.12 eH7gPhm2.net
>>867-869
やっぱりデータが変化するようなものだと、インデックスだけで
管理は無理ですね。よく考えたら当たり前の事だった。
まあ、今ならアイテム程度のバイナリデータいくつ持ってても
問題無いか。携帯とかモバイル環境だと制限あるかもしれないけど
そんな環境だと、そもそもそれ程大規模のゲームも作らないだろうし。
871:名前は開発中のものです。
11/04/03 21:06:06.82 t0UP3s0y.net
しーん
872: ◆MBbNHCnf2M
11/04/03 21:10:34.12 wtGWHPRo.net
>>871
ちょうど今書こうと思ってた所です
今週は、風邪をひいてあまり集中して出来なかったので
とりあえず、ポリゴン出したりテクスチャ貼ったりというのは理解したと思う
これで音を出す以外の大体の事は何とかなるような気がする
873: ◆MBbNHCnf2M
11/04/03 21:17:09.28 wtGWHPRo.net
で、マップスクロールについて考えていたんですけど
URLﾘﾝｸ(d.hatena.ne.jp)
上記のサイトのRPGの項目にあるような、マップ全体を裏画面に描画して
そこから表示画面分だけ切り出すという方法が結構検索していると
見つかるのに驚いたわけです
これって結構スタンダードな方法なのかな？
いくらメモリを気にしなくてもいいPC環境とはいえ、マップ全体を描画って
あり得るのだろうか、少なくとも市販作品では無いような気がする
874: ◆MBbNHCnf2M
11/04/03 21:23:57.58 wtGWHPRo.net
昔はマップスクロールというと、RPG作成において一番の難所で
これが出来たらもうRPGは出来たも同然というような感じだった
特に私が使っていたMSXなんかだと、ハードウェアスクロール機能が
縦方向しかなかったので、1ドットスクロールは厳しかった
本当に最初の頃は、レイヤという概念も無くて（知らなかっただけかも）
そもそもレイヤをいくつも重ね合わせられるほどの処理速度もメモリも無かった
875:名前は開発中のものです。
11/04/03 21:27:16.75 /2gPwasz.net
昔とかどうでもいい話してないでDirectX使えよ。
無理ならＤＸライブラリでも使え
876: ◆MBbNHCnf2M
11/04/03 21:32:21.82 wtGWHPRo.net
そこで、どういう風にマップスクロールを実装していたかと言うと
裏画面に表示画面より、縦・横共にマップチップ1個分大きいマップを描画し
そこから1ドットずつずらしてコピーするという方法だった
ページフリッピングも出来ないわけではなかったけど、VRAM容量を考えると
そんなもったいない方法は許されなかった
今でも縦・横でマップチップ一個分だけの裏画面からコピーするのが
定番だと思っていたけれど、マップ全体からコピーするという方法が
多く見つかるというのは、そっちの方が定番のかな
877:名前は開発中のものです。
11/04/03 21:34:32.01 t0UP3s0y.net
>>873
256*256のマップだけで256MB消費ってのは普通じゃないと思う
878: ◆MBbNHCnf2M
11/04/03 22:04:18.84 wtGWHPRo.net
>>877
そうですか、やはり普通じゃないのか
説明しやすいからそうしているのが多いのかな
今考えている方法は
用意すべき画面
1. 表示画面分の表・裏のサーフェイス（DirectX初期標準）
2. 最終的に合成する画面、ここから1ドットずつすらして裏サーフェイスにコピー
（表示画面より縦・横1チップだけ大きい画面を確保）
3. レイヤを3つ使うとして、各レイヤ分の裏画面（これも表示画面より1チップ分だけ大きい）
4. マップチップ・キャラやNPC等のグラフィック
処理
1. まず、方向キーが押されたら、3の各レイヤ用の画面にマップ描画
2. 最下層のレイヤ分を2に画面にコピー
3. 最下層上にいるキャラクタ・NPCを2に描画
4. 2-3をレイヤ分処理
5. 2の画面から1の裏画面にコピーして裏画面を表に
6. 2-5までを1ドットずらして1チップ分処理
無駄がありそうだけれど、これでいけそうな気がする
でもテクスチャって座標指定でコピーできないから
1ドットずつコピーするのが難しそうな気が
もっとテクスチャについて勉強する必要がありそう
879:名前は開発中のものです。
11/04/03 22:06:51.98 /2gPwasz.net
あのさ？座標にマイナスを指定できるの知ってる？
880: ◆MBbNHCnf2M
11/04/03 22:36:46.84 wtGWHPRo.net
>>879
失礼、連続で5回以上書き込めないようで
テクスチャ座標に負の値が使えるのは知ってます
それをどこに使うんですか？
まだ勉強中なので教えてください
881:名前は開発中のものです。
11/04/03 23:07:20.50 mqRgK4Gz.net
あなたの文章を読んでいて思ったのだが。
まさか、一枚のテクスチャに複数のレイヤーを重ねて最終的に
画面に描画しようとしている？
DirectXのバージョンをいくつ使うか知らないけど
いくらなんでも概念が古すぎるよ。
(DirectDrawとか使おうとしてる？）
WindiwsXPターゲットのDirectX9ならポリゴンまたはスプライト使えば解決できることを
わざわざ難しい方法でやろうとしているように見える。
ここで説明するのは無理があるからいくつかサイトのＵＲＬ貼っとく
DirectX8の解説サイト
URLﾘﾝｸ(rina.jpn.ph)
Microsoft本家のゲームプログラミング入門資料（数学の知識必須）
URLﾘﾝｸ(msdn.microsoft.com)
まさかとは思うがDirectX7ならこの辺り
URLﾘﾝｸ(rina.jpn.ph)
入門者ならDirectXと言わずＤＸライブラリを使うのもありだと思う。
ＤＸライブラリを使った解説サイト
URLﾘﾝｸ(dixq.net)
あと、ネットの情報は色々不足な部分や整理されていないから
一冊、入門書を買うことをお勧めする。
882:879
11/04/03 23:08:21.00 mqRgK4Gz.net
あれＩＤ変ったｗ
883: ◆MBbNHCnf2M
11/04/03 23:49:00.27 wtGWHPRo.net
全然連続で書き込めない、この板人が少な過ぎるのか・・・
>>881
DirectX 9.0c でやろうと思ってます
つまり、DirectDrawでなくて、DirectX Graphicsですね
そのサイトも読んだんですけど、多分ポリゴンにテクスチャに貼り付けて
2Dの処理をするのがよく理解できてないんですね
特にテクスチャの扱いが多分よく分かってないので、勉強しときます
ポリゴンに単純にテクスチャ貼るところまでは理解できてる（と思う）んですが
884:名前は開発中のものです。
11/04/04 00:57:26.26 EfnOmkqq.net
だったら素直にD3DXのSprite使えばいいよ
表示範囲内のタイルを毎フレーム全て描画しなおせばいいだけ
一見効率悪そうだけど>>878よりは遥かに効率が良い
885:名前は開発中のものです。
11/04/04 01:16:24.28 EfnOmkqq.net
一つのレイヤ内で使われるタイルを一つの大きなテクスチャにまとめておいて
レイヤ全体を一つの図形とみなしてテクスチャ座標でマッピングするのが
多分一番速くて効率の良い方法
スプライトはそれと同じようなことを自動でやってくれるから
毎フレーム大量の描画を行ってもわりと速い
886:名前は開発中のものです。
11/04/23 16:35:48.28 CvPk8hGJ.net
ゲーム制作メンバーを募集しています。
ｽﾚﾘﾝｸ(ff板)l50
URLﾘﾝｸ(www31.atwiki.jp)
・最近のFFが嫌い
・昔のFFが好き
どちらかに当てはまれば誰でも結構です。
昔ながらのFFをみんなで作りましょう。
887:名前は開発中のものです。
11/04/28 16:06:00.10 odTXZLNY.net
募集要項の大雑把さにフイタ
888: 忍法帖【Lv=18,xxxPT】
11/05/05 11:29:11.77 Zs6VE70C.net
うん？
889:名前は開発中のものです。
11/07/08 21:16:59.44 nxuNDnA1.net
マップ画面から事ある事に戦闘画面に行くよくあるRPGを作ろうと思うんだけど、
戦闘画面を呼び出すのはマップ画面の中で関数呼び出す感じにするもんなの？
それともデータ保存してマップ画面終了してから戦闘画面に行くもんなの？
作る時は前者が楽だけど、メモリがちょっと心配。
890:名前は開発中のものです。
11/07/08 21:29:25.17 TDxk0CvB.net
メッセージループ内でシーン分岐
891:名前は開発中のものです。
11/07/08 21:34:45.63 nxuNDnA1.net
ああ、やっぱそれか……ありがとう。
892:名前は開発中のものです。
11/07/13 17:30:26.96 7GbeQNs3.net
> それともデータ保存してマップ画面終了してから戦闘画面に行くもんなの？
毎回状態を記憶した一時セーブデータみたいなの書き出して読み込んで、
オブジェクトの生成と破棄とリソースの読み込みと開放してまた再現するって事？
その処理を作ってテストするのが大変そうだなぁ…
所謂普通のセーブデータと共用できればマシそうだけど…
仕様にもよるけど、マップ画面でのbgmを元の位置から再生したい時とかも少し面倒だね。
イベントなんかの途中で戦闘が始まるようなのは復元するの大変そうだなぁ…
どんなゲームなのか判らないから一概には言えないけど、
メモリなんてせいぜい該当マップで利用する敵グラや音のリソースが＋されるだけなんだし、
そこまで気にする程でも無いような。
昨今のPC事情で考えたらCPUやメモリの容量は異常だよね。
10万満たない簡素なPCでも凄い積んでる。
ところがHDアクセスはまだまだ遅いんだよね。
だから前者でいいんでね？
> 戦闘画面を呼び出すのはマップ画面の中で関数呼び出す感じにするもんなの？
↓
> メッセージループ内でシーン分岐
要するにマップ画面に戦闘画面への遷移を固定化するコードを持たさないで部品化した方がいいよねって話かと。
方法はいろいろあって、FSM(有限オートマトン)やstateパターンでシーン単位で切り替えるのが有名だけど、
遷移を管理する側にごちゃごちゃさせたくないなら、マップと戦闘を保持したクラスを用意してやれば済む話だよね。
つーか別に仕様が完全固定化されてるなら戦闘からマップ直接呼んでもいいと思うよ。
あの手の技法なんて納期とか変更とかに厳しい世界の人たちが使ってる苦肉の策なんだしw
難しい事や汎用的な事は手段であって、それが目的化するよりはゲームが動くほうがいいよね。
それからこれも仕様によるけど、
所謂シーン単位での完全切り替えだとマップの上に戦闘を描くスタイルできないけどいいの？
あとエンカウントのアニメーションなんか必要な場合、マップ画面側にその処理だけが残るとかキモクない？
893:名前は開発中のものです。
11/07/14 16:32:39.19 0xB3ByY3.net
ふぅ…
894:名前は開発中のものです。
11/12/06 13:22:55.40 oDkZLgbY.net
あげ
895:名前は開発中のものです。
12/03/26 23:19:50.12 q+Fv8Yng.net
>>889
グラフィック関連はさすがに解放すると思う
でもドラクエみたいな2Dロープレなら何をどう作ってもメモリ不足なんてありえない
もう1つの質問の意図はマップ画面の下位に戦闘画面が来るか
それともマップ画面と戦闘画面を同じ立場において別途切り替える機構を作るかっていう問題だと思うけど
何らかのイベントやミニゲームなどで戦闘シーンを使う場合に上下関係が密接に関係してると
後で再利用しづらいのにで戦闘画面は独立させておいたほうがいいと思う。
896:名前は開発中のものです。
12/05/10 12:17:40.31 CvbrCj71.net
FFよりダンマスみたいなの作ってよ
いっとくけどMSX版の方じゃないよｗ
897:名前は開発中のものです。
12/08/23 21:04:32.49 8Fyjiw0F.net
MSXのダンジョンマスターをオンライン対応でリメイクして欲しいけど
スレ違いだし他力本願だねｗ
898:名前は開発中のものです。
12/09/07 19:10:16.76 M4WerZHY.net
あげ
899:名前は開発中のものです。
12/09/16 21:05:26.04 3z6vfuIt.net
ダンマスならRTC版じゃいかんのか？
900:あずにゃん ◆PaaSYgVvtw
12/11/29 18:47:56.93 T/exNI7l.net
c始めたばかりなのですが質問です。
tp//codepad.org/WsNDfYIs
これをビルドしたら実行結果が
a = 1
&a = 18ff44
*pa = 1
&pa = 18ff3c
b = 1
と表示されたんですが&aと&paが何故こう表示されるのか分かりません
16進数で表示される事は分かるんですが
printf("&pa = %04x\n",&pa);
実行結果が18ff3c
これが特に分かりません＾＾；
数学的に考えるとpa=&a;でアドレスがaに代入されるからaの16進数表示に
ならないんですか？
仕組みはよく分からなくてどなたか教えて下さい。
まずは基礎から勉強してるので宜しくです。
まずはｃからなのでｃ＋はまだ先のことですが＾＾；
ゲ制作も遠い道のりです。。。
901:名前は開発中のものです。
12/11/29 19:15:49.60 f6gZcj+t.net
paのアドレスじゃん
902:名前は開発中のものです。
12/12/01 19:58:04.77 CrVsmJCK.net
>>900
codepad.org/qZh2vLXf
903:名前は開発中のものです。
12/12/01 20:18:25.61 CrVsmJCK.net
>>900
ごめん、やっぱこっちで
codepad.org/UB5JFPnU
904:名前は開発中のものです。
12/12/28 09:37:26.68 8KDAkRIs.net
ズルするならマップでエンカウント直前のスクリーンを保持しておいて、戦闘画面の背景にあてれば出来るね。
動くマップチップで戦闘中も動かしたいなら見えてる部分をきちんとしたデータで渡して戦闘シーンで再構築しないといけないけどたぶん難しくないか。
やっぱマップと戦闘だと載せるUI違うから分けた方が見やすくなるんじゃないかと思ってる。
背景がマップだと戦闘場面が戦闘UIという意識でマップにのっかってるって感覚が強くなりそうだから一緒に書くのが自然に思えなくもないけど、
ほかのシーンは分けてるのにマップと戦闘はくっついてるというのは汎用的ではないような気がする。
でも面倒になったら分けない。
905:名前は開発中のものです。
15/10/16 10:06:10.59 c5lx3m67.net
>>1は消息不明？
DXライブラリだけど
俺もアクション、シューティングと何作か作って来たので
そろそろRPG作ってみたいんだけど、
膨大になるゲーム中の台詞を合理的に管理する方法が思い付かないんだよね。
それが解決するなら重い腰あげられそうなんだけど。。
906:名前は開発中のものです。
15/10/23 21:15:34.15 yK+GV+yo.net
あえて一度ツクールなりウディタなり触ってみればいい
907:名前は開発中のものです。
17/01/31 20:51:48.28 D6yECHIX.net
age