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

**プチ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/05/23 22:58

名前をsageちまった。
俺が頭悪かったようです。
逝ってきます。

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

>>497 FUCK aSS

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

>>497
あんまり、本当の事を言うと話が止まるので
わかっていてもしらんぷりしとけよ（ﾜﾗ

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

トルネコみたいなダンジョンではなく、女神転生シリーズに近い
通路ばかりのダンジョンをランダムで生成したいのですが、
唯一見つかったアルゴリズムでは綺麗なダンジョンが作れませんでした。
トンネルを掘るようにしてダンジョンを作るアルゴリズムを使うと
綺麗なダンジョンが作れる、と読んだのですが、参考になる
情報などがありましたら教えていただけないでしょうか？
よろしくお願いします。

**名前は開発中のものです。** · 02/05/24 01:54

http://members.tripod.co.jp/karai/
このページ見た？なんか凄そうだけど。
色々なパターンが紹介されているみたいだし。

**416(HSP)** ◆HoSW/FCI · 02/05/24 03:53

>>501
　0が通路で1が壁だとすると、まず、n×mの広さを1で全部埋めます。一番外側だけ0にすると範囲チェックしなくて済むから楽かも。
　で、親座標と子座標を用意して、親は左上から右下まで2ステップずつ捜査させます。子は親からランダムに4方向を選んで移動するわけですが、これも2ステップずつ移動させます。子の移動先が壁だったら掘って、またランダムに移動。
　移動予定先が全部通路で選択肢が無い場合は、子の移動は終了して、親を1つ進めます。
そしてまたその親座標から子を移動させて動けなくなるまで掘っていく。これを最後まで繰り返すと解が1つだけの迷路ができます。

　同様の方法で2つの接しない壁を作っていくという方法もありますが、上記のほうがシンプルかも。

**416(HSP)** ◆HoSW/FCI · 02/05/24 04:06

　上記の方法を発展させ、矩形を用いて自由な角度に掘り進んでいく方法も。
　すでに掘った場所には移動しない、という判定自体は同じです。この場合の分岐方法は、掘り進んでいく過程で分岐点を複数置いていく(記憶していく)ことになります。
　記憶しないで矩形の範囲単位で掘れるだけ掘るという方法もありますが、洞窟っぽくはならないでしょう。また、掘っていく過程で矩形の大きさを変えれば、より自然の洞窟に近い迷路ができます。

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

>>502
アルゴリズムを作れそうにはないけど
パズル的に楽しませていただきました。

>>503
そのアルゴリズムをベースに作ってみようかと思います。
ありがとうございました。

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

完全ランダムで無くて良いのなら n x n のサイズの小さい迷路を
いくつか作っておいて、つながるように並べるのもあり

**やさしい** · 02/05/27 01:43

板で協力してゲームを作ろうと思ったので
プログラマを募集してます
われこそはと思うつわものは覗いてください

http://ex.2ch.net/test/read.cgi/shar/1022428219/

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

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

sage

**オ㍗ル艦長** · 02/06/25 14:18

緊急浮上

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

ＶＢで敵を誘導させて全滅させればクリア、というゲームを作っています。
敵の番になったら、自分のいるマスにむかって１歩（1マス）近づく、
という感じにしたいのですが、ちょっとなやんでいます。

敵のキャラと自分のキャラの座標を比較して、
敵のｘ座標が自分のｘ座標より大きければ1マス分増やす、
ｙ座標が自分のｙ座標より小さければ1マス分減らす、というかんじです。

ifやSelect Case の入れ子でやってみたんですが、
行がながーくなってしまって、
どうもこれでは上手いやり方ではないような気がします。

もっと効率の良い考え方がありましたら教えていただければと思います。
説明がへたですみません。。

**511** · 02/07/24 12:49

あげてみたり。。。。

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

>>511
どうして長くなったのかわかんないけど、行がなが～くなったらそれぞれの処理を分割するしかないのでは？
ifの条件文が長い場合はあらかじめ比較するモノを変数に入れておくとか。
if～endifはつかってるよね？

手法としては、移動する処理自体を1つの関数にしておいて後から高速化するのが望ましいかも。
とりあえず遅くてもゲーム自体はできるから。

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

