DXライブラリ総合スレッドその16

**名前は開発中のものです。** · 2013/06/30(日) 23:57:05.06

Cを習得した程度のスキルでも、ゲームのグラフィックを比較的容易に描画する事のできる、
「DXライブラリ」に関するスレッドです。
DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。

【公式】
http://homepage2.nifty.com/natupaji/DxLib/

【関連スレ】
C/C++ゲーム製作総合スレッド Part1
http://toro.2ch.net/test/read.cgi/gamedev/1337516528/
ゲームプログラムなら俺に聞け(プログラム技術板)
http://toro.2ch.net/test/read.cgi/tech/1366526476/

●DXライブラリではなくDirectXの質問ならこっちへ
【C++】DirectX初心者質問スレ【C】(プログラム技術板)
http://toro.2ch.net/test/read.cgi/tech/1370015791/

**名前は開発中のものです。** · 2013/08/17(土) NY:AN:NY.AN

アサシンクリードやGTAみたいなのが気になる

あとエースコンバットの地平線とかどうやって表現してんだ？
高度あげると地形マップが四角なってるのが見えちゃう
かといってこれ以上Zバファの探索距離を伸ばすと処理能力がきついからマップ広げられないし、
遠くなるだけで四角く見えなくなるわけでは無いだろうし

**名前は開発中のものです。** · 2013/08/17(土) NY:AN:NY.AN

>>235
Level of Detailでググれ

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

>>237
LODってカメラとオブジェクトの距離を一個一個測って描画するモデルを決めるの？

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

>>238
最低限がそうだよ。俺は区画の論理マップ用意しておいてそれに対して計算するけど、
相手が物理座標じゃないだけでやってる事はそう。

で、本当のLOD処理になるとそれプラス、距離に応じて頂点数異なるメッシュに切り替えたりもする。
何故ならアップで見えて欲しいディテールと遠景で最低限必要なディテールは異なるから

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

簡単に言うと、カメラの死角にあるものは描画しないし、近くにある木は枝の枝まで見えて欲しいが、
遥か遠景の木にそこまでのディテールは必要ないので簡素なモデルに切り替える。
テクスチャについても同じ理屈

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

なるほど、あとひとつ
カメラの向いてる方向から、オブジェクトの座標をみて、そもそものZバッファ登録を間引いたりする？
間引くとしたら、巨大なオブジェクト、例えば重心がカメラの後ろにあるのに描画範囲内に頂点があるようなオブジェクト
とかってどうすればいい？

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

自分>>222だが>>224のアドバイスを参考にしてサンプルをつくってみた

http://www1.axfc.net/uploader/so/3000313
pass:jump

重力計算のほうは、とりあえず最大値でジャンプしはじめてボタンが離された瞬間に
最小値に切り替えるようにしたらそれっぽくなった

問題はテーブルのほうなんだが、いろいろいじってみたけどやっぱりわからない
とくにブロックとの当たり判定とか自由落下が加わるとややこしくなってさっぱり
根本的につくり方が違ってるんだろか・・・

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

マリオのジャンプテーブルは、色々と調整してみた結果、
（ファミコンで可能な範囲で）計算するより、手作業で数値を突っ込むのが一番心地いいジャンプになった、ってだけの話？

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

8bitのCPUが貧弱だからだよ

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

>>242-243
正解？を言うと
テーブルを作る手間は非常に面倒臭いのでファミコン時代ならともかく今のPCゲームじゃ普通に計算するのが当たり前
sincosとかは今でも遅いからsin0°,sin1°…といった値をテーブル化して計算の途中で参照する手法はある

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

重力計算でできたんならその計算結果をテーブルに入れて、
計算結果を参照する代わりにそのテーブルを参照すればいいだけじゃないの

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

少数の計算が遅いからそれを避けるためにテーブルにしたってだけよ

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

てか少数演算自体がファミコンじゃできないのかな

**名前は開発中のものです。** · 2013/08/18(日) NY:AN:NY.AN

>>241
俺のやってる方法は別に完全無欠な訳じゃないからアレだけど、
とりあえずZバッファの部分的なクリアやdiscardみたいな事はしてなくて、そもそも対象外のオブジェクトをドローさせないようにしてる。

で、それとも繋がるけど、重心がカメラの後ろにあるがカメラの前に部分的に見えるほど巨大な物に関しては、
なるだけそう巨大にならないよう分割管理してる。

勿論それでも程度問題で重心とオブジェ
クト半径の間にカメラが来る事は普通にあるんだが、その場合は基本的に描画する。
で、その1描画に対してどれだけの頂点量なりが必要なのか、って話で、それを減らすためにバランスみて分割し、
巨大にならないようにするって感じ。それだけ

