DXライブラリ総合スレッド 2008

**名前は開発中のものです。** · 2008/10/25(土) 17:37:53

Cを習得した程度のスキルでも、
GUIのゲームを比較的容易に作成する事を可能にする、
「DXライブラリ」に関するスレッドです。

DXライブラリの詳細ついては
http://homepage2.nifty.com/natupaji/DxLib/
を参照して頂きたい。

DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。

過去スレ：DXライブラリ総合スレッド
　　　　　　http://pc11.2ch.net/test/read.cgi/gamedev/1197468399/

**189** · 2008/12/03(水) 17:18:45

>>191
お返事遅くなって申し訳ありません。
当方の環境ではDrawStringでやった場合のFPSが30くらいでDrawGraphにすると60になりました。
DirectX自体、文字描画にGDIを使っているのでビデオカードで処理できるBitBltの方が高速だと思っていました。数年前の知識ですが。。
低スペックでも快適に動くように作りたいので、DrawStringは極力使いたくないです。

**189** · 2008/12/03(水) 17:29:14

フォントの変更は行っていないので、フォントハンドルは使用していないです。

**名前は開発中のものです。** · 2008/12/03(水) 18:07:17

そんなにたくさんの文字を同時に表示してるのかな？
それともＰＣ環境が悪すぎる？

俺普通にDrawString使ってるけど別に遅くなった事ないよ？
普通に60FPS出てる。古いノートパソコンで。
最高でまぁ10行程度の表示しかしてないけど。

**名前は開発中のものです。** · 2008/12/03(水) 18:30:58

いやそれじゃ全くテストになってないから。
192の知識通り、今も文字列表示は遅いよ。
189の方法が適切だと思うし、他に方法を提示できないのは申し訳ないけど、
少なくとも文字列表示が遅いって前提でレスされると無駄だと思ったので口を出してみた。

**名前は開発中のものです。** · 2008/12/03(水) 18:37:18

×少なくとも文字列表示が遅いって前提でレスされると無駄だと
○少なくとも文字列表示が遅いって前提を否定するレスは無駄だと

**名前は開発中のものです。** · 2008/12/03(水) 19:17:52

俺の事？
別にテストしたわけじゃなくて、普通に使ってるだけなんだが。

文字列表示が遅いってのが前提なら、そもそもグラフィック表示だって遅いだろ。

グラフィック表示が遅いから他の方法はありますか？　って質問があったとしたら
まず現在どういう環境でどれだけのグラフィックをどういう方法で表示させてるのか教えろってのは普通の流れだろ？

そこをかっとばしてグラフィック表示処理そのものを早くする方法を考えるのは無駄な話だ。

**名前は開発中のものです。** · 2008/12/03(水) 19:27:15

確かに
今与えられた情報だけではなんともいえんな

**名前は開発中のものです。** · 2008/12/03(水) 19:41:02

文字列の長さ、量がまずわからない。

「フォントの変更は行っていない」というのが、フォントの大きさやアンチエイリアス有無の変更は行っているかもしれないとも読める。

**名前は開発中のものです。** · 2008/12/04(木) 00:31:01

>>197
文字列表示はグラフィック表示より遅いって常識知らないの？
そこは議論の余地なしだから言ったまで。
それと、テストじゃないなら>>194の報告は不適切。
まあ上記の前提を知らなかった故だからしかたないと言えばしかたないが、ややこしくなるのでなかったほうがよかったな。

情報は少ないが、前提を知っているば容易に共感できるし、解決方法を知っている人ならこの情報量でも回答できるかもしれない。

**名前は開発中のものです。** · 2008/12/04(木) 00:33:46

>>197
＞文字列表示が遅いってのが前提なら、そもそもグラフィック表示だって遅いだろ。

（；^ω^）

**名前は開発中のものです。** · 2008/12/04(木) 02:05:10

何人か偉そうにレスしてるけど、誰もライブラリのソース見てないのか？

DXライブラリは文字を描画する前にテクスチャにキャッシュしてるから
同じ文字なら２回目以降はほぼDrawGraphと同じコストで処理は完了する
キャッシュ用のテクスチャは512x512だから画面一杯に異なった文字を
描画するくらいしない限りは文字列描画特有の遅さは発生しないぞ