>>511
>敵のｘ座標が自分のｘ座標より大きければ1マス分増やす、
>ｙ座標が自分のｙ座標より小さければ1マス分減らす、というかんじです。

敵のｘ座標が自分のｘ座標より小さい場合や
ｙ座標が自分のｙ座標より大きい場合は考えなくていいのか

俺ならとりあえず移動処理をブラックボックスにしてほっとく
あとからいくらでも高速化できる（かもしれない）からな。

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

>>511
このスレどうよ
http://game.2ch.net/test/read.cgi/gamedev/1024902432/l50

**511** · 02/07/24 13:22

レスありがとうございます。
＞ifの条件文が長い場合はあらかじめ比較するモノを変数に入れておくとか。
んと、とりあえずこんな感じにしてみたんです。
select case Npc.x(敵のｘ座標）
case is > Player.x(自分のｘ座標）
　　if Npc.Y < player.Y then
Npc.X = Npc.X - 32（32はひとますぶんです）
Npc.Y = Npc.Y + 32
endif
...こんなかんじで、敵のいる位置のパターンが8こ（斜め４個に上下左右）
もあるんで、どんどん入れ子じょうたいになってしまって。。。

＞移動する処理自体を1つの関数にしておいて後から高速化するのが望ましいかも。
ふむふむ。上記の移動の処理をMoveNpc というPublic Subにしているんですが、
そのなかに自作の関数をいれるということでしょうか？

＞敵のｘ座標が自分のｘ座標より小さい場合や
ｙ座標が自分のｙ座標より大きい場合は考えなくていいのか

そうなんです！パターンのぶんだけif －ｅｎｄｉｆ　文がふえてしまって
ながくなっちゃってるんですよね。これをもっとどうにかして
みじかくならないかなあと。。。

＞俺ならとりあえず移動処理をブラックボックスにしてほっとく
ふむふむ、さきにほかのところを完成させちゃえー、ということですね。
たしかに、、、ほかにも考えなきゃいけないとこがいっぱいあるんで
そっちもがんばりたいとおもいます。

**511** · 02/07/24 14:00

ここに書かせてもらってレスを拝見したおかげで、
ぱにくってた頭が少しすっきりしたみたいです。
移動処理のとこの致命的なミスを発見し、うまくなおせました！
（行の長さは相変わらずながくなっちゃいましたが）
今は敵が死んだときの処理をがんばってます。

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

>>516
> そうなんです！パターンのぶんだけif －ｅｎｄｉｆ　文がふえてしまって

if 敵のx座標 < 自分のx座標 then 敵のx座標を増やす
if 敵のx座標 > 自分のx座標 then 敵のx座標を減らす
if 敵のy座標 < 自分のy座標 then 敵のy座標を増やす
if 敵のy座標 > 自分のy座標 then 敵のy座標を減らす

コレだけで済むと思うんだが。

ちなみに、
> Npc.X = Npc.X - 32（32はひとますぶんです）
今の状態では右へ1キャラ分移動するのに32を加えていると思うけど、
これはそういう風にするんじゃなくて、将棋の「マス」みたいに管理すべき。
そしてグラフィックを表示するときにx座標とy座標を32倍すればいい。

**511** · 02/07/24 19:40

レスありがとうございます、書きこみ遅くなってすみません。
＞＞518
＞今の状態では右へ1キャラ分移動するのに32を加えていると思うけど、
＞これはそういう風にするんじゃなくて、将棋の「マス」みたいに管理すべき。
＞そしてグラフィックを表示するときにx座標とy座標を32倍すればいい。

おお！ということは、移動処理のほうでNpc.X = Npc.X+1にして、線画処理で
BitBlt FrmMain.PicMain.hDC, Npc.X　*　32, Npc.Y　*　32, 32, 32, FrmMain.PicChara.hDC, 0, 32, vbSrcPaint
てなかんじでいいのでしょうか？
この方がのちのち管理もしやすそうですね。

今までは１個１個のマス目の番号を割り出すときに
intBlockNo = (8 * (Chara.Y / 32)) + (Chara.X / 32)
ってやってたんですが、この方法ならいちいち32で割らずにすむので
かなりすっきりできますね！！！
これからさっそくかきなおします。

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

>>516
absとsgn関数をうまく使え

if abs(敵のx座標-自分のx座標) < 1 then 敵のx座標にsgn(敵のx座標-自分のx座標)を加える
Y座標についても同じ

**511** · 02/07/25 02:23

レスありがとうございます。
>>520
>absとsgn関数をうまく使え

今　abs関数とsgn 関数調べてきました！
絶対値、、、中学のときに習ったような、、自分の不勉強さに身がちぢこまります。
理解できてないままソースにコピペではあまりにも恥ずかしいので
いまから紙にかいて考えてみます。

あれれ？と思うようなとこはたくさん有りますが
ゲームのおおまかなソースが書きあがったので、
明日は他の部分ももっと効率的な書きかたができないか考えてみます。

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

>>521
お前は効率的な書き方をマスターしたいのかゲームを完成させたいのかどちらだ？と
小一時間（以下略

慣れないうちはきっちり動くものを作り上げてから速度＆効率のチューニングをやれYO!
とマジレスもしてみるテスト

**チューニングなんて後から** · 02/07/25 12:51

とりあえず作りかける
↓
ちょっと効率のいいアルゴリズム発見
↓
それにあわせて書き直す
↓
さらに効率のいいアルゴリズム発見
↓
それにあわせて書き直す
↓
さらに効率のいいアルゴリズム発見
↓
：
：

**511** · 02/07/25 21:22

レスありがとうございます。激しく反省中の511です。
>>522
>お前は効率的な書き方をマスターしたいのかゲームを完成させたいのかどちらだ？
ゲーム完成させたいです！

>慣れないうちはきっちり動くものを作り上げてから速度＆効率のチューニングをやれYO!
そうですね、まだ直さなきゃ行けないとこがいぱーいあるのに
綺麗なソースをかきたいなんて100年早かったです。。反省。。。

>>523
うう、完成しないままループしてしまいますね。。。。。
きっちりさいごまで仕上げることに専念します。

今日は移動用の選択カーソルの不具合をなおします。

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

>>524
報告ならここにしろ
■自主製作ゲーム：開発状況報告スレ■
http://game.2ch.net/test/read.cgi/gamedev/1005143186/l50

**西村トオル、ナイスですね～** · 02/07/26 20:35

今、DirectX8で3Dのゲーム作っています。
カメラアングルは、女優(対象)を後ろから捉えています。
そこで質問なんですが、
イベント中とかにゲームの動きを止めて
カメラだけを動かして女優(対象)を舐め回すように撮影したいんですが、
(取り合えず、女優を中心に球を想定して、常に女優の方を捉えつつ
その球面上をカメラが移動って方向で)
何か良いカメラの動きのアルゴリズムとか知りませんか？
やはり、監督自身(自分で)動く軌跡(座標)を切ってやらないといけませんかね？

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

>>526
ベジェ曲線みたいにすりゃいいんじゃない?

**名前は開発中のものです。** · 02/07/28 03:47

>>511氏
検証もせずに、他人のコード採用してたら、それこそあぼーんだよ。
解決案が必要なのに、エゴに凝り固まって、他人のソース見ることも出来ないのは、もっと重傷だけどね。
まあ、ゲームに関して言えば、コーディング技術云々より、ゲーム全体としてのデザインの方が重要だから、
そんな小さなことにこだわるな、というのが正解かもね。

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

>>528
んなこたーない

**名前は開発中のものです。** · 02/09/15 11:53

おまいらは、リソースの管理はどうしてますか？
基底クラスを書いて、音や絵やその他のデータなんかも
まとめて管理してるんでしょうか？

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

>>530
PCの話で良い?

データのI/Oはインタフェースに肉付けしてく形で作ってる。
具象クラス側で生ファイル、圧縮ファイル、ネットワーク、リソース、
各I/O方法にあわせる事が出来るし、プロトタイプ作ってる途中は
生ファイルI/Oだけあればよいし。

**530** · 02/09/17 02:30

>>531
私も同じようなもんですが、ネットワークは別にしてました。
参考になりました。

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

スプライトを管理するクラスが作れません。C++ です。

今は、各々のキャラクタのクラスがサーフェスやアニメーションの情報も持っていて、
なんとなく不細工な感じがするので、見た目の情報を切り分ける事にしたんですが、
それを一元管理するクラスの設計が出来ません。

今動いてる物をいじるんだから、それなりに便利にしようと思い、
確保したサーフェスやアニメーションの情報や、今表示中のスプライトの情報を、
管理クラスの寿命と共に廃棄できるようにしようとしたり、
サーフェスやアニメーションの情報を削除しても、それをまだ使用してるスプライトがあったら、
そのスプライトが削除される時までは、保持されるような物を作ろうとしました。

けれど、実装してもうまくいかないし、
整理しようと紙に書いていても、頭が混乱してきました。

みなさんは、こんな場合にはどう設計されていましたか？

**533** · 02/09/19 05:03

sage 忘れてました。
すみません。

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

普通にリファレンスカウンタ使う

**名前は開発中のものです。** · 02/09/19 05:14

俺の場合

◆オブジェクトクラス
スプライトへのポインタ（場合によってはテーブル）
各種パラメータ
＿＿＿＿＿＿＿

◆スプライトクラス
対象サーフェスへのポインタ
サーフェス上のRECT
現在位置
アニメーションありの場合RECTのテーブル
＿＿＿＿＿＿＿

◆サーフェースクラス
サーフェス実体
スプライトからの参照カウント

という風に階層分けをしてうまく作った。

**536** · 02/09/19 05:18

場合によっては、

スプライトクラスを

◆スプライトクラス
現在位置
スプライト定義クラスへのポインタ
表示しているRECTのindex

◆スプライト定義クラス
対象サーフェスへのポインタ
RECTのテーブル

と分ける。

**名前は開発中のものです。** · 02/09/19 05:18

キャラをオブジェクトと見立ててそれぞれで画像を管理するとめちゃくちゃにならない？
私がやったときは、各キャラのデータを保持するクラスを作って
それとは別に「キャラのデータを元に画面を組み立てる」関数を作った。

ハードコーディングでキャラの外見を決める場当たり的な方法だけど、
小規模なら混乱を最小限に防げてプラクティカルだよ。

**名前は開発中のものです。** · 02/09/19 05:35

スプライトをリファレンスカウンタで管理するってどうよ。
シーン構築時に必要な物をすべて読み込んで、
終了時にまとめて削除する方が速いしスマートじゃね？

**533** · 02/09/19 05:42

>>535-536
早朝からありがとうございます。

リファレンスカウンタは、調べていてる時に見つけて
>>536 さんのような感じにしていたんですが、
管理するクラスと、それに管理されるクラスとの関係を
上手くまとめられませんでした。

ゲーム開始前の時点で、管理クラスにサーフェスやアニメーションなんかの
描画に関係する物を登録して、終わった時には、使っていたほうは意識せずに、
管理クラスが、自動的に廃棄してくれるようにしようとしたんですが、
>>533 で書いたように、混乱して終わりました。

ここらへんの管理クラス回りの設計を質問したかったんですが、
文章が長い上に要点がボケてました。すみません。

**533** · 02/09/19 06:08

>>540 を書き込む前に、その間の書き込みを確認してませんでした。

>>537
そうやって定義を分けておくと、同じ種類のキャラクタのスプライトで使いまわせますね。
参考になりました。

>>538
>「キャラのデータを元に画面を組み立てる」関数
が私が最初にとっていた方法だと思います。
その場合のキャラのデータとは、見た目やゲーム内での状態を一つにまとめて
表してる物の事ですよね？
違ってたら、すみません。

>>539
> シーン構築時に必要な物をすべて読み込んで、
> 終了時にまとめて削除する方が速いしスマートじゃね？
そうしたかったんですが、このへんが、よくわからなかったところなんです。
必要な物を管理するクラスの設計を、触りだけでも解説していただけませんか？

**名前は開発中のものです。** · 02/09/19 12:33

>>539
読み込み失敗時のエラー処理が繁雑になるから、ゲーム開始時点で
まとめて読んでしまった方が良いかも。データ量にも依るけど。

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

vertex-shaderってなんですか？

**名前は開発中のものです。** · 02/09/19 15:57

vertex-shader（頂点シェーダ）ってのは、
トランスフォームやライティングやテクスチャやブレンディングなどの頂点処理機能のこと。

プログラマブル頂点シェーダは、いままで処理系（Direct3Dなど）の
固定機能のみであったのに対して、これらの機能をプログラムできるってやつ。

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

http://muvc.net/jsweb/happy_solution.html

**543** · 02/09/19 16:38

>>544
サンクス。
禿しくわかりました。
ｵﾚｲﾃﾞｽ(・∀・)つ旦~

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

>>545
ｲｲ!

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

ここはひどいインターネットでしたね

**名前は開発中のものです。** · 02/09/22 18:44

画角を、視点からの距離に応じて自然に変化させる事はできますか？
普通の人間に近い画角を設定すると、至近距離での物の見え方が
おかしいように感じます。

**名前は開発中のものです。** · 02/09/22 19:54

その問題は随分昔から色々言われてきて、
今のところ現実的な解決方法が見つかってないと思う。
至近距離のものは、目には歪んで見えているのに真っ直ぐのものを
真っ直ぐと認識できる。これは脳みそが補正しているからです。

至近のものをなんとかして正しくゆがめて表示すると、
それはそれで不自然に感じるはず。
なぜなら、脳が補正しないから。

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

もー少し書くと、
最大の問題は、目からディスプレイまでの距離が離れているから、
自然な映像は目からディスプレイよりも近い映像を表示し得ない
のです。

ヘッドマウント式のディスプレイであれば、
正しくゆがめるとちゃんと認識できると思う。

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

>>551
HMDは焦点距離を1mくらいに設定してるので、
結局うまく認識できないと思う。

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

それは１６Ｂｉｔでの単色のグラデーションが汚いことより重大な問題なのか？

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

Virtual Realityとしては結構な問題。
グラデーションはbit数を上げれば解決するけど。

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

dxfフォーマットの詳しい解説ページ教えて下さい
本は絶版みたいだし、お願いします

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

>>555
やめとけ。検索すればすぐでると思うが、情報がいい加減でひどい
フォーマットってうわさだ。何に使うん？

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

ちょっと調べたが酷いもんだったなあ
３Ｄ拡張もあるらしいが

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

http://homepage1.nifty.com/atmori/cg/shade/dxf/dxf.htm

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

>>556 >>557 >>558
ありがとうございます。
3Dを扱う一般的なフォーマットは知っておかんといかんかな、と思いまして

**549** · 02/09/23 03:58

>>550-554
単純な問題じゃないと言うわけですね。
自分の知識でまだまだ足りない部分があった事がわかりました。
ありがとうございました。

**名前は開発中のものです。** · 02/09/23 06:14

ゲーム作成用のC++クラスフレームワークいいのありませんか？
DirectX8はWizardもついてだいぶよくなったみたいだけど
構造体がいっぱい残ってるのがうっとしいです。
やれることが限定されても、そのへんクラスで結構隠してくれてるのが
あればいいんですが。

**名前は開発中のものです。** · 02/09/23 07:28

Wizardで作られたものを整理して、テンプレートとしてとって置く

**名前は開発中のものです。** · 02/09/23 07:39

>>561
http://www3.justnet.ne.jp/~botchy/el.htm

**名前は開発中のものです。** · 02/09/23 07:57

>>536
ｵｲｵｲ
> いいの
ﾀﾞﾖ

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

elはごった煮だけど良い物だよ。
洗練されているという良い物ではないけど。

**名前は開発中のものです。** · 02/09/23 08:14

>>562-563

ありがとうございます。
ELLibちょっとヘッダ眺めてみました(眺めただけ)。
ほかにもあれば、情報収集しときたいのでお願いします。

**名前は開発中のものです。** · 02/09/23 08:34

>>566
やねうらおの奴使っておけ。
まー、完璧ではないかも知れないが普通に使う分には問題ない。
NxDrawが生きてたらそれが良いと思うんだけどね。
あとはゆきいるかの所かなぁ

リンクは面倒なのでぐぐってくれ。

ゲーム用のフレームワークが本格的なゲームエンジンを指す場合、
高い金払ってUTのエンジン使えるように契約したりしてくれ。

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

>>567
ふんふん、なかなか本格的ですね。
これはどうもありがとうございます。YTLには笑った。

趣味で使うつもりなので。
UTって何でしょう。

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

たぶんUnreal Tournamentのことだろう。
この辺を嫁ばいい。
http://udn.epicgames.com/

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

>>569

ありがとうございます。
ちょっと見ただけでは良く分かりませんでしたが
今度暇なときに見てみます。

**名前は開発中のものです。** · 02/09/23 14:39

>>567
あれじゃあ、片手落ちじゃない？

**名前は開発中のものです。** · 02/09/23 15:12

>>571
その前に君は日本語を使いなさい。
「あれ」は何の指示代名詞なんだい。

**571** · 02/09/23 15:22

>>572
ﾎﾟﾘﾎﾟﾘ

**名前は開発中のものです。** · 02/09/23 15:29

>>572

　 571
<#｀Д´>ﾊﾟ､ﾊﾟｶﾆｽﾙﾅ

**名前は開発中のものです。** · 02/09/23 16:30

「片手落ち」ってのは使わないほうがいいよ
厨に変なツッコミいれられるから

**名前は開発中のものです。** · 02/09/23 16:52

>厨に変なツッコミいれられるから
575=厨

**名前は開発中のものです。** · 02/09/23 16:58

なんかよく分からんのだが
とりあえず誰か>>571の解説を頼む。
　
正直、俺には読解不能。

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

>>577
やねうライブラリでは、2D しか対応してないって事では？

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

3Dやりたいなんて書いてないじゃん

**578** · 02/09/25 02:18

>>579
今時の PC でゲーム作るって言ったら、
3D に対応してるライブラリのほうが、作るのが簡単で良いんじゃない？
無理に 2D に落として仕様を考えるよりも、素直にアイデアを出せるし、
三世代くらい前のカードでも、充分速かったと思うよ。

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

>>580
ん？
3Dの世界を構築するエンジンじゃなくて、
3Dハードを使うって事か？

**名前は開発中のものです。** · 02/09/25 08:22

3Dだと初心者で権威を失うから駄目なんだよ。

**名前は開発中のものです。** · 02/09/25 08:52

意味がわからない

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

3Dだと初心者で←教える人は2Dは得意だけど3Dは苦手
権威を失うから駄目なんだよ。←2Dなら深い質問も大丈夫です、かかってきなさい

という意味と思われ

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

一つのファイルにバイナリとテキストを混在させるのは可能でしょうか？
また可能ならどういった方法がありますか？
テキストとバイナリを交互に書き込んでみたのですがテキストが化けました
Delphi、Windowsです

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

>>585
テキストをバイナリとして扱えばいいんでねーの？

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

>>586
なるほど、その手がありましたか！！
ありがとうございました

**名前は開発中のものです。** · 02/09/25 21:07

ｱﾌｫが増えたな・・・

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

やっぱりファイルヘッダはテキストのほうがかっこいいので
>>585を再度質問させていただきます
よろしこ

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

>>584
漢文を訳すより難解なり

**名前は開発中のものです。** · 02/09/25 21:40

>>589
ヘッダだけテキストにしてそれ以降をバイナリ
もしくは全部テキストにしたければバイナリをbase64にでも変換すれば？

**名前は開発中のものです。** · 02/09/25 21:54

>>591
＞ヘッダだけテキストにしてそれ以降をバイナリ
Delphiでどうすればできるのか教えて欲しいです
Cではできますた

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

>>592
同じようにしる！！

その手の作業に関しては、
DelphiでできてCでできないのはわかる(VCL使っているとか)が、
CでできてDelphiでできないというのはよくわからない。

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

とりあえず、Cではどういやってたか言ってくれれば、
こたえられるかもしれんよ。

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

そういえば漏れはDelphiでパケット越しに
テキストバイナリ混成データ送ろうとして
四苦八苦した思い出があるなぁ

けど、もうどうやったのか忘れた（藁

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

Delphiを捨てればいいと思うんだけど、、、ダメ？

**名前は開発中のものです。** · 02/09/25 23:41

Delphiﾊﾟｶﾆｽﾙﾅ!!
Personalでやったから苦労したんだよ！

ちなみにパケット越しじゃなくて
パケットに詰めて、だな