**名前は開発中のものです。** · 2013/08/19(月) NY:AN:NY.AN

constexprを使おう！

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

>>242
すまん、VSでいじって研究したいから
ついでにMap、Graphic、Commonらのソースもつけてくれん？

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

>>251
いらないだろ。研究したいとか嘘つけ

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

嘘じゃ無いよ
なんで嘘呼ばわりされるのか

確かにジャンプそのものの構造は入ってるソースでわかるし
includeで必要な外回りも自分で作って補えば済むが
全部渡してもらった方が、その場で色々触れるんだから
話が早いじゃないか。

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

秘伝のソースなんだから見知らぬ人にあげられるわけないだろ

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

なら聞いてみようよ

>>242
秘伝なのかい？

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

>>253
要点は書いて頂いたんだからそれ以上いらないだろっての
秘伝とかどうでもいいよ

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

桃伝のソースがもらえると聞いて

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

まあコピペしてゲーム作りたいんだろ

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

自分で作れるなら作ればいいだけ。
他人に何かさせて「その方が早い」とか言うのは失礼極まりない。

新入社員が「自分がやるより先輩がやるほうが早いし効率いいじゃないですか」と
先輩に全部仕事丸投げして自分は何もせずいたらどう思うよ。

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

コピペしただけでゲームが出切るわけないだろうに。
別にマップ製作のソースに興味無いよ。

そんなこと疑うんなら、他の誰でもいいから
include消してVSでただのジャンプソースをビルド出来るようにしたのを
うPし直してくれ。
別にこっちはそれで結構だから。

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

なんで偉そうな態度の乞食に赤の他人がそこまでしてやらにゃいかんの？ｗ

お前みたいにウザい奴は罵倒して放置でおしまいだって

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

とりあえずみなさん落ち着いてください。

信じるか否かは本人の判断を見て待つということでいいじゃないですか。
無駄に争うのはやめましょうよ。

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

うざい奴はうざいと言われるのが2chなんでしゃーない

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

>>261
お前が疑うからだろ、バカが。
行動出来ないなら口出すな、ハゲ

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

いや、行動できてないのはお前さんなんだが。

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

ま、叩かれた乞食が発狂するお決まりの展開だよねｗ

**名前は開発中のものです。** · 2013/08/20(火) NY:AN:NY.AN

お決まりというか、同一人物だよね？

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

DXライブラリ使った事無いんだが、一回くらい使ってどこまで省力出来るか実験してみようかな…

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

ウィンドウ作るところからやるなら労力は激減すると思う。
既存のゲーム用ツールやエンジンからの比較だと増えると思う。

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

ライブラリ乗り換えの場合でも単にリファレンス読む手間が増えるだけだよなｗ
他のDirectXライブラリを使えてるなら乗り換えでの大きな省力メリットは特にない

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

就活用の作品でDXライブラリ使っても良い？
それともゲームとしてのインパクト薄くなるけど直にダイレクトえっクス叩いたほうがいい？

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

技術力を訴えたいかアイディアを訴えたいかによるだろうなぁ。
斬新なゲームならライブラリ使っても良いんだろうけど、
3Dプログラミング出来ますって言って
DXライブラリ使われるとどうだろうね。
unityだとまた話違うだろうけど。

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

DXライブラリ使うならアイデア路線ってことは、就活に使うなら別途企画書とか必要な訳・・・

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

太鼓の達人的な叩き方のゲーム作りたいんだけど、参考になりそうなサンプルない？
太鼓の鉄人をみてループで行うべき機能は大体わかったけど書き方が分からない

効果音フラグを初期化
入力に対する計算
弾の計算メイン
弾ヒット結果表示メイン
描画メイン
FPS表示
効果音
fps制御

ちなみにそのゲームではこういう感じで回してた

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

>>269 >>270
thx。どう言う場合に適用するか、って意味の評価をしたいだけなのだ。
既存って意味だと、基本的にwin32に関わる部分はずいぶん前に作ってちまちま改良した自前のライブラリがある。
その他既成の物だと、OGRE3Dやbulletは慣れてる。C#の場合はUnityも。

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

それだけできるならリファレンス流し読みで自分にとっての省力化になるかわかりそうなもんだけどね
そういや本家の掲示板にエラーわかる！C結構できる！でもpathの通し方わかんない！ってコがいたなあ

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

今晩帰ったらリファレンス見てみるぜ

**名前は開発中のものです。** · 2013/08/22(木) NY:AN:NY.AN