まあ、毎フレームキャッシュに無い文字を描画したら一般に言うところの
「文字列表示が遅い」ってのに当てはまるけど

**名前は開発中のものです。** · 2008/12/04(木) 09:46:46

良スレage
みなぎってきた､学校でゲーム作ってくる

**名前は開発中のものです。** · 2008/12/04(木) 10:33:56

>>200

何を言ってるんだ君は。
60FPSで動いてるゲームに、一回のDrawString処理を追加しただけで30FPSにまで落ちたりするか？
普通はしないだろ？

じゃあどういう処理にしてるんだ？　っつーレベルの話だぞ？

192が出してる情報はその程度って事。

**名前は開発中のものです。** · 2008/12/04(木) 12:47:01

>>204
>>202

分からない(・∀・)ｶｴﾚ!!

**名前は開発中のものです。** · 2008/12/05(金) 18:06:46

ソフトウェア描画モードと言う物があるらしいのですが、
どれのことなのでしょうか？
一部のPCだと動かなかったりする時にこれを使えばいいらしいのですが……。
リファレンスを見た限りそれっぽいのがありませんでした。

**名前は開発中のものです。** · 2008/12/05(金) 18:19:39

この辺をどうぞ。
ttp://www.dkut.flnet.org/dxlibwiki/?3D%B5%A1%C7%BD%A4%F2%BB%C8%A4%A6%A4%AB%A4%C9%A4%A6%A4%AB%A4%F2%A5%E6%A1%BC%A5%B6%A1%BC%A4%CB%C1%AA%C2%F2%A4%B5%A4%BB%A4%EB

**名前は開発中のものです。** · 2008/12/05(金) 20:49:20

>>207
ありがとうございます。
SetScreenMemToVramFlag( FALSE );
と、
SetUse3DFlag( FALSE );
を使ったらよさそうなのでこの二つを使ってみようと思います。

**名前は開発中のものです。** · 2008/12/06(土) 03:56:27

>>204
垂直同期を使って処理していれば僅かな処理の遅さでFPSは半分になることがある
そしてGDIは遅い

>>189はDrawStringを使用せずに同等の文字描画処理をする方法を模索しているであって
デバッグをしてくれと言っているわけじゃないんだから君がムキになるのは頓珍漢な話
俺を含め解決策が分からない初心者が回答することが間違い

**名前は開発中のものです。** · 2008/12/06(土) 04:17:22

俺もよくわからないけど、>>189は

＞DXライブラリでは作成したサーフェスに直接描画出来ないのでしょうか？

と明確に聞いてるぞ。
それを初心者が関係ない知ったか話をしてるとしか見えない。
「俺は平気だよ？」とか言う話もいらないと思うｗｗ

>>202もヒントになると思うけど多分新しい文字列を頻繁に表示しようとしてるんじゃないかな。
毎フレーム更新される数値を表示するって事も多いと思うし。

**名前は開発中のものです。** · 2008/12/06(土) 06:11:31

ファイナルファンタジーの裏ワザででてくる
数字ゲームとかあれ作ると面白そう

**名前は開発中のものです。** · 2008/12/06(土) 09:55:12

ブラックジャックといいたまへ

**名前は開発中のものです。** · 2008/12/06(土) 11:21:34

>>189は「同じ文字列」って書いてるじゃないか。
まあ任意のオフスクリーンバッファに描いてそれを転送したい、というのはわかるが
できる機能を追加するかDXライブラリをやめるしかないのでは。

**名前は開発中のものです。** · 2008/12/06(土) 16:48:54

クリックイベントを使いたいのですがどうすればよいのでしょうか？
公式などにクリックイベントのコードがなかったのでここで質問させてください

**名前は開発中のものです。** · 2008/12/06(土) 17:16:43

SetWaitVSyncFlagをFalseにしておいて、16666マイクロミリセカンド待機し描画

↑で描画すると30フレームあたりまで落ちるんですが、SetWaitVSyncFlagをFalseにしてても同期するってあるんでしょうか？

待機を16200にすると60フレームになるので、同期でひっかかってるんだと思うのですが……

**名前は開発中のものです。** · 2008/12/06(土) 17:19:10

自己解決しました

**名前は開発中のものです。** · 2008/12/06(土) 20:30:15

なんだったのよｗ

**215** · 2008/12/07(日) 18:55:49

すいません、こちらも自己解決しました……

**名前は開発中のものです。** · 2008/12/08(月) 00:25:32

Cの入門書見てる段階なんですが、DXライブラリでのゲーム製作講座を見てみたら、
C言語というより、DXライブラリ言語でのプログラミングという印象を受けました。
DXライブラリを使ってプログラミングする場合は、
Cのほうは入門書を一通り読んだだけの知識でよくて、
あとはDXライブラリの使い方をきちんとやるほうがいいんですよね？

**名前は開発中のものです。** · 2008/12/08(月) 00:31:03

Ｃも一通りの知識は要るだろうから
平行して勉強しなはれ。

**名前は開発中のものです。** · 2008/12/08(月) 00:55:25

いやいや
もろCで作ってるよ
printfが絵を表示する関数になるだけ

**名前は開発中のものです。** · 2008/12/08(月) 03:17:20

>>219
「Ｃ言語＝ printfやscanf、fopen等の標準関数」だと思ってるんならそれは間違いだ

**名前は開発中のものです。** · 2008/12/08(月) 03:37:47

>>219
それでいいと思うよー。
Cの文法なんて覚える事少ないし、入門書片手に取り掛かっちゃえば大丈夫。
今後も、プログラミングで何かを作る時、基本的にDXライブラリのような、外部のライブラリの使い方を覚えるって作業が大半になるよ。
入門書に書いてあるstdio.hのprintfみたいな標準関数を覚えるみたいに。

**名前は開発中のものです。** · 2008/12/08(月) 11:27:49

>>210

>>>202もヒントになると思うけど多分新しい文字列を頻繁に表示しようとしてるんじゃないかな。
>毎フレーム更新される数値を表示するって事も多いと思うし。

それこそ仕様を見直せとしか言いようがないようなｗ
毎フレーム更新する数値や文章ならプレイヤーに全文しっかり読ませるためものじゃないだろうし。

**名前は開発中のものです。** · 2008/12/08(月) 18:07:49

ノベルとかアドベンチャーのサンプルがあるサイト教えてください

**名前は開発中のものです。** · 2008/12/08(月) 18:55:26

公式にあったような気がするが……。

**名前は開発中のものです。** · 2008/12/08(月) 20:50:58

Dxライブラリを使って
60フレーム固定のｼｭｰﾃｨﾝｸﾞを作ろうと思ったんですが

公式をみると「グラフィックがぶれがひどくなる」と書いてあって
ttp://homepage2.nifty.com/natupaji/DxLib/dxprogram.html#N13

で、実際にｻﾝﾌﾟﾙ試してみたら
確かに時々ひっかかる感じが。

これって改善はできないものなんでしょうか？

**名前は開発中のものです。** · 2008/12/08(月) 20:56:58

内部の更新処理(当たり判定，posX += vXなど)のフレームレートを倍にするとか

**名前は開発中のものです。** · 2008/12/09(火) 01:42:49

>>227
int Time; を
LONGLONG Time; に、

Time = GetNowCount();　を
Time = GetNowHiPerformanceCount();　に

while( GetNowCount() - Time < 17) {}　を
while (GetNowHiPerformanceCount() - Time < (1000000 / 60)) {} に

書き換えてみたら？

**名前は開発中のものです。** · 2008/12/09(火) 13:46:02

>>224
RPGやアドベンチャーゲームなら
1文字ずつゲーム内Windowに描画され、ゲーム内Windowごと表示非表示を切り替えられるって仕様は普通に有るでしょう

**名前は開発中のものです。** · 2008/12/09(火) 15:29:12

>>226
文字表示ぐらいしかないと思うけど・・・

**名前は開発中のものです。** · 2008/12/09(火) 15:52:37

サンプルゲームみたいなのでなかったっけ？
前はあったはずなんだが。

**名前は開発中のものです。** · 2008/12/09(火) 17:32:59

「ＤＸライブラリサンプルゲームのダウンロード」のページにある
「スクリプトプレーヤー」の事じゃないかな。

**名前は開発中のものです。** · 2008/12/09(火) 18:26:23

スクリプトプレーヤーはソースの意味が分からない
いきなりスクリプトのソースみろとか言われてもなにがなにやらって感じ

**名前は開発中のものです。** · 2008/12/09(火) 19:12:36

サンプル見たいって話を聞くたびに
見てもわかるの？
という疑問が湧く。
同じ動きをするものを自分で書けるくらいの技量がなければ結局読めない気がする。

他人のソース読むのが超苦手で自分で書いた方が早い俺限定の話だが。

**名前は開発中のものです。** · 2008/12/09(火) 19:35:05

>>235
アルゴリズムは同程度の技量がないと読めないけど、設計はそんなことないよ。

スクリプトプレイヤーのソース見たけどちょっと酷いな。
マジックナンバー、関数長すぎる、グローバル変数使いまくりetc...
たしかにこれ読めとか言われても俺も困る。

自作2Dライブラリ作ってたんだが、画像系の実装が終了したところで
面倒になってきたんでDXライブラリを使うことにした。おまいらよろしく。

**名前は開発中のものです。** · 2008/12/09(火) 20:33:33

>>236
ああ確かに設計は読みたいかも。
うまい人のクラス構成とかはみてみたい。

**名前は開発中のものです。** · 2008/12/09(火) 20:44:39

うまい人のコードは，クラスやメソッドの実装にどんどんステップインしていかなくても
表面だけ見れば理解できるよね

**名前は開発中のものです。** · 2008/12/09(火) 20:59:26

>>228
すいません、内部処理は一定化したかったので・・

>>229
ありがとうございます！
引っかかりが無くなりました。
タイマーの精度の問題だったみたいですね。

**名前は開発中のものです。** · 2008/12/10(水) 15:43:30

>>220
>>221
>>222
>>223
printfなどが関数だということを意識していませんでした。
まさに、Ｃ言語＝標準関数のつもりで勉強していました。
外部ライブラリを使うのだから、それから提供される関数の使い方を勉強するのは当たり前ですね。
プログラミングに対する疑問が少し解けました。どうもありがとうございました。

**名前は開発中のものです。** · 2008/12/11(木) 09:38:29

画像の、ある部分だけを拡大して描画することは出来ますか？
ループ表示する背景の一部分だけを拡大表示したいです。

**名前は開発中のものです。** · 2008/12/11(木) 10:38:54

やった事ないけど、指定領域だけで新しいグラフィックハンドルを作るとかできるはずだから、
それをしてから拡大表示させればいいんじゃないかな。

前提条件として矩形範囲のみって事になるけど。

**名前は開発中のものです。** · 2008/12/11(木) 11:00:28

>>242
なるほど、ありがとうございます。矩形なのでその辺は大丈夫です。
でもアクションゲームみたいに、リアルタイムにバックグラウンドをスクロールさせつつ、
拡大率を変えてバックグラウンド表示するのはその方法ではコストが掛かり過ぎて無理なようですね。
DrawExtendGraphの描画元矩形指定関数があれば一発なのに＞＜

**名前は開発中のものです。** · 2008/12/11(木) 11:23:00

背景をスクロールさせつつ、拡大部分もスクロールさせるのかな。
それじゃ無理だね。

それならいっそ、

背景を普通の大きさで書く　→　画面の描画範囲を設定（SetDrawArea）　→　背景を拡大して書く

ってやってみるのはどうだろう。
背景を二回描くから、やり方によってはコストかかるけど……。

**名前は開発中のものです。** · 2008/12/11(木) 12:23:15

つDrawRectExtendGraph

**名前は開発中のものです。** · 2008/12/11(木) 12:49:25

>>244
そうですそうです、元画像の一部分を拡大表示したいんです。

>>245
おお！ありがとうございます。そんな関数があったんですねｗ
面倒でも自分でDxLib.hをチェックしないと駄目ですねｗ

**名前は開発中のものです。** · 2008/12/12(金) 18:14:48

今トルネコやシレンみたいな2Dダンジョン探索ゲームを
800 x 600 ウィンドウモードで作っているんですが
2Dゲームは 640 x 480 が基本だと聞きました。

800x600だと何か不都合でも起こるんでしょうか？

**名前は開発中のものです。** · 2008/12/12(金) 19:08:10

32x32とか16x16のブロックがぴったり収まらない、とか。？

**名前は開発中のものです。** · 2008/12/12(金) 20:15:13

画面下と右にブロックが半分だけ表示されるのは我慢しようと思います。
800x600だと特定の環境ではちらつきが酷いとかだったら嫌だなぁと思いまして

**名前は開発中のものです。** · 2008/12/12(金) 20:24:18

>>247
処理速度の問題とユーザの環境の問題
ちなみにカラーモードも256色パレットモードが基本だった
しかしそれは過去の話
今はPCのスペックは十分だし、800*600の画面モードの無いPCの方が少ないと思うから問題ないかと

**名前は開発中のものです。** · 2008/12/12(金) 21:25:42

ちょっと便乗
CRT使いなんでわからないんだけど
液晶の場合、画面サイズに合わない画面モードの表示ってどうなるの？

１）全画面に拡大されてぼやける
２）表示分だけ使われて余白は黒塗りになる

**名前は開発中のものです。** · 2008/12/12(金) 21:28:59

>>251
Ａ．液晶の設定しだい

**名前は開発中のものです。** · 2008/12/12(金) 22:00:48

初心者で悪いんだが質問。

うまく言えないんだけど

player.cpp内でint宣言をして、void player()で増減させる。
そして
「enemy.cpp内」で「player.cppのvoid player()」で増減したint変数を使用して作りたい判定があるんだけど。

こういうのってやっぱり出来ないのかな？

**名前は開発中のものです。** · 2008/12/12(金) 22:09:20

extern

**名前は開発中のものです。** · 2008/12/12(金) 22:12:35

player.cppでグローバル変数としてint宣言して
enemy.cppの冒頭にextern宣言すれば判定にも使えるようになるよ

**名前は開発中のものです。** · 2008/12/12(金) 22:19:36

>>254-255
ああそれ忘れてたｗｗ
おもいっくそ素材ファイルの読み込みで使ってたのに

ありがと、助かった

**名前は開発中のものです。** · 2008/12/12(金) 22:34:39

-- player.cpp --
int i;
void player(){ i += 1; }

-- enemy.cpp --
extern int i;
void enemy(){ if(i) ･･･ ;}

**名前は開発中のものです。** · 2008/12/12(金) 22:49:50

>>252
即ﾚｽサンクス。

じゃあプログラムする側としては
あんまり気にしても意味無いんだ・・

勉強になりますた。

**名前は開発中のものです。** · 2008/12/12(金) 23:04:32

＞画面サイズ
最近流行りの低価格ノートPCとかだと、どんな感じなんだろう？
縦600くらい？

**名前は開発中のものです。** · 2008/12/13(土) 01:45:20

if(enemy01_Life < 0){
DeleteGraph( enemy01 ) ;
}
else if(hitS < hit ){
PlaySoundMem( hit_test , DX_PLAYTYPE_BACK );
shotflag = 0;
enemy01_Life -=1;
}

このコードで、最後のenemy01_Life -=1の判定を一回だけ判定場合ってどうすればいいの？
ダメージ判定だけがどうしても残ってしまう

**名前は開発中のものです。** · 2008/12/13(土) 02:02:18

>260
具体的に何がしたいが、何が起こってるのかを示せ。
コードにはコメントを入れろ。第三者には何をやってるか分からない。

んで、だ。
ショットが命中した時、

　(1)ショット自体を消す（敵に当たると弾が消える）
　(2)敵ごとにカウンタを作っておき、「一度当たったら10フレームの間は無敵」とかにする
　(3)弾ごとに自分がどの敵に命中したかを覚えておき、2度目は命中扱いにならないようにする

こんな感じ？

**名前は開発中のものです。** · 2008/12/13(土) 02:20:00

>>261
玉の画像は消えるんだけど、当たり判定だけが「次にショットボタンを押すまで」残るんだ。
何がしたいかは、「玉一つにつき一回だけダメージ判定」をしたい。
ショットコード↓

if( Key & PAD_INPUT_A && shotflag == 0){ //ショットボタンが押されたら
PlaySoundMem( p_shot_se , DX_PLAYTYPE_BACK );//ショット音を鳴らす
shotX = PlayerX ;
shotY = PlayerY ; //プレイヤーの現在位置を取得
shotflag = 1 ; //ショットフラグＯＮにする
}
if( shotflag == 1 ){ //ショットフラグＯＮになったら
shotY -= SHOT_SPEED ;
DrawGraph( shotX+10 , shotY , p_shot_img , TRUE ) ;
if(shotY < SHOT_DELAY){
shotflag = 0 ;
}
}

判定コード↓
GetGraphSize( enemy01 , &SizeX , &SizeY ) ; //グラフィックのサイズを取得
hit = SizeX/2 ; //グラフィックの当たり判定（半径）
hitX = shotX - enemy01X;
hitY = shotY - enemy01Y; //三角形の斜辺を除くＸＹの長さ
hitS = sqrt(hitX*hitX+hitY*hitY); //斜辺
if(enemy01_Life < 0){ //敵死亡してる時
DeleteGraph( enemy01 ) ;
}
else if(hitS < hit ){ //（ヒット時）
PlaySoundMem( hit_test , DX_PLAYTYPE_BACK );
shotflag = 0;
enemy01_Life -=1;

**名前は開発中のものです。** · 2008/12/13(土) 02:39:09

>>262
判定のコードがifにかかってない

if( shotflag == 1 ){ //ショットフラグＯＮになったら
shotY -= SHOT_SPEED ;
DrawGraph( shotX+10 , shotY , p_shot_img , TRUE ) ;
if(shotY < SHOT_DELAY){
shotflag = 0 ;
}

判定コード↓
GetGraphSize( enemy01 , &SizeX , &SizeY ) ; //グラフィックのサイズを取得
hit = SizeX/2 ; //グラフィックの当たり判定（半径）
hitX = shotX - enemy01X;
hitY = shotY - enemy01Y; //三角形の斜辺を除くＸＹの長さ
hitS = sqrt(hitX*hitX+hitY*hitY); //斜辺
if(enemy01_Life < 0){ //敵死亡してる時
DeleteGraph( enemy01 ) ;
}

**名前は開発中のものです。** · 2008/12/13(土) 02:43:12

なんか伝わる気がしないから書き方を変えると

if(shotflagが真)
{
　　//ここに判定のコードも書く
}

**名前は開発中のものです。** · 2008/12/13(土) 02:56:17

えっと、つまり

ショットコード内で
if( shotflag == 1 ){ //ショットフラグＯＮになったら

この部分に判定コード（>>263のGetGraphSize～DeleteGraph( enemy01 ) ;）

}

を入れないとダメってこと？

**名前は開発中のものです。** · 2008/12/13(土) 03:06:51

そう
shotflagって弾があるかないかのフラグでしょ？
今のままだとshotflagが0の時にも判定される

あといろいろ突っ込みどころがあるけど
そういう書き方してると確実にスパゲティソースになる

**名前は開発中のものです。** · 2008/12/13(土) 11:56:05

>>266
マジかｗ
プログラム初心者で全然分からんから適当に組んでる
既にややこしくなってる

**名前は開発中のものです。** · 2008/12/13(土) 12:55:29

動けば結構。
実際に作って慣れればいいのだ。

**名前は開発中のものです。** · 2008/12/13(土) 13:01:52

>>263-264
そのとおりにやってみたけど
やっぱり玉一つで「次にショットボタンが押されるまで」の間に複数回攻撃判定が出ちゃう・・・。

**名前は開発中のものです。** · 2008/12/13(土) 13:08:45

>>267
初心者なら仕方なら、一回スパゲティコード書いて捨てる経験もしてみるといいかもね。
それがいやならオブジェクト指向の簡単な本があるからそれ読んでみるといいよ。
オブジェクト指向とゲームは相性がよい部類。

ためしにオブジェクト指向で書き直してみようかと思ったけど、半分ほど書いた時点で
長くなった上に果たしてこれを理解できるのかという疑問がわいてきたので捨てた＾ｗ＾）

**名前は開発中のものです。** · 2008/12/13(土) 13:10:15

仕方ならってなんだよOTL　仕方ない、ね

**名前は開発中のものです。** · 2008/12/13(土) 13:19:00

OOとゲームって相性いいかなぁ。
素人の俺がいうのもなんだけどむしろ相性はよくない方だと思うけど、経験が足りないからかな？
一応ゲーム作りはDXライブラリ使ってもOO（OO風ともいう）を意識して書いてるけど、
C++の便利な機能（クラスや継承程度）を使うくらいでこれぞOOって感じでもないなぁ。
C#でちょっとしたツールなんか作るとOOだなぁって感じるけど。

**名前は開発中のものです。** · 2008/12/13(土) 13:48:06

>>272
ツールを作る件はオブジェクト指向じゃなくて提供されるオブジェクト指向ライブラリが優秀
ってだけだと思う。

>相性はよくない方
どの辺が？ならデータ指向で作る？手続き指向で？俺は絶対いやだけどなー。

パラダイムってのはつまるところコードの整理術なわけで、それを感じないってのは別に
不思議じゃないよ。

さっきでたコード、弾丸と敵との当たり判定がでてきだけど、

int dx = shot->getX() - enemy->getX();
int dy = shot->getY() - enemy->getY();
double distance = sqrt( dx*dx + dy*dy );
if( distance < HIT_SIZE )
{
/*ヒット処理*/
}

って書いてたらお前ちょっと表に出ろだけど、ちゃんとTell, dont ask の原則にのっとって書いたら

if( shot->hitTest( enemy ) )
{
/*ヒット処理*/
}

変更にも強く、なおかつコードはわかりやすくなる。

**名前は開発中のものです。** · 2008/12/13(土) 17:56:36

もー全然できねーよおおおおおおお

いっそコレ仕様にすっか
敵の端っこにショット当てた状態でショットボタンを押さないと一定時間大ダメージ！

画期的と言えば画期的だが生憎ただのバグだ。

**名前は開発中のものです。** · 2008/12/13(土) 18:54:39

>>274
今じっくり見たけど
>>262のif( shotflag == 1 )のブロックを>>262の一番最後で閉じるか
else if(hitS < hit )のブロックの中でhitSを条件満たさないように変更する
これで正常になると思うが、違ったらすまそ

**名前は開発中のものです。** · 2008/12/13(土) 18:56:46

shotflagっていうのは弾の生死状態を管理するフラグなんだから、
弾が生きているときだけ判定をすればいいわけだよね。
>>>264が言う通り当たり判定をするブロックを if ( shotflag == 1 ){｝で囲めば出来ると思うんだけどなあ。
弾が死んでても玉の座標は留まって、さらにshotflagが機能していないから(セットが上手く行っていないか判定処理に考慮されていない）
何度も当たっていると思われるんだけど。

てか敵をデタッチするのにDeleteGraph()で画像そのものを削除するって激しすぎないか？ｗ
if ( enemy_alive ) { Task(); } // 敵が生きているときのみ敵に関する処理を行う
とかにした方が良いと思うんだが。

**名前は開発中のものです。** · 2008/12/13(土) 18:59:29

ごめん、if ( enemy_alive ) → if ( enemy01_Life >= 0 )

**名前は開発中のものです。** · 2008/12/13(土) 21:59:39

>>274だけど、ちょっと検証した
当たり判定は座標で行ってたから

http://www.uploda.org/uporg1853070.jpg

この画像の様に(hit>hitS)になってる時に判定が出て、その判定が次玉を出すときまで残るんだ。
だからこの画像はhitは21でhitSは13.9.....ってなってるので次に玉が出るまで（hitSの数値が変わるまで）凄い勢いでenemy_Lifeが減り続けてる

敵に当たった瞬間にhitSをリセットすればいいのかな？

**名前は開発中のものです。** · 2008/12/13(土) 22:22:05

もうソースうｐしてくれよ

**名前は開発中のものです。** · 2008/12/13(土) 22:28:29

http://www2.uploda.org/uporg1853197.zip.html
パスは274

問題のソースはenemy_moveとplayerにあります。

初心者だからすげー読みずらいと思う

**名前は開発中のものです。** · 2008/12/13(土) 22:30:08

>>275では解決しなかったか？

**名前は開発中のものです。** · 2008/12/13(土) 22:32:35

>>281
うん、その通りにやってみても何故か結果は変わらずだった

**名前は開発中のものです。** · 2008/12/13(土) 22:32:46

hitSっていうのは敵と弾との距離でしょ
それは当たり判定をする必要があるとき、
つまり弾と敵が生きているときに毎フレーム計算すればいい
弾の座標を遥か彼方にリセットしたりhitSを直接いじくって
当たり判定が真にならないようにすれば確かに上手く行くだろうけど
本質的には当たり判定をする必要が無いときに判定しているのが問題なんじゃないの？

**名前は開発中のものです。** · 2008/12/13(土) 22:45:11

>>283
毎回計算して判定してるんだけど
ヒットした時に計算が次玉出すときまで止まっちゃう

**名前は開発中のものです。** · 2008/12/13(土) 22:47:31

>>280
全然修正されてないじゃないかｗ

「enemy_move.cpp」の
GetGraphSize( enemy01 , &SizeX , &SizeY ) ; //グラフィックのサイズを取得
の前に一行追加して
if　( shotflag == 1 ){
GetGraphSize( enemy01 , &SizeX , &SizeY ) ; //グラフィックのサイズを取得
とする。
次に、その下のほうの
int Color ;
の前に閉じ括弧を追加して
}
int Color ;
とする。
つまり、当たり判定をしている部分を
if　( shotflag == 1 ){
}
で括る。

それとインデントをきっちりしないとネストレベルが分からなくなるよ。

**名前は開発中のものです。** · 2008/12/13(土) 22:53:39

>>273
んーていうかC#の件は、ライブラリが優秀で作りやすい＝オブジェクト指向って事じゃなくて、
コントロール一つ設置してイベントを呼び出すってだけでオブジェクト指向を感じる。
もっと具体的に言えばイベントハンドラ（やデリゲート）がオブジェクト指向だなぁって。

提示してくれた下のコードも、それだけじゃオブジェクト指向を感じない。
結果的に言わんとしようとしてることはわかるけどね。
ただそれだけじゃただのサブルーチン呼び出し。

言いたいのはそのコードだけを見てオブジェクト指向じゃないって事じゃないし、
自分でゲーム作る時もオブジェクト指向で書きたいわけだけど、
概念的に無理やり感があるのと、非オブジェクト指向でも書けるってので、
GUIアプリと比べて相性がいい方ではないって事。

**名前は開発中のものです。** · 2008/12/13(土) 23:05:58

>>285
おおおおおおお！！！ありがとおおおおお
一つのライフしか減らないｗｗｗｗｗｗｗ

すげー！ショットフラグがＯＮの時にしか判定しないようにするってそういう事だったのかｗｗｗ

ちなみにプログラムの書き方？はこんな感じでいいのかな？

**名前は開発中のものです。** · 2008/12/13(土) 23:22:28

どうでもいいけど定数を#defineで書くのとconstで書くのってどっちがいいのけ？
俺は気持ち悪いからconstでやってるわけだが

**名前は開発中のものです。** · 2008/12/13(土) 23:33:22

>288
・歴史的な経緯とかはあるかも
・特に理由が無ければconstでいいんじゃね？
・defineじゃないと出来ないこと、スマートなこともあるから気をつけろ

**名前は開発中のものです。** · 2008/12/13(土) 23:34:35

>287
とりあえず、何でもいいので1つ完成させてからじゃないと
定番の書き方とかは説明しても意味が無いし、おそらく理解できないと思う。

**名前は開発中のものです。** · 2008/12/13(土) 23:42:11

#defineは計算式入れられるのがいいな
気を付けないと間違った結果が返ってくるハメになるが

DXライブラリ 総合スレッド 2008

DXライブラリ総合スレッド 2008