めちゃはややで
DXライブラリのソースコードを使って、ライブラリを作成せずに 例えば、真ん中に点を打つだけのプログラム とかを作成したいのですが ソースコードをどのようにいじれば良いでしょうか?
いや、何でもない。聞かなかったことに
よかった立ってた
スレ立てられなかったからどうしようかと
>>1 乙!
スレも立てられたし、ライブラリの正式版もバージョンアップされたな
DXライブラリは、汎用性上げるためにDLLで配布したほうがいいだろ。 コンパイラ別にするのは面倒だし。 ライブラリのアップデートに対応できないし。
8 :
名前は開発中のものです。 :2011/04/04(月) 14:58:40.04 ID:XwqulUWi
そうは思わない
自分みたいに、DLL形式じゃないから選んでるような人間も居るだろうしなあ。
どうせバイナリ配布するなら両方用意すればいいだけのことなんじゃない まぁ必要なものは自分で作ればいいんだけど
実はDLLでもLIBでも速度差はないらしいが。 windowsが上手いことやって。
総合アーカイバープロジェクトってあるだろう。 あれはほとんどDLLのみの配布だ。 バージョンアップされも、自作ゲーム・アプリの更新はいらない。
アーカイバとかは仕様がハッキリ決まってるものだけど、ゲームのライブラリはそういうのとは違うんだよ 仕様が100%確定でない以上、ゲームとその周辺のバージョンの管理は作者がやらないといけない 例えば、ライブラリ側で生成される乱数が変更されたら、本体のバージョンは変わらないままリプレイが再生できなくなったりする
うだうだ言ってないで自分で作れよ。 そのためのオープンソースだろ?
>>12 たぶん、DLLなら「DXライブラリがアップデートする度にビルドして配布」っていう手間がなくなるよ
って言いたいんだと思うけど、俺は逆だと思う。
DLLがアップデートされたら、配布中のゲームの挙動が変わったりして結構うざいと思うよ。
埋め込んでおけば、少なくとも挙動が変わる事がないからDLLが出る度に対応作業をしなくていい。
極端なことを言うと、新しいDLLが出る度に自作ゲームのテストをやり直さないといけない。
だから、開発者側でライブラリのバージョンをコントロールできないって結構大変だと思う。
統合アーカイバーの場合は
DLL→解凍処理そのもの
アプリ→DLLへのGUIを提供
というようにお互いに独立性が高い(特定のDLLやアプリである必要がない)。だから成り立っている。
>>12 統合アーカイバプロジェクトでDLL形式が使われてるのは
DLLを追加することでプラグイン的にソフトの対応フォーマットを
拡張できるようにするためだと思うの。
そういう意味では、対比としてその例を出すのは
あんまり適切じゃないと思うの。
あと、他の有名なゲーム用ライブラリであるLunaとかも
LIB形式配布だった気がするけど。
ってか君、前スレでも同じ事言ってなかった?
一定の需要があるのは確かだろうけどね。 DLL形式で再配布してるところ無かったか。
DLL+Cリンケージはかなり多くの処理系でサポートされてて簡単に別の言語から呼び出せたりするのが夢があって良い
作る側の都合としてはメリットあるんだけど 実質ゲーム遊ぶ人の視点で考えると 「わざわざDLLも入れないといけないの? ちょっと遊びたいだけなのに、面倒だからいらね」 となる危惧はあるなあ…
dll使いたきゃc#用使えばいいじゃん。dll自体はネイティブなんだし。
>>19 かと言ってゲームと一緒にDLLも配布すると、せっかくのDLL形式の利点の1つが無くなるしな。
サイズ節約なんて利点のうちに入らないと思うけど そもそもDLLのバージョンが違ったら動かないなんてザラだしユーザ側のDLLインストールとかに頼っちゃ駄目だろこの場合は
DxLib.DLLを別インストールするのは無しでしょ。 DXライブラリを使ったソフトが世間に大量にあるわけでも DXライブラリが数十MBの巨大ライブラリってわけでも無いのに。 DXライブラリに対する利点がほとんど無いよ。無用にユーザの環境を汚すだけ。
DXライブラリを使ったソフトって数えたら結構な数がある気がする
25 :
名前は開発中のものです。 :2011/04/05(火) 20:58:30.77 ID:rodxN/HH
7が汎用性とかイミフなことを言うから意味のない雑談が始まったな
作ったエフェクトがイチマチ暗いというか効果がなかったんだが 二重に加算したらすごくよくなった。 どうやら画像を拡大するときの補完の影響で、エフェクトが全体的に暗くなっていたらしい
二重加算は自分もやるけど、数を増やしまくったりすると結構重いな。 極端に古いマシンではないはずだけど、動画キャプったときにカクついた。
拡大すると二重に描画しなきゃならないなら、最初から拡大しておいて、 それを明るさ二倍にした画像を用意しといた方が軽いと思う 色飽和させたいなら別だけど
画像を大きくすると今度はメモリが圧迫されるから状況しだいかもしれん
30 :
名前は開発中のものです。 :2011/04/06(水) 20:24:44.37 ID:QYbzkIKn
class Picture{ public: const int handle; int x,y,width,height; //.. Picture(char* filename):handle(LoadGraph(filename)), //.. draw(){DrawGraph(x,y,handle,TRUE);} }; ってしたいんだが仕様のせいか描いてくれない 何か解決法ない?
そこだけ書かれても何も言えないYO
33 :
名前は開発中のものです。 :2011/04/06(水) 21:26:12.85 ID:QYbzkIKn
#include "DxLib.h" using namespace std; class Picture{ public: const int handle; int x,y,width,height; Picture(char* filename):handle(LoadGraph(filename)),x(0),y(0)){ GetGraphSize(handle,&width,&height); } draw(){DrawGraph(x,y,handle,TRUE);} };
34 :
名前は開発中のものです。 :2011/04/06(水) 21:27:15.55 ID:QYbzkIKn
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { DxLib_Init(); Picture p; p.draw(); DxLib_End(); return 0; } こんなカンジです
定義してるコンストラクタ呼び出されてないYO?
36 :
名前は開発中のものです。 :2011/04/06(水) 21:38:43.97 ID:QYbzkIKn
悪い俺のミス Picture p("test.png"); だ
DXライブラリの問題ではない もう一度クラスの使い方について勉強しなおしてください
コードが手元になくてうろ覚えで書いてる? 実際のコードを貼付けた方が確実。 このコードを基準に指摘するなら、 ・ハンドル格納先がconst intだから ・描画後に即DxLib_Endしてるから画面が見えてない
39 :
名前は開発中のものです。 :2011/04/06(水) 22:55:38.57 ID:QYbzkIKn
分かりました ご指摘ありがとうございました
ハンドル格納する変数がconstかどうかは関係ないぞ
41 :
38 :2011/04/07(木) 01:33:22.98 ID:IGrDi287
>>40 試したら確かにconstでも問題なかった。
C#とごっちゃになってた。済まない。
公式質問掲示板のスパムうぜえな
今DXライブラリの通信機能を利用して、クラスを渡して受信側のクラスにコピーするプログラムを組んでいるのですが どうやらクラスにstringやコンテナがあるとクラスをシリアライズしないといけないらしく、 boostのシリアライズと組み合わせて何とかできないかとがんばっているのですがどうしてもうまくいかないのです・・・ どなたか同じようなことをやっている人はいらっしゃいませんか? 送信側 Clarss A std::ostringstream test; boost::archive::binary_oarchive sou(test); sou << (const Class&) A std::string aaaa =test.str();; char* s = new char[aaaa.length() + 1 ]; strcpy( s, aaaa.c_str() ); NetWorkSend( NetHandle , &s, sizeof(&s) ) ; 受信側 〜(DXライブラリの通信サンプル) if( DataLength != 0 ) break ; } Class B; char a[255]; NetWorkRecv( NetHandle , a , DataLength ) ; istringstream is(a); boost::archive::binary_iarchive jyu(is); ←ここで領域外エラー jyu >> B;
DLLでの配布をいってたものですが。 LIBはvs2008、vs2010の差でも動かない。 ヘッダファイルで動的にDLLの関数を読み込めば、Windowsのほぼすべてのコンパイラで統一して動作する。 LIBとDLLを両方配布して、機能差に違いが無いようにしてほしいです。
45 :
名前は開発中のものです。 :2011/04/08(金) 09:12:48.77 ID:1Q+gaT6K
ダイナミックリンクの必要性がよくわからない いいことないぞ
むしろスタティックリンクの開発環境の限定がうざい
DXLIBって、初心者がC/C++でDXを使えるようにするライブラリじゃねーの? だから、ビルド時にスタティックリンクして、完結するようにしてるんじゃないのか。 大体、なんで作者が興味ない環境までサポートしてやる必要があるんだよ。 単なる自分勝手な欲求を、多数の利益みたいに言ってるんじゃねえ。
DLLになってうれしいのはDelphiやD、BCCだろうけど すでに廃れてるしな VC以外でどんな環境で使うの?
>>43 boostってのをしらんが
> char* s = new char[aaaa.length() + 1 ];
> strcpy( s, aaaa.c_str() );
> NetWorkSend( NetHandle , &s, sizeof(?
&sの時点でまちがってね?
ダイナミックライブラリも、スタティックライブラリも、同じに使えるようにして公開してほしいって事。 あと関数の動作はボージョンアップがあっても、インターフェースは固定されてた方がいいって事。
つまりクレクレ
どういうメリットがあるのか聞かれてるのに 自分の希望をたらたら述べるんだもんな こういう奴はマジで害だわ
必要なければ使わなきゃいいだけで 客観的に見れば要らないって言ってるやつらもただの保守厨 他のライブラリを見ても動的静的バイナリを両方配布するのは別に普通のことだし 初心者にとって無用な選択をさせたくないってのはわかるけど推奨と強制は違う
○○が簡単にできますよー!って仕様を変えたら、 自力でできない初心者の面倒みることになっちゃうだろ 今の状態でも出来る人は簡単に出来る。このくらいで丁度いいんだよ
なんでそんなにDLLに拘るのかがよくわからないけど…… DLLにこだわるのならソースコード公開されてるし自分でビルドしてみるという手もあるよ ついでにlibjpegとかzlibもdllで扱うようにすれば省メモリ性も上がるかもよ
だよな 欲しいなら作者に強請らず自分でやればいい
自分でやるのは意味が無い。汎用性を上げたらいいっていう主張な訳。 ローカルで、独自に開発を進めても、広く使われるようにならない。
イミフ、ゲームやる人間が全員DXライブラリのDLLをインストールするような言い方 MicrosoftのDirectXとかならまだしも、なんかものすごい勘違いをしているように思う。 それともゲーム本体のパッケージにはDLLを同封しないで 作者サイトでDLLをダウンロードしてね?ってスタンス? ゲームのパッケージにすべて同封させるならダイナミックライブラリだろうとスタティックリンクだろうと変わらないと思うけど。
おっと 言葉足らずだった。 作者サイトとはDXライブラリの作者さんのサイトね
自分でやれって言われてるのは、他の人がそれを需要がないと思ってるからなんだけど…… 需要がないものを実装しても広く使われるようにはならんよ
>57 それからDXライブラリをDLL化することで何についての汎用性がどのように向上するのか説明よろしく。 あなたの文章ではそれが少しも伝わってこない。
LIB版もDLL版も標準で配布して、ゲーム開発者がどっちでやるか選べた方がいい。
CRTが結局バージョン違いで読み込まれるぐらいならLIBで固定化でいいだろ。
会話になってねぇw
自作部分のコードの改変なくLIB版もDLL版もコンパイルできる。 全く同じ機能が使えてインポートライブラリ、動的読み込みしてもLIBと機能差が無い。 DLLを読み込める言語からすべての機能が使える。
いまの設計ではC#版からではVC++2008と全く同じ機能は使えないだろ。 関数の入出力インターフェースだけの問題で回避することは可能だろう。
賢いふりしたい馬鹿ですね?
全関数に渡ってインターフェースを見直して、ラッパーを作ればDXライブラリ本体には手を加える要はないがな。 初めから他言語のアクセスを意識していればよかった。次のバージョンは汎用性、統一性を重視してほしい。
>>49 確かに間違ってました。ポインタの扱いをもっとしっかり学ばなければ・・・
おかげで上手く通信することができました。ありがとうございました
DLL版で配布するとトラブルになる可能性がある 基本的に単一の実行ファイルにまとまってる方が安心 ユーザーサポートの時間が増えるのは厄介だな
あえてDLL版を使う必要は無いが。LIB版が使えない環境のため汎用性上げてLIBとDLLの統一化を。
多分だけど、それをやるとして、前提としてDLLは同梱するものだと思ってると思うよ。 スタティックリンクと比べて何が良いのかというと、VC以外の環境(基本的にVCでコンパイルされたlibファイルはVCでしかリンクできない)でDxlibの関数が使えるようになる。 それだけ。それ以外のメリットはメリットとして見ることは普通絶対にしない。トラブルの元なので。 VC以外の環境とは、他のC/C++環境はもちろんのこと、他の言語(DLLのC関数が使える言語は星の数ほどある)も含む。 個人的にはそういうニッチな環境で開発してみたいとも思ってるのでDLL版も欲しい
DLLは開発向けに使えないこともないんじゃない ちょっとしたテストやデバッグの繰り返しとか 大きいファイルをリンクする必要がなくなれば手軽に感じる人もいるかもな
DLL化&インターフェイスの改善がしてほしいってのはわかったし、それらに有用性があるのも確かだと思う けど、前者はともかく後者は作者さんに頼むはちょっと現実的じゃないから DXライブラリPortableみたいに外部に派生プロジェクト作ってみたらいいんじゃないかな
具体的にどういう環境で開発してるんだ? VC使ってないならもともとこんなんに興味持つとも思えないのだけど
仕事で別の環境を使ってて、それに近づけたいとかなのかな。
自分も似たようなことやってるけど、頭と手の切り替えが面倒くさい。
>>75 >VC使ってないならもともとこんなんに興味持つとも思えない
「VCだからDXライブラリを使う」っていう人は、そんなに多く無い気がするけどなあ。
Win環境でゲームを作りたいと思ったときに、有力候補としてDXライブラリがあり、それがVC対応だったって言うだけだろう。
DLL化は場合によっては有用だとは思うけど それは作者の仕事ではないとも思う オープンソースであることの意義は 不満があれば自分で改変できる点 DLLにしたいなら、自分でやればいいのでは? もし、その作業が面倒だと思ったら その面倒を他人に押し付けてる事を理解するべき
CSVファイルなどから2バイト文字を読み込むことは出来ないのでしょうか? FileRead_getc()関数ではなく、FileRead_gets()関数を使用すれば2バイト文字でも 読み込めますでしょうか?
FileRead_gets()で読み込めますですよ FileRead_getc()はリファレンスの書き方がちょっと紛らわしいかもね アレは結果的に一文字読むことになるけど、単に1バイト読んでるってだけ
>>74 DLLとLIBで関数が違ったら価値が減る。コードの変更なしで両方コンパイルできることが大事。
なんでlibとdllで関数が変わるの?
DLLだと関数名が違うからな こいつの言うことも分からなくはないが、 大した需要が無い反面、作者への負荷がでかくて大したメリットもない まあ、やるか決めるのは作者だし、 あったらいいね、くらいしか言うことないわ
関数名が違うってどういうこと?詳しく教えて
関数名が違うって意味がわからないし作者にかかる負担も大きいとはとても思えないんだが
同名でラッピングしてDLLにしてヘッダファイル書いて DLLは暗黙的、静的リンクするようにして VCのCRTみたいにリンクするライブラリを切り替えるだけだろ。 全部自分だけで出来ることじゃないか。
確かに意味が分からない。 DEFファイル使わないってことか?
関数名が違うって、今配布されてるDxLib.dllの話な
そういう意味か、ていうか何度も言われてるが。オープンソースなんだから 自分でDLLビルドしろよ。 VC++だって無料で配布されてるんだからできるだろ。
面倒くさいっちゃ面倒くさいけど、 不要な機能を削るといったカスタマイズを並行して行うつもりなら、そこまで手間じゃないかな。
90 :
名前は開発中のものです。 :2011/04/10(日) 19:30:45.16 ID:/WvqFBq9
元の主張だと「世の中全部のDXライブラリアプリがDLLを共有すれば重複してる分が節約できて幸せだよね」 ってことだと思うけど、ゲームなんて同時に実行することはほとんどないし 今どきのHDD容量だとDXライブラリのDLLなんて屁みたいな小ささだから気にしても仕方がない 以上のことからDLL化は意味がない
は?だから容量節約なんて誰も考えてないっての
関数名が違うっていったって、先頭に dx_ が付くだけじゃないか。 そんなにウダウダ言うほどのことなのだろうか?
流用できないことが問題点なんだろ
dx_つくのは公式で配布してるC#用のdllだけの仕様だから 自分でC++からDLLとしてビルドすれば関数名が違うなんてことはないよ
C#用だと関数名が違うのか。知らなかった。 なんか理由あるのかな、
DXライブラリは3Dが弱いといわれているみたいだけど 管理人さん、やっぱ3D機能の強化をしていくみたいだね。
あくまでグラフィックライブラリとして強化していくのかな 2Dゲームエンジンとして進化するかと思ってたけど
>>97 2009年9月に初めてDirectX9と3Dに対応したって時代遅れも度が過ぎる
未だに3D機能弱いとかお粗末だな、外国では5年以上も前に3DのSDK沢山あるっていうのに
何でこんなものが日本のアマチュアに人気なのかわからん
>>99 日本製で日本語のドキュメントも豊富だからに決まってんだろ
なんでわかんないんだよ
>>99 DXライブラリに3D機能が求められてないからだろ
小学生レベルの知能かお前は
初めて作るゲームがいきなり3Dとかはあんまり無いからな 2Dのゲームを作るのにDXライブラリが役立つからだろ…
3D酔いするから、3Dグリグリのゲームはだめだわオレ SFCのマリオカートですら酔うんだぜ・・・
作者さんは、2D機能はもう十分完成しているという考えなのかも。 だから3D機能の拡充に動いてるんじゃないかな。 あと、ゲ製で海外とか外国とか言ってるレスはスルーが吉。
2Dゲームでも3Dデータ使うこと多いし求められてないってことはないだろ
107 :
名前は開発中のものです。 :2011/04/12(火) 19:11:07.88 ID:gm9+f4H+
残念ながら日本製のゲームライブラリではdx以外選択肢はないきがする pygameとかのほうが使いやすいんだけどはやりそうにないし 日本語資料が豊富かどうかが重要だと思います ライブライぐらい自分で調べろ そういわれてもこちとら趣味なのでそこまで必死になって プログラミングしたいわけじゃございません
>>107 DXライブラリ製の3Dの惑星シミュ?
よぅわからん
>>108 pygameってコミュニティあるの?
日本語か英語でいいのがあったら教えてくれ
CでもDirectXでもライブラリでもない スレチにも程がある
よくかんがえるとそうだな ここは有数のライブラリの中からDXライブラリを使うことを選んだ人が語り合ったりするスレだったな……
まぁ、IronPythonならDXライブラリを使えるけどな
プログラミング初心者丸出しの質問で申し訳ないんだけど、DXライブラリの中身って結構高度なのかな こういうライブラリも(つくろうと思えば)自分で作れるくらいの技術がないとプロにはなれないんだろうか
>>114 DXライブラリレベルのライブラリを作れるようになる必要はない
けど、少なくとも自分が欲しい機能を持っただけのライブラリは自作できないとウチの会社では採用しないよー、
って、知り合いのそれ系プログラマーが言ってた
その人も趣味ではDXライブラリ使ってるんだけどね
>>115 遅くてもいいから自分でDXライブラリと同じような機能を実装できるようになればって感じなのかな
参考になったよ!ありがとう
DXライブラリもどきを目標に勉強するよ
>>114 ライブラリに頼らないで開発できるようじゃないとプロは厳しいぞ
特にコンシューマは、DirectXすら使えないし、CPU制御やハードウェア知識も要る
初心からこんなライブラリに頼ってる奴はメモリ管理なとのきちんとしたプログラム作法身に付かないからプロから嫌われる
プロ目指すなら楽を覚えちゃいけないよ
まともなfps管理を導入したらすごく安定してワロタ
定期的に出てくるな、こうやって脅しつける奴
で、FPS管理はどうやるのが正解?
いや、俺がアホだっただけなんだ。 1フレームごとに処理時間を計って、スキップ判定をしていたのを 10フレームごとの平均処理時間を計って、その平均処理時間がお望みの値になるまで 描画スキップするという処理にしたら、とても安定したんだ。
「そのフレームの処理時間」の部分を、 まるっと「過去10フレームの平均処理時間」に置き換えたと。
123 :
名前は開発中のものです。 :2011/04/14(木) 18:09:18.15 ID:MaJ4GcR6
ファイアーエンブレムみたいに四角のユニットを動かしていくゲームを作っているんだけど 移動範囲を描画するのに何か良い方法、というか方針的なものを教えてくれまいか… 2次関数x,yに◇の領域で、 y > x + a, .y < -x + .... のとき描写とかしてたんだが… 障害物とか敵があって通り越せないとか、回り道とかでもうだめぽ
移動可能なマスを予め計算しておいて配列に記憶しておく。それをただ描画する。 再帰とか使って一マスずつ移動するのをシミュレートすると楽。
やはりシュミレートれすか… 再起全然わからない…勉強しまふ…
画像処理でのペイントアルゴリズムと同じだろ
フラッドフィルアルゴリズムだな
前スレ
>>919 さん、DXライブラリでのgifアニメの再生の件、
教えていただいてありがとうございました、再生できました。
諸事情でお礼が遅れてしまいすみませんでした。
DXライブラリを使おうと思っているんだけど スーファミくらいのゲームを実行できる速度なの? それの起動時間ってどれくらい? 教えてくださいおながいします
エミュレーターじゃねぇよ
パソコンの環境にもよるけど余裕だろ。 起動は一瞬だけど遊べる段階に行くまではローディングの仕様による。
>>133 DXライブラリ使おうと思います
あざました
アンチエイリアスきた。
なんか最近紹介ページが賑やかになってきてるな 段々流行ってきてるのかね
紹介だけじゃなくてゲーム自体もアップできればいいのに
サーバが死ぬw 自サイトへの誘導がメインだと、サイトも見てもらえるし今のままでいいと思うけど
描画関数の並び順を入れ替えるする方法をしりたいんだけど クイックソート?する方法が分からない とある掲示板でも同じような質問があったんだけどチンプンカンプン
めんどっちいからソートの為だけに配列にvector使ってる自分
Cのライブラリにqsortってのがあるからそれを使う。関数名で調べるといいよ。
クイックソートなら標準ライブラリにあるやん
…y座標が大きい順に並べたいんだけど、どうやって比較しよう? 今までは単純に数の大きさでソートしてたんだけど 画像って描画する為に一つ一つ違う変数を使うじゃん? それの比較の仕方が分からない 配列を使うのか? 教えてくだちい
違う変数を使うって、同じ変数をどうやってソートしてたんだよ
int GetGraphSize( int GrHandle , int *SizeXBuf , int *SizeYBuf ) ; この関数を使えば読み込んだ画像のxとyが得られるぞ
すいません 100%私の言い方が悪かったです 具体例をあげます LoadGraphScreen( ch.x , ch.y , "test1.bmp" , TRUE ) ; LoadGraphScreen( tk.x , tk.y , "test2.bmp" , TRUE ) ; この2つのy座標を比較する方法を知りたいのです
多分、自己解決しました
やっぱり自己解決してませんでした 2つの関数のy座標だけを比べて並び替える方法を教えてください
ch.yとtk.yを比べたいのかch.y+test1とtk.y+test2を比べたいのか
ch.yとtk.yを比較して関数の並びを入れ替えるということです
普通は座標やグラフィックハンドルを一つの構造体に入れて、その配列にqsortをかけたりするんだけど
構造体が分からないと流石に難しいだろうな
座標をソートすれば関数自体がソートされるのでしょうか?
LoadGraphScreen( 10 , 10 , "test1.bmp" , TRUE ) ; こういう風に直接数字を入れてる?
いいえ、yやxといった変数で表示しています
言うまでもなく、座標をソートしても関数はソートされない せめてソートする座標と画像の情報(この場合は名称?)を関連付ける必要があるよ だから素直に構造体を学びなさい
変数にしてるならx[loop]みたいな感じでできそうだけれども
Cの勉強はしたので構造体は分かるのですが 関連付けってのがよく分からないです せめて関連付けのヒントやサイトを教えてください
関連付けは別にプログラムとかじゃないよ。ただ座標を構造体の変数にするだけ
typedef struct{
int x;//x座標の値
int y;//y座標の値
char *name;//画像の名前
}TEST;
TEST base[2];
for( i=0; i<10; i++ ){
LoadGraphScreen( base[i].x , base[i]y ,*base[i].name , TRUE ) ;
}
こんな感じ。ソートは
>>146
なるへそ
なんでfor文があるんですか?
multimapでfirstをY座標の値、secondを構造体かクラスのポインタ
配列の各要素にアクセスするためとしか言いようがないな ちなみに要素数が2なんでfor( i=0; i<10; i++ ) はfor( i=0; i<2; i++ ) になるはず
ID:OCzKiVRH、小学生だろこいつ 基本的な文くらいできるようになってから来いよ…。 もしくはなん質でも行け。
そのとある掲示板がなん質かなんかだったと思う。昨日見た。
ID:OCzKiVRHはpredicateがわかってないか忘れているだけじゃないかと予想
要素数2だけでいいのか? 2なら簡単だけど多分違うんだろうな 違うという前提ならやはり構造体かクラスに座標情報を持たせて それらを配列なりリストなりにして ソートさせて表示でいいんじゃないの
>>167 まぁまぁ
初心者がいないとスレも過疎るじゃん?
できるできる
え?だって質問者はy座標で関数を入れ替えたいんだろ? qsortってのは使ったことないんだけどできなさそうなんだが
使ってみれば分かるんだけどね・・
qsortは要素の比較関数ってのを自分で作って渡すんだけど、その関数にY座標の比較を入れればそういうふうにソートできる。
y座標を比較すれば構造体のおかげで関数も自然に入れ替わるってこと? qsortは使ったことないんだけど …おかしいこといってたらごめんってことです
質問が難しいな 関数入れ替えたいってどういうことなんだろう
Cの勉強をしたって書いてあるけど、経験が無くて使い方がわからないんじゃないかと推測。 彼はプログラムの概念をわかっていないように見えるし、レスもよくわからないから的外れだったら申し訳ない。 たぶん彼が言いたいことはこう。 まず以下のように書くとA、B、Cの順で描画される。 LoadGraphScreen( A.x , A.y , "A.bmp" , TRUE ) ; LoadGraphScreen( B.x , B.y , "B.bmp" , TRUE ) ; LoadGraphScreen( C.x , C.y , "C.bmp" , TRUE ) ; けれどもこの時y座標の大きい順に描画したい。 例えばC、A、Bの順に大きかったら、以下のようになると良し。 LoadGraphScreen( C.x , C.y , "C.bmp" , TRUE ) ; LoadGraphScreen( A.x , A.y , "A.bmp" , TRUE ) ; LoadGraphScreen( B.x , B.y , "B.bmp" , TRUE ) ; つまり、彼は描画順序を入れ替えたいんだけど、その手段としてソース上で順序を入れ替えないといけないと思っているんじゃないかな。 二つに限定して、且つ超初歩的にやればこれでいいんじゃないの? もちろん配列でソートでって方が汎用性高いのはわかってる。 if(ch.y > tk.y){ LoadGraphScreen( ch.x , ch.y , "test1.bmp" , TRUE ) ; LoadGraphScreen( tk.x , tk.y , "test2.bmp" , TRUE ) ; }else{ LoadGraphScreen( tk.x , tk.y , "test2.bmp" , TRUE ) ; LoadGraphScreen( ch.x , ch.y , "test1.bmp" , TRUE ) ; }
それならLoadGraphScreenじゃなくてLoadGraphにして グラフィックハンドル使うようにしたほうがよくね?
>>181 ああ、書き方が悪かった
先にLoadGraph覚えたほうがよくね?と
でも絵を描画する為にわざわざ構造体を使うだなんて面倒くさいな もっと簡単な方法があればいいんだけどね
3D機能のZバッファとかなんとかで適当に何とかなんないかな?
>>184 それでも半透明含む画像なら描画順ソートしないといけないからなぁ
>>183 は訂正
わざわざ構造体を何度も使わなくても良かった
>>179 質問者の意図を理解できた! ありがとう>179! お前さん凄いよ!
そんなもんみんな気付いてたことなんじゃないの
ソース公開したら簡単に解決したと思う
>>188 関数の入れ替えってあたりの文面がどうも意味不明で
質問の意図を理解できてなかったんだ
なんかいろいろ勘違いしてるんだろうなーでも触れるとめんどくさそうだなーと思ったから誰も触れなかったんだよ
文字を回転や拡大させたかったら文字の画像を作るのが一番なのかな
そうだな
>>160 わ、分からない…
描画関数の分だけ構造体つくればおkなの?
はい?
「関数そのもの」と「関数呼び出し」と「ソースコードの一行」を使い分けろ
はい?
関数のぶんだけというか描画する画像の分だけ構造体をつくるんだな
手続きか
CとC++勉強してから出直してきなっ が正解だと思う もしくはゲームの基本設計
画像をロードしてから、
DrawGraphやDrawExtendGraphといった複数の描画関数を使ってることだよね?
そしてこの場合、単純に
>>160 の方法では無理なんじゃない、って話?
俺は経験薄なんでこれがまともな方法か分からんが
どの描画関数を使うかのフラグと、全ての描画関数に対応したメンバを持つ構造体を作って
それに次々に値を放り込んだ後、ソート→フラグに応じた描画関数で描画、という流れにするかなぁ
描画系関数って、上位互換/下位互換的な関係のものが多いから (例:DrawGraphで出来る描画はDrawExtendGraphでも可能) どれぐらい複雑な描画をしたいか、に応じて使う関数を決めれば良いと思うよ。
>>203 流れから言って
>>195 はド初心者だ。
描画関数っていうのはLoadGraphScreenのことだと思われる。
プログラムを教えるときに初心者の説明が正しいと思って聞くことがまず間違い。
まずLoadGraph覚えて DrawGraph等の描画関数使えるようにならないとだるい
>>203 ありがとうございました
おかげで解決しました
今までファイル読み込み関係の関数の存在意義がわからなかったのだが もしかしてこれを使わないとDXアーカイブ内部のファイルが読めない?
んだねー
製作中はアーカイブにせずそのままだろうから いざ最後にアーカイブ化してそのことに気づくというパターンはありそう っていうか俺も今気づいた。 アーカイブにしたら動かないだろうな
>>211 DXアーカイブの強みは、DxLib内の関数のみを使用している意識せずに使えることなんだけど…。
ちゃんとリファレンスを読もう。
今日は起きたばかりなせいか文章能力がだいぶ欠落してるなw
>>210 用と為被ってておかしいのと、
>>212 DxLib内の読込関数を使用していれば意識せずに です。
ごめんなさい、許して。
ゆるしますん
ゆるせませんん
スンスンスーン
FireRead_readをC標準関数のreadと同じ感覚で使おうとしたら 痛い目にあったことを思い出した。
FileRead_readをC標準関数のreadと同じ感覚で使おうとしたら 痛い目にあったことを思い出した。
生まれて初めて2重書き込みという物をやらかした。 すまん。
気にするな
どんまいだ
責任を取って死ぬべき
>>212 製作中はアーカイブにしないから
標準の読み込み関数を使ってしまって
そのためにアーカイブ化すると動かなくなるということ話ね。
>>223 あぁ、何も考えずに勝手に手が動いちゃってみたいな意味か。
>>203 それだったらクラスでスッキリ解決するのでは
自分もそのパターンだなあ。 俺用フレームワークを作ってる人は多いと思うけど、 拡張しながら使っているとは言え、新しい機能とか部分的に対応してなかったりするんだよなw
64bit版ライブラリを作ろうとしてソース調べてたんだけど DxWin.cppのWM_MOVEShred関数の WinData.WindowRect.left = ( lParam << 16 ) >> 16; を筆頭に変な書き方をしている部分が多くて挫折しそう
固定小数点の変数として見てて 上位16ビットを捨てて小数点以下にしてるとか?
いや、lParamが32bitだと仮定して16bit左シフト16bit右シフトで 上位16bitをクリアしようとしてる 当然lParamが64bitであるx64では破綻する むしろ符号拡張絡みで32bitでもやばい気がしないでもない Windows的にはHIWORD,LOWORDマクロで取り出すのが正攻法
>>229 公式で指摘してあげたらいんじゃね?
管理人さんも万能のスーパーマンというわけではないのだから
結局、質問掲示板のほうに言ったか 向こうも大混乱だな
>>230 ネイティブ64bit対応なんてこのライブラリのユーザ層からして需要がないから
公式には書きにくくてね
ネイティブで64bit対応するとどういう得があるんだっけ?おしえてくだちい
開発側が32bitを切りたいと思ってるなら役立つ? 少なくともXPは全滅しそう。
メモリコピーがちょっと早くなるだけ?それってそんなにいるの?
龍神録のHPのゲームプログラミングの館が一新されてる
あ、古いのは下側にあったわ
初心者が詰まりそうなトコが個別に分かりやすくまとめられてるな ナイスだ
おおおおお
SNS設置してねーわとか思ってたけど無くなったの? やっぱり不評だったんだな。 まあ個人サイトをここでとやかく言うことではないか。
mixc++とかいうのがバーンとあるじゃん
いや、前はSNSだったけど今はForumになってるみたい。
あれはフォーラムにしてSNSだよ
このゲームはDXライブラリ使ってるとか分かる方法ありますか?
何か根本的な勘違いをしてる気もするが……まあいいや。 Log.txtとDXライブラリ用アーカイブあたりで判別できることはある。 あとreadme
そのゲームのexeをメモ帳で開いてDxLibで検索してみ
ふと思ったんだが DXライブラリでつくられたゲームで売れているのってあるか?
>>248 有名なのはディアドラエンプティとかかな
売れてるかはわからないけどアナザーアポカリプスってのも評判良かった
あと東方二次創作ではDXライブラリ製が結構多い
全部シューティングか
ロックマンみたいなやつもあったね
>>251 あーそれ、さっきまで遊んでた
フロイデンシュタヘルとかいって喋るやつじゃない?
Rosenkreuzstiletteだね あと古いゲームだけど、だんえたもそこそこ売れたんじゃないかな 調べてみるとフリーで有名なゲームにもDXlib使ってるのがちらほら
SetAlwaysRunFlagをTRUEにして、GetActiveFlagがTRUEの時に キー判定をするようにしても、VC++がアクティブ時だとキーが 反応してる気がする
VC++が親プロセスになってるからかな? 単独で動かしたときはどうよ?
DXライブラリからSeleneに移行したみたいな人っている? 3DならSeleneがいいみたいな話を小耳に挟んだのでちょっと興味が沸いた
2.xの頃はたまに聞いたけど今はどうなんだろう
DXライブラリに慣れてるならそのままがいいんじゃないかな 感覚そのままで3Dに以降できるし 昔selene使ってみようとしたことがあったけど、 色々用意されすぎてて独自ルール満載のseleneプログラミングを勉強しなおす事になっちゃう
ちょっと見てみたけど確かに難しそうだったな。 やっぱ慣れてるほうのがいいか。ありがとう。
dxライブラリで物足りなくなったら大人しくdirectx直叩きに移行するかなぁ
やっぱり読み込む画像のサイズが小さい方が描画速度が速いようだぞ 画像を読み込むときに画像を16x16毎に分けて個別に配列に格納して描画するようにしたら めっちゃ早くなったわ。処理を見直すよりよっぽど効果があるわ。 画像が小さい方がビデオメモリに画像データをキャッシュさせやすくなるとかなのかな。
例えば横513ピクセルだと1024まで拡張しちゃう的ななにかかもしれない
なんでソフト屋様がハード仕様を意識してコーディングしないといけないんだよふざけんあよ
高級言語プログラマ様はお偉くていらっしゃるw
と思ったけどDxライブラリってそこ勝手に分割してくれるとかなんとか フラグ建てないとだめなんだっけ?そんな感じの記述をどっかで読んだ覚えが
というよりそんなことしないといけないような重いプログラムのほうが問題だったりしないか
軽くできるなら軽くだぜ
DXライブラリの通信プログラムを触ってゲームつくりたいんだけど 詳しく載ってるサイトない?
軽くできるならそうすべきだけど、他に原因があんじゃね?って話だよな 普通に考えるとBlt回数減らした方が早いと思うんだけど
いや16x16のマップチップを画面左上から右下方向に順に画面全体に表示させるということをやっていて、 マップチップ画像全体を読み込んで表示位置をIDに従って切り替えるんじゃなくて 16x16毎に画像を切って読み込んだら早くなったっていうことなんだけど、 Blt回数減らせるかね?
>>270 以前は一部だけ描画する関数を使ってたってこと?
それなら比較すれば早くなるだろうけど
>>271 マップチップ画像の事をマップ画像だと思ってる?
マップ画像は持ってなくて、マップチップ画像からチップIDに従って16x16を抜き出して適切な位置に表示してる
描画回数はどちらも(ウィンドウの幅/16)*(ウィンドウの高さ/16)回ですよ
DrawRectGraph? それとも1マス毎にDerivationGraph+DrawGraph?
DrawRectGraph
マップチップ画像をLoadDivGraphで分割読み込みすればDrawRectGraphより速くない? あ、でもマップチップ画像が2のn乗サイズじゃないと重いかも マップチップ画像のサイズは幅・高さ何?
大きな画像があってそれを分割転送してるのかと思って。マップ並べる話ね。ごめん 俺はLoadDivGraphだと元画像でチップの境目がわからなくなるので、 普通にLoadGraphしてDerivationGraphでチップに切り分けるLoad関数を作って使ってる 線引いて格子状にした上と横に番号振った画像用意すると、どこに何が割り当たってるのかわかりやすいので
格子&ナンバリングした画像を用意するのと、LoadDivGraph云々の関係が分からなかったorz
>>277 LoadDivGraphだけで画像分割ロードを一括して行なった場合
画像内全てに対して切り出しを行うから格子だのナンバリングだの落書きできるスペースがない
でもLoadGraphしてDerivationGraphした場合は好きな場所から切り出すことができるので
画像内に落書きしてあっても利用したい画像同士が離れていても問題ない
この話ってすごく有益な情報じゃね? なのにこんがらがってよくわからん…
なんとなく分かったような分からんような。 画像を出してくれれば一発な気がする。
最初っから言ってることは理解できるけど、 それをやる意味が理解できない。 配布するときは画像差し替えるのか? 面倒だし意味なくね。
改善前と改善後のコード貼ってくれよもう お前の脳内を知ってること前提で話しててわけわからん
たぶん、本人の糞コードが一部書き直したら改善されたんだが 本人はなぜ改善されたのかを誤った解釈をしている、というパターン 有益な知見は含んでいそうにない
あなたはすごいエスパーなんですね
286 :
280 :2011/05/09(月) 20:00:02.26 ID:cCCnXiw+
画像の方にばかり意識が集中してて、
元々の話題がコードを修正したら速くなったって話だったのを忘れてたぜ!
>>281 なるほど、実際に使う機会があるかどうかは別として
確かにLoadDivGraphじゃ難しいな。
ペイントツールのレイヤーで対応できることだな 素材レイヤーだけを出力するだけだし
こんだけ説明してんのになんでわかんないんだよ馬鹿か。 読み込む画像サイズが小さい方が高速化するからもともと256x2560(適当)とかのサイズのマップチップ画像を 16x16の小さい画像にプログラム内部で切って分割して読み込んだら早くなったってことだろうがよ。 あと俺はBlt回数減らせるかね?と質問してるわけだが答えてないよね。
min(縦幅, 横幅)を超えない最大の2のn乗サイズの正方形を使えばちょうどいいんじゃないかな
そうだといいですね。
Bltとか言ってるのに内部でどういう処理してるのかわかってないように思える 「大きいサイズのマップチップ画像を読み込んでた」のと 「16x16の小さい画像にプログラム内部で切って分割して読み込んだ」っていうのが具体的にどんな処理の違いなのか、 抽象的というか>288の脳内でのみの定義を前提にしてるから理解しにくいんだよ ちなみにブリットに関しては何も変わらない というかこの場合全く関係ないし 正直串の人は頭良く見られてたい馬鹿にしか見えないにゃー やきとりもぐもぐ
あっそ。俺の問題は解決したからもうどうでもいい。 情報を提供したところで俺には何のメリットもないし。
DXLIBはもう覚えてないけどたしか配列にして画像ロードするやつでしょ? uv座標の計算をあらかじめしておくだけで画像は分割しないと思うよ。 同じ画像を繰り返し描画(描画時にUV座標で一部を切り出す)をするのが drawIndexedPrimitive()で速いんだから。
正直、全然意味がわからん 1チップが64*64ピクセルで、512*512ピクセルのBMPファイルに8*8チップ分描いた場合、 通常は 「64*64を1チップとして切り出し、ハンドルを64(8*8)個作成する」 が、 「1チップをさらに16分割(4*4)し、ハンドルを1024個(32*32)作成する。描画時は16チップを一まとめに扱う」 ってことか?
まあ串は何か馬鹿なミスをしてたんだろうね
ソースコードがわからないから なんとも言えない が正解
バカっぽいからバカなミスしてたんだろう が正解
あー、ソース見てみたいね 処理時間比較の結果とかも見たい
ソースみなくてもDirect3Dの仕組みから見当つくだろ 内部がDirectX9なら
言いたいことが何となく分かった
LoadDivGraphだと分けたい画像を同じ大きさの奴を左上からびちっと並べなければならないのを
DerivationGraphだと好きな所切り分けられるから例えば
>>281 のように分割対象の画像を作れるような自由度があるってわけか
VRAMが勿体無いから普通はみっちり詰めちゃうけどね
描画時に好きなところ切り分けられるってことは 描画時にUV座標の計算をしているってこと。 画像ロードしたときにUV座標の計算して固定したほうが 割り算いくつか分だけCPUが効率的だけど高速化といえる程ではない。
おまえら何が言いたいんだ? 話題が一本筋通ってそうで良く見えないんだが
細かいことよりまずはゲームを完成させるのが一番大切ってこった
>281のような画像に対応したLoadDivGraph()を作ってみようかな。 使う機会は今のところないけど…
ハードウェア的に高速化するって言ってるのにCPUがどうとか言って全然理解して無いじゃん そもそもLoadDivGraphとかDerivationGraphとか俺は言い出してないし。言い出した奴に聞けよ
俺言ってないしとか誰だよこいつ
串くんの話題と画像の格子とかの話題と2つ同時に進行してたしね どっちも画像分割っていう共通ワードがあったからこんがらがりそうだけど
串くんて何って思ったけど今ようやくわかった。 おい串やろう! 俺は画像の格子の方にレスしてたんだよ。 お前の画像のサイズだがMSDNによるとD3Dでは 256x256 or 512x512に最適化されてるらしいぞ。 わかったらキンタマに串刺して寝ろ。
>こんだけ説明してんのになんでわかんないんだよ馬鹿か。 >読み込む画像サイズが小さい方が高速化するからもともと256x2560(適当)とかのサイズのマップチップ画像を >16x16の小さい画像にプログラム内部で切って分割して読み込んだら早くなったってことだろうがよ。 >あと俺はBlt回数減らせるかね?と質問してるわけだが答えてないよね。 D3Dでテクスチャを生成するにあたり2の乗数で正方形であることが望ましい。 またビデオカードが高性能であってもD3D9ではテクスチャサイズは2048x2048 ぐらいが限界になっている。 憶測だが、おかしなサイズでテクスチャを生成すると ビデオメモリではなくシステムメモリからテクスチャを 生成して遅くなると思う。
わかったら肛門に串刺して寝ろ。
つーか、当たり前すぎて即レス付いてるじゃん。 512x512をLoadDivGraphで16x16分割で読み込むのと、 個別読込とで比べて結果とプログラムをアップロードした方が早い。
自分で場合分けして、どっちが早いか検証しない時点で お脳の程度が知れるっちゅーことよ
串w逃亡ww雑魚すぎwww
煽ってやるなよかわいそうだろ
親切心で情報提供したつもりだったのかもしれないけど 指摘が無かったら誤った情報を発信してしまうところだったね ×同サイズの画像は一つの画像に並べてLoadDivGraphするより個別のファイルにして読み込んだほうが描画が速い ○同サイズの画像は一つの画像に並べてLoadDivGraphしたほうが個別のファイルにして読み込むより描画が速い
DirectXでの質問です 通常、ビュー変換を行うと視点の中心がそのまま画面の中心になると思うんですけど 視点の中心を左にずらし、周辺視野部分を画面の中心に持ってきたいんですけど どうしたらいいのでしょうか ワールド座標系で変換しても上手くいきません ビューポートの矩形領域を横に広げてウィンドウ上の描写位置を左にずらすという方法も考えたのですが そうすると他の問題が出てきてしまい上手くいきませんでした
個別のファイルにして読み込むとか誰が言ってんだよ 俺はこうとしか言ってないし >16x16の小さい画像にプログラム内部で切って分割して読み込んだら早くなったってことだろうがよ。
ああ、288でそう言ってるね 261や270の説明だといまいちどっちなのか分からなかった まあ、プログラム内部で切る手段がDerivationGraph以外にもあるから288も誤解を招く可能性はあるけど
>>318 マルチポストするような人には答えません
>>321 あなたはどっちにしろ答える気は無かったでしょう?
或いは答えられなかったか
やっぱりマルチポストするやつって精神的におかしいんだな。
マルチポストするやつは掲示板の先にほかの「人」がいるって考えがないからね。 認識的には「便利な道具」。 まぁ、それも間違いじゃないんだけどさ。
>>324 じゃあどうすればよかったんですか?
以前に書いたスレは過疎スレだったのでこっちに書き直したんですけど
これって変な事なんですか?
そもそもここがDirectXのスレじゃない DXライブラリ≠DirectX
別のところで質問してきます、って書けばいい。 質問スレよくある展開だよ。 「誘導されてきました」ってのもよく見るね。
>>325 過疎っていたのでこちらで聞きたいんだけどって付け加えればいい
問題の解決方法を聞くときには状況だけじゃなく経緯を説明したほうが何かと捗るぞ
>>325 書き直す際にどのスレに移動するか明記しておけば
そのスレでの質問を〆たことにもなるし、知ってる人がその書き込みを見たときに
移動先で返事をしてくれることもある。
そうすればマルチポストじゃなく趣旨に合うスレに移動したって伝わるし
書き込んだ全部のスレを自分で見て回る手間も省ける。
当然マルチポストが嫌いな人への心証も壊すことがないんで
より回答を得やすくなるよ。
最初のスレでは「レス付かないので○○で質問します。ありがとうございました。」 新しいスレでは「○○で質問しましたが、レスがつかなかったのでこちらで質問させていただきます。」 これならまず怒られない。 常識的に物事を考えられない年齢で知らない人に質問なんてするもんじゃないよ。 小学校や親から何を教わってきたのか…。
DQNの親はほぼ確実にDQN
>>325 どうすればよかったのかちゃんと聞いたことをオレは評価する
なるほど、必要な一言があったわけですか
>>327-330 すみませんでした
以後気をつけます
甘いぜてめーら!
>>334 ちょらぁーーー!!1
もっともっと反省しる!
ふぅ……ちょ〜気持ちいい〜♪
すいませんみなさん、
>>335 には俺がきっついお仕置きしときます
主にアナルに
>>334 まだ見てるか分からないけど
中心を左にずらすってことは、カメラを右に平行移動したい
という解釈であってる?
であれば
float fov = D3DX_PI / 4.0f;
float height = 480.0f; //描画する矩形の高さ
float X = 100.0f; //これがカメラの移動量
D3DXVECTOR3 vEyePt = D3DXVECTOR3( X, 0.0f, (height / -2.0f) / tan(fov / 2.0f) ); //カメラの位置
D3DXVECTOR3 vLookatPt = D3DXVECTOR3( X, 0.0f, 0.0f ); //カメラが映している位置
D3DXVECTOR3 vUpVec( 0.0f, 1.0f, 0.0f );
D3DXMATRIX matView;
D3DXMatrixLookAtLH( &matView, &vEyePt, &vLookatPt, &vUpVec ); //またはD3DXMatrixLookAtRH()
LPD3D9Divece->SetTransform( D3DTS_VIEW, &matView );
これで左にずれてレンダリングされるはず
カメラを平行移動させる時は注視点を連動させる
DiveceじゃないDeviceだろorz
339 :
名前は開発中のものです。 :2011/05/25(水) 10:09:49.81 ID:2LG25rFZ
21日にバージョンアップしてるね
340 :
254 :2011/05/26(木) 20:53:42.12 ID:pDvbsZn3
>>255 もの凄く今更だけど、単独起動では処理は止まってた
だけど、ソフトをアクティブから最小化にした直後は
キー操作に反応してる(処理は止まってない)ようだった
SetAlwaysRunFlagはFALSEで、GetActiveFlagがTRUEの時に
キー判定するようにしてても
バージョンは3.05
なに意味不明なことを。 たいてい配布されてるDLLにはバージョン返す関数が用意されてるだろ。
マス目のゲーム戦闘画面ってDXライブラリで製作出来ます? マップに座標を打ち込みつつ初期化 {0,0,0} {0,1,1}の様な形。 for文でマップのマス目左上からズレていくように書き switch文で case 0 は DrawGraph 画像 case 1 は 〜〜 の様にしてみたんですが、上手く表示されません・・・。 マス目ごとに対応した番号の画像を表示させるにはどのようにすれば宜しいでしょうか?
プログラミング言語より まず日本語ちゃんと使えるようになろうな な! てか、説明する気全然無いだろおまえ
case 0|case 1|case 2| case 3|case 4|case 5| みたいな感じに表示したいって事だろう? caseで上手く行かないっていうのはどういう風に上手く行かないか書かないとわからんな。画像が映らないとか
なんか、おまえらの優しさに涙でそうになった
すみません; 文字制限があって削ってたら訳分からん文章に・・ ちょっと連投してソースコード貼りますがお許し下さい include "DxLib.h" #define MAP_SIZE 64 // マップチップ一つのドットサイズ #define MAP_WIDTH 4 // マップの幅 #define MAP_HEIGHT 4 // マップの縦長さ 本当はもっと大きいですがあくまで一例としてお願いします
規制受けたので携帯から #define BLACK 0 #define White 1 int MapData[ MAP_HEIGHT ][ MAP_WIDTH ] = { {1,1,1,1} {1,0,0,1} {1,1,0,1} {1.1.1.1} }; int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ) { ChangeWindowMode(TRUE); // ウィンドウモードに設定
SetGraphMode( 640 , 480 , 32 ) ; if( DxLib_Init() == -1 )// DXライブラリ初期化処理 { return -1;// エラーが起きたら直ちに終了 } int i, j; // マップを描く for( i = 0 ; i < MAP_HEIGHT ; i ++ ) { for( j = 0 ; j < MAP_WIDTH ; j ++ ) { switch(MapData[ i ][ j ] ) { case BLACK : DrawGraph("画像/サンプル1.bmp"); break;
case White : DrawGraph("画像/サンプル2.bmp"); break; } } } // キー入力待ち WaitKey() ; DxLib_End() ;// DXライブラリ使用の終了処理 return 0 ;// ソフトの終了 } 以上。投稿してから気付いた。White本当は全部大文字です。あぁしまった。画像ロード書き忘れてら・・・。
void load(){ LoadGraph("画像/サンプル1.bmp"); LoadGraph("画像/サンプル2.bmp"); } ↑がWinMainの上にあります。 エラーは画像描画の行で関数に一個の引数を指定できません。でした 時間やばいので寝ます。 スレ騒がせてしまって申し訳御座いません。
まぁスレが過疎るよりはマシだから
int DrawGraph( int x, int y, int GrHandle, int TransFlag ) ; この4つをちゃんと与えてないとかいうエラーだったら殴るぞ
switch内のDrawGraphはなんだよw もう一度リファレンス読みなおせww
つうかみんな待機してたのかよwwww ・・・・乙
長いコード貼るときはideoneかcodepad使うと便利だよ
皆様の優しさに泣いた しねぼけかすとか言われるかと思ってたら・・・。 バイト終わったらアドバイス通りに色々試してみます。
DxLibはDirectXでの描画を簡単にしてくれてるだけだから描画に関することしか制約はないと思います。 例えばアンチエイリアスとかエフェクトとかそういう描画関係での制約はあったりなかったり…。 制約あっても管理人さんに頼めば実装してくれる場合もあり。 というかシステム的な面はC言語,C++,C#でできるかって話だから基本的にはできないものはないと思っていいかと。 ここからは質問について。 まず、1枚の画像を分割して配列に入れられる関数があります。詳細はリファレンス読んでください。 int LoadDivGraph( char *FileName , int AllNum , int XNum , int YNum , int XSize , int YSize , int *HandleBuf ) ; これを使って読み込むと、例えば配列の中身に{土、草、木、海}と画像(マップチップ)を入れられるって感じです。 仮にこの配列の名前をChipImgとしておきます。 で、マップを書くときのfor文を以下のようにすれば希望の動作になると思います。 かなり基礎的なことなので検索すればどこにでも書いてあります。 ただ、そのままコピペするのではなくちゃんと理解してください。難しいことは何もしてないです。 細かいところ間違ってたら申し訳ない。 // マップを描く for( i = 0 ; i < MAP_HEIGHT ; i ++ ) { for( j = 0 ; j < MAP_WIDTH ; j ++ ) { DrawGraph(j*MAP_SIZE, i*MAP_SIZE, ChipImg[MapData[j][i]], false); } }
このスレって早朝でもレスポンスあるんだな
更新スレの一つでいつも見てるよ 最近スレとまってたけど。
LoadGraph削除後 int GHandle1; int GHandle2; GHandle1 = LoadGraph("画像/サンプル1.bmp"); GHandle2 = LoadGraph("画像/サンプル2.bmp"); case BLACK : DrawGraph(i,j,GHandle1,TRUE); break; case White : DrawGraph( i, j, GHandle2, TRUE); break; にしてみましたが、エラーはありませんでしたがウインドウ真っ暗で画像表示せず・・・。
リビルドしてアプリ起動したら何故か左上のマスだけ、不鮮明ながら画像が表示されてました。不思議。 今度は357さんの案を内容を理解するため勉強しつつ試してきます。
マップチップを1ドットずつずらして描画してどうするつもりだ
DrawGraph(i*MAP_SIZE,j*MAP_SIZE に変更する事で無事表示する事が出来ました! ただ、デバックなしで開始しても何も表示されないのが少し気になりますが。 取り敢えず解決してしまいました。 本当に有難う御座いました!m(_ _)m
デバックなしってどういう意味だ? ひょっとしてリリースの方でコンパイルして実行してるけど リリースの方のフォルダに画像を用意してないとか?
いえ、リリースにも画像フォルダ用意しリリースにもアプリ製作しました。 が、アプリ起動すると表示される画像が Ctrl+f5 で立ち上げたウインドウには表示されないのですよね。 VC++2008を使用しています。 一応アプリケーションは正常に動いているのであんまり気には掛けていないのですが、何かおかしいのでしょうか・・・。
DXライブラリの使い方というかVCやC++の使い方のレベルじゃないか リリース側の実行ファイルから画像までのパスがまともに取れてないとしかまず考えられない 問診して説明するよりプロジェクト入ってるフォルダごとアップしてもらった方が説明しやすいかもしれない…
LoadGraphに成功してるかエラーチェック入れろよ
>>366 すみません、確かにスレチでした。
当方C言語しか学習してなかったのでVCかC++の板に行ってみます。
失礼しましたm(_ _)m
DxLibと言うよりは確かにC言語初心者スレとかの方がいいかもね。 後はキッチリやさしい本を読むといいよ。 「やさしいJava」のC言語版的なもの。
>>368 だがC++やVCの板でもDXライブラリの関数なんか知らねえよとか言われそうではあるので
>>367 の言う通り
GHandle1 = LoadGraph("画像/サンプル1.bmp");
を
if( GHandle1 = LoadGraph("画像パス") )
{MessageBox(NULL,TEXT("エラー"),TEXT("画像のパス合ってない"),MB_OK);}
に差し替えてリリース側でエラーチェック試してみようか
これでアラート出たら絶対それ画像置く場所悪いから
if( GHandle1 = LoadGraph("画像パス") )じゃなくて if( GHandle1 = LoadGraph("画像パス")==-1 )だったごめんよ LoadGraphの返り値調べてエラー確認するんだ
何度もすみません。 無事エラーが表示されました。
あぁ、なるほど。 DebugとRelaeseフォルダにだけそれぞれ画像フォルダを置いていたのが間違ってました。 ↑二つが入ってるフォルダに入れておかないと駄目だったんですね・・・。 ほんとに初歩的な間違いでスレ汚してしまって申し訳なかったです; 解決しました。感謝
374 :
名前は開発中のものです。 :2011/05/28(土) 05:53:10.67 ID:bOluCu1Z
それはVSの都合なのかな? Releaseのを直接起動した場合Releaseフォルダ内にないと動かないよね
えーとこういうことなのか LoadGraph("Data\HogeHoge.bmp",〜); HogeHoge\Data\HogeHoge.bmp ... ←コレを読み込みたい HogeHoge\Release\HogeHoge.exe ←VSは実行ファイルをココに作る HogeHoge\HogeHoge.cpp ソース HogeHoge\ ←VSは実行ファイルを起動するときココを実行ディレクトリに設定する それなら直接起動するときは実行ファイルをココに移動/コピーして起動してやれば良い…?のでは HogeHoge\HogeHoge.exe ←ココにコピー ビルド後イベントコマンドで cp もにゃもにゃと設定してやれば一応自動化できそ
実行ファイルも同じフォルダに出力するようにして名前だけ変えるで区別とかして デバッグの作業ディレクトリも同じにすりゃいいだけ。
377 :
373 :2011/05/29(日) 00:44:52.38 ID:BFzS8fGx
またまたお世話になります。 と言っても今回はDXライブラリが絡むか自信が無いため、まずその段階からですが・・。 よくRPGなどの戦闘画面で、斜め上から見下ろした形になっているゲームが多いと思いますが、その表示方法についての質問です。 前に書いた様な座標型マップ表示で出来るものなのでしょうか? (絵を斜めっぽく工夫して描けば行ける・・・?) それとも座標自体を特殊な表記にしないと駄目でしょうか・・。 2Dの範囲内で実現可能という事は分かってるのですが、あちらこちら探しても中々答えが見つからずorz
378 :
名前は開発中のものです。 :2011/05/29(日) 00:48:22.93 ID:Ul9KwIs9
クォータービュー
基本的には描画の方法が違うだけ。マップデータ自体はそのまま流用できると思うよ。 ただし、クォータービューのマップチップは、 トップビューに比べてマップチップの縦幅が狭くなる(半分くらい)になってしまうので、 常に奥から描画するようにしないと、キャラが首チョンパ状態になったりするので注意。 ○ <大> 単独だときちんと人間が表示されるが ↓ ○ ○ <大><大> 上方向に重なるとマミっちゃう <大>
菱形の画像をうまく並べるだけさー 各マスの位置をベクタ的に回転させると楽
iが増えたら右下に(x,yそれぞれ増やす) jが増えたら左下に(x減らしてy増やす) とかすりゃいいじゃん
>>377 座標自体は同じだ。表示が違うだけだ。
【01】【02】【03】
【11】【12】【13】
【21】【22】【23】
を
【01】【02】【03】
【11】【12】【13】
【21】【22】【23】
って表示するだけの話だ。
383 :
373 :2011/05/29(日) 01:07:48.70 ID:BFzS8fGx
>>379 おぉ!
とても分かり易いお答え感謝致します!
取り敢えず素材は後回しでプログラムから頑張っているので、素材描く時参考にさせて頂きます。
有難ですm(_ _)m
384 :
373 :2011/05/29(日) 01:12:53.32 ID:BFzS8fGx
>>380-382 おおぉ、なるほど。
382さんの方法で表示させ、絵の描き方を工夫し、上手く調整する方向で頑張ってみたいと思います。
有難う御座いました!
>>379 を解決する為に描画順を動的に変更するのって面倒だよね
「描画は後でまとめて行え」っての守って書いてればどうすればいいかすぐ気付けるけど
だれかにまとめを作って欲しい
DXライブラリのリファレンス以上のまとめって何を記載すべきなんだろう?
まとめというか、使用例は沢山あって困ることがない
使用例をまとめたWikiってことか? 公式はあくまで一つ一つの材料紹介って感じだしレシピを纏めるってのなら割と需要あるかもね 場所なら一応用意できるが・・・作るか?
まずDxLibは描画などの面倒くさいことを簡単にしてくれるだけであって、 本質的なシステム面のプログラムは一切関係ないのだからこのスレには不必要。 検索すればいくらでも使用例は出てくる。 DxLibの関数の使用例は公式+検索で十分。
質問、回答をまとめるとか? もう7スレ消化してるんだし結構な数になってそう
>>390 まあスレチかもしれんけど
DXlib用のフレームワークは欲しい人多いんじゃない?
フレームワークとDirectXのラッパーが全く無関係ってこともないし
全力で否定せんでもいいでしょw
やるなら自分も協力するけど、スレは立てるか
他に引っ越すかがいいかもね
誰もフレームワークなんて言ってないねww 俺が先走りすぎたゴメンwww
なんだよ。 そこを突っ込もうと思ったら気づいたか つまらん
公式+検索で十分って言うけど、公式が見やすいとも使いやすいとも思えないし 掲示板の情報は要約されてないからwiki設置に賛成
下手に使用例を充実させると 今まで以上に初心者のコピペプログラミングが増えそうで あんまりいい気がしないなぁ。 使用例を集約するにしても、一工夫あった方がいい気がする。 このスレに持ってこられる大きめの質問の大半は 動作の意図を理解しないで、サンプルのコピペで済ませようとした コードのような印象がある。 本文長すぎるって言われたんで分割する。
(続き) きちんとそのコードが何を意味しているのか、とか 何と何と何の組み合わせによってその動作を実現しているか、とか 細かい解説が必要なんじゃないかな。 ・・・初心者の成長とかどうでもよくて、テクニックの集約とか そっち方面が目的なら、見当違いになるけどね。
別に誰かがコピペプログラミングとやらをしていても実害ないし
解説つけるべきだというのはその通りだと思う コードを理解する段階まで行ったときに、自分で思考するにしても解説あるのは勉強になるし有り難い コピペで済ませる人は解説があろうが使用例が分散してようが「理解」しようとはしないから 考慮してもしょうがないのでは? wikiにtips書く人に読者の勉強姿勢まで面倒みる責任はないよ 教師じゃないんだし
DXライブラリでWikiっていうと、前に一悶着あったような。 外部から俺らがごちゃごちゃ言ってただけというのが正しいか。
んじゃぁとりあえず場所用意するね 駄目なら駄目でその時はバッサリって感じで 少し時間くだしあ
>>399 個人サイトに責任はないよ。
だから有志で何やっても勝手。
ただ、このスレの共有サイトとしてのWikiであれば、万人が納得するようにしなければならない。
だから中途半端に解説も無いものを置かれても困るんだよね。
こうやってどのスレも初心者の質問でスレが埋まるようになってしまうんだから。
ごめんなさい、「考慮すべきでない」ってのは反論になってませんでした 初学者の学習に悪影響を及ぼすというのなら、注意文を記載しておくことでは解決しないかな?
2chを参考に勝手に立てたwikiであり、 このスレの住人は解説の義務を負っていないし、内容にも責任を負いませんよと明記すればいいんじゃないの 最近はwebで無料で閲覧した情報だのフリーソフトだのにも 執拗に責任を追及する変な奴が多くてダルいよな
使用例のまとめとかじゃなくて あくまで「このスレのまとめサイト」とかだったら 諸手を挙げて賛成。 過去に出た話題とかおさらいできるし、あるとうれしい。
欲を言うなら、ソースコードが載せやすいものがいいよね。
アフィとかはどうするんだ? 以前個人運営のまとめサイトがあったけどアフィ大量で叩かれてたじゃん
HP維持もタダじゃないしなぁ
409 :
401 :2011/06/03(金) 16:29:38.13 ID:mUEsLjLT
場所は確保したが色々立て込んじゃって、枠組み作成までもうちょい時間くだしあ
場所はWikiwikiにしました。わりとシンプルに使えるしそれなりに見た目も綺麗だからってのが理由です
>>407 そう言うのは一切入れてないから問題ないと思います
でもWiki側からデフォでついてる広告はどうしようも無いからそこら辺だけご容赦を
>>406 ソースコード貼付けはAA貼付けのタグ使えば綺麗に貼り付けれるようになります
そこら辺の説明含めて最初に書いておきます
あと内容に関してだけど
とりあえず2chで出た内容をまとめていったり、誰か気が向いた人が色々付け足していったり
とりあえず強制的なものは双方無いスタンスでやっていこうかと
場所用意するって自鯖じゃないんかい。 小学生の掲示板作った→レンタル掲示板みたいな流れだなww 前の流れだとテンプレ入れたらその時点でアウトなわけだけど、 作っても誰も見なきゃ意味ないぞ。 仮にどうしてもテンプレ入れるならdixq氏のサイトとかDxlibFunとか他有用なものと共にじゃないと不公平だしな。 まあ、それはそれでいいけど。
借りてるさくら鯖余ってるから提供できるならしたいけどどうすればいいのやらね
>>410 横からだけど、自鯖やレンタル鯖でやるほどのことか?
ありもので十分ならそれ使えば良いじゃん。
「他のサイトもテンプレに入れないと不公平」の意味もよく分からないが。
というか、どういうサイトを想定してる?
俺が想定してるのはcsharpgamedev wikiみたいな
2chのスレから派生した情報収集Wikiなんだけど。
この辺の認識があってないと、作った人も作ってもらった人も
不幸になりかねない気がする。
あと、「前の流れ」っていつごろの話だったっけ?
スレ番だけでも良いから教えてくれると嬉しい。
>>407 アフィふざけんなって人と、いちいち気にすんなよって人と、
論争になって結局Wikiが消えるのが一番困るって人とが仲良く言い争ってた記憶がw
個人運営でまとめてるサイトのアフィを叩いてるのってただの嫉妬だろ、気にすることない いちいち過去ログから探す手間が省けて有り難いし、アフィなんてその手間賃みたいなもんだろ アフィ収入が羨ましいなら叩いてないで自分もまとめてみればいいのに
ちゃんと整備されたまとめならアフィくらいいいけど アフィをべたべた貼ってるまとめって、情報を整理するとか絶対ないんだよね
普通に考えられる程度なら全然いいよ ただコンテンツの最初最後じゃなくて 途中の中断に入れてくるタイプは正直かなり読み難い
アフィやりたいって言ってんの?
アフィアフィ言ってんじゃないよ
wikiwikiのなら十分アリだと思うよ、邪魔じゃないし。 下手に個人鯖とかでアフィ見つけちゃうと嫌な論争になるしね
アフィあっても非表示にしてるからどうでもいいけど
かったああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ!!
ごめん、超誤爆した 申し訳ない
配布ファイルが7zipになった
DGCAェ・・・
7zip解凍できるソフト教えてくれ けっこう有名なソフトを使ってるつもりだったが無理だった
Noahとか
>>428 サンキュー
よく考えたらexeなんだからソフトが対応してなくてもよかったんだな
早とちりしたぜ
DGCAの時みたいにSFX圧縮で何も無しに展開できる。 圧縮ファイルのサイズが11MB→5MBほどになっていた。
LZMAすげーな LZMA圧縮なPNGとかどっかねーかな
>>417 そういうのは心配しなくても自然と誰も見なくなるだろ
>>432 検索時にアフィべたべたのとこが上位独占はよくあること
苦労して直接DirectXで書いのになぜかDXライブラリで書いたプログラムの方が速く動く・・・ 余分な処理してるってことかな・・・
なんだかんだ遅いと言われてるけど、一応面倒な最適化とかもちゃんとやってるしね 何もせずに直接走らせるより速いことも多い
そうなんだ、初期化コードいっぱい書いたのに・・・ このままじゃゲーム部分までたどり着けない、ライブラリ再検討しよ。
今のゲームPCで実際速さの違いがわかるようなプレイヤーがいるのかねえ
DXライブラリがなくなったときのために DirectXも少しずつ勉強してるけど、DXライブラリがある内はこれでいいわ
俺はDXライブラリなしでは何も作れない無能者だから434がまぶしいぜ。 そんな俺が言うのはなんだが、434がやった事は決して無駄じゃないと思うぜ!
DXライブラリと同じ仕組みのソースなら 自力で書いたからって早くなるわけがない
コードが糞だからだよ
DXライブラリ始めたばかりなのですが、角が丸い四角形を描画する方法ってありませんか?
ありますよ
そういうDxLibの関数は、たしかなかったよね? DrawBoxとDrawCircleでどうとでもなるだろうけど
今普通にあるんじゃね?と思ってヘッダさらっと見たけど、 角丸四角形を描画する関数は無かったな。 簡単に描画するならDrawBoxとDrawCircleだけど、 そもそもDraw系関数は糞思いから画像使ってなんとかしたほうが良いかと。
久しぶりに見たら フォントビルボードとか多少機能が増えてるな
C++公式ラッパーとかないの?
文字にぼかしを入れたいんだが、どうやればいいんでしょうか?
ピクセルシェーダ
C#だとメモリ上でBitmap作ってGDIでエフェクトかけて文字書き出して それをメモリからグラフィック作成で 似たようなこと出来るね Cはしらね
RPGの攻撃のエフェクトってパラパラ漫画みたいに 複数の画像を次々に表示する以外に何か方法ありませんかね
それ以外だったらリアルタイムにパーティクルを描画するしかないじゃないかな
ありがとうございます。 調べてみます
調べるほどのことじゃないけどな パラパラ漫画にする代わりに、画像を拡大したり位置を変えたりしながら何枚か表示するだけ 素材用意できるならパラパラ漫画の方が楽
3Dのエフェクトのモーションデータを再生とか? よくわからないけど
バージョン3.05のソースファイルを今までの改造したコード付け足してビルドすると、 出来たlibを使う際にいろいろ未解決って言われる 要求されてるっぽいwinmm.libをリンクしても、今度は起動時に初期化に失敗してグラボがクラッシュする…… こういう場合でも公式に報告したほうがいいのかな 自分でもわけわかんないんだけど
>>456 わけわかってないこと報告したらだめでしょw
VC10でDXライブラリを公開されているソース玉からビルドしてみたら ものすごく重い(時間がかかる)ので驚いた
>>456 さすがに自分で追加/修正したものを、公式に投げるのは辞めたほうがいいんじゃないかなあ。
そういう自分も、かなり昔に報告したことがあるんだけどね。
#defineの切り替えで、機能を削ってライブラリ軽量化できたりするわけだけど、
特定の組み合わせだとバグるとかそんなの。
DirectXをDXって略す奴まじ紛らわしい
リソースのイメージファイルからLoadSoftImageしたいんですがどうしたらいいですか
相変わらず串は無能だな 向いてないからやめたほうがいいよ
LoadSoftImage(MAKEINTRESOURCE(id))では駄目みたいだし、 LoadGraphToResource(id)の結果をソフトイメージに変換とかできないのかな。 うーむ
久しぶりに公式HP見て来たんですけど、なんだかバリエーションが変わってますね。 VisualC++用(Ver3.05) BorlandC++用(Ver3.05) Gnu C++用(Ver3.05) の3つになってましたね。 GNU C++用が出来ている辺りがなんか進化してる感がありますが、気になる点が。 以前はVC++用と言っても2011用、2008用、visual studio .net 2003用とか色々ありましたよね? これからはどの環境でもVisualC++用だけでおkという事なのでしょうか? なんか公式の掲示板斜め読みしたら、2008だとどうとか、問題があったとか書き込みが見えましたが、基本的に大丈夫なんでしょうか??
>>463 GetResourceInfoとLoadSoftImageToMem使えばいける
>>464 まじかよ!
おれのC#版は、まだ正式バリエーションには入れてもらえないんだな。
467 :
名前は開発中のものです。 :2011/06/19(日) 22:02:26.65 ID:Mk/qPjyt
DrawPolygonIndexed3Dで作った1×1×1の立方体を平面に 隙間なく10×10ほど並べると、カメラの角度によって 隙間があるように見えるんだが 原因か対策方法をおしえてくれないだろうか?
ソースコードをSubversionか何かのリポジトリに置いてくれよう 何で置かないの?
メインループでない他の関数から 終了処理を呼び出すとエラーが出ます 例えばキーの情報をまとめた関数のESCを押したときの終了処理などで起こります どうしたらいいでしょう?
他の関数では終了フラグをONさせるだけで、 終了処理はメインループでやればいい。
>>497 アンチエイリアスかけるしかないかと。
例えばDS市販ソフトの立体ピクロス等でもそういう現象は起こる。
>>469 エラー内容コピペしてみたら?
そんなこと起こらないと思うけど…。
まさか別ファイルにしていてdxlib.hをインクルードし忘れてるなんてことはないよね。
ユーザーがバグ修正のコード送ろうにも、バージョン管理システム使ってなかったらやりづらい
自分のところでも同じ部分を書き換えていたら、両方の変更を失わないようにするのが難しいし
>>459 色いろ問題あるよね、今でも
・Theora使う機能オフにしてビルドしようとすると、
#ifndefの使う場所が間違っているところがあるみたいで
無しだとビルドできない
・libpngは仕様変更のせいで1.5系ではビルドできない 1.4系は可
・デフォルトだと、
DxLib.hに#pragmaでリンクするライブラリを指定するようになっているけど、これやだ
ライブラリの名前が1つでも変わると、全てビルドし直しになる
(最新版だと名前が違っているから、自前でビルドするには全部変えないといけないや)
面倒でもプロジェクトの設定でやった方がいい希ガス
・あと、1998年からlibjpegは更新されていないって書いてるけど、最近も更新あったよ
俺の場合は本家のコードに付け足すコードをインクルードしてビルドしてるだけだったなー 挙動を書き換えた別バージョンの関数を追加、って感じで
>>470 その方法を試してみます
>>471 例のESCキーを押して実行窓は閉じれるのですが、
プロセス自体の終了ができていなく、タスクマネージャから消している状況です
dxlib.hはインクルードしています
>>472 何か自分の言葉じゃないよね
本の受け売りか、学校の先生が言ってたそのまんまって感じ
>>474 もしかして DxLib_End(); でプロセスも終了してくれると思ってない?
メイン関数で終了するときに、 DxLib_End(); でDxlib周りの終了処理をして、
そのあとにメイン関数に return 0; で0を返してプログラムを終了してるわけ。
ということはメイン関数以外から直接は終了できないんじゃないかと思うよね。
それでは色々と面倒ということで stdlib.h に void exit(int status); という関数が用意されてる。
これはメイン関数に引数で渡した値を返す動作なので、 exit(0); としてやればよいということになる。
もし、 exit(0); でエラーが出るという話ならどういうエラーなのか書くこと。
470のやり方を基本としておさえておいたほうがいいと思うぞ
478 :
467 :2011/06/21(火) 19:29:12.62 ID:63a9Z6UZ
>>471 アドバイスありがとん
DXライブラリでアンチエイリアスの指定ってできたっけ?
まぁ、色々いじって、解決させたので方法書いておきます
・SetCameraNearFarで手前クリップ位置を遠くしてみる
これでだいぶ軽減できました。でも見えるときは見える
・くっついた位置に描画されるポリゴンを描画しない
ブロック同士の境目のポリゴンを消しとけば、隙間なくうまってるように見える。
要するに何らかの加減で、縦方向のポリゴンの一部が見えてるってことらしい。
LoadSoundMem 使うと、読み込むファイルの倍近くメモリ食うんだけどこんなもん?
読み込んでるのが圧縮ファイルなら SetCreateSoundDataTypeがDX_SOUNDDATATYPE_MEMNOPRESS(デフォルト)だからかもしれない
おぉ、そんな設定があるんだ 知らんかった
>>480 素早いレスポンスまじ助かる
用途に合わせて使ったらメモリ使用量がスゲー減ったよ
本当にありがとう
描写の基礎中の基礎だと思うのですが 例えば落ち物パズルゲーム(ジャンル関係なく) 落下物を一番下まで置く 次の落下物 以下ループ 移動物は当然、描画→消す→再描画が必要になると思いますが 動かなくなった物もこのルーチンに組み込むしかないのでしょうか?
>>483 そうだよ、毎回全部再描画
全消し&全再描画が基本
一昔前のスペックのPCでも、60フレームで毎回数千枚画像を描画しても問題ないしな ゲーム作り始めた人は大抵最初疑問に思うよな、コレ
むしろDxLibのサンプルを読むと、裏描画→スワップ→裏消す→ループの流れになってたから素直に馴染んでた。
>>483 処理速度の遅い、昔のパソコンだと、いかに描画部分を減らすかが勝負だったから、
貴方の考えてるような事(動かないものは再描画しない)は重要だった。
ファミコン等で使われてるスプライトやBG機能はそういうのをハード的に処理する事で、
軽快な動きを実現させていた。
今のPCはそんな事考える必要ないくらいの処理速度なので、やってる人はいないでしょう。
もちろんできなくはないけどデメリットが多くてメリットは少ない。
>>483 画面のほとんどが将棋みたいに静止してるゲームを除いて
削れる対象って少ないよ。(高速化が必要なゲームで使えない手法)
小さな領域で何回も描画すると遅くなるし。
ハイポリゴンの3Dがぼけっと止まってるとかなら 描画した結果を写真みたいに1枚のテクスチャにしてしまうのが有効
C#板で壁にぶち当たってきたので、ちょっと愚痴らせてくれ 万単位のVERTEX3Dを1フレーム毎に更新なんてできねーよ テクスチャアニメーションはやるなってことでFAなんか?
今話題の京なら楽勝
>ファミコン等で使われてるスプライトやBG機能はそういうのをハード的に処理する事で、 ハード機能だったのか〜
串って、めだか信者なの?
3D関数のリファレンスページを見ているのですが、 >Vertex[ 0 ].pos = VGet( 100.0f, 100.0f, 0.0f ) ; この100.0fや0.0fに付いているfはfloat型という意味なのでしょうか?
はい、そうです。
>>492 今更かよ!そもそもスプライトはハードウェアの機能の事
DirectX等でいわれているスプライトはエミュレーションにすぎない
スプライト動かして背景に影響が出る以上、エミュレーションになってないと思うがw ただ名前を借りてるだけだろう。
スプライトはハードが対応してれば有効じゃなかったかな。 そんなカードにはお目に掛かったことないけど。
---------disp.h--------- void disp(){ int FontHandle; FontHandle = CreateFontToHandle( "MS ゴシック" , 20 , 1 , DX_FONTTYPE_NORMAL ); DrawFormatStringToHandle(100,100,色,FontHandle,"テスト"); } ---------main--------- main(){ while(i== 0){ Disp(); // ループ処理 } } このようにプログラムを組んだらフォントハンドルの作成数が限界になってエラーになり 修正を加えました
---------moji.h--------- void moji(){ int FontHandle; FontHandle = CreateFontToHandle( "MS ゴシック" , 20 , 1 , DX_FONTTYPE_NORMAL ); } ---------disp.h--------- #include "moji.h" void disp(){ int FontHandle; DrawFormatStringToHandle(100,100,色,FontHandle,"テスト"); } ---------main--------- #include "disp.h" main(){ while(i== 0){ Disp(); // ループ処理 } } どうにも上手く動かないのですが、フォントの初期設定?とそのハンドルの使いまわし方がイマイチ理解できません
int FontHandleをグローバルにしないとそのハンドル値が保存されないので、 DrawFormatStringToHandleにうまく渡せていない
---------moji.h--------- int FontHandle; void moji(){ FontHandle = CreateFontToHandle( "MS ゴシック" , 20 , 1 , DX_FONTTYPE_NORMAL ); } ---------disp.h--------- #include "moji.h" void disp(){ DrawFormatStringToHandle(100,100,色,FontHandle,"テスト"); } ---------main--------- #include "disp.h" main(){ while(i== 0){ Disp(); // ループ処理 } } 詳しくは変数のスコープでググれ
moji()呼んでなくね? てか、確かフォントハンドル作成は時間かかる処理だし、最初に一回だけやればいいだろ。 それでも作成しなおしたいんだったら、使わないフォントハンドルはちゃんと削除しといたほうが……。
あ、ほんとだ ---------main--------- #include "disp.h" main(){ moji(); while(i== 0){ Disp(); // ループ処理 } } こうか でもDXライブラリのハンドルは、感覚掴まないと難しいしな…… ハンドルと実態は別だし
>でもDXライブラリのハンドルは、感覚掴まないと難しいしな…… >ハンドルと実態は別だし 俺はよく解ってないまま使ってるw まぁデータベースみたいなものが自動的に作られてて ハンドルはそのキーってとこだろうという程度の認識で。
507 :
501 :2011/06/28(火) 00:39:04.09 ID:ACSn663z
無事解決しました ありがとうございます そもそもグローバル変数をよく理解できず それでいてそういう変数の操作ができず不便で戻り値を駆使して対応していたのですが 色々な問題が一気に解決した気分です
半透明のビルボードが欲しいのだけど、なんかいい方法ないもんかな? DrawBillboard3Dには半透明にする機能がないし DrawPolygon3Dとかから自作すればいけるのか?
509 :
508 :2011/06/28(火) 20:43:19.16 ID:ZHM0z8W2
自己解決 SetDrawBlendModeはDrawBillboard3Dにも適用されてるのね
角っちょが丸い四角形がかける関数があるとか前にこのスレかどこかでみかけたんですが そんな物は無い?
そんなものは無いっていう話ならこのスレで見た
>>507 むしろグローバル領域に頼らない心意気は大事だと思うます
とは言っても終始必要な情報をグローバルに置くのも一つの手なので
その時はヘッダファイルの宣言にexternをつけて、対になるソースファイルに実態を定義する
>>501 の例をdisp.hとdisp.cにまとめた場合こんな感じ。実際はもっと一意的な名前にする
---------disp.h---------
// 宣言
extern int FontHandle;
extern void set(void);
extern void disp(void);
---------disp.c---------
// 定義
int FontHandle = 0;
void set() { FontHandle = CreateFontToHandle( "MS ゴシック" , 20 , 1 , DX_FONTTYPE_NORMAL ); }
void disp() { DrawFormatStringToHandle(100,100,色,FontHandle,"テスト"); }
むしろ初期化関数とハンドル取得関数を作って一つのファイルで完結させるとか
C言語あまり使ってないから詳しくは知らないけど フォントハンドルは公開する必要ないんだからstaticにして dispに集約しても良いんじゃね? それこそ関数ポインタか下のようにif文でsetなんて消したい。 //----disp.h---- void disp(); void disp2(int x, int y, char* moji); //----disp.c---- static int FontHandl=0;//プログラム実行時に0に初期化される void disp(){ if(!FontHandle){ FontHandle = CreateFontToHandle( "MS ゴシック" , 20 , 1 , DX_FONTTYPE_NORMAL ); } DrawFormatStringToHandle(100,100,色,FontHandle,"テスト"); } void disp2(int x, int y, char* moji){ if(!FontHandle){ FontHandle = CreateFontToHandle( "MS ゴシック" , 20 , 1 , DX_FONTTYPE_NORMAL ); } DrawFormatStringToHandle(x,y,色,FontHandle,moji); }
どうでもいいけど、DXライブラリでのハンドル取得におけるエラー時の返り値は-1だから 初期化は0でなくー1でやるべきだと思うんだ。
>>515 ごめんよ、DXライブラリもまともに使ったこと無かったんだよ
DrawPolygonIndexed3D関数の使い方として 10個の頂点の情報をセットして、 必要に応じた頂点を好きなだけ選んでポリゴンを表示できますか? VERTEX3D Vertex[10]; Vertex[0] = VGet(x0,y0,z0); 〜 Vertex[9] = VGet(x9,y9,z9); としておいて、描きたいようにIndexの配列の値を変える。
>>517 VERTEX3D[]は固定なんだろうから
どっかに面単位でインデックス(ushort[])作っておいて
必要に応じて、コレクションに加えていけば
最後には出力用のインデックスつくれるんでない?
そいやぁwikiどうなったの?
>>518 ありがとうございます。
なんとか出来ました。
while(特定のキーが押されるまで) { 処理 } 終了 ベタなプログラムだと思うのですが、処理内容が空白でも CPU使用率が50%から下がらなくなる状況なんですが、そういうもんなんですか? メモリの使用量も文字列を1行字表示させるだけでも他の数十MBも利用するみたいですが(DirectXの仕様?)
文字を表示するにはフォントを読み込む必要があるからじゃないの
待つ場合は ProcessMessage() 通しておけよ
>>521 スリープしてないからCPUの空き時間すべて判定と処理に回される
無限ループは待機なきゃwhile内の処理空白でもCPU使いまくるぞ
だいたいの人がこんな感じにするんでね? 初期処理 SetDrawScreen(DX_SCREEN_BACK) while(終了条件判定) { ProcessMessage() 任意の処理 ScreenFlip() } 終了処理 終了
単純にProcessMessage()を入れ忘れてました 別プロジェクトからプチ検証プログラムを用意する程度だったもので お騒がせしました
527 :
名前は開発中のものです。 :2011/07/04(月) 17:24:01.94 ID:oYSdKTV1
dx最強、他はゴミ
日本ではそうだねぇ
VERTEX3D[]とそのインデックスのshort[]で構成された面情報と 線分の衝突を判定使用と思った場合 HitCheck_Line_Triangleですべての面を調べるしかない? なんとか、全部調べなくてもいい方法ないかな?
自前で空間カリングしかないんじゃないかな
ドットアニメーションの画像があるとして LoadDivGraph( ) ; で細切れにして、順番に画像を呼び出すのと 画像はそのままで DrawRectGraph()範囲指定呼び出し どちらが良いんでしょ
LoadDivGraphでいいよ その程度で速度に大差はないし使いやすい方使えば
測った事ないからわからんけど、 機能だけみるとDrawRectGraph()は 同じアニメーションを頻繁に繰り返す用途には向かない気がするが。
何度もアニメを回すならLoadDivGraphでしょ。 1度しか使わないなら大差ないからどっちでもいいかと。 普通は使い分ける意味ないからLoadDivGraphで統一。
LoadGraphで画像をメモリに大量に記憶させまくったら ブルースクリーンになって落ちました メモリがオーバーした(メインメモリはオーバーしない程度のはずだったけど)から ブルースクリーンになったと思うのですが PCのスペックの限界付近になったら処理を終了 (プログラム実行を終了)という感じはできるんですかね?
そのブルースクリーンは再現可能なの? つまり、一回だけあった現象なのか、同じ処理を実行すると必ずそうなるのか。 つぎに、その「大量に記憶」ってのは具体的にどれくらい? どれくらいのサイズの画像をいくつくらい? もし現象が再現可能なら、いくつくらいで落ちるか大雑把には調べられるよね? 最後に、メモリがハード的に壊れてないか調べてみた?
PCがぶっ壊れると困るので再現性は確認してませんが 確かに再現性を調べてから質問すべきでした 画像は300*300の画像を300〜400枚ぐらいでした
538 :
名前は開発中のものです。 :2011/07/07(木) 16:57:35.61 ID:4fOFO6+S
グラボのメモリは足りてるのか?ブルースクリーンなどはグラボのドライバーが比較的おおい
539 :
名前は開発中のものです。 :2011/07/07(木) 17:00:07.62 ID:4fOFO6+S
あと、物によるがテクスチャの容量計算は圧縮サイズで見積もってもあまり意味がない。
540 :
名前は開発中のものです。 :2011/07/07(木) 19:47:51.91 ID:no4toLki
>>535 > PCのスペックの限界付近になったら処理を終了
> (プログラム実行を終了)という感じはできるんですかね?
あなたがそうプログラムを書けばできます。
>>535 限界超えたら例外吐いて終了って実装が多いんじゃね。
ブルースクリーンってことはメモリの使い過ぎじゃないよ。
使い過ぎぐらいでそんなもん出てたまるかwww
OSのパフォーマンスモニタや、グラフィックボードのその手のツールを使うと
メモリ使用量等に関しては計測可能になるよ。
というかデバッグするのにツール使わないとか時間の無駄だから。
DXライブラリにビデオメモリを表示する関数がある
めもりくりーなーとかでよくね?漏れとかそれで見てる
何もしなくても70〜80MB喰うよな ダイレクトXの仕様なのか 意識しないと200MB近くになっている
何いってんだよ・・・そんな訳無いじゃん!
VRAMなのかメインメモリなのか
547 :
名前は開発中のものです。 :2011/07/08(金) 02:05:10.25 ID:ju5ZjKNL
今の時代200MBなんてミジンコのようなもんじゃないの
VRAM圧迫でブルースクリーンはOSとDirectXの仕様的に考えにくいわ 物理的にメモリが逝ってるとか、変な領域にアクセスしようとしたとか そっちのほうが、まだ説得力あるよ
>>547 タスクマネージャでメモリを確認した時
自分のゴミゲーのメモリ使用量がトップになるのがなんとも・・・・
紙芝居のエロゲーでさえ100〜150MBだからな
紙芝居はビットマップを全部メモリにキャッシュしたりすると結構食うんじゃない? 640x480x32bitの絵を一枚で1MBかかるし
最近の紙芝居はワイド画面にキャラだしまくりんぐで、結構喰うのはわかるけど その紙芝居より(見た目が)ショボい自分のゴミゲーが超えるってのがなんだかな〜っとw 2Dドットアニメーションってプログラムとしては扱いやすいけど沢山出すとメモリを喰うよな まぁ、1キャラでもアニメーション分が増えるわけだから表面的な画像量より多く喰うのは当然なんだけど 小さい物体ならいいけど大きい物体となると尚更 やはり時代は3Dなのか?
内部的に32ビットで扱ってるから容量食いまくるんだよな 8ビットとかでも高速描画できるようにしとけばよかったのに ハードの設計から思想的に間違ってるんじゃないの
素材を作れず、吸い出しやネットで集めていると 8ビットは厳しいんだよなw 仕様を要求できず、こっちが仕様に合わせる
>内部的に32ビットで扱ってるから容量食いまくるんだよな つまり 100x100x8と100x100x32の画像を用意しても DirectXの処理ではどちらも100x100x32で扱われているってこと?
それどころか内部的には128x128x32になってる可能性もある。
い、いい加減なこと言うなよ!?
DXTつかえよ、、、
dxtってなに?
いまどきの圧縮フォーマット。 フルカラーで最大1/8になる。
>DXT 対応グラボなら、圧縮された状態でキャッシュに持てるんだっけ?
VRAM上は圧縮されたまま。 テクスチャキャッシュ上では展開されている。 対応自体はGeForce3とかの時代にはもうあったはず。
でそれDXライブラリで使えるの?
DXTってファイルのフォーマットであって、 画像ファイルそのものがこちらで選択できない場合は無理だよね?
今時のPCのVRAMの最低基準が128MBだとして、 それがいっぱいになるくらいテクスチャ読み込むのっておかしいだろ…… 512*512フルカラー1枚でキッカリ1MBだし…… 小さなゲームなら起動時に画像全読み込みもOKだろうけど、 そこまで大規模なゲームなら、画像が必要になったときに読み込んだり要らなくなったら開放する仕組みを組むべき
565 :
名前は開発中のものです。 :2011/07/08(金) 18:05:22.70 ID:XTPS3PsK
300枚から400枚だろ。300×300なら512になっているかもなー
その枚数ならストリーミングすべき
音声やムービーならストリーミングってのもわかるけど 画像ファイルでストリーミングってできるもんなの? 手動で順次読み込み機能を組めってこと? 参考にはならんかもしれないが 俺が知ってるDXライブラリ製ソフトで256x256の画像データを 1200個近く読み込んでいる(と思う)のあるけど 普通に動いてたよ。 何か工夫してるのかもしれないけど。
それだけの量を一度に読み込む意図がわからんが・・・ 面ごとに必要な分量を読んでるとかじゃなくて?
別にメインメモリに読み込む分にはなにも問題ないんじゃね? 500MBくらいならそこらの市販ゲームでもやってるよね VRAMに転送しすぎるとなんかやばそうな気がするけど
メインメモリに送っているのかVRAMに送っているのかどうやって判断するんですか?
初歩の初歩なんですけど、 空間上に画像を描画したい時は DrawPolygon3D でやればいいんですかね。 DrawBillboard3D は常にこっちを向いてくれちゃうみたいなんで。 こっち見んな。
メインメモリにテクスチャー置いても 描画するときは一時的にVRAMテクスチャ作って それにコピーしてからスクリーンに描画する
VRAMってのはいわゆるスクリーンに投影される部分の事じゃないのか。
>>571 空間上に画像を(○○で)描画したい時は、という風に使い分けるんだよ。
ビルボドードで表示したいときは、DrawBillboard3Dを使うだけ。
このへんは2Dでも同じ、というか全てにおいて同じでしょう。
575 :
名前は開発中のものです。 :2011/07/09(土) 08:41:20.01 ID:EUxsgPhf
VRAMの役割は昔の画面だけと大分ちがうよ?同じ部分も含んでるけど。
複数のスレッドで同時にDXライブラリを使うと、 ときどきエラーをはくのだが、DXライブラリって マルチスレッド対応じゃなかったの? 使ってるのはC#版です
>>576 スレッドはエラー起こりやすい。このライブラリが原因と特定できたなら作者へ連絡すれば良い。
>>577 公式掲示板に再現可能なソースをつけてあげてきた。
ソースのほうに問題がありそうなら、みなさん指摘お願いします。
hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=view&no=2301 すぐ下にわかりやすい答えがあるみたいだが
DXライブラリはバグばっかり ちょっと込み入ったことやろうとするとすぐ強制終了する しかもエラーコードとかなくてエラー時にには関数が-1を返すだけだからそれ以上調べようがないしうんこすぎぶりぶり
え
>>578 C#はしらんが。C++のコードない?
C++だったらデバッグて゜きるんだけども。
583 :
名前は開発中のものです。 :2011/07/09(土) 19:01:55.39 ID:gbiBau/k
>>580 具体的に書いてみ、そしてソースコード添付。
そいから、あなたの動作環境を提示(PCハード情報、OS情報、など)
再現性のある情報を提供してくださいね
584 :
名前は開発中のものです。 :2011/07/09(土) 19:22:46.74 ID:7E7LKpx7
バかがわいてきたwktk
585 :
名前は開発中のものです。 :2011/07/09(土) 21:01:44.35 ID:BdkS/RBR
だれか今作ってるゲームのスクショ上げてくれ モチベーションがあがらない
俺も前にPPLでゲーム処理のマルチやろうとしたら何らかのエラー(忘れた)が出て、 まったく使えなかったので諦めたな
587 :
名前は開発中のものです。 :2011/07/09(土) 22:02:30.71 ID:aAP3Q2i0
>>579 ありがとん、マルチスレッドで使っちゃだめなのね
だとすると、データのロードとか初期化の作業とか
みなさん、どんな風に組んでるの?
Direct3D9がマルチスレッド向きじゃないからね。 最近出たDirect3D11の特徴がマルチスレッド対応だし。 DxLibのAPIを呼ぶのはメインスレッドのみに制限したほうがいい
ID:aAP3Q2i0はどこで競合など発生しているのか調べて、そこを再入不可能にしたらいいだろう。
>>589 ダンジョンRPGだと……
発表時期によってはウチの作品のライバルになりそうだ
593 :
名前は開発中のものです。 :2011/07/09(土) 22:15:40.92 ID:63ssXNtP
バカが公式掲示板にも書き込んでやがる 早く解決レスつけてこいよ つか質問する前に過去ログくらいあされよクズ
この部分を、スレッドで連続で呼び出すとエラーになるってことか? { // メモリに読み込んで消すだけ int temp = DX.LoadGraph("testpatan02.png"); DX.DeleteGraph(temp); }
最近はDXライブラリ使って3Dが普通になってきてるんだなぁ。 未だに2Dしか使えない俺はこの先困りそうだな……。
>>595 >>590 をみると。データの読み込み(DX.LoadGraph)と書き込みと
描画(DrawBoxとDrawString)を同時にやるのが問題みたい
これにより、オレの「動いてかっこいいロード画面計画」は頓挫したわけだ・・・・
普通に止め絵でロード画面作るけどね。
他人が作ってる開発画面を見るのも面白いな
>>597 データロード中に0%から100%に動く表示をしたいのか?
C#はしらないが公式掲示板のソースは、無数にスレッドを生成してないか?
画面描写とデータロードは並列に出来るだろ? 自分はこのライブラリ使ったことないがな。
>>597 複数のスレッドで描画関係の関数呼ぶのが問題なわけだから、
読み込みと書き込みは別スレッドでやりつつ描画を1つのスレッドでやるのは問題ないんじゃないの?
2DもSTGとかの原型だけは作ったりしてる。
そこまでできちゃうとデータ作ったりするのに疲れて色々浮気しちゃうんだよね。
>>592 あと5年は完成しないと思うよ。
>>589 メタセコイアで壁とか床だけ作ってる。
603 :
名前は開発中のものです。 :2011/07/09(土) 23:44:29.00 ID:BdkS/RBR
>>602 なんかもっとド派手な技だしてる画像とかの方がモチベーション上がったと思う
つかこれ、マップ表示のフィールドの形と目で見るフィールドの形がちょっと
違うようにみえるけど、まあ開発段階は皆そんなもんだろうね
目に見える範囲はまだ踏破してないから マップに表示されてないという画像に見えるが・・・
やはりウィザードリィっぽいゲームは誰もが作りたくなるものなのだなw 俺も中学生の頃作ったからなつかすいわ
人体アニメーションは自分には相当厳しいと判断した。 小さい人形ならできるかもしれないけど。 壁とかエフェクトを3D化なら少ししてみた。 それから3Dでのαブレンドがトラウマになった。 結局、ポリゴンが交差したらZソートしてもダメなんだろ? 面倒だから今のところ3Dエフェクト類は全て加算合成。 減算合成もなんか上手くいかないし、仮対応らしいしな
>>599 シンボルがテカテカ光ったり、SDキャラがテクテクあるいたり・・
スレッドは、以前に作ったスレッドが動いていないときだけ、動くようにしてるんで
本スレッドいがいは読み書きをするスレッドが1つ常に動いてる状態になってるサンプル
>>600 それができたら、オレのサンプルは普通に動いてるよ
>>601 それが、ロードと描画も同時にやってはいかんらしい
たぶん、ロードに使うポインタと描画に使うポインタが一緒とか、
そういうことなんじゃないかな?DXライブラリのソースは読んでないから
詳しくはしらないけど。
>>607 いくらでもサンプルあるんだから少しはググろうぜ。
>>603 モチベがどうとか言うって事は、自分でも作ってるんだろ?
他人のものを見るより、自分のスクショを上げるべきだろ。
610 :
名前は開発中のものです。 :2011/07/10(日) 01:46:33.14 ID:CZHVbp3+
>>609 自分のスクショでモチべ上がるわけないだろ
自分の思い描いているプレイ画面のスクショがあれば相当上がるけどな
さあ、君も上げるんだ
お前のモチベーションなんてどうでもいいから お前がスクショ上げて俺のモチベーション上げろよ
データロードと画面表示を並列実行したいのなら 1.メモリにデータを読み込む(読み込み終わるごとに2のスレッドにメッセージを投げる) 2.読込アニメーションと1で読込完了したデータをDXライブラリで設定(CreateGraphFromMem等を使う) というようにスレッドを分ければいい ただスレッドをきちんと理解できていることが前提。理解できていないのなら止め絵一択
アニメーションすら出来なら物作り無理。
データロード中のロード待ちアニメーション処理とか、昔からあこがれるが そもそも俺の作ってる2Dゲームなんて画像データ少なくて、ロードも一瞬だからそんな処理する必要もねぇw
>>615 2Dゲーでもドットアニメーション絵を大量に呼び出すと一瞬固まるぜ
>>587 , 597
>動いてかっこいいロード画面計画
よほどでかいデータじゃなきゃロード処理中に定期的に画面更新するだけでも十分だったりするよ
エスコン風ゲーム作ってるんだけど広い背景作るの難しいね
619 :
名前は開発中のものです。 :2011/07/10(日) 23:33:06.06 ID:CZHVbp3+
爆発とかのエフェクトって、ソフトで出力した画像を分割読み込みして それを一定間隔で描画して表現するものなのか? なんか動画形式で出来るものだと思ってたんだが
他には、数枚の炎っぽく見える絵を加算ブレンドで組み合わせてアニメさせる方法もある。
621 :
名前は開発中のものです。 :2011/07/11(月) 00:09:23.91 ID:9JlkIYT5
そうなんか その2つがメインな方法ってわけか なんかもっと簡単な方法ないかな エフェクトで文章量食うのはなんだか嫌だな
パラパラ漫画方式で順番に表示させるのが、一番わかりやすくて融通も効くと思うけど むしろこれができないとゲーム作るの厳しくないか?
そんな数行で済むような処理をケチるために時間潰すくらいならさっさと書けばよろしい。
YES SIR
「音たま」みたいなもん?
BMSの曲データから弾幕生成する「おたま」ってのは知ってたけど こんなゲームあったのか、知らなかった・・・ 体験版をやってみた感じ やりたいことは基本的に同じ 違う部分は、 音たまが曲を流しながらリアルタイムで弾幕生成するのに対して 俺のは予め曲を解析して弾幕データ作るって部分かな 解析に時間かける分、わりかし曲のテンポにそった感じに弾はくよ オレはAudioSurf見て、つくろうと思ったんだけど 音たまの人もそうなのかな アイデア的には割と誰でも思いつくもんだとおもうけど
弾幕じゃなくて、3Dでも2Dでもアクションゲーにしたらどうだ? 音のデータによって闘う敵が変わる感じだ もっとテンションあがるかもしれないぜ
東方二次だが弾幕蓄音機っていうのもあるぞ アレは音楽に影響してるの弾幕の生成位置とタイミングだけだった気がするけど
>>621 もっと簡単な方法ってどんなイメージなんだ?
パラパラ漫画方式は、動画を表示するための基礎だし
汎用的なクラスなり関数なりを作っておけば、爆発以外でも使えるし
下手すると、表示はすべてコレだけでもいけるぞ
複数の絵を組み合わせる方式は、動的にエフェクトの様子を
変化させるために使うのだが、
この方式もパラパラ漫画と組み合わせて使うことで真価を発揮するものだぞ
あとはゲームには向かないけど、光の粒を物理法則にそって計算して
リアルな状態を作るとかあるけどな。
音たま風脊髄反射であっちょーですね。 これは期待w
日本語でおk
「脊髄反射であっちょ〜」って、今の人らは知らないんじゃないかな・・・?
あんたら宣伝用にプレイ画面の録画とかする時あるでしょ? その時どのツール使ってる?
AmaRecCoでいーんじゃねーの?
はーい。じゃあ俺もそうする。
アマレコってやつか
>>637 AMVコーデックはシェアウェアだが
AmaRecCoで利用する分にはタダだ
でも、登録しないと左下の方に「AMV」ってロゴ出てくるから注意な
ニコ動とかでAMVのロゴ出たまんまの人結構いる所を見ると
知らない人割といる予感
俺はMSのやつ使ってる 画面に余計な宣伝入らないし ただ10分以上録りたいなら有料だけど
ごくごく普通にwme
基本的にfraps
俺もアマレレコ使ってたけど、Bandicamに変えた。 こっちの方が手軽に操作できるし、ヘボPCでも多少はマシだと思えるくらい軽かった。 もちろんタダで使える。
>>632 あ〜、昔そういうゲームがあったのか
ぐぐってやっとわかった
やってみたいけど、X68000とかPC98用みたいだから無理か・・・
残念
DxLib3.0にしてから、キャプろうとすると不具合が出るんだよなあ。 何度か試してると上手くいくから、そこまで問題にはならないんだけど。
647 :
名前は開発中のものです。 :2011/07/13(水) 01:43:00.30 ID:9PnxXa1e
最近感じるようになってきたんだが、c言語リアル初心者にいきなりゲーム制作 は厳しい闘いだな とりあえず スタート画面 → メニュー画面(ストーリー、武器選択、武器開発、部隊編成etc)→ 戦闘 という流れは作ったものの、細かなところまで作り込んでいくのは到底無理な気がしてきた という形は
そこまで作ったなら十分すごいと思う そういうのは一度作ったら使いまわしができるから、かなり楽になるんじゃないの
例えばスクリーンショットを取るAPIがあるけど 画像サイズを大きくしていくと突然強制終了するようになる たぶんビデオメモリの容量でデータ量が決まってるぽい 俺が間違ってるのかDXlibが間違ってるのか何も分からないし DXlibの実装を見てやっと分かったわ。 それからはスクリーンショットをとるときは自分でfopenとかfwriteとか使って やるようにしたわ たかがスクリーンショットとるのに何でビデオメモリ使うんだよ
DirectXのライブラリだからじゃね? ゲームが作れるということを売りにしてるけど、実際は単なるDirectXのライブラリでゲームライブラリっぽくない。 スクリーンショットを撮ってメモリ上でいろいろやったりできるだろう。 ただとって保存するならDirectXのライブラリを使う必要ないし。
まぁライブラリのスクショ機能を使わないと実装できない処理もあるんだけどな 例えば普通のスクショだと、スクショにだけ写り込ませたくないものを除外して撮影とかできない ……たぶん
>>648 >>649 違うんだ
確かに頑張ったつもりではいるんだけど、インターフェースとかAIとかかなり
ウンコレベルなんだわ
細かなエフェクトとか全くないし、AIが糞みたいな動きだし、不完全すぎるのが問題だ
それは言語初心者とかそういうプログラミングの問題ではない
いかなる改造をしたら「それ」っぽく見えるかというアイデアが必要なのだああああ
656 :
とんちゃもん :2011/07/13(水) 14:59:47.06 ID:jc99v67W
>>650 スクリーショットを作る方法はDirect3Dのバックバッファテクスチャを
画像に変換するのが一般的で、テクスチャを作れるサイズが
実行環境のビデオカード次第だからそれを超えてはならんのですよ。
強制終了することはないだろ
658 :
名前は開発中のものです。 :2011/07/14(木) 01:51:01.54 ID:+qxB3wjg
エフェクト作ったらバグって何も表示されなくなった これだから・・・
>>653 C言語初心者は関係ないじゃん。
発想とセンスとノウハウの問題だ。
市販のゲームプレイしまくって、自分でもゲーム作りまくるしかない。
AIは難しいよなー アクション系ならいくらでも誤魔化せるんだが、テーブルゲームやシミュレーションだと永久に止まったり弱かったり・・・
ゲームを沢山遊べば面白いゲーム作れると思ってる人いるよねー。 音楽聞きまくれば、良い音楽が作れる理論に同じw
そりゃただ遊べばいいと思ってる奴にはな
他のソフトいろいろ触った人じゃないと、かゆい所に手が届くUIって なかなか難しいと思う。 そういうこと考えずに触ってるだけとか、単に画一的になるだけ になる恐れはあるけれども。
664 :
名前は開発中のものです。 :2011/07/14(木) 15:38:34.84 ID:CyI75f3H
まじでそういう勘違いな企画屋が居るから困る
あ、プロの方いたんですか^^;
UIに注目してノートを取りながらゲームをするなら意味あるかもしれんな。 意識した行動をとらずに普通に遊んでしまったら駄目だと思う
RPGのメニュー画面とかSS撮ってフォルダにまとめてる
触ってて気持ちのいいUIってのは確実にあるよな
STGの本で、敵のパターンやら弾幕やらを、簡単にアルゴリズム付きで紹介してるやつがあるけど、 あれのUI版みたいなのが欲しくなるね。
好きなゲームのスクショとか資料フォルダに大量に保存してあるな 個人的に気を付けてるのは、ウィンドウやメニューを表示する際に2〜8フレーム位のアニメーションで出すこと これをやると、ただパっと出てくるのに比べて自然と目線がそちらへ向かうのでスムーズにプレイできる 8フレームまでならウェイトうぜー、って心配もないし
>>661 音楽聞かずに音楽作ってるやつの曲なんて、耳障りなだけだろ。
ゲームをプレイしない奴、ゲームを好きじゃない奴、
そういうのが作ったゲームはストレス溜まりすぎてプレイできねえぞ。
面白くもなんともない製作者自己満足ゲームにしかならねえ。
何を言ってるんだキミは。 661は音楽聴かないほうがいいなんて一言も言ってないだろう。 読解力が無いのなら、もっとたくさん本を読んで、身につけた方がいいぞ。
>>672 むしろお前が
>>659 と合わせて見直せよ。
ゲームを沢山遊べばプログラムをほとんど書かなくても面白いゲームができあがる、
それこそ何も考えずにゲームをひたすらプレイすれば面白いゲームができあがる、
その考えは間違ってますよ。なんてくだらないこと言ってるわけじゃないだろうに。
さー、そろそろDXLibの話題にもどしましょうね〜
675 :
名前は開発中のものです。 :2011/07/14(木) 21:17:31.60 ID:Cp8vQO2+
名人企画様乙
すまんが君の文章は解りづらい。 ちゃんと主語を明確にしてくれ。何が言いたいのか、結論もきちんと述べてくれ。
いろんな意味でスレ違い
678 :
名前は開発中のものです。 :2011/07/14(木) 23:37:01.61 ID:+qxB3wjg
ここにいる奴は一人で企画、素材、実装の全役勤めてるんじゃないのか? でもそれが面白いんだろ で一人で詰め込んでると気が滅入るから、そうならないようにゲームをプレイする って感じだな
別に自分の好きなように作りゃーいーだろ どうしても思ったようなUI作れないんだったらどっかから自分のイメージに出来るだけ合うようなのパチってくりゃいーだけ どうせどこぞやに出品する程のもんなんて作るわけじゃねえんだろ 最悪四角書いてりゃ実用的には事足りるわけだし
>>650 ソース見てみたけど、ビデオメモリ使ってなくね?
extern使うことは妥協に他ならないのか?
妥協でも何でも完成すればよし 何本くらい完成させたことがある?
683 :
名前は開発中のものです。 :2011/07/15(金) 12:08:10.06 ID:sINpyDal
>>682 まだ0本、ガチ初心者だし
LoadGraphが宣言の時にできないって仕様がなんとも使いにくいんだが
なんかいい方法ないかな
画像ロードするためだけに初期化関数つくらなくても使えるようになりたいわ
ヘッダファイルでLoadGraphを書きたいて事?
685 :
名前は開発中のものです。 :2011/07/15(金) 12:41:54.64 ID:sINpyDal
そうなるのかな ソースファイルの配列宣言するときに書きたいんだけど Enemy_t Enemy[5][10]={ /*鋼鉄軍 */ /*Ctrl, hp, en,EnAtk,FiAtk,EnDef,FiDef,speed, rotate, saku, Egen,jspd, gear, maai, rad,haichi, jimg,image*/ {/*No1*/{ 0, 100, 100, 0, 0, 0, 0, 0.5, PI/120, 300, 0.3, 1, 2, 100, 5, 0, jet1, ship3},//LoadGraph("jet1.png"), LoadGraph("ship3.png") }, /*No2*/{ 0, 200, 200, 0, 0, 0, 0, 0.5, PI/120, 300, 0.3, 1, 2, 100, 5, 0, jet1, ship3a},//LoadGraph("jet1.png"), LoadGraph("ship3a.png") }, }, /*焔軍*/ ・・・ って感じなんだけど、宣言と同時に初期化してもLoadGraphはできなかった すげー不便だと感じた
エスパーするとグローバルスコープでその配列からデータを作るクラスを実態化とかしてるのかな なんにしてもDXライブラリの仕様に文句つける前に言語仕様を理解できていないことだけは確実 初心者はサンプル参考に定石どおり組んだ方がいいよ
たぶんDXライブラリ初期化するまえに呼ぶからじゃないのかな。 class作って動的に生成したほうが楽だわ。 C言語だけならデータ更新関数作ってライブラリ初期化後に呼ぶか グローバル変数をあきらめる。
そもそも、おんなじ画像を2回以上LoadGraphするのは無駄が多すぎるから、 そんな書き方は普通はありえない
689 :
とんちゃもん :2011/07/15(金) 13:20:05.46 ID:UPz+2Wt3
>>685 /*鋼鉄軍 *//*焔軍*/ だと・・・?中二心がくすぐられるぜ
>LoadGraphがライブラリ初期化前に呼べない
簡単に言えばDirect3DのテクスチャはDirect3Dによって作られた
ウィンドウから生成されなければならないから、
とにかく最初に初期化によってウィンドウを作る必要がある。
初期化前に行った場合に遅延処理という実装方法もできると思うけど
画面(シーン)の切り替えが起きるようなゲームだと結局クラス化
するから同じ事よ
690 :
名前は開発中のものです。 :2011/07/15(金) 13:44:56.71 ID:sINpyDal
素直にやったつもりがボロボロじゃん・・・
どうやらクラスは必須なんだな
まずはCって思って作ってたけど、c++にも手を出す日が来が来てしまった
ちょっと勉強してきますわ
>>689 最初に作るものなんだから内容は定番でいいんだ
まずはCを、って言われて勘違いしてる人がたまに居るけど、Cは実践では使えないぞ ゲーム制作においてCはあくまでC++学習用の言語だと思ったほうがいい それだって、理由は文法の教本がみんなCで書かれてるからって理由だし、 webを資料にするとかならいきなりC++から触ったほうが効率いいよ
別にcで何ら不都合ないんだが。 oopが必要なら所だけcでソレやりゃいいし、 stlが便利とか言うけど、cでライブラリ拾ってくりゃリストとかすぐ使えるし。
そんなことするくらいなら最初からC++でええやん
694 :
685 :2011/07/15(金) 14:42:58.10 ID:sINpyDal
クラス、継承とか一通り読んでみたけど、C++まじで意味不明だった 今回の問題がどうやってクラスで解決するのか考えてみたけど、よくわからなかったわ とりあえず今回のゲームはCのみでそれなりに進んじゃってるから 途中からC++混ざるよりは、今回はCだけでやりとげる方がいいような気がした で次に作るのはC++を最初から使って作るよ
本質はクラス云々じゃなくてテクニックな件。 そもそもEnemyの配列は固定サイズでいいのん?
クラスは機能が拡張された構造体って考えればいんじゃね 「龍神録プログラミングの館」は読んでみた? 全くの初心者ならとりあえず読んでみることを勧める
>>694 クラスなんて関係ないよ
問題はDXライブラリ初期化以前にLoadGraphを呼び出していることであって、
それはクラスで書き直したとこで、グローバル変数にしてたら解決しない
素直に初期化関数を書いたほうがいい
698 :
名前は開発中のものです。 :2011/07/15(金) 15:40:47.67 ID:sINpyDal
>>695 50体作れれば十分かなと思った
これ以上は増えないと思う
>>696 クラスってそんなもんなの?
呼んだのは旧新プログラミングの館
龍神録はextern使ってて、それはよくないことって書いてあったからあまり読んでないな
ノウハウで必要なところは読んだりしてるかも
>697 classのが楽なのはこの場合は LoadGraphするのをハンドルが必要なときまで遅延させるのを 隠蔽しつつ楽に書けるからだけどな。 グローバル変数で値設定しても問題なくなる。
>>699 どういうこと?それって値設定の時点でLoadGraphしないってことでしょ?
そしたら結局、画像のための初期化の手続きを踏むことになるんじゃないの?
ちょっと遅れたけど、どうしても初期化の時点で使える状態になってて欲しいならこんなのはどうなの /* ヘッダー */ extern Enemy_t *Enemy(int a, int b); /* ソース */ Enemy_t *Enemy(int a, int b) { static Enemy_t array[5][10] = { /* 初期化 */ }; return &array[a][b]; } 使うときはEnemy(n, n)って感じになるけど(ポインタなので注意)
まあ最初は「関数をメンバに持てる構造体」程度にクラスは認識しておけばいいと思う 使ってるうちに慣れるし、逆にある程度使ってみないと利点なんて見えてこない 合間合間に独習C++あたりでも読むと思わぬ発見があったりして面白い
相変わらず、みんなの言ってる事がほとんど理解できない。 そんな俺でもすでに二本ゲームを完成させたし、三本目も半分くらいに達している。 これも全てDXライブラリのおかげ。
言語なんて所詮手段。完成させることが一番大事よ
ゲームで使うOOPはそれなりに高度になるからな 入門者がなんとなく始めてもあれこれ悩む時間が増えるだけでいい結果にはならないと思う
ただまあ一つだけ言えるのは、生のDXライブラリの関数を全体にばらまくのだけは避けた方が良いかな あとで仕様変更したくなったときに大変なことになる 例えばDrawGraphにしたって、捻りの無いネーミングだとmyDrawGraphみたいにして一枚噛ませることだけはしておいた方がいいね 仕様変えたくなったら後でオーバーロードして好きにパラメタ追加できる
707 :
名前は開発中のものです。 :2011/07/15(金) 17:46:34.30 ID:sINpyDal
>>701 いや、まじでありがとう
さくっとできた
すげーな、returnするならintかdoubleくらいしかないと思ってたわ
まさか構造体そのものを返す関数なんて考えたこともなかったや
本当に感謝です
>>698 そんなもんだよ>クラス
関数と構造体がくっついたものって考えでもさほど的外れじゃ無いと思うぜ
externが良くないっていうけど、その情報はどこから拾ってきたのよ?
初心者が個人で開発する規模で
何か都合が悪いことが起こるとはおもえないぜ
個人とチームじゃ勝手が全く違うからね
自分が開発しやすいようにやればいいのさ
グローバル変数イクナイ!とか半分宗教的に書いてるところとかあるけど、
初心者はそんなもの気にしちゃいけませんと個人的に思う。そこら辺
>>705 と似たようなことを思ってる
グローバル変数とかexternが何で良くないかとか、実際に使ってみて不都合が起きてから考えればいいんだよ
ただ、C++で作るならバッファオーバーランとメモリリークにだけは気をつけておいた方が良いとは思う
初心者の頃にここでハマると原因が特定できないまま延々悩むことになるw
あ、ちなみにこんな自分はbreakもcontinueもgotoも躊躇いなく使いますw そっちの方がコードが綺麗に書けるんだったらわざわざ封印するのも馬鹿らしい
breakとcontinueは使うがgotoはなんか怖くて一度も使ったことないわw エラー処理ならthrow-catch使うのが筋だし
宗教の話ばっかりでつまらんスレになったな
gotoは流れの見通しが凄く悪くなるから多人数開発では不味いけど、 自分が見通し分かってるんだったら何の問題もないんじゃないかなあ 俺は場合によって丸々飛ばしたい処理があるときなんかに使うかな フラグ立ててifで無視させる方が何か綺麗じゃない気がする。ネストも深くなるし 戻る方向ではループで囲めばいいから使わないけど 基本は関数に分割して無視させたりするけど、分割した方が見通し悪くなることもあるし
try-catch悪くはないがfinalyねーからな。
>>712 悩める子羊がいるから、それは悩むことではないのです、って言いたいだけなんだけどw
糞の役にも立たん説教ばかりされてもだな
gotoが害悪だという話が出たのは1968年頃なんだよね。 高級言語というとFORTRANとかBASICが主流の時代で この頃は構造化プログラミングというところまで、まだ進歩してなかったので 確かに多くのプログラマがGOTOを乱用してスパゲッティなコードを書いていた。 でもその後、構造化プログラミングの考え方を取り入れた CやPascal が出て 構造化プログラミングは基本中の基本になったし gotoは上手く使えば有用なので 確かに危ないといえば危ないんだけど、無闇に毛嫌いすることもない気がするんだけどね…。
>>716 そもそもお前は説教されてねーだろw
何だその被害妄想はw
756 名前:名前は開発中のものです。[] 投稿日:2011/07/15(金) 18:13:42.99 ID:qXxkBsjG で?完成したゲームはどこにあるの? 某スレからコピペ同じことがこのスレにも言えるな。 てか、この板全体だが
720 :
名前は開発中のものです。 :2011/07/15(金) 20:59:03.64 ID:sINpyDal
>>703 の完成した2本のゲームをやってみたいな
どっかにアップされてないの?
>>719 ドヤ顔で2chに自作ゲーム晒されても何も言えねーだろw
>721 wwwwwwwwww 確かにそうだなw
想定外のコントに思わず吹いたわwwwww
>>709 バッファオーバーラン、メモリリークなんて言われてもどれだけの人が理解できるだろうな?
ここの住人はへっぽこ三流プログラマー多いもんな、C++でメモリ管理やオブジェクト指向がわからないとか恥意識無く平気で口にするし
メモリアクセスのバグについても存在すらわからんって言ってる奴も居る
変数のスコープは出来る限り短くする、グローバル変数を多用しないというのはC++の常識なんだけどね
結局はきちんとした作法と正しいプログラミング知識を身に着けようと努力しない奴らが多すぎて困ったもんだ
ゲーム製作を目的にプログラムを始めた人に対して その常識や知識を最低限叩き込めるサイトがテンプレにあればいいんじゃない、コード規約にならん程度で。 そういうのがあれば、初心者のDXライブラリの使用率が高そうだから公式でも紹介してくれればいいね
>>724 まあメモリアクセスのバグが見つけられないようだと後で悲惨なことになるから、
そんぐらいは理解できる力を身につけてから本格的にゲーム作りを始めた方がいい気はするな
>>724 そもそもここの住人は職業プログラマじゃないもの
良くも悪くも作法や規則には縛られないんだよ
>>724 そういう口だけの奴ほどゲームを完成できないという事が
この板全体&ブログでプログラミングについてあれこれ語っている奴をみてきて良くわかった
なんというか無知だけど情熱だけで突っ走っているタイプの方が
ゴール目前まで言っている事が多いww
ああ、それはよくわかるw
なんつーか、プログラミングでもそうだけど ゲームの仕様から、キャラ設定に至るまで 「本当にこれでいいのか?もっといい方法があるんじゃないのか?」 って考え始めると、そこから中々進めなくなる
しょぼんのアクションとかそんな感じする
733 :
名前は開発中のものです。 :2011/07/15(金) 23:05:38.88 ID:sINpyDal
俺とかむしろ絵師なんだけどな ただゲーム作りにおいてオールマイティになってみたかった ゲームプログラミングの館でC++での解説がないのが問題
734 :
名前は開発中のものです。 :2011/07/15(金) 23:06:53.96 ID:6TwBqCXy
なんつうか、昔見たソースコード if文だけを使ったテキストアドベンチャー、作者は超初心者なのだろうけど 膨大な量のif文の羅列 ちゃんと動くのよね。 最初の一歩は、とりあえず完成品を見せること。 次は、改良ですね。
本当にプログラミング用語を連発している奴は完成しないなw ゲーム製作に興味が失せたのなら仕方ないが ジャンルや言語だけがコロコロ変わる 理屈と脳内仕様書だけを熱く語って終わり 仕様書?知らんがなwwww という感じ場当たり的にゴリゴリやっている奴のがゲーム製作している しかし後者は70〜90%あたりで壁にぶち当たりβ版で完成としてしまう ま、前者みたいに口だけで10%で投げ出す奴より良いがwww
>本当にプログラミング用語を連発している奴は完成しないなw てめえw これでも作ってるゲームは5割以上出来ていて体験版公開もしてるんだぜと自己弁護しておくw まあ仕様書ナニソレなのはその通りだけどw
趣味グラマに対して作法とか正しいプログラミング知識とか何言ってんの。 ゲーム作りたいだけの人間にとっては入門書すら必要ないわ。わからないことだけググってりゃいい。 ひたすらやりたいこと実装してりゃあ完成するよ。むしろ一個一個丁寧に練ってたら終わるものも終わらん。
個人ゲーム製作でフローチャートやら仕様書とか言い出す奴はマジで駄目だな 形式重視型はなぜゲームが完成しないんだろ? 「何事も基本に忠実に」ってのが有利なはずなのに、そういうのに重きを置く人達のが投げ出して そういうのを疎かにしている人達のが完成しやすい ゲーム製作の謎!
完成させてほしかったら金出せや
741 :
名前は開発中のものです。 :2011/07/15(金) 23:43:03.34 ID:6TwBqCXy
フローチャートは重要、完成へのキーワードだよ
>>738 個人ゲーム製作は行動力が鍵。マジで
考える前に作る。作ってダメだったら捨てる
うだうだ考えるよりもそれが一番早いよ
と、分析にもならない分析をしてみるw
ただ、嵌ってどうにもならなくなるバグに関してだけは把握しておいた方がいいと繰り返してみる
>>735 壁にぶち当たるのは間違いないね。
完成まではいけるけど、結局自分の手の届く範囲までしかやらない。、
さらに上の段階の物を作れない。作れると思えないから作ろうとしない。
頭良い人なら壁にすらならないものが、全く越せない。
>>738 個人ゲーム製作で一番大事なのはモチベーションだからね。
期限もなければ報酬もない。結局時間が経って飽きて、次のゲームに取り掛かるループ。
while(寿命>年齢) { if(やる気>0){ ゲーム製作[i] } else{ i++: } }
>>737 どうしてこんなに開き直れるのかな、出来ないプログラマーの典型例か
趣味にしろ本業にしろ正しい知識とマナーを身に着けるのは、バグを出さずソフトウェアを正常に動かすために大事なことじゃないのかな
特にC++でソフト作るなら尚更ね、他の高級言語ならまだ作法が緩いだろうけど
完成完成ってうるさく言ってるけど、バグまみれのソフト完成させても自慢にならないでしょ
それにC/C++のメモリアクセスのバグは非常に厄介だし最悪システムに損傷与える可能性もある
自分のPCだけで動かすのは勝手だが、間違っても他人に配布しないで欲しいよな、たとえ無料でも
どこを縦読み?
ナーシャジベリとかバグだらけだったけど面白いゲーム作ったよな
749 :
名前は開発中のものです。 :2011/07/16(土) 00:16:17.51 ID:kFJQ2zKw
>>746 でも完成させなかったら、バグだらけで完成しないよりも意味がない
って言ってんじゃね
モチベーションを上げるためには妄想を膨らませ、完成図を思い描いて興奮してればいいよ
出来ない奴のためのDXライブラリでそない講釈たれてどうすんだ バグ上等の心意気と寛容さがないと前進しねえぞ
どうしてこんなに開き直れるのかな、気持ち良いオナニーを知らない典型例か 趣味にしろ本業にしろ正しい知識とマナーは身に着けるのは、精液を出すチ○コを正常に動かすために大事なことじゃないのかな 特に二次で射精すなら尚更ね、他の高級三次ならまだ作法が緩いだろうけど
バグ上等(ゴリ押し)は二点三点する事が多いからバグでても問題ないかな そうしてバグ混じりだが、自分好みのソースが大量生産され その結果使えるパーツが増え、ゴールに近づく 頭でっかちな事をやっているなら突き進めって事でしょ
>その結果使えるパーツが増え、ゴールに近づく これは本当にあるある
さくっと本で勉強してしまった俺はチキン・・・
本で勉強することを否定するものじゃないだろうさ
>>746 バグ出たら直せばいいと思うよ。つーか、個人規模でバグなんてそんなにでるか?
あなたの応用力がなくて規則通りにやらないとバグでちゃうだけだと思うんだけども。
んで、バグだらけの市販ゲームははたして三流プログラマーが作ったものなのかね。
ゲーム機が壊れるのが怖くて、とてもじゃないけど市販ゲームはできないねw
>>755 参考書の方がまとまってて見やすいし買って損はない。
一冊が高いし、今はネットで気軽に調べられるし言語の勉強したいんじゃなければ買う必要はない。
758 :
名前は開発中のものです。 :2011/07/16(土) 00:37:11.96 ID:kFJQ2zKw
俺デバッグするたびに1000行ものエラーが出てるの放置してるわ
>>758 それwarningだろ
どうでもいいレベルのwarningはdisableで黙らせればいいような
本を活用できるならいいけど ・本で理解した『だけ』 ・本を読んで満足 ・理解する事ばかり専念して、製作時間を回せない ・本に依存しすぎて応用力が無くなる ゲーム製作ブログ系ってそんなんばかりだから 本から入る人=駄目ってイメージが付く ゲームを作るための本なのか、本を元にゲームを作るのか
正しい知識と作法を身につける事は大事だろうが、 それがない、イコール、バグまみれ、というのはいささか決めつけが過ぎるんじゃないか。
>>761 典型的な依存型でしょ
こうなんだから、こうするのが正しい
個人製作でなく、ゲーム製作でなく
業務用プログラマーなら仕様書さえ渡せば、その通りに動いてくれそうなタイプだから
IT土方としてはエリートとかも
単体テストとかやらせたら優秀なタイプ
みんなガンバw
>>762 依存症というかそういうのは強迫観念っていうんじゃないか?
作法どうこうよりも、書き方の統一とコメント文がやっぱ大事だと思うぜ
メモリ管理とか面倒ならC#でやれば、大体解決!! ガベージコレクションまじ最高!! 使わないオブジェクトとか放置でOKとかC++で泣いてた俺がお勧めします。
寧ろバグ出しまくってこそそのバグに対する対処法が身につくというもの
>>746 今時PCに直接損傷を与えるようなメモリバグなんてありえるの?
プログラム終了時にはnewしたものは絶対にdeleteしないといけないとか思ってるタイプ?
firefoxなんかも超有名だけど、メモリリークが酷過ぎる
769 :
名前は開発中のものです。 :2011/07/16(土) 06:46:06.87 ID:q6xm95Kb
おまえら一度、外人達が書いた汚いオープンソースのゲームソース読んでみろよ。作法も何もあったもんじゃないが。ちゃんと動くぞ。
>>767 万太郎乙
c++使えるなら使えばいいんだけど、コスト度外視して人に薦める奴多すぎだろ。
c++使った所でコーディング量減るわけでもないのにさ。
それならcで自作した方が学習コスト分早くゲーム作れるわ。
せっかくDXライブラリがBASIC並に簡単にしてくれてるのに。
つーかどうせ2Dだろ?cで十分だろww
情熱で突っ走ると完成する可能性は高いよ でも、見てきた限りでは何故か独り善がりなクソゲー率も恐ろしく跳ね上がるんだよねw 結局のところ製作と学習にそれぞれどれだけ割り振るかのバランスが大事じゃないのかね 初心者が評判の良い入門書をざっと読むことが害になるとは思えないし、 実地での製作経験がゼロの人がクラスを駆使したデザインパターンまで学んでも その段階で益になるとも思えない、みたいな
>770 DXライブラリが標準でC++用になってるからC++使ってるだけの事。 それをわざわざ違うのにするとかコスト度外視もいいところだよ。
細かいこと気にしすぎて進まなくなるよりはがんがん作って経験積んだほうがいいんじゃね それとそんなに初心者の事考えてやれるなら作り方でもTIPSでもアルゴリズムでも設計方法でもブログなりwikiなりにアップしてやれw
GC付き言語は初心者を狂気の沙汰へ誘うけどな フレーム更新のたびにnewしまくりとか
Cで書いてるったってC++コンパイラ使ってるんだろ? コーディング量だってテンプレートライブラリ使うだけでも激減するし 変数を途中で宣言とか名前空間だけでも有用すぎる。 わざわざ純粋なC言語として書いてコンパイルする必要性も無い。
D言語ですねわかります。
Dなら効率的に書けるかわりに言語仕様の破壊的変更でコードそのものを粉砕してくれるよ!
D言語使ってる連中こそ宗教団体のようできもい。少ない仲間を集めて集会開いてるイメージ
779 :
名前は開発中のものです。 :2011/07/16(土) 11:40:46.67 ID:kFJQ2zKw
そうだな 構造体に関数いれてみたら、なんと動いてしまったからな 俺はcだけをつかってるつもりで、知らず農地にc++を使っているのかもしれん
コストとか本人の問題だし、Cに拘る必要が無いのもわかるけど Cを理解せずにC++なんて無謀にも程があるからな Cでゲーム作れとまでは行かなくても十分理解するための経験は必要 ところでおまえらは誰と戦ってるんだ。俺は初級者向けの話をしてるもんだと思ったけど
782 :
名前は開発中のものです。 :2011/07/16(土) 12:43:01.85 ID:jQtLQay0
そら、あの方に決まっているだろう
メンバに関数持てるってだけで柔軟性が飛躍的に増すからな そのためだけでもC++にする価値はある
C++を特別視する思考がサッパリ理解不能なんだが
C++は基本的にCを内包してるんだから、C++を選んで必要な部分だけを使えばいい
>>781 みたいな考え方こそ初心者には害悪
アクセス権を学べないCから入ると設計をいちいち勉強し直さなければならないし、ここでへんな癖がつくと後々厄介 C++から入ればJAVAでもC#でもASでもあっさり習得できる。この3言語は使えるとなにかと便利 問題点は複数プログラマで作るときに規約をがっちり決めとかないといけないことぐらいなので個人製作ではまず問題にならない わざわざCから始めるくらいならその時間でアセンブラかじったほうがゲーム制作にははるかに有益だよ
そろそろ
787 :
名前は開発中のものです。 :2011/07/16(土) 13:24:30.76 ID:FSPWn2j2
名人様、布教活動ご苦労様です。
789 :
とんちゃもん :2011/07/16(土) 13:32:11.97 ID:wCHDAvML
C++は最初は全部publicなクラスだけ使ってればいいと思いますね。 継承とかはあとあと覚えたら使うぐらいの気持ちで とりあえずファイル拡張子を.cppにしておけばいいのですよ。 あとはjavaを少しずつ学んでいると クラスのパターンとか名前のネタや無名クラスの使い方とかが身につくかも。 ちなみにC#ではなくjavaなのはググったときの情報の質です。。
経験積んでから〜なんて言ってたらいつまでたっても始まらんよ。 案ずるより産むが易し。迷わず行けよ。行けば分かるさ。 初心者はまず手を動かすこった。
C++の細かい内容は 「うーん、○○したいけど上手く行かない・・・何か良い方法ないかな」 って思ったときに参考書パラパラめくる程度でおk
792 :
名前は開発中のものです。 :2011/07/16(土) 14:48:06.67 ID:kFJQ2zKw
ほんとLoadGraph関数って面倒事起こしまくるな なんで他の値は全部格納されてるのに、画像ハンドルだけ格納されてないんだ ステルス機体ばっかじゃねーかよ
>>792 戻り値が-1になってないか?
原因としては
・初期化前に呼んだ
・ファイルのパスが間違ってる
・そもそも戻り値を取得してない
・取得はしたがスコープが変
って感じだと思うぞ
>>792 超初心者だけど俺も詰まった所
そしてあれこれ考えるのが嫌でDeleteしてからLoadするように組み合わせた
ググればもっといい対処方法がみつかったりもする
Deleteせずに同じ画像ファイルをなんども呼び出したり
Deleteのタイミング次第で、意図しないハンドルが消える
そもそもDeleteせずに同じ画像ファイルを何度も呼び出すのが良くない そんなことやらないからどんな不具合が生じてるのか分からんけど
>>795 当初は
func()
{
gazou1=LoadGraph()
途中で送信してしまった といった感じの関数を作り、同じ画像ファイルを呼び出だしたとしても 入れる変数は同じだから上書き保存!的な処理にしたつもりだった まぁ、792がどういった感じで詰まっているかは知らんけど
>>797 それアウト
Deleteしないとメモリ領域が開放されないから、重複読み込みはそのままメモリリークになる
>>798 あ、ちょっと使ってるバージョンが古いから最新版では対策入ってる可能性もあるけどね
けど、動的に確保されたものはきっちり解放する癖をつけないとメモリリークに悩まされるよ
自前のCreateとDeleteするクラスor関数作って mapでファイル名キーで参照カウンタ変数とハンドル保持して Createで読み込み済みならそのハンドルでなければ新規読み込みしてカウンタ+1 Deleteでカウンタ-1してカウント0なら削除 という仕組み作ればOk 外部でdeleteされる対策とかスマートポインタみたいのは難易度あがるから言語が使えるようになってから。
何というか、やっぱメモリ領域の概念に関して「だけ」はきっちり理解しておいた方がいいんだろうなと思った
>>797 みたいに落とし穴にはまって気付かないこともあるわけで
だからといって
>>781 みたいな意見には全く同意できないがw
ってか、使い終わったリソースって、開放しないのが初心者なのか それ以前に、せっかくメモリに確保したハンドルを使いまわししないで 新たに同じ画像を読むというのが、どうしてそういう処理するのか理解できん ゲームの基本処理って データのロードと作成 ↓ 操作とか当たり判定とかの処理 ↓ ↓(ループ)↑ ↓ 画面の描画 ↓ 後片付け って流れだと思うんだが、もしかして AVG形式のエンジン部分で、1フレーム毎に必要な 画像をメモリにロードするとかって作業をしてるのか?
>>802 毎フレーム読み込みってのは初心者が一番最初にやらかすことはあるみたい
まあそれは流石に重くて気付くことが多いみたいだけどね
けど頭にメモリの概念が無いと、新たに画像を読むっていうことを躊躇無くやってしまうんじゃないだろうか
メモリ関係のバグは厄介だし、メモリに関しては概念くらいは理解しておいた方がいいと思う
CありきのC++だと言いたかっただけなのに そりゃ俺だってC++なしでゲーム作ろうなんて微塵も思わないしやったこともないからw
LoadAllGraph( int Stage ) { //すべてのハンドルに対してDelete DeleteGraph( Handle1 ); DeleteGraph( Handle2 ); DeleteGraph( Handle3 ); … switch( Stage ) { case 0: Handle1 = LoadGraph(); Handle2 = LoadGraph(); … break; case 1: Handle1 = LoadGraph(); Handle3 = LoadGraph(); … break; … … } へたれ趣味グラマだからシーンごとにこういう関数呼んでる
>AVG形式のエンジン部分で、1フレーム毎に必要な >画像をメモリにロードするとかって作業をしてるのか? それに近いことをやる事になっているな ドット絵なんだけど1キャラあたり 400x400 1動作あたり10モーション 1キャラあたり8動作 300x300の画像が8*10で80枚 (数字は大袈裟にしているがそんな感じ) そういうキャラを数十体同時に出そうとして、始めに画像情報を全部読み込んで〜ってプランは早々に変更することになった 普通はそんな作りにしないんだろうけど
ポインタを理解しようとしたらメモリに対して理解深まるよ
>>805 俺は使う画像と使わない画像をフラグで管理して、立ってるものは読んで立ってないものは消すようにしてる
画像は管理用のクラス作って、自分がいじるのはそのクラスの内容
プログラム初期化時、画像管理クラスにファイルアドレスをセット。
別に画像管理クラスへのアドレスを一覧としてまとめた配列を用意して、ファイルアドレスセット時にこの配列にクラスのアドレスを登録
読み込み/消去はこの配列を利用してイテレート
ってやって取りあえず冗長な部分はなくせたと思う
概念的にはこんな感じ class csImageInfo{ char *addr; int Flag: public: int Set(char *addr); }; class csImage{ csImageInfo *list[num_max]; public: int Update(){ for(int i = 0 ; i < num_max ; i++){ ... } } };
>>805 と
>>808 がよく言われる
完成一歩手前知識不足製作者
と
知識ばかりで実際にゲーム製作は頓挫する奴
の構図に思えるwwww
>>810 凄い節穴だなw
残念だけど、完成させたことくらいあるよw
ってか俺はずっと考えるよりも行動することが大事だって言い続けてるんだがw
むしろ「知識があるだけ」と「実践的なコードが書ける」の区別も付かない
>>810 は節穴ってレベルじゃない。
差詰め『「知識ばかりで実際にゲーム製作は頓挫する奴」をただ笑って何もしない野次馬』ってところか。
ID:0cJOmXZJにプログラムの技術がほとんどないってことだけはよく分かった ずれたツッコミって怖いね。うっかりすると自分のバカさ加減をさらけ出してしまう
>>805 俺もほぼそれ
せめてシーンをクラスに分けて、ロードとアンロードできないか考えているが
今は別のことをしている
私はRAIIでやってますね
>>805 それで十分なんだよね
なんかあれこれやってより高機能にしたがる人がいるけど
力を入れるところはそんな所じゃねーだろwと良く思う
一番最初に作ったゲームは if(scene==0) { //タイトル画面 } else if (scene==1) { //プレイ画面 } だったなあ。 第2作目でやっと関数分けされた。(それでも分岐はifのまま)
まあ作ってるゲームによるよね
ビッグスケールだと
>>805 の方法じゃ破綻するし
>>819 805で破綻するようなスケールを作ろうとする事が一番破綻する原因だと思うのw
数十時間プレイするような商業レベル物でも目指しているのかよwってね
この手の資源管理方法は個人レベルだろうが商業レベルだろうが変わらんよ
出来る奴はできるし出来ない奴は
>>805 みたいにとりあえず動くものでお茶をにごすのが正解
俺は表示リスト作って呼ばれなくなったものから消すようにしてる(一般的なキャッシュアルゴリズムと同じ方法)
今のグラフィックカードを基準にするとよほど無駄なグラフィックの使い方をしない限りDeleteGraphなんて使う必要もないんだけどね
読み込み量がたいしたことないなら 画像と効果音だけ最初に全部読み込んでもいいと思う。 BGMなんかはサイズがでかいから全部ってわけには行かないけど 特別な使い方しないならストリーミングで再生できるし。
シーン毎に読み込みと解放するだけだわ
人が書いたソースを見るだけでその人の部屋の散らかり具合が だいたいわかるようになった
あとはダブルポインタっていうやつは だいたいiphone持ってる これ定説
826 :
名前は開発中のものです。 :2011/07/17(日) 00:36:17.63 ID:9R7sKILt
>>793 ついこの前に質問したんだけどね
前に言ってくれた
>>701 みたいにやってたんだよ
で武器データも欲しくてShip_t Ship(int a, int b){ return Ship[][] }みたいな感じで
Sshot_t Sshot(int a, int b){ return Sshot[][] }で作ることはできた
この二つをセットにしたくて
typedef struct{
Ship_t Ship;
Sshot_t Sshot;
}ShipPare_t;
ShipPare_t ShipPare[5][10]={
{{Ship(0,0), Sshot(0,0)},{Ship(0,1), Sshot(0,1)},{Ship(0,2),Sshot(0,1)},
};
ていうのを作って、引数で&ShipPare[][]渡すだけで船体と武器のデータを得ることができるようにしようと思った
んだが画像だけロードされなかった
今の俺のレベルで考えられる原因は、使う時にShipPareP->Sshot.image;って感じだから
結局ロードされてないんじゃないかって思ったりした
お願いします
一体何人のソースと部屋を見て統計をとったのだ。
>>826 つstatic
Cなんて一度忘れて素直にC++勉強しろってば
データの動的管理を根本的に理解できていないからLoadGrpなんかで問題起こすんだよ
自分の無能をいちいちライブラリのせいにされるのを見るのはいい加減うざい
>>826 構造体の初期化は関数のなかでやらないと。
void f(int a, int b){
static ShipPare_t ShipPare[5][10] ={{ ship(0, 0), Sshot(0,0) }};
return ShipPare[a][b];
}
まあ、これでなかでLoadGraph呼んでても
DxLib初期化したあとにこの関数が呼ばれて
LoadGraph成功するけどさ。
ふつうはこのやりかたはしないな。
830 :
名前は開発中のものです。 :2011/07/17(日) 02:21:32.77 ID:9R7sKILt
>>829 ・・・
そうだった、今日で思い知ったわ
でも動いたよ、ありがとう
ゲーム作り始めて1カ月だからノウハウとか全くない
本当は正当なやり方とかしてみたいけどさ、まとまった情報がないんだな
ゲーム作りかC++とDXLibを始めて3ヶ月だが、独学と資料はネットだけでも十分な物ができあがるぞ(正当なやり方なんて気にしたら負け) ただ、ゲーム製作を投げ出す最初の壁みたいな物にぶつかった プログラミング的に困っているわけじゃないけど、あれもこれもと作業が増えてきて ゲーム製作の一番の醍醐味であろう色々な数値設定を決める部分の面倒さに投げ出したくなってきたw 「あの武器は攻撃力15ぐらいでいいだろ」 「あのユニットの価格は300Gでいいだろ」 「キャラ名。アイテム名。町の名前。スキル名」 あんな敵こんな敵。こんな攻撃。あんなスキル。こんな弾幕。あんなステージ。こんな敵配置etc 作る前は一番楽しい部分のはずだったのに、0から設定&全キャラ設定となると超面倒という事を思い知らされた そして糞バランスゲーができる原因を痛感させられたwww
それわかる。 でも人と組んでゲーム作るのもわずらわしいジレンマ。。。
初心者が初心者に語っちゃだめだろ 何をわかった気になってんだよ
はしかみたいなもんだが 自分の黒歴史を掘り返されてる気分になる
同レベルぐらいの人のが目線を合わせて会話出来るからいいな 自称脱初心者様は役に立たない 技術的な事を掘り下げた話をしたいならプログラム板か 外部のそれ系の所で聞いた方が良い 2chは行き詰まった時の 「初心者プギャーwwww」 「あるあるwwww」 「知識だけでゲーム公開できねぇ雑魚wwwww」 とモチベを上げる場所
解説サイト作ろうと思ったがDxLibとVC++のインストールと設定だけで めんどくさくなってきたw
それは公式に解説あったようなw 龍神録プログラミングの館で入門は十分かなって感じだし 作るなら中級レベル向けがいいかもね
>>840 ソフトの規模が大きくなると管理が大変になってバグが発生しやすくなる
>>820 みたいなこと言ってる奴いるけど、普通にでかい規模の作品作ってる奴とかいるだろ
視野が狭すぎ
っていうかぶっちゃけUcTd5altはド素人なのに一体何を言ってるんだ、って印象w
>>838 そうだね。。。でも中級ってどのくらいの人だろ?
Cでテトリス作れるけどC++で画面遷移のswitch文消したいとか
そう言う人には実際にアプリを組む流れを見せたいし、
Direct3D9知らないけどチューニングの大まかなコツ知りたい人には
プログラミングチップスがいいと思う。
お願いですから ID:UcTd5alt と書いてください。
仕様書(excel)などから自動でコード吐き出すような事してると普通に
>>820 みたいな記述になるけどなw
文字列リソースとかww
まあそんなに規模大きくない程度のものなら805で十分ってことだろ 規模が大きいものってなってくるとそれはまた別の話ってだけ
>>841 できればもう少し具体的に。
例えばStage数が増えると管理が面倒臭いとか。
これだと逆に言えばStage数が少なければ問題はないってことになるよね。
一般的にSTGならStage数は10以下だろうし、RPGなどでStage数をシーン数に置き換えても
多分5〜6までに収まるんじゃないんだろうか。
>>845 で、お前は何がしたいわけ?
もう結論出ちゃってます系の人なんじゃないの?
>>840 シームレスな動作にこだわりがあるかどうか
場面転換ごとにいちいちブラックアウトすることやフィールドがいくつかに分断されてても疑問を感じないのならば問題はない
俺はステージの繋ぎで一フレームも落としたくないので
>>805 みたいなシーン管理はやってない
switchを使わない書き方をしろっていうことなのかな、よう分からんが まあそれなら書きようがあると思うけど
てか
>>805 みたいに管理したい奴はしてればいいんじゃね?
ある程度慣れるとそっちのが手間だから、一回ちゃんとしたクラス作るのが普通だろうけど
>>805 のやり方で困らない奴はその程度なわけで
まあ別に作る人毎に仕様が異なるんだから805で足りる人もいれば805じゃまずいって人もいるってだけでそんな大した問題じゃない気がする
実際にそこまで大規模な物を作っている人っているのか? 構想だけでそんなでかい規模のゲームなんてフリーはもちろん、同人でも中々見かけないぞ ACT、STGなら6面 スクロール無しの1画面ACTパズル系?は30面ぐらい RPGならDQ1弱(街少々洞窟少々。全体マップ小規模) SLGなら8マップ程度 この規模でもちゃんと最後まで完成させたら賞賛する この半分の規模でも完成させたら超糞ゲーでも拍手を送る
>>847 ああ、シームレスにする場合は
こうやって一気にロードするやり方じゃダメなんだな…
俺なら、大規模ゲーなら挙動は自作のスクリプトに書き出してるだろうし、 そのシーンで使う画像をスクリプト舐めて抽出してそれを読み込む、って感じでやるだろうなー もしくは、シーンに関連付けた使う画像リストを外部ファイルで作る 大規模ゲーなのにプログラム直書きで画像を読み込むのが前提なのがおかしいと思う
まあ
>>805 の何が悪いって、
>>849 もちょっと言ってるけど生産効率
使い回し効かないしコピペで時間はかかるし修正するときに大変だしバグは出やすいしで良いことがない
最初から仕様がガチガチに固まっていて後で変更が絶対に起きないならまだいいけど、
何か仕様を変更したくなったときにこういう書き方だと大変なことになる
そもそも専用のクラス作ったとしても小一時間もかからんし、あとで使い回しが効くから最終的な効率は断然良い
まあ技術的な問題でクラス作るのに時間がかかるようなら無難に
>>805 の方がいいかもしれないけど
基本的にコーディングってのはスマートなやり方が一番作るの早いわけだから
>>851 その規模のを完成させてるし、委託販売もしてる
同人ならその規模で当たり前だろ。まあ俺がその規模の作品しか視野に入れてないって可能性も否定できんが
プログラミングを始める前 「ツクールゲーwww」 その後 「ツクールだろうがゲームを完成させた奴は俺より上」 1面作ったらそれで満足 ゲームと呼べるボリュームまで作り込む奴は偉い
>>854 いや、その規模なら805で済むという話であり、よくある同人レベルであって
大規模クラスっていうからそれ以上の物なんてそうそう見かけないというわけで・・・
それ以上のボリュームの同人ソフトで委託しているというとよくバナーでみかける東○のローグゲーでも作った人なんか?
STG、ACTでいえば6面ぐらいが個人製作目安で、それ以上は人が集まってガチ製作している集団だと思っている
そして集団でゲームを作っている人が、個人製作基準で語っている人が多いであろうこのスレで
集団製作基準であれこれ言っているとしたらちょっとKY
結局クラスって資産なんだよな。 俺は5年前に作ったユーザー入力を管理するクラスを今でも使い回してるわw 最初のうちは仕方ないけど、ある程度力が付いたら絶対に再利用を前提に作った方が良い。 開発のスピードが半端無く上がる。
いや、規模ってステージ数じゃないだろ 例えばポケモンみたいなゲームを作るとすると、モンスター画像が百以上必要になる またそうなるとそれを配置するマップもそれなりの枚数になる そうなると……って感じに考えた上で作業量が多くなるのがゲームの規模ってもんじゃないのか?
>>856 そもそもSTGは個人だろうが同人だろうが商業だろうが5〜6面が目安です。どうでもいいツッコミだけど
あと別に集団製作基準なんて言ってないけど?
技術無い人はベタ書きすればいいし、ある人は論理的に作った方が都合がいい。ただそう言ってるだけなんだけど
ところで、今まさにこの瞬間にライブラリが更新されたよ
覚え方は人それぞれだがいきなり便利だからとクラスを理解させるのは反対だな 最初はとにかくわかりやすく、そうして「もっと汎用性と利便性を〜」と不満を持ち始めた時 自ら新しい技術を求めて覚えた方が身に付きやすい しかし形から入った方が覚えやすいと言う人は 本と一緒に覚えた方が無駄が無いから、最初から全部覚えた方が良いはず 結局、規模、コード共に熱意が冷めない物を選ぶのが一番重要 冷めた時点でゲームオーバーだから
何かざっと見てみたけど、まとめる力のない人間があーだこーだと屁理屈並べてるようにしか見えない。
どう考えたって小綺麗なプログラムを手早く書けるならそっちの方がいいわけで、それを否定すんのはおかしな話だろ。
それができないって理由で
>>805 みたいな書き方をするのは別にいいと思うよ。
でもできないのに
>>805 を正当化すんのはあまりに見苦しすぎるだろ。
>>861 概ね同意なんだけど、俺は別に冷めてもいいんじゃないかと思ってる
熱して冷めての繰り返しで段々前進していくわけだから
逆に熱しすぎた後に反動が来たりしたときの方が大変。ゲーム作りなんて長丁場だし、ずっと熱しぱなしって方が無理があるよ
まぁプログラミングって顕著に出来る出来ないが分かれるからな このスレにも出来る人間と出来ない人間が混在してるわけで、そりゃ話も通じないだろうよ、と 結局、自分の技量にあった作り方をするのが一番 でも向上心を忘れたら終わりよ
同人で売り物レベルの作品を作るならそれでもいいけど 個人の趣味は冷めたらおしまい 集団製作っぽいけど、その場合良くも悪くも自分の担当という責任が発生するから 冷めても進まなければならないでしょ? 売り物ってのは今時なんとも思わないが 実際に絵や音楽担当と分業したプログラミングは怖いな スランプやバグでハマったらどうすればいいんだろ 極端な話、絵や音楽は他人を使うで済むが 自分の糞コードを他人に引き継ぐなんて無理!
個人は貴重な時間費やしてるから成果物が目に見えないと萎え萎えだろん?
>>865 それ逆だわ
個人の趣味だったら冷めてもあとで暖まればいいけど、集団だったら責任問題だから冷ますわけにはいかない
「進まなければならない」で進むほど集団製作は甘くない。そうなったら高確率で空中分解する
企業レベルになると流石に話は変わるが
個人の製作なんて冷めていいんだよ。冷めちゃいけないなんて思うから重荷になる
冷めたって製作が好きならまた暖まる。暖まらないなら、所詮その程度の気持ちだったってことさ
暖まった後でコードが訳分からなくなったならまた作り直せばいい。前より上手く作れるから
シームレス以外の問題点は例えばどんなのがありそう?
>集団だったら責任問題だから冷ますわけにはいかない 責任問題と重圧だけで冷めないもの? 表面的には頑張っていても冷めた(そこまでいかなくてもモチベダウン)らどうするの? こればかりは精神面・肉体面・本業の多忙さ等で同人といえども維持が難しい所では 個人製作のモチベ維持に役立つかもしれないから、同人製作のモチベ維持方法についてkwsk 仕事が多忙になって週末ぐらいしか弄れなくなると一気に熱が冷めるのが一番の悩みの種 再開すると継続せず、再出発してしまう
>>870 集団製作については、正直冷めるかどうかは指揮取ってる人間の力量次第だと思う
メンバーが冷めたりするのを監督者がきちんと把握して冷めない方向に誘導できるかどうかが鍵
まあ監督経験そんなに無いから上手い方法に関しては語れないけど。基本一匹狼だしw
そういうわけで個人製作のモチベ維持の話になるんだけど、自分の場合はユーザーとのコミュニケーションかな
自分の作ったものに対してリアクションがあるとやっぱりモチベ上がるよ
あとは自分の成長を逐一実感するとか。「ああ、今回この部分は前より上手く作れたな」ってのが地味に楽しい
俺も週単位で触らないときとかあるけど、モチベ回復させるのに困ったりはしないかなあ
間が開いたときには、やっぱりコードをある程度分かりやすく書いてるかどうかってのは大きいと思う
そういう意味で、身の丈にあった規模を目標にするってのは大事かも
技術が無いのに大規模なものを作ろうとしたら、コードが訳分からなくなってリセットの可能性が高そう
と読み返してみて、たまには身の丈に合わないものを作ってみるのも大事なのかな、とも思った 身の丈に合わないと色々と歪みが生じるわけで、その「歪み」を把握しておくことが、 後々に上手くやる方法を考え出すきっかけにもなるんだと思った。自分の例ではだけど
>>871 最近はモンスタークレーマーみたいなのがフリーの物にも寄ってくる時代になってると感じるんだが、
ユーザーとのコミュニケーションてBBSとかでやってんの?
やっぱフリーより500円でも1000円でも取れば、基地外が来る率が減るのかなぁ
経営してるネットショップだと、支払いにクレカ使えない人、
安価な商品を買う人のモンスタークレーマー率が有意に高いんだよね
楽しく開発したいならフリーって最悪の選択肢なのかなぁと思いはじめている
>>873 個人的な印象だけど、やっぱりフリーはクレーマー率高いと思う
誰でもダウンロードできるってことが利点でもあり欠点でもあるんだろうね
コミュニケーション方法は具体的に書くとちょっと特定されそうで怖いんだけど、BBSは使ってないとだけ
あまり濃密なコミュニケーションは逆に製作の妨げになるから。軽く感想貰って、軽くお礼を言って、くらいかな
金取れるくらいのクオリティ出せるんなら、その方が楽しく開発はできるんだろうと思う
ただクオリティが出せないと誰にも遊んでもらえないっていう悲しいことにもなりかねないけどw
どういうクレームなんだろ 動かないは双方の問題かな しかし金を取る以上相性で逃げるのはクレームがついても文句は言えない スペック不足は別だけど 難しい!温い!は、そんな事言われてもって気分になるな(意見が偏っているなら問題あり) 糞ゲー!的なクレームはサーセンw
>>874 ありがとう、だいたいわかった
金取れるクオリティは、同人でそこそこ売れているくらいの作品を見ると満たすことができると思う
金取った方が逆に変なのが来にくいなら、儲からんでも金取って貯まった分でゲーム内音楽でも発注してトントンで回した方がいいよなぁ
大規模とか小規模っていうのに齟齬がありそうだな ブロック崩し、スペースインベーダー ネットハック、ウルティマ、ウィザードリィ ポートピア連続殺人事件、太陽の神殿 このあたりの有名タイトルを使って どの辺りが、どのように大規模開発なのか説明してよ。 (プログラム的に大規模とかシナリオ的に大規模とか)
文字通りじゃね。 例えばテトリスって言ってもまともに作れば十分大規模だと思うよ。 SRSすら実装しないでテトリスとか名乗るなら1日レベルの小規模だけども。
879 :
名前は開発中のものです。 :2011/07/17(日) 10:41:49.09 ID:9R7sKILt
C++で使えるクラスが構造体の中に関数が使えるものだとしたら どうしてそれだけでそんなにもCより実用的になるんだ? 結局やることはかわらんだろ
IDが不正とかなんとか
おっぱい
クラスって使いまわししやすいか? 他のクラスとの絡みとかあって流用しずらくね 結局関数単位の方がコピペしやすいと思うんだが
手続き型とオブジェクト指向の違いなんだから、どちらが良いとか他人が決めるもんじゃないでしょ 例え同じC++の中だったとしても
>>805 は保持できるものが固定なんだよな・・・
ステージによって使うリソースの種類、数に大きな違いがあると嫌なことになりそう
>>879 RectとかPointをクラスで単純にラッピングしただけの奴でも使い勝手が上がるんだけどな
operator再定義によりシンプルに書ける。グローバル空間に同名の関数が飛び散らない。
文字列なんてstd::string使えばmallocとかのメモリ管理が要らない。
>>879 いや、全然違うからw
カプセル化、継承、STLで生産性と保守性を上げられるのが主なC++のメリット
前提条件を「全然違う」って否定するのはおかしいだろ…
>>884 他のクラスと絡む時点でOOPに失敗してるってことだからね
>>889 間違った前提条件を元に勝手な結論出してるから違うって指摘しただけなんだが何がおかしいんだ?
ディスカッションやってるわけじゃないんだから前提条件を覆しちゃいけないなんてルールはないだろ?
何か全体的に初心者が身の程弁えてなさすぎ。
近い所だと
>>879 とか
>>884 とかどう見ても分かってない初心者なんだから、もう少し慎ましくしとけよ。
質問したりするのはいいんだが、主張するとか三年くらい早い。
眠い
他のクラスと絡まないクラスとか存在してる意味ないじゃん
個人的にC++の肝はジェネリックプログラミングだと思う
>>894 std::vector<int>
これが単品で使われて存在意味無いと言うのか?
>>891 お前の回答はズレてるだろ
>>879 は「クラスを構造体+関数としたときの有用性」を聞いてるのであって、
「クラスは構造体+関数であって、有用性はない」という主張じゃないだろ
そらカプセル化や多態性が使えたらそれが一番だろうが、
初心者なりに、まずはクラスを構造体+関数で使ってみるとして、
それには実用性があるかという話じゃないの?流れ的に考えれば。
>>898 横だけど、「分かりやすく書ける」ってだけで実用性は高いと思う
例えばメニューカーソルを次に送る処理を書こうと思ったら
MenuDown(Cursor);
と
Cursor.Down();
今の自分の感覚だと、わざわざ引数持たせてしまってる前者は気持ち悪く感じる
理由は他にもあるけど
蛇足だけど、そう言えばCって関数のオーバーロード機能無かったんじゃなかったっけ?
オーバーロード無しで組むとか正直ぞっとする
>>898 前提である「クラスは構造体+関数」というのが間違っているので
つっこみを入れるとするとそこからだろ
CとC++だけを見ると、そう見れないこともないかもしれないが
オブジェクト指向からみるとまったくの別物だよ
>>898 >初心者なりに、まずはクラスを構造体+関数で使ってみるとして、
>それには実用性があるかという話じゃないの?流れ的に考えれば。
違うと思うよ。
>>879 がいちばん主張したいことは
>結局やることはかわらんだろ
の部分だから。日本語解釈的に。結局Cで何が悪いってのが彼の主張。C++使いにさんざん否定されたから反撃したかったんだろうね
そもそも「クラスを構造体+関数としたときの有用性」なんてC++使いは誰も主張していないもの
そんなものを語るよりも実際に有益なものを紹介した方が実があるでしょ
スレに書き込んでる以上レスをつけた相手に対してだけメッセージを送ってるわけじゃないのよ
カプセル化、継承もCでできるし STLも自己参照構造体使って自作できるわけでC++でしかできないわけじゃないよね
>>899 実用性はあるよね、それについては
>>887 が十分に説明してくれてると思う
>>900 そら定義的には違うさ
でも、その前提はOOP的な機能を排除するところに意味を持ってんじゃないの
つまり、ベターC的な使い方を聞いてんでしょ
>>901 話としてはあったよ、ベターC的な使い方でC++に触れるのはイイって
お前はなんだか、C使い VS C++使い みたいな対立構造を望んでいるみたいだけど、
それこそ全く、何の意味もない無粋な議論なんだよね。そんなのプ板で好きにやってきなよ
こちとらCでもC++でもOOPでも、実用的な使い方を話したいわけよ
実際、クラスを構造体+関数としたときの有用性はあるんだもの
それとOOP、どっちが初心者に勧めるべきかなんて明らかだろ
>>902 そういう台詞はカプセル化ができるようになってから言うこった
>>904 >お前はなんだか、C使い VS C++使い みたいな対立構造を望んでいるみたいだけど、
これは明確に否定しておく。俺は元々Cから入って二度手間を味わったからこそC++から入れる人間はC++から入ったほうがいいと思ってるだけ
>実際、クラスを構造体+関数としたときの有用性はあるんだもの
>それとOOP、どっちが初心者に勧めるべきかなんて明らかだろ
初心者に対してだったら後者を薦めるのが普通な気がするんだがなぁ
他言語への移行も簡単だし。ゲーム作りをやってる人間にとってC#を簡単に習得できるのはすごいメリットだと思うんだけどね
>>906 それはちょっと同意できない
小学校卒業したばかりの人間に微分積分の有用性を説いても理解できないのと似たようなものかと
もうちょっと初心者目線に立った方がいいと思う
>>907 そういうものなのかな?
俺はビギナー段階からオブジェクト指向やデザパタ頭に入れてる人間の成長速度を目の当たりにしていたのでそう考えていたのだが
上で語ってる人たちが初心者向けのC++でのゲーム制作講座書けば解決するんじゃね
>>906 そうか、すまん
ただ、DXライブラリのサンプルプログラムや入門サイトが、
ほとんどCで書かれていることを考えると、やっぱそれに準ずるほうが混乱しないと思うし、
趣味プログラマにとって、プログラミング技術の習得よりは、やっぱりゲームが出来ることのほうが重要
だから、他言語へ移行が簡単だとか、習得しやすいとかは、魅力になりにくいと思うわ
>>908 ループになるがまさにこういう状況だから
>>719 >>738 そういう人達が本当に最後までゲームを完成させていたら
ちゃんと最後まで遊べる程のボリュームのゲームがこの世に出回っているはず
C++でのゲーム製作講座は見てみたいな どこ行っても大抵CかC++でも単純なミニゲームレベルしかなくて今一参考にならない
>>908 それはそいつが素質ある人間か、あるいは教育環境が整っていたかのどっちかだろう
ポインタやメモリアクセスの概念すら満足に理解できない人間が大勢いるのが現実なわけだから
>>909 未熟ながら、暇があれば作ってみたいと思うよ
だが、そんな暇は無いw
オブジェクト指向は人間の物事の捉え方と似せてあるから そのことを実感させられれば楽なんだけど・・・ 普通の人は自分がどのように物事を認識し、扱っているかなんて考えないよなw
もう初心者はC#からでいいと思うけどね ネット上にある解説やリファレンスも豊富で、デザインパターンの取り入れも容易 後から興味本位でC/C++に触れても遅いなんてことはない
プログラミング用語連発でしか語れなくなる奴は「このゲーム開発のエンディング見えた!」 と満足してしまう病気に陥ってしまうからな 熱意だけで走っている無知を嫌う傾向が強い 個人的には知識より熱意とクリエイト熱だけで突っ走っても良いぐらい 初心者には強くそう薦めたい やりたい事が出来なくなったり、手抜き(実際は効率的なコード)をしたくなってから 新しい技術を習得しても遅くはないはず 今までの無駄なコードはなんだったんだ?となるかもしれないが 自分が作ったベタなコードで置き換えるから、本やサイトより 理解力や応用力が身に付くはず
なんかこの話題DXライブラリとか関係なくね? 雑談だからいいか
DXライブラリの話題といえば、前バージョンあたりでやっぱり内部の仕様変わったのかね?
C++勉強しとくと利点が多いのは間違いない 利用頻度高いライブラリの大半がC++ 英語が不自由でもソース読めりゃ海外ライブラリも使える DxLibと他ライブラリ組み合わせてる人って結構いるんじゃね? DxLibはゲームライブラリっぽくないし
DXライブラリは出来が良すぎるからあんまり語ること無いんだよなw たまに困った初心者が質問して誰かがそれに答えるくらいで
>>918 ごめんw
そんな前から続いてたとは思わなかった
>>920 あとメモリアクセスの概念は何らかの形で勉強しといた方がいいと思う
先立って勉強しなきゃいけないとは言わないけど
そういう意味でもC++は結構良いと思うんだ
勉強なんかしなくても自然に覚えるもんじゃないの? ポインタとかも
>>924 ああ、勉強って書いたけどそういう意味のこと
>>923 んだね、ポインタ勉強すればとりあえず良いと思う
寝てる時に突然ひらめくものでもないしなw
>>927 ひらめくは大袈裟だが
寝て起きたら(気分転換)理解できたって事なくねw
煮詰まったら腹筋とかたまにするwww
>>910 あ〜、サンプルプログラムの問題とかもあるのか
DXライブラリはたしかにそれそのものがC的な文法で組まれてるからねぇ、混乱するってのはそういうことか
あと言葉がたりなかったわ、C#の利点ってのはゲーム用のツールを作り易いってところね
結局、結論はC++でのDXライブラリ入門サイトが必要ってことかなぁ
勉強嫌いというのは辛いんだよ・・・
>>928 12時間以上寝てると、夢の中でアルゴリズムをいろいろ試行錯誤していて、
目が覚めた時「ああ、そういう事だったのか!!」ってのはたまにあるぞw
>>928 あるあるw
俺は煮詰まったら銭湯行くわw
とりあえずIDの数だけ腹筋しようずw
STLとboostだけでもすごい楽になるっすね アルゴリズムとかもういちいち実装しないから楽すぎて 自分は脳がスカスカになってダメ人間になってますわ…
>>913 いや、俺もまったくのビギナーが学ぶならやっぱオブジェクト指向から入った方がいいと思うな。
問題は俺みたいな手続き型から入った頭の固い人間が、オブジェクト指向に移行しようとする場合に
高い壁を感じる事じゃないかな。
>>934 だからそれは無茶な話だってば
どうやってポインタの概念すら満足に分かってないような素人がOOP理解するのさ
しかも大抵の場合独学で
ついでに書くなら、OOPを過不足無く解説した参考書やサイトを俺は知らない そういう「まとまった情報」が無いのも学習を困難にさせる原因だよ まあ、概念の輪郭がはっきりと定まってないのが原因でもあるんだろうけど
現在のWindowsの入門言語がC#という時点で初心者にオブジェクト指向は手に負えないなんて理論は通用しないよ 対応できないのは初心者ではなくかつてのVBプログラマというのが現実
算数や数学の検定教科書みたいに書いてくれれば分かるんだけどなあ 基本のやり方教えて簡単な練習問題を五、六個 軽い応用教えて練習問題を二、三個 章末にひねったの一個だけとか ドリル式で身につくみたいな感じのでもいいけど
どうでもいいけどお前ら、ほんとに初心者を茨の道にたたき落としたいんだなwww
>>937 C#使ってる初心者がオブジェクト指向を理解できてると思ってんのか
お目出度すぎるぞそれは
「こういう風に書くものだ」程度にしか理解できてないよ
あとそもそもC#が入門言語って思いこみが誤ってる
そもそもOOPをやたらと推してる奴はOOPをあんまり理解してないんじゃないのか? まともな神経してたら、あれを初心者が理解できるなんて結論には到底至れねーぞ。 OOPは踏み込めば踏み込むほど泥沼だ。
下手に手続き型に触れてなければ、 オブジェクト指向はポインタよりはすんなり理解できるんじゃないか? そんな難しい概念だとも思えん C++はCのしがらみのせいで確かに厳しいかも知れないが…
943 :
名前は開発中のものです。 :2011/07/17(日) 17:49:52.96 ID:RhtIuNis
どっからこんなに人が沸いてくるんだろう
>>942 てか、ポインタなんて正直「なんでこんなのが理解できないんだ」って次元だと思ってる
その「こんなもの」すら理解できないのが本当の初心者ってことだって言いたいんだ
能力も資質も、自分や近しい人間を基準に考えてはいけないと思うよ
オブジェクト指向は確かにそれに特化した言語ならまだ取っ付ける部分はあると思う
けど現実的に、DXライブラリ使うならCかC++だよね。C#でも一応使えるらしいけど
その初心者のポテンシャルによるね ダメな子にできるまで勉強を強制するのは拷問だし できる子に何も考えずに突き進めと言うのもまた酷な話かと
>>940 十分できるよ、っていうか入門でいきなりオブジェクト指向を意識したコードなんて書くわけないだろ
少なくともポインタが克服できずに音を上げるようなことはない
>>945 いや、こういう場所だって前提があることを考えてくれよ
その「ダメな子」が大勢いるだろここは
ダメな子がいる中でできる子向けの話をしたら、ダメな子はドロップアウトしてしまうだろ
できる子はどうせ自分で道を切り開いていくからいいんだよ
>>946 >少なくともポインタが克服できずに音を上げるようなことはない
この時点で言ってることがおかしいんだよ
だったらなんで現実に世の中はポインタが克服できない人で溢れかえってるんだよ
ダメな子が独学で勉強するって前提を少しは考慮に入れろよ
なんかDXライブラリを最新バージョンに代えたら 今の今まで動いてたプログラムが起動すらしなくなった……。 さて、原因を突き止めないと……。
>>947 一理あるね
ダメな子もできる子も互いにおかしな煽りを入れずにスルーできるようになるのが理想かな
ま、2ch的に無理かw
その出来ない子なんで、出来ない子の目線に立って考えてくれると有り難いデス… メモリなにそれ美味しいの(^p^)
ポインタが理解されにくいのって、ポインタの必要性を感じ無い時点で ポインタ!ポインタ!と無理に理解させるからだと思うんだよな・・・ 直接値を書き換えればいいでしょ? グローバル変数で対応すれば問題ないでしょ? 暗記型(そういうもんだ)という人は何も考えず、本に書いてあったから!的に覚えるけど 理屈で覚える(別に使わなくても○○って組めばいい)と人は、自分でポインタに頼る状況になるまで覚えたがらない そしてプログラム資料全般的に言える事だけど、でっていう?という説明が多すぎる int a* int b=10; a=&b 以下略 こんな感じでbの値を変わる様を見せても、フーン。で?と (ゲームプログラミングの事なんか意識してないからそれで正しいのだろうけど) DXライブラリ サンプルプログラム のページを もっとブツ切りにして処理ごとに画像付きで説明するようなサイトがあれば初心者の理解力は大幅に増すと思う
同じくダメな子なんで割とまじでこのスレの人でまとめとか作ってくれるとすごく助かる 少し前の流れであった画面遷移の話とかもあればいいなあ
ポインタはX68使ってGVRAM直駆で絵を描くプログラムを組ませると簡単に理解してくれる その環境を整えるまでが難度高いだろうけどw
グローバル変数一切禁止 変数の直接変更禁止 全てポインタで操作しろ! って教育方針はどうかな? 煩わしい方法でひたすら組ませるみたいな
自分が作りたいものに有効な方法を取捨選択する能力が欠如すると思うw
プログラム言語なんて手段でしかないのに何を言ってるんだお前らは。 OOPを習得するためにプログラミングするんじゃ完璧に本末転倒じゃねえか。 組めれば何だっていいんだよ。そりゃきれいに組むに越したことはないがな。 ハードルが越えられなくて挫折するってのが最悪のパターンだ。 ポインタと一緒で必要になってから身につければいい。 手続き型で固まってて習得が難しいってんならそれはそれでいいだろ。手続き型で組む力が固まってるってことなんだから。 後のことなんか考えたところでいいことなんてない。お前らはプロのプログラマーでも養成したいのか。
このスレも賑やかになって嬉しいわw
>>957 プログラム言語にあれこれ語りだす。ゲーム製作ブログが陥る現象
ツクラーやウディタ等でゲーム製作を語っている人のが
生き生きとしているんだよな
DXライブラリを選ぶ人の多くは途中でゲーム製作について語らなくなるwww
ツクールでも普通にエターなるけどな
この勢いのまま次スレも進行してほしいな
連休中このテンションで新スレはさすがに勘弁してほしい
まあCをある程度使いこなせるようじゃないとC++に手を出さない方が無難でしょ
未だに
>>963 みたいなことを言う奴がいるのがさっぱり理解できない
C++はほぼCを包含してるんだから、C++で必要な部分だけ使えばいい
敢えてCを選択するメリットは皆無
それC++舐め過ぎでしょw まあベターCの部分をってのならまだ分からないでもないが
そもそもベターCとC++分けてる時点で意味不明すぎる 大体、わざわざCを選択するメリットは? 別に理解してなくてもC++にして、必要が無ければCの部分だけ使ってりゃいいんだよ 制限つける利点なんて何もない
まあ初心者がC++に無理に手を出さないってんならそれでもいいかもしれんが
C++に手を出さない方が無難とか言ってるのは流石に釣りと思いたい。 割と初期からクラスとかオーバーロードくらいは使うよ。普通に。 それをわざわざ制限して汚い書き方を強いられることの方が害悪だ。 はっきり言うが、Cを選択する利点なんて環境の制約を受けたりする場合以外は全く無い。 超初心者にとってもだ。
一般論としてはそうかもね DXライブラリ使用者としてはどうだろう
使えるものは何でも使えばいいの 使い方が分からなかったり上手く使えなかったりするのなら使わなければいい なんでわざわざ制限するんだ それ以外に言いようが無いわ
そんなカッカすんなよw いつもの「まあ」の人の妄言じゃねえか
ホントだ、すげえw
>>970 こういう機能があるんだから覚えろ!
そして使え!
参考書の大半がそんなのばかりだから
Cも使えんような初心者が初っ端からクラスに手を出すと爆死するだろどう考えてもw
まずは失敗を人のせいにしないことが大切かな
>>971 らじゃ。まあ、ギクっとしたじゃないかw
>>973 ってか、初学者には参考書ってクソの役にしか立たないような気がする
ある程度力が付くとリファレンス的な使い方ができるけど
初心者向けの解説書とかも役に立ったって記憶が無い
ポインタなんてなかなか理解できない奴の方が大半だと思うが
>>951 >そしてプログラム資料全般的に言える事だけど、でっていう?という説明が多すぎる
それ、マジでそう思うよw
「これをやる事で、どうゲームプログラミング上で役に立つのか?」という事が説明されないから
どう受け取っていいかわかんないんだよね……。
ポインタに限らず、クラスの有用性とかよく語られるけど、継承だのなんだのと単語がならべられるだけで
具体的には語られないから(本人は理解してるから語る必要を感じてないのだろうけど)結局、理解できなかったりする。
おまいらCとC++のはなしばっかりだがな C#だってやれば出来る子なんだぞ ポインタとかの難しいところは隠蔽してくれてるし ガベージコレクションもしてくれる VisualC#があるので、初心者にもとっつきやすい 対初心者教育だって、既存の 手続き→関数→オブジェクト の学習パターンを使えるし なにより、DXライブラリが使える!! すばらしい言語なんだよ だから.netをみんなインスコしてよ
C#は物量ゲーにも耐えられる速さと、十二分なwebの資料があればなぁ
>十二分なwebの資料があればなぁ C++でググるとVBとC#の記事で、C#のがいいんじゃね?と思う事も C++は資料は多いが古いのが多いからな ゲーム製作資料だと最近書かれた物より 2000年前後に書かれた分かりやすかった時はどうかと思ったさw
ポインタもクラスも継承も「どう動くか」じゃなくて「どう使うか」だものな
最初のうちは概念だけおおまかに知っておけばいいんだと思う
で、慣れた頃に「もっと上手く組みたい」と思ったときに武器になる
極端な話、プログラムなんて演算と反復と条件分岐と入出力だけで大抵組めるわけで
その他のものは「より上手く組むための道具」でしかない(WinAPIとか絡むと別ね)
まずはそれを知ることが大切だと思うんだけど、それを教えてくれる参考書って・・・無いよなあ
>>979 C#はとても優秀な子だと思うよ
けど向き不向きで言ったら、ゲーム製作との相性はちょっと微妙な気がするw
ちょっと前に、曲から弾幕作るの作ってるって言ったものだけど
テスト版アップしたからちょっと遊んでみてくれない?
テスト版と言いつつ弾幕1種類しかでないから
クソゲーだけど
http://www1.axfc.net/uploader/Sc/so/255957.zip 解析処理の重さとか、曲の区切りの具合とかそういうの知りたい
あ、解析処理はCPUパワーとメモリ食うからメモリの空き容量1Gはあったほうがいいよ
曲は自分で用意してね、読み込める形式は中のテキストに書いといた
OOP無して複雑なゲーム作る人ってある意味尊敬するわ 手漕ぎボートで太平洋横断するみたいな
手漕ぎボートで太平洋横断するか、 一人でボーイング747を作るか、どっちが挫折しないかって話だな
どっちも嫌だわw せめて帆船使うくらいにしてくれよ
>>984 世の中には構造体すら無い言語(HSPとか)で複雑なゲーム作ってる人もいるんだぜ
ある意味、OOPが使える人間よりも凄く能力が高いんじゃないかと思えるw
ボーイングディスってんの?
コンチキ号なめんなよ
948で言った異常終了の原因がわかった。 GetNowCount()が今まではDXLibの宣言前にも使えてた(エラーにならなかった)のが、使えなくなってた。 いやまぁもともと使えない(保証されない使い方してた)のを、使ってた俺が悪いのかもだけど。
OOPもゲーム製作も難しく見積もられ過ぎwww
>>992 ゲーム製作そのものは簡単だが、実際に完成品となると極めてハードルが高くなる
ダイエットみたいなもんだな
方法ばかり拘る奴より、とりあえず行動に移す人のが成功しやすい
でもより効率的にやった方がより効果が出る
一週間ぐらいで飽きる。忘れた頃にまた再開する。
そしてブログ等でダイエット方法について色々語る人ほど
知識ばかり増えるが実際に痩せたという報告が無い
お前はどんだけブログが好きなんだよw
土日スレには俺も一本寄贈したわw
他人のゲーム製作状況なんて商業同人個人含めてブログが普通じゃね 板全体を見ても作っている。完成した。は証拠は無いから
フゥー↑
自演自重
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。