と思ったが今晩無理なので今週末土日のどっちか休めた日に。
障害対応まだ終わんね

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

なあ今まで長いことアクションのゲーム部分ばっか実装してて、
勝手に例にして悪いけどmain関数が>>274みたいになってるんだけど
メニュー画面とか実装していくなら>>274のようなゲーム部分(初期化、ループ処理、終了処理)はひとまとめにして
メインメニューのコンテンツがmainに並んで選べるようにする感じ(ゲーム処理関数、コンフィグ変更処理関数、など)しか思いつかないんだけど
これってどうなのかな
みんなmainになに置いてる？

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

main (){
auto Game =new TitleMenu();
while(???){
Game->Update();
}
delete Game;
}

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

十中八九>>280みたいな感じだよね
mainなんて現在のシーンの更新をループ回すだけ

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

俺はオブジェクト指向わからんけど、結局280みたいなのに落ち着いたな。もちろんオブジェクト指向関係なく。

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

うーん説明悪かったか俺がアホなだけなのか

今のところアクションゲームのゲーム部分だけしか作ってないから>>280みたいに
初期化→更新(ループ)→終了ってだけで済んでるけど、
例えば自機の装備変えるとか、ステージ選択とか実装するとすると
ゲーム部分以外の処理の初期化→更新(ループ)→終了があるわけじゃん

だから>>280みたいなのをゲーム、ガレージ、コンフィグ、とかっていくつか作って、
選んだ処理の初期化→更新(ループ)→終了を行うっていう風にしようとしてる俺は間違ってる？

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

>>283
最終的にはゲームが完成するのが「正解」ではあるのだろうけど、
あまり見ない作り方だと思う

各「画面」の下にループがぶら下がってるんじゃなくて、
ループの下に、各画面の処理を入れる。

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

初期化が関わる部分は専用フラグ作って
フラグごとに分岐するように組めばいいと思うの

自分はゲーム作る時にモードフラグの分岐で
タイトル含めて各種画面処理にいけるよう分けてる

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

ゲームに限らずユーティリティ作るときもそうだけど、大抵は処理のレイヤ毎に整理するかな。
で、メインループとかはそれで言うと最下層。
各処理レイヤの分離量や度合いは概要(基本)設計から下ろしながら決めてく感じ

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

マルチスレッドで当たり判定とかする場合
結局キャラクタが当たり判定の結果を処理するまで次の判定できないわけじゃん
これってただしいの？

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

おもにマルチスレッド化できそうなのは当たるか当たらないかだけのリストを作成するところ
当たった後の処理はゲームによっては不可能なのでそのあとにやる

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

RPG等で使えるmap管理作ってみたんだけどこんなものでいいのかな・・？
http://www1.axfc.net/uploader/so/3006859

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

>>287
そういう「ゲームロジック側の一部分を切り取ったものだけをマルチスレッド化」ってよっぽど事情が無いとやらないが、
やるとしたら >>288 みたいに候補のリストアップの荒い振り分けとか、あるいはフラグ列挙くらいかな。

大抵は音楽再生や描画や入力処理側と、ゲームロジックって切り口でスレッド分けるはするが

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

というか、逐次処理で問題がない部分を
わざわざ他スレッド処理にすると、無意味に新しい問題が発生するケースの方が多いからね

**282** · 2013/08/25(日) NY:AN:NY.AN

>>283

俺も最初はそうやってたけど、ループ一本にすると管理や変更が凄く簡単になった。

**283** · 2013/08/25(日) NY:AN:NY.AN

>>284 >>285
やっぱそうするほうがいいのかな
どうせ完全に独立してる処理だし>>283みたいにしたほうが
読みやすくて管理しやすいかと思ってたがそうでもないのか
よしじゃあこの方向性で作ってくことにするよ
>>292も経験談ありがとう

**名前は開発中のものです。** · 2013/08/25(日) NY:AN:NY.AN

DestinationDirectionという目的地の方向を向いてるベクトルがあるのですが、
これがなぜか真逆を向いてるので、0から引いてみたのですが同じ方向をさしてしまいます。
どうしたらいいですか？

DrawLine3D(Position,VScale(VAdd(Position,DestinationDirection),500),321321);

DestinationDirection = VSub(VGet(0,0,0), DestinationDirection);

DrawLine3D(Position,VScale(VAdd(Position,DestinationDirection),500),121121);

**名前は開発中のものです。** · 2013/08/26(月) NY:AN:NY.AN

>>294
自分の経験だと、「なぜか真逆を向いている」という状況を見直さないと、今仮に直ったとしても、どこかでしわ寄せがくるよ

２行目が実行された後、DestinationDirectionはちゃんと更新されてる？
VECTORにoperator=が実装されていれば問題ないと思うけど

**282** · 2013/08/26(月) NY:AN:NY.AN

>今仮に直ったとしても、どこかでしわ寄せがくるよ

あるあるｗ

なんかおかしいな、っていうのは絶対どこかにバグがあるって事だからな。

**名前は開発中のものです。** · 2013/08/26(月) NY:AN:NY.AN

DestinationDirectionの作り方として、多分間違いではないと思うのですが・・・

今ブレークポイントで値を確認してみたところ、実行前と実行後でしっかり符号が反転してます。

//目的地へのベクトル
VECTOR DestinationDirection = VSub(目的地 , 現在地);

//座標系を自分視点に回転させる行列
MATRIX Rot= MGetAxis2(キャラクターのx軸,キャラクターのy軸,キャラクターのz軸,キャラクターの座標);

//回転適用後正規化
DestinationDirection = VNorm(VTransform(DestinationDirection,Rot));

**名前は開発中のものです。** · 2013/08/26(月) NY:AN:NY.AN

>>297

>>294でのDrawLine3Dに１行目と３行目で渡している引数は異なるけど、結果は同じ値だってこと？
あと、何でもかんでもDestinationDirectionにしちゃうと、どういう状態の値かわからなくなっちゃうよ
変数の使い回しは最小限にすべき(速度に致命的な問題がなければ)

**名前は開発中のものです。** · 2013/08/26(月) NY:AN:NY.AN

そうです、結果が変わらないんです。

目的地の座標を、オブジェクトの周りにグルグル動くように設置してみたのですが
DrawLine3Dがまったく動きません。。同じ方向を向いたまま・・
画面に目的地の座標と、オブジェクトの座標を描画させましたが両方共正常に動いてましたでした。

ということは
MGetAxis2の使い方が間違ってるんですか？

**名前は開発中のものです。** · 2013/08/26(月) NY:AN:NY.AN

間違ってるかもしれないけど

もしかしてワールド座標の原点からキャラクターの座標離れてないか?
>>297だと「(ワールド座標原点から)目的地へのベクトル」を、
キャラクターのローカル座標に変換(ここで目的地～現在地のベクトルが、キャラ～原点の長さより微小だと、
いくら目的地～現在地のベクトルを回しても「キャラから原点」のベクトルとほぼ等しいから動いてるように見えない)
さらに正規化してるのでベクトルが短くなって変化がわかりにくくなる

って処理になってる気がする
キャラクターの座標動かしてもベクトルが回らないなら俺が間違ってるけど

俺の言ってる通りなら
//目的地へのベクトル
VECTOR DestinationDirection = VSub(目的地 , 現在地);
を
= VGet(目的地)でいいと思うんだけど

**名前は開発中のものです。** · 2013/08/26(月) NY:AN:NY.AN

訂正、
>>300の3行目
「(ワールド座標原点から)現在地～目的地"方向"へのベクトル」

分かりにくい文章でスマン
●騒動で規制解除されてるとは思わんかった

**名前は開発中のものです。** · 2013/08/28(水) NY:AN:NY.AN

>失敗したコードは
>VECTOR VAtoB = VSub(ObjectB.Pos, ObjectA.Pos);
>MATRIX MAngle = MGetAxis2(ObjectA.AxisX, ObjectA.AxisY, ObjectA.AxisZ, ObjectA.Pos);
>VECTOR VRDir = VNorm(VTransform(VAtoB, MAngle));

騙されたと思っていっぺん
VECTOR VRDir = VNorm(VTransform(VAdd(ObjectA.Pos,VAtoB), MAngle));
こう書き換えてみて

**名前は開発中のものです。** · 2013/08/28(水) NY:AN:NY.AN

てす

**名前は開発中のものです。** · 2013/08/29(木) NY:AN:NY.AN

>>242
このサンプルって、
テーブルジャンプに切り替えるボタンある？
画像には専用キャラが用意されてるみたいだけど。
それとも出来なかった、というオチなのかな

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

　　　　 ∧＿∧
ｶﾞﾗｶﾞﾗ(　　＾＾　）＜これからも僕を応援して下さいね（＾＾
　　＝〔~∪￣￣〕
　　＝ □――◇ 　　　　　　　　　　　　　　　　　　　　　　Kazuki

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

http://userdisk.webry.biglobe.ne.jp/004/941/50/1/0802-01.gif
数値にこのような光彩は使えますか？

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

数値だけなら0-9の画像用意したほうが楽

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

ASCIIの文字くらいは用意しておくと、色々と便利だよね

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

ゲームごとに違う自作フォント（というほど大げさなものではないが）用意するのは面倒臭いけどな……

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

フォトショ使えよ
一発だぞ

**306** · 2013/08/30(金) NY:AN:NY.AN

なるほどありがとうございます

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

>>310

なにが一発なの？

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

ソフトイメージを使って起動時にロード中と称して装飾数字画像作るのもありかな

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

実際に画像として出力する前の、テンプレート的なものをあらかじめ作っておけば、
確かにPhotoshop一発でいろんなパターンを作れそうだ

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

前に使う文字を加工して一枚画像に並べて吐き出すコード前に書いたな俺

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

フィールドが球面のRPGって過去に存在するんですか？

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

ドラクエだって見た目だけメルカトル化されてるだけで球面なんじゃないかな（震え声）

**名前は開発中のものです。** · 2013/08/30(金) NY:AN:NY.AN

未だにオープンワールド系のゲームをdxlibで作るとなると
どうやって実装すればいいか思いつかない俺がいる
指定座標周辺のモデルだけを読み込み・描画する方法とかあったっけ
まあ作る予定は無いからわりとどうでもいいけど

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

>>318
あったっけって、俺はそうやってるけど。

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

いや、dxlibの関数をどう使って実現するかってこと
指定メッシュのみ描画とかあったっけ？
それともシェーダで切り捨てでもしてるの？

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

いや考え方は2Dと一緒で、地形パーツ並べてドローするだけだけど
見かけ上一続きに見える地形だからって描画物のデータまで一つにはしないでしょ
カメラに見える範囲の論理座標上にあるパーツだけを描画するだけ
シェーダで切り捨てって何かエラく曖昧で遠回りな発想だと思う

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

>>312
一度、文字列レイヤーで等幅フォントをASCIIコード順に文字を並べておく
それのフォント指定を変えたりレイヤースタイルをいじったりすることでいろんなフォント画像をサクっと作れる

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

でもその方法じゃ8*8ドットとかのいわゆるナムコフォントみたいなのは無理でしょう。

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

何勝手に新たな縛り追加してんの

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

こついらの出番だな
http://www.forest.impress.co.jp/docs/review/20130829_613180.html
http://www.forest.impress.co.jp/docs/review/20120229_515208.html
http://www.forest.impress.co.jp/docs/review/20120315_518253.html

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

こついらってなんだよ・・・orz

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

こんなのあるんか
便利そう

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

IPAフォントは使いづらかろうに・・・

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

>>321
遠い地形の部分ってどうするの？
フォグでかき消すの？

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

ちょっと遠くを描画しようと思うとZバッファ描画が荒くなるんだけど
巨大なメッシュを遠くに描画すると、描画距離ギリギリのところでギザギザになる

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

>>323
アンチエイリアスあり・なしが設定出来るから、その形状のフォントを使えば出来る
レゲー再現フォントをゲームで使用する上での著作権の問題はしらん

あと>>325みたいなビットマップフォントを使えばレトロっぽい表現も不可能ではない

**名前は開発中のものです。** · 2013/08/31(土) NY:AN:NY.AN

>>321
そうか箱庭型ばっかり作ってたせいで確かになんか凝り固まってたわ
でも木とか建物はその通りで出来るけど地形なんかは難しくないか？
地形も単位塊に分解しておいて描画するの？

>>330
最近Zバッファのビット深度変更する関数追加されて
24(32)bit管理出来るようになったけどそれでもダメなの？

**名前は開発中のものです。** · 2013/09/01(日) 10:41:51.34

>>332
今まで8ビットだったの？

**名前は開発中のものです。** · 2013/09/01(日) 10:43:46.93

アルファテストとかミップマップとかそういうのではないの？

**名前は開発中のものです。** · 2013/09/01(日) 18:19:53.79

>>333
今までは16bit
16,24,32bitに変更できるようになった
管理人さん曰く32bitはほとんどのグラボでまだ対応してないと思われる、らしい

>Ｚバッファのビット深度を設定するための関数を追加しましたので、よろしければお試しください

>// 画面用のＺバッファのビット深度を設定する( 16 or 24 or 32 )
>int SetZBufferBitDepth( int BitDepth ) ;

>ただ、現状 32bit深度のZバッファは無さそうです( GeForce GTX 660 Ti でも 32bit は非対応でした )
>なので 32bit を指定した場合は恐らく 24bit になります

DXライブラリ 総合スレッド その16

DXライブラリ総合スレッドその16