ゲームプログラミング相談室

**プチ9627ｍ** · 01/11/06 18:47

ゲームプログラミング全般についての質問スレッド。
駄スレ立てる前にココで聞きましょう。

■旧スレ（プログラミング技術板より）
○パート１
http://piza.2ch.net/tech/kako/969/969984472.html
○パート２
http://pc.2ch.net/test/read.cgi/tech/985540361
○パート３
http://pc.2ch.net/test/read.cgi/tech/1002894129/

**名前は開発中のものです。** · 02/10/10 00:10

パーツを動的に弄らないという前提なら

_ · 02/10/10 02:32

>>702
遅いのはJavaアプレット。
Javaアプリケーションといっしょにするな！ボゲェ！！

**名前は開発中のものです。** · 02/10/10 07:50

>>705
今現在Javaでゲーム作ってる漏れが言うのも何だが、
起動とGUIは非常に遅いっす。色々工夫しないと話にならんです。

**要ブックマーク** · 02/10/10 11:15

Computer Programing(日本語)
http://www.realdigital.co.jp/densi2/progindex.html
＞C言語・C＋＋言語・WINDOWSプログラム・DirectX Draw・DirectX 3D・ソフトウェアライブラリー
＞各言語の説明と、サンプルソース。

ＹａｎｅｕｒａｏＧａｍｅＳcript & SDK本体
http://www.sun-inet.or.jp/~yaneurao/links/ygs/

yaneuraoGameScript2000
http://isweb19.infoseek.co.jp/computer/yaneurao/ygs/
＞初心者向けＣ言語によるゲーム制作指南

Ｃ言語初心者向けリンク集
http://www3.mahoroba.ne.jp/~seibi/gad_cgi/html/16_02.html

ヒューマンアカデミー
http://www.athuman.com/a/it/course.html
＞３ヶ月コースなど

初心者向けゲーム制作講座"Delphi de GAME"TopPage
http://www.din.or.jp/~koudai/Delphi/Delphi.html

**名前は開発中のものです。** · 02/10/10 12:07

>701
はぁ？DirectX8にスプライト関数（ラッパークラス）あるだろ？
非常に簡単に半透明使えるし、回転拡大縮小できるし、ポリゴンみたいなこと
できるし、いいんじゃないの？エフェクトはかけられないけど・・・。
DirectDrawより簡単ではるかに便利。2Dならこれを使えや

**名前は開発中のものです。** · 02/10/10 12:11

>>701はもうプログラム諦めたに1000ﾏﾝｾｰ

**名前は開発中のものです。** · 02/10/10 12:28

DirectX8以降だとWin95を切り捨てる事になる。

**名前は開発中のものです。** · 02/10/10 13:02

>>708はID3DXSpriteまともに使った事無いに１０万ペリカ

**名前は開発中のものです。** · 02/10/10 13:45

おまえら、相談室で煽りあうのは寄席。

**名前は開発中のものです。** · 02/10/10 16:22

煽りあいできるクソスレは他にいくらでもあるだろう

**名前は開発中のものです。** · 02/10/10 16:37

（´-`）.｡oO(くどい)

**708** · 02/10/10 16:41

DX8のスプライト関数使うとよく叩かれるんだけど
なんか理由あるの？
drawPrimitiveUPと比較しても速度変わんないんだけど？
抜き色指定とかでDDS使わない分、楽でいいだろうに・・・。

**708** · 02/10/10 16:42

ｱｹﾞﾊﾁｮｳ

**ひきプロ** ◆8fhky/PGis · 02/10/10 16:49

>>703
ためしに作ってみたら毎フレーム全部描画しても
GDIの時より軽くなりますた。
>>708
そういえばアルファブレンドができなくて悩みました
８のヘルプも読んでみようと思います

**名前は開発中のものです。** · 02/10/10 17:02

>>715
ID3DXSpriteを使うと叩かれるのか。謎だな。
それはどこでの話だ。

**708** · 02/10/10 17:43

>>718
2ｃｈ

**名前は開発中のものです。** · 02/10/10 17:51

ID3DXSpriteで、scaleで拡大率変えてたんだけど、
他の環境で動かしたらscaleが有効になってなくてしょぼんだった。

**718** · 02/10/10 17:54

>>719
ｽﾚのﾘﾝｸを貼るほどの価値もない話題ということか。
それなら気にしねーほうがいいんじゃねーの。
　
どうせ具体的な指摘は何も無かったんだろ？

**名前は開発中のものです。** · 02/10/10 18:08

（　´,_ゝ`）ﾌﾟッ

**名前は開発中のものです。** · 02/10/10 19:04

708=722？

**718** · 02/10/10 19:15

>>723
違うだろ。さすがに。

**名前は開発中のものです。** · 02/10/10 20:45

ID3DXSpriteだと256*256以上の大きさのテクスチャを扱えないからじゃねーの？

**名前は開発中のものです。** · 02/10/10 20:50

そんな制限は無い

**名前は開発中のものです。** · 02/10/10 22:57

>>726
あるぞ。

**名前は開発中のものです。** · 02/10/10 23:53

>>708
> DirectDrawより簡単ではるかに便利。
DirectDraw は初期化と、ロスト時の再初期化処理だけで意外と面倒。

**名前は開発中のものです。** · 02/10/11 00:28

>>727
無い
サイズの制限はハード依存であってID3DXSpriteそのものの制限とは関係ない

**名前は開発中のものです。** · 02/10/11 00:33

どのみち相対的な話である。

**730** · 02/10/11 00:46

730は728へのレス。

**名前は開発中のものです。** · 02/10/11 02:21

＞725 ：名前は開発中のものです。：02/10/10 20:45 ID:pMa8asNt
＞　　ID3DXSpriteだと256*256以上の大きさのテクスチャを扱えないからじゃねーの？
＞726 ：名前は開発中のものです。：02/10/10 20:50 ID:???
＞　　そんな制限は無い
＞727 ：名前は開発中のものです。：02/10/10 22:57 ID:???
＞　　>>726
＞　　あるぞ。
＞729 ：名前は開発中のものです。：02/10/11 00:28 ID:???
＞　　>>727
＞　　無い
＞　　サイズの制限はハード依存であってID3DXSpriteそのものの制限とは関係ない
　
このやりとりは不毛だな。まず具体例書いてくれ。
　
　Windows98SE + DirectX8.1(debug runtime)
　GeForce256 (Detonatorﾄﾞﾗｲﾊﾞ 40.72)
　D3DCAPS8.MaxTextureWidth　 = 2048
　D3DCAPS8.MaxTextureHeight　= 2048
　
　Windows98SE + DirectX8.1(debug runtime)
　ATI RADEON ALL-IN-WONDER (ﾄﾞﾗｲﾊﾞ 4.13.01.9039 7.72-020524M-004273C)
　D3DCAPS8.MaxTextureWidth　 = 2048
　D3DCAPS8.MaxTextureHeight　= 2048
　
上記2つ例ではID3DXSprite固有のテクスチャサイズ制限(256x256)は確認できない。

**名前は開発中のものです。** · 02/10/11 02:45

チュートリアルの5だと多少の変更で実行できるので、とりあえずコード書いて動かしてみたが、
Drawだと左上から256×256の部分が表示されるだけだな。
GeForce2MXだからVoodooのような256×256の制限はない。

確かDirectX7の時にはこの制限がなかったと思うが。

**名前は開発中のものです。** · 02/10/11 03:43

Geforce3(32MB)で512*512テクスチャを試した。問題なく表示された。
ドライバは40.72 Beta

**734(補足)** · 02/10/11 03:44

環境はWin2k+DirectX8.1SDK

**734** · 02/10/11 03:50

>>733
2MXで問題が出るってことは結構メジャーな問題ぽいね。
HALドライバ依存の問題はいつも頭痛の種になるから欝。

**名前は開発中のものです。** · 02/10/12 08:41

テクスチャサイズが256x256に制限されるのは、
VooDoo系チップの場合じゃ、ホゲェェェ!!
そういうハード特有の事情を知らんやつが、
Direct3D触るとろくなことがない。

**名前は開発中のものです。** · 02/10/13 01:22

>>737
だからハードウェアの制限とID3DXSpriteの制限を分けろよ（藁

**名前は開発中のものです。** · 02/10/13 03:02

>>737
おまいのまなこたんは、ふしあなさんでつか？

**名前は開発中のものです。** · 02/10/13 03:30

要点は256×256以上のテクスチャサイズを扱えるにも関わらず、
ID3DXSprite・Drawだと256×256以上のテクスチャは使えないだな。

**名前は開発中のものです。** · 02/10/18 08:11

>>733
DirectX8.1bのランタイムと
ｎVidiaの最新ﾄﾞﾗｲﾊﾞを使ってみたか。

**名前は開発中のものです。** · 02/10/22 20:32

ゲームで、プログラム以外のファイルからデータを読み出したいのですが、
データを生で置きたくないのです。

他のゲームを見てみたら、結構暗号化(?)されてたりして読めないのがあるのですが、
あれはどうやっているのでしょうか。

セーブデータや環境設定。
jpeg画像。
midやwavファイル。

についてそれぞれ教えてください。

**名前は開発中のものです。** · 02/10/22 20:33

すいません、環境は

VS.NET
C++
DirectX8

です。

**名前は開発中のものです。** · 02/10/22 20:41

どうやるもなにも自分で好きなように変えれば良いだけ

**名前は開発中のものです。** · 02/10/22 20:43

>>742
初心者スレ向けの内容だね。

「普通に読めない」というのは、暗号化（スクランブル）の場合と
圧縮の場合がありますが、それぞれについて。
スクランブルに決まったやり方はありません。
なぜなら、決まった暗号化の手続きがあるのであれば、
決まった複号の手続きで簡単に戻されてしまい、暗号化の意味が無いからです。
ですが、全部1bitローテートするだけで普通に読めなくなるので
簡単なものでも問題なしかと。

圧縮については、辞書圧縮や動的ハフマン法、ランレングス法といった
有名なアルゴリズムがありますのでそういったものを利用する場合が多いようです。
具体的なアルゴリズムは文献を調べるなりネットで調べるなりしてください。

**名前は開発中のものです。** · 02/10/22 22:57

マップの書き方はどういうのがいいのやら

**名前は開発中のものです。** · 02/10/22 22:58

先頭に余分なものを追加するなり1ビットずつ反転するなり好きにするよろし

拡張子だけ変えて実はgifそのもの、なんてのもあったなー。すぐばれるけど。

**名前は開発中のものです。** · 02/10/22 23:38

>>746
どんなマップ？
平面なら二次元配列でいいと思うが。

**名前は開発中のものです。** · 02/10/23 00:55

逆汗すれば終わりだなー
名かには逆汗ブロックするものもあるけど

**名前は開発中のものです。** · 02/10/23 01:44

>>749
ん？　発想が逆だと思うよ。

「リバースエンジニアリングされたら終わり」じゃなくて、
「リバースエンジニアリングされなきゃ大丈夫」。
平文で読まれなきゃ読める人は大きく限定されるわけだからね。

でも、解析されても、個人製作のソフトにそこまで情熱を傾けてくれるのなら
それはそれで嬉しい気もする。

**名前は開発中のものです。** · 02/10/23 21:37

ゲーム製作者に質問です。

正直、Vectorにある数多くのフリーゲームで、何割くらい(または、いくつくらい)が
遊べるゲームだと思っていますか？

人によってかなり答えが異なると思いますが、みなさんの意見を聞かせてください。

**名前は開発中のものです。** · 02/10/23 21:50

プログラミングとの関係がないなら雑談スレでやろうよ・・・

**名前は開発中のものです。** · 02/10/23 23:47

>>751
http://game.2ch.net/test/read.cgi/gamedev/1007129482/84n-

**名前は開発中のものです。** · 02/10/24 16:35

>>751
個人的にはゼロ。
ぜんぜん遊べん。

**名前は開発中のものです。** · 02/10/24 17:51

タスクあるいはジョブコンと呼ばれるリアルタイム処理なプログラミング技法上で
再帰処理が必要な思考ルーチンを組まなければならない場合、どうやってますか？

**名前は開発中のものです。** · 02/10/24 17:57

製作中断

**名前は開発中のものです。** · 02/10/24 19:21

>>755
ageないと質問に答えてもらいにくいよ
急いでいないならいいが

**755** · 02/10/24 19:37

>>757
急ぎではないのでﾏﾀｰﾘ待ちます。

**名前は開発中のものです。** · 02/10/24 19:44

>>755
・マルチスレッド
・再帰処理をタスクシステムへ載る様に組み直す

パッと思いつくのはこれぐらい。

**名前は開発中のものです。** · 02/10/24 20:59

>>754
そんなことはない。少なくともゼロではない。

>>760
必死だな(w

**名前は開発中のものです。** · 02/10/24 21:41

>>760
なんでそんなに必死なの

**名前は開発中のものです。** · 02/10/24 22:06

warata

**名前は開発中のものです。** · 02/10/24 22:50

ﾜﾛﾀ

**名前は開発中のものです。** · 02/10/25 02:42

こんな事で笑っていてはいけません。
もっとおかしい事はたくさんありﾏﾝｺ｡

**755** · 02/10/25 10:46

>>759
２番目の奴の詳細解説キボン。
擬似スタックを作るんだっけ？

**名前は開発中のものです。** · 02/10/25 11:11

おまいらは、そんなにも擬似とつけたいのでつか？
おまいらが、いまよんでいるのは擬似文字でつか？

**名前は開発中のものです。** · 02/10/25 14:59

擬似じゃなくて仮想なら無問題？

**名前は開発中のものです。** · 02/10/25 15:06

いまここにある文字は
おまいらにとっては仮想文字なんでつね？

**名前は開発中のものです。** · 02/10/25 16:06

ごめん、virtualにしといて

**755** · 02/10/25 16:07

仮性ホーケーは黙ってて欲しいな >768

**759** · 02/10/25 17:17

>>765
そういうことです。配列にスタックを作って自前で管理し、ローカル変数を
そのスタック上に置きます。
再帰を単純なループに開いた上、タスクシステム上でまわす事になります。

**名前は開発中のものです。** · 02/10/25 20:04

DirectXフルスクリーン＠C言語で、
ユーザーからの入力文字（漢字変換とかもアリ）をげっちゅーするには
やっぱりInputBoxのAPIしかないのでしょうか？

**名前は開発中のものです。** · 02/10/26 01:01

XindowsXP HomeEditionを使っているのですが、
自分のプログラムを実行するごとに重くなっていきます。
プロセス自体はちゃんと終了しています。

windowsって、プログラム終了時にメモリの解放って行ってくれないんですか？
まぁ、自分がメモリリークをつぶさなければいけないのですが。

特に、大き目の画像を扱った後にそのような現象がおきるみたいです。
どうなんでしょう。

**名前は開発中のものです。** · 02/10/26 01:14

>>773
タスクマネージャに該当プロセスがないことは確認したかい？

**名前は開発中のものです。** · 02/10/26 01:14

はい、確認しました。

**名前は開発中のものです。** · 02/10/26 01:28

解放は自動的に行われることになってるし、XPはNT系だからさらに安全なはず。
ただしこれはドライバが正常に動作していればの話。
ディスプレイドライバを更新するとかしてみれば？

**名前は開発中のものです。** · 02/10/26 01:46

メモリ確保して開放せずに終了したら駄目じゃん。

**名前は開発中のものです。** · 02/10/26 02:48

>>777
プロセス終了時のメモリ解放は
OSの管轄ですが何か？

メモリリークが問題になるのは
長時間常駐するプロセスだけ

**名前は開発中のものです。** · 02/10/26 02:55

不正な処理で終了した場合も開放してくれる？

**名前は開発中のものです。** · 02/10/26 03:54

>>779
まさか、しないと思ってるのか？

**名前は開発中のものです。** · 02/10/26 04:37

Win95のころはひどかったな。
一応OSが開放してくれるハズだが、
それを過度に期待したプログラムを組むのは避けた方が無難。

**名前は開発中のものです。** · 02/10/26 04:44

関係ないけど、windowsでプログラム書くんだったら
確保したメモリは必ず自分で解放しなくちゃダメだよ。
OSを信用する方が悪い。

**名前は開発中のものです。** · 02/10/26 07:46

ＯＳが開放してくれるとしても、それはあくまでも開放ミスに対する
救済措置と思ったほうがいい。確保したメモリは必ず開放するのが鉄則。

**名前は開発中のものです。** · 02/10/26 10:14

またmalloc&freeネタか・・・飽きないねえ

**名前は開発中のものです。** · 02/10/26 12:43

>>783
> ＯＳが開放してくれるとしても、それはあくまでも開放ミスに対する
> 救済措置と思ったほうがいい
そりゃ違うだろ。

そもそも仮想記憶を使ってる OS の場合、ページテーブルやら TLB (*1) やら
は OS 以外は触れない。そこにバグがあると疑い始めたら、もはやアプリケー
ション側でとれる対策は何もないよ。

(*1)
IA-32 だと TLB はソフトウェアからいじる必要はない（ページテーブルをハード
が勝手にコピーしてくれる）けど、MIPS などは TLB ミスが起きると例外を発生
して、OS が自前で埋める必要がある。

**名前は開発中のものです。** · 02/10/26 14:26

どんな環境でも開放しなかったメモリの後始末をしてくれる
という保証は無いからメモリリークするようなプログラムは
そもそも欠陥品と見ていい。だから開放しないと駄目。
それにＯＳが開放しなかったからといって、それはＯＳの
過失ではない。プログラム作った奴が悪い。

**名前は開発中のものです。** · 02/10/26 14:35

786でまとまりました。

では次の話題。
↓

**名前は開発中のものです。** · 02/10/26 15:24

実験に使いたいのですがOSがリソースを開放できない終了方法を教えてください
いくらやってもけしからんことに勝手に開放されてしまいます

**名前は開発中のものです。** · 02/10/26 16:18

>>788
Win98でRPCだか何だかを使うと起こりやすいそうだ
使ったことないけど

**名前は開発中のものです。** · 02/10/26 16:22

>>788
ＤＯＳ環境とかゲーム専用機等ならたぶん開放しないのでは。

**名前は開発中のものです。** · 02/10/26 22:41

>>745
アルゴリズムが公開されている暗号もある。

>>755
タスクと再帰処理がなぜ両立できないのか分からん。

>>788
何の実験に使うのか知らんが。
ファイルや共有メモリ等、OSが勝手に解放することがないリソースは存在する。
存分に使え。

**名前は開発中のものです。** · 02/10/27 01:11

>>786
そもそも「どんな環境でも」なんて言い出したら、それこそ malloc/free がない
世界とか、あっても C 言語の規格書に従ってない環境まで出てくるから、議論
にならんよ。

規格書を行間まで読めば、C 言語の hosted environment を前提とする限り
malloc したメモリは OS に解放されるはず、が結論。

だいたいヒープの仕組みとか仮想記憶の仕組みを知っていれば、そんなに
ビクビクする必要はないと思うんだが。解放されないって、実際にどんな環境
を想定してるんだ？

（スタイルとして解放する方が良いかは別問題な）

**名前は開発中のものです。** · 02/10/27 01:28

つーか、解放しないと再利用できないじゃん？
こまめに解放してメモリを開けたほうがいいと思うんだが。

**名前は開発中のものです。** · 02/10/27 01:52

ＰＳ２のアルファブレンド設定を
DirectXでもやりたいのですが、　そういうことはできないのでしょうか？
たしか　こんな計算式
　C　=　（A+B）>>7+D

　　　A:　と　B:
　　　ソースのカラーか　フレームバッファのカラー
　　　
　　　D:　ソースかフレームのアルファ値

**名前は開発中のものです。** · 02/10/27 03:45

>>794
IDirect3DDevice8::SetTextureStageState( )

**名前は開発中のものです。** · 02/10/27 05:52

>>793
ところが大抵の処理系では
freeは解放済みフラグが立つだけで
実際に解放されるのはプロセス終了時なんだな・・・

**名前は開発中のものです。** · 02/10/27 06:27

JAVAなんかはガベッジコレクションを行ってくれるけどね。

**名前は開発中のものです。** · 02/10/27 09:49

>>796
それじゃfree自体存在意義ねーじゃん

**名前は開発中のものです。** · 02/10/27 10:25

>>798
けど同じプロセスが再び○allocするときは
その解放済みの領域からメモリ確保するので
あながち無意味とも言えない

**名前は開発中のものです。** · 02/10/27 10:53

>>798
一種のキャッシュだよ。まっとーなメモリ保護のある環境下で OS を呼び出して
メモリを割り当ててもらうのは

　ソフトウェア割り込みによる特権モード変更
　割り込みハンドラでのレジスタの待避などの定型処理
　 (ここで OS のメモリ割り当て関係のコードに入って)
　各種制限のチェック（たとえばユーザあたりのメモリ割り当て越えてないか、
　とか)
　仮想記憶のページテーブル、TLB の変更
　 OS の持つ仮想記憶レイヤーにおけるページエントリの変更

と、いろいろ手間がかかる。ユーザ空間で完結できれば、それに越したことはな
い。

このあたりは使ってるライブラリによっても変わってくるけど、昔の UNIX だと
一度 malloc したら二度と OS には返さないのが一般的で、最近でも条件 (*1)
が揃わない限りはまず返さない。

本当に OS からメモリを短時間・大量に借りたいなら malloc/free なんか使っ
ちゃダメです。mmap() とか VirtualAlloc() とか使いましょう。

(*1)
ヒープの端っこが free() されるとか、ページ単位で連続した空間が free される
とか。この条件を緩くして OS 側に返すチャンスを増やそうとすればするほど、
malloc/free が内部で管理・チェックするデータが増え、割り当て・解放に掛か
る時間もメモリ消費も大きくなるというトレードオフがある。

たとえば Solaris だと libc, libmalloc, libmapalloc あたりに実装が異なる
malloc/free がいくつかあるから、ソースを眺めながら処理速度を比べてみると
勉強になるよ。

**名前は開発中のものです。** · 02/10/27 11:02

検索で調べてみたが、実際メモリリークは問題になって
るからメモリ開放しないプログラムを書くのは良くないと思う。

**名前は開発中のものです。** · 02/10/27 17:34

>>800
Win32の場合、mallocもVirtualAlloc呼び出してんじゃないの？
同様に、freeはVirtualFreeって感じで。
メモリマップはこれらとは違うだろうけど。
思い切り勘違いなら、ごめんな。

**名前は開発中のものです。** · 02/10/27 17:36

＞Win32の場合、mallocもVirtualAlloc呼び出してんじゃないの？
Win32じゃなくてCのランタイムライブラリの実装次第

＞思い切り勘違いなら、ごめんな。
あやまるくらいなら最初からいい加減なことは書くな