ドラゴンクエストクローンを作ろう (746レス)
上下前次1-新
420: 名前は開発中のものです。 [] 2006/07/09(日) 22:19:14 ID:+Qr3aq5u(1) AAS
 あんま細かい挙動は気にしなくてもおkじゃないかな。 
421: 名前は開発中のものです。 [sage] 2006/07/09(日) 23:01:20 ID:kZxAL1hq(1) AAS
 >仲間呼び出し 
 DQ2では1つの画面内で出現する敵数のアルファベットを使いまわす様です。 
 というか仲間呼び出しよりむしろ旅の扉が・・・(パレット使えないので)
422(1): 名前は開発中のものです。 [sage] 2006/07/10(月) 16:49:31 ID:uX9pMO6R(1) AAS
 むしろエフェクトのほうが問題じゃねえか。 
 色は違うビットマップ用意すればすむことだし。 
423(1): 名前は開発中のものです。 [sage] 2006/07/10(月) 16:52:17 ID:CfejISFX(1) AAS
 パレット使えばいいじゃん 
424(1): 名前は開発中のものです。 [sage] 2006/07/11(火) 03:10:10 ID:Ybzn37tE(1) AAS
 >>422 
 >むしろエフェクトのほうが問題じゃねえか。  
 DQ2にエフェクトと呼べるようなものはありましたっけ・・・ 
 魔法を唱えた時のフラッシュ等でしょうか? 
  
 >色は違うビットマップ用意すればすむことだし。 
 一度それで解決したのですが旅の扉は一回に48回色が変化するので 
 マップチップ256x256x2B(16bit時)の画像x48で6MBも使ってしまいます。 
 ただの意地ですが何となくDQ2にVRAM6MBも喰うのはなんだか悔しい。 
 かといって最近のチップはハードレベルではパレットに対応して 
 いないので、下手に256色モードで起動すると場合によっては話に 
 ならないくらい重くなる。 
 残る手段は画面は16bit以上の場合でもパレットの効果を得る為の 
 擬似パレット画像の機能を用意してソフトでガリガリ書く方法ですが、 
 今の所描画は全てハードで描画しているのでなるべくソフトとハードの 
 描画処理を混ぜたくない。(速度も遅くなるし不具合が起こる環境が多くなる) 
 とはいえ背に腹は変えられない、ということで結局その機能を使って 
 解決しました。(擬似パレット画像の機能はDXライブラリのものを 
 そのまま使っただけですが) 
  
 >>423 
 紆余曲折を経ましたが仰る通りの結果となりました。
425(4): 名前は開発中のものです。 [] 2006/07/14(金) 00:32:16 ID:XNNCuakE(1) AAS
 >>424 
 ところでDXライブラリ使ってるみたいだけどこれ使わなくてもDQ1みたいなゲームつくれんの? 
426(1): 名前は開発中のものです。 [sage] 2006/07/14(金) 16:57:26 ID:Gj7Nrkw/(1) AAS
 もちろんできるし 
 ファミコンのグラフィック機能組んだほうが楽そうだけど。 
 ソフト描画になるがたいしたことないだろうし。 
427(2): 名前は開発中のものです。 [sage] 2006/07/14(金) 19:08:57 ID:p+qm4mCS(1/2) AAS
 >>425 
 作れます。 
 家庭用ゲーム機と同じ60FPSのゲームの場合は最低でもDirectXを 
 使う必要があると思いますが、逆にDirectXを使える環境であれば 
 DXライブラリだろうとLUNAだろうとDirectXを直に使う場合だろうと 
 問題ないと思います。 
 C言語以外でも作れるかどうかは、C言語しか知らないので分かりません。 
 DQ1程度のデータ規模を楽に扱える言語仕様(C言語で言う構造体があれば 
 とりあえず大丈夫だと思う)と60FPSでゲームを動かすことが出来る 
 くらいの速度で動作して、且つその言語でDirectXを使えるような 
 仕組みがあれば問題無いと思いますが。
428(1): 名前は開発中のものです。 [] 2006/07/14(金) 21:05:39 ID:2BtiSCsl(1/2) AAS
 DIBで行け。 
429: 名前は開発中のものです。 [sage] 2006/07/14(金) 21:17:48 ID:p+qm4mCS(2/2) AAS
 DIBで640x480で60FPSって可能ですか? 
 可能であればDirectXの使用環境は必須ではなくなりますが・・・
430(1): 名前は開発中のものです。 [] 2006/07/14(金) 22:05:12 ID:2BtiSCsl(2/2) AAS
 可能すぎる。 
  
 ただし、グラボの恩恵を最大限には受けることが出来ない。 
431(1): 名前は開発中のものです。 [sage] 2006/07/15(土) 00:21:00 ID:J160mIqM(1/10) AAS
 試してみました。 
 640x480一回の転送で約5ms、60FPSで1フレ約17msですから余裕ですね。 
 何か勘違いしていました。申し訳ありません。 
  
 この際環境依存が激しいDirectXを捨ててDIBに乗り換えようかと 
 思ったのですが、私が知る限りではDIBは垂直同期を取る方法が 
 なかったような気がします。 
 スクロールするゲームではなるべくテアリングは避けたいのですが、 
 DIBで垂直同期を取る方法はあるのでしょうか?
432: 名前は開発中のものです。 [] 2006/07/15(土) 00:39:27 ID:81t16XAC(1/4) AAS
 同期方法と言うか、それは自分で作るところでは無いんですか? 
433: 名前は開発中のものです。 [sage] 2006/07/15(土) 01:16:03 ID:J160mIqM(2/10) AAS
 垂直同期はゲームの進行処理の同期のこととは違います。 
 ハードの信号なのでソフトだけでは解決出来ません。 
  
 詳しくはこちらをどうぞ。 
 本文を「ティアリング」で検索して下さい、丁度その説明があります。 
 外部リンク[html]:ascii24.com 
 (古い記事ですがティアリング、垂直同期辺りは昔話ではありません)
434: 名前は開発中のものです。 [] 2006/07/15(土) 01:53:20 ID:W+y22RQ0(1) AAS
 1はへたれ  市ねww ぶはははw 
435(1): 名前は開発中のものです。 [] 2006/07/15(土) 03:05:51 ID:81t16XAC(2/4) AAS
 俺が言葉足らずだったのは申し訳ないが、 
 垂直同期をとるところは作るもんではないんですか? 
  
 dxみたいに同期を待ってくれるものがあれば、それを使えばいいですけれども。 
  
 実験して5msとあるのであれば、16.6待つまでに時間あるから 
 あんまり気にしないでも大丈夫だと思います。 
436: 名前は開発中のものです。 [sage] 2006/07/15(土) 07:56:06 ID:J160mIqM(3/10) AAS
 >>435 
 ですから、垂直同期をとるには専用のAPIが必要なんです。 
 垂直同期信号を検地する為のAPIが無ければ何時垂直同期信号が 
 来ているのか知る術はありません。 
 そのAPIが私の知る限りではDirectX以外に無いのです。 
  
 標準のWin32APIにDirectDrawのWaitForVerticalBlankやGetScanLineに 
 相当する機能を持つAPIがあれば良いのですが、ご存知ですか?
437(1): 名前は開発中のものです。 [] 2006/07/15(土) 09:08:09 ID:gt1duSp0(1) AAS
 んなもん使わねーよ 
438: 名前は開発中のものです。 [sage] 2006/07/15(土) 09:26:13 ID:J160mIqM(4/10) AAS
 >>437 
 実際はFlipやPresentの中で自動的に垂直同期を待ってからフリップ 
 されるのでWaitForVerticalBlankやGetScanLineを使う機会は無い 
 かもしれませんが、要はDIBに垂直同期を待ってからスクリーンに 
 画像を転送すき仕組みがあるかどうかです。 
 無い場合はテアリングが発生してしまうのでスクロール処理がある 
 2Dのゲームには向いていないということになります。
439(1): 名前は開発中のものです。 [sage] 2006/07/15(土) 09:27:46 ID:9Xtt4+04(1) AAS
 ウィンドウで動くアプリで垂直同期は全く関係ないとおもったけど? 
  
 てーかフルスクリーンで動くDirectXだからこそ関係ある話。 
440(1): 名前は開発中のものです。 [sage] 2006/07/15(土) 10:24:05 ID:J160mIqM(5/10) AAS
 >>439 
 デスクトップが希望のリフレッシュレートになっていないと 
 見苦しいことになりますが、一応ウインドウで動くアプリでも 
 垂直同期は関係あります。 
 試しに同期を取るアプリと取らないアプリをうpしましたので 
 お時間があれば試してみて下さい。 
 (画面のリフレッシュレートが60Hzだと違いが特に分かります) 
  
 外部リンク[zip]:gamdev.org 
  
 リフレッシュレートがゲームのFPSと合っていない場合は垂直同期 
 を取っても取らなくても見苦しくなりますが、最近はリフレッシュ 
 レートの設定項目数が少ない液晶モニタが普及しているので 
 ウインドウで動作させる場合も割と意味があると思います。
441: 名前は開発中のものです。 [sage] 2006/07/15(土) 10:31:52 ID:J160mIqM(6/10) AAS
 >>425 
 論点を >>431 で少しずらしてしまいましたが、テアリングを気に 
 しないのであれば >>430 の指摘通り >>427 の条件からDirectXは外れます。 
 誤ったレスをしてしまって申し訳ありません。
442(1): 名前は開発中のものです。 [] 2006/07/15(土) 12:10:07 ID:81t16XAC(3/4) AAS
 >>440 
 上げてくれた同期取りをしない奴に、 
 自分で作った垂直同期とりの関数かなんかをいれると 
  
 上げてくれた同期取りをしている方のような動作に出来ます。 
  
 って俺はそうしてるんだが・・・。 
443: 名前は開発中のものです。 [sage] 2006/07/15(土) 12:29:37 ID:J160mIqM(7/10) AAS
 >>442 
 >自分で作った垂直同期とりの関数かなんかをいれると 
  
 それはDirectXを使わない方法ですか? 
 もしDirectXを使わないで垂直同期をとっているのでしたら 
 是非その方法を教えていただけないでしょうか。 
 私もDIBで済むのならDIBにしたいので・・・
444(1): 名前は開発中のものです。 [sage] 2006/07/15(土) 16:41:48 ID:WwdAlzc2(1) AAS
 内部の描画はDIBでやって 
 表示だけdirectdrawにすりゃええやん。 
上下前次1-新書関写板覧索設栞歴
あと 302 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.022s