親父PGがゲームを作り始めるスレッド
■ このスレッドは過去ログ倉庫に格納されています
C++やC、アセンブラは昔こなしたし、プログラムの事なら自信はあるけど ゲームは作った事が無い方。現場からも引退したし(w。 ここは一つ趣味でDirectXでも勉強して、ゲームでも作ってみようかなぁと思った、 オジサンPGのスレッドです。 一緒にマターリライブラリから作りませんか? とりあえずC++だけでいいなら19800円(ゲーム作るだけなら他はいらない) Visual C++ .NET Standard 2003 通常パッケージ 19,800円 アカデミック パッケージ 7,800円 最初の半年の目標 SDKをざっと読む 開発環境を整える デモをコンパイラする スケルトンの作成 ここからは目的に応じて多少変化すると思いますが.... タイマー、スケジュール、ポーリング部分をどのように設計するか検討する 上を設計した上で、最小単位のオブジェクトクラス(最初のメンバはLife)を設計 オブジェクトの番号を管理するクラス設計 グラフィック関連 文字関連 テクスチャ関連 マウス・キーボード関連 ビューポート関連 メッシュ関連 ライト関連 STL(動的配列関連)※クラス設計に大きく関係する DirectXとは直接関係ないけどね。 とりあえずこの辺までは共通事項かなぁ。追加があればご指摘ください ゲームを作るのか、ライブラリを作るだけなのか。 C++とかでブイブイやってたんなら、オープンソースのDirectXライブラリ持ってきて まず何かゲームを作りつつライブラリを解析したほうが良いと思う。 パソコンを勉強するおじ様方に多いけど、本だけ読んでもあんまり身につかないからねぇ。 実際に動かして、動きを見ながらソースをトレースして理解したほうが本読むより早い。 ていうかC++なら0円でIDEも揃うけど。DEV-C++とかEclipseとか。 VC系が必要になるのはポトペタでデザイン作るときだしね。 >>5 早速レスありがとう >パソコンを勉強するおじ様方に多いけど、本だけ読んでもあんまり身につかないからねぇ。 既にそのレベルは超えてもらわないと話が進まない^^; スケルトンぐらい(質問はしてもいいけど)自作作成できないとおそらく オープンソースライブラリなんて使いこなすのは無理でしょう。 >オープンソースのDirectXライブラリ持ってきて >まず何かゲームを作りつつライブラリを解析したほうが良いと思う。 これは一旦自分で(調べて作って)解析した後でないと、かえって理解が遅くなると思います。 まぁあくまで持論ではあるのですけどね。 DirectXの動きを理解してからライブラリからコツコツと、それも楽しみの一つですから... [最低でも問題のSDKのHELPは調べる] 親父PGに限った事ではないと思いますが^^; ヘタレだけど面白そうだから参加していいかな。 大分前、SDKのみの自前描画で簡単な3Dモデルを表示してみた。 ちょい前、DirectXを覚えようと、とりあえず突貫工事で Xファイルを表示してキーボードで移動させてみた。 いろんな所からサンプル拾ってほとんどコピペしただけ。 次はスキンメッシュのサンプルをどっかからパクって組み込もうと考えたが わけ分かんなくて挫折。 最近、TCPとWinsockでS/C型の簡単な一対一チャットを作ったが、 一対多のやり方がワカンネェので挫折。 先週、暇だったからテトリス作ってみた。初めてのゲーム。 ライブラリ?クラス?なにそれ。 分割コンパイルすらままならない、道しるべが欲しいそんなダメオジサン。 それより親父さんよ この板にはたくさんの厨がいる そいつらは開発ってのを分かっていない ここは一つ、お前さんが連中を管理してゲームを完成させるスレとかにしてみたらどう? >>7 歓迎いたしますよ! 何か出来たことを報告してくれると、盛り上がって良いと思います >>8 >この板にはたくさんの厨がいる そいつらは開発ってのを分かっていない 私の個人的な意見を言わせていただければ、もしPGの事が解って無くても また、開発の事がわかってなくても、なんというか、「組立てるセンス」あれば ある程度の事はできると思う。それは他の事でも物事を組み立てて考える力さえあれば、PG習得もその応用にすぎないからなのです。 PGには3つの壁があり、 プログラム理論ロジック習得の壁 if for 言語そのものに対する知識の壁 C++ int 環境に関する知識の壁 Windows DirectX があると私は思っています。これらを分けてひとつひとつ知識のリンクを、つないで行けば自ずと光が見えてきます。 >ここは一つ、お前さんが連中を管理して... そんな大それた事はできませぬ^^ 参加したいのであれば年齢は問いませんが、姿勢は問いますよ。 >>9 >みんなリストラされたのか? あはは、冗談きついなぁ。 取り合えずSDKのサンプル「三角形を回す奴」をコンパイルして実行する事 これが出来ないと先へ進めません。 回る三角形ができたら、これを四角形にする(頂点数の変更) FVFフォーマットを変えて実験してみる。 テクスチャを張り込むにしても4画ポリゴンは基本となるので、 まずはここまでを目標にしましょう!! >プログラム理論ロジック習得の壁 if for >言語そのものに対する知識の壁 C++ int >環境に関する知識の壁 Windows DirectX 計算機の動作原理の理解に対する壁が抜けてるな。 >>11 CPUアーキテクチャなんかは知らなくても とりあえず何かは作れるんじゃないか? もちろん、知っておいたほうが質の良いコードが書けるだろうけどね。 >>7 偉そうな事を言える立場ではないですが、書き込みの内容を拝見するに 基本的なプログラムの技術をお持ちだと思いますので、ますはSDKサンプルの ライブラリを見てDIRECTXの初期化とWINSOWSループあたりを見てみると良いのではないでしょうか? WINDOWSのサンプルは描画速度はマシン速度(環境)に依存しています。 このままでは定期的な処理ができないので、PeekMessage周りを調べて定期的タイマーで特定の処理を呼び出すようなものを作ってみてはどうでしょうか? while( WM_QUIT != msg.message ) { if( m_bActive && m_pd3dDevice != NULL ){ if ( tTake==FALSE ){ QueryPerformanceCounter( ( LARGE_INTEGER * )&sTIME );//時間計測開始 FSP60call();//同期して動かすものはここで } FSP60nonSYNCcall();//何か出来ることあればやってしまおう } th_GetandPeekMessage( NULL );//Peek Message func if( bGotMsg!=TRUE ){ if( m_bDeviceLost ){ // Yield some CPU time to other processes Sleep( 100 ); // 100 milliseconds } if( m_bActive && m_pd3dDevice != NULL ){ if( FAILED( Render3DEnvironment() ) )SendMessage( m_hWnd, WM_CLOSE, 0, 0 ); QueryPerformanceCounter( ( LARGE_INTEGER * )&eTIME );// 計測終了 DWORD wTIME; wTIME=( DWORD )16666; if ( ( eTIME.LowPart - sTIME.LowPart )>wTIME ){ tTake=FALSE; }else {tTake=TRUE;}//endof if } } 私が自作した部分ですが、サンプルのソースに試行錯誤を繰り返しこのような形になりました。 >>11 >計算機の動作原理の理解に対する壁が抜けてるな。 理解に必用なヒントがあれば是非紹介してください。^^ これはネタとして昔やったアセンブラの事を紹介します。 PUSH AX PUSH BX PUSH CX CALL fanction function: MOV BP,SP MOV SS,AX MOV AX,ES ;スタックポイントへのアクセス MOV DX,ES:[BP+0] MOV AX,ES:[BP+2] このような形でスタック上の価(引数)にアクセス.... 80186(V30)のころのスタックフレームへのアクセス方法です。 いまやアドレス空間幅は32ビットに広がり、 このようなことは必要ありませんが(W かつてはCPUの動作を知らないとPGが書けなかった時代がありました。 現代の目で見ると、私の書いたような事はもはや御伽噺になっておりますなぁ... >>14 懐かしいな、もうそこらへんのことはすっかり忘れたよ 今やれといわれても資料読みつつじゃなきゃ絶対無理だ。 >>11 は親父PG氏に計算機の動作原理の理解がない、と言ってるんじゃなくて 3つの壁じゃなくて4つの壁ではないか?と提案してるんじゃないか? 少なくとも俺はそう読んだ まぁ計算機に関する理解は環境に関する理解に含まれると思うけどね >>13 のサンプルにちょっとだけ指摘 QueryPerformanceCounterで取ってきた値を1/1000msecとして扱ってるが その値は思いっきり環境依存です 環境によってはバグります あと、LARGE_INTEGERのLowPartのみ比較はやめたほうがいいです QueryPerformanceCounterから取得した値がなぜ64bit値なのか考えましょ あえて荒らしにも反応しとくけど >>16 この程度読みづらいならおまえの能力が低すぎ >>15 >11は親父PG氏に計算機の動作原理の理解がない、と言ってるんじゃなくて 私もそうとってますよ^^; 11氏が提案する部分で、具体的な話があれば是非紹介して欲しいなぁと思って... >>16 すんませんorz 自分でも汚いと思っております(反省 訂正 違 MOV SS,AX MOV AX,ES 正 MOV AX,SS MOV ES,AX ネタとは言え恥ずかしい....orz 価の移動は右から左だった。 というかセグメントレジスタに、直接価が入れられない制約があったんだよね。 (なんかまだ間違ってるような気がするけど、深く考えないようにしよう) まだ取り組んでいませんが、シェイダーの扱いで一部アセンブラライクなものが あるみたいなので、アセンブラの知識が(一部)役に立つかもしれません(笑 >>17 おお! 御指摘ありがとうございます早速、修正させてもらいます。 とはいえ >QueryPerformanceCounterで取ってきた値を1/1000msecとして扱ってるが >その値は思いっきり環境依存です このあたりを解決するには調べることがありそうですね。 頑張ってみます^^ あーしまった、何を使ってQueryPerformanceCounterの周波数調べるか書いてなかった QueryPerformanceFrequency使うと調べられます。 なお、高分解能パフォーマンスカウンタは今までサポートしていない環境を見たことがありません (CEも業務で数種扱ってますが全て使えました) あと、使う値はLONGLONGで定義してキャストするほうが楽です こんな感じ LARGE_INTEGER llStartTime, llEndTime; LARGE_INTEGER llCounter; DWORD dwTime; DWORD dwKeta = 1000; //ここを好きな桁に変更してください。1000だと1msec単位、1000000で0.001msec単位 bRet = QueryPerformanceFrequency((LARGE_INTEGER*)&llCounter); 〜略〜 QueryPerformanceCounter(LARGE_INTEGER*)&llStartTime); 〜略〜 QueryPerformanceCounter(LARGE_INTEGER*)&llEndTime); dwTime = (DWORD)((llEndTime - llStartTime) * dwKeta / llCounter); ってーミスってるΣ LARGE_INTEGER llStartTime(略)→LONGLONG llStartTime(略) に直してください >>20 なんだかありがたいなぁ。 悪いねぇ。。。。orz いろいろ教えてもらって^^; 他の方にも参考になると思います。 こういうレスがついてくることを、内心期待してはいましたがほんとにくると嬉しいです。 これからもいろいろと私にできる情報を提供使用と思います。 高精度タイマーが使えない環境はない! と私も決め打ちしています。 このへんは「ゲーム」という事で許される範囲ですかね。 高精度タイマーが動かなければ、おそらく他のゲームも動かないでしょうから^^ wTIME=( double )16666; //駄目コード if ( ( eTIME.LowPart - sTIME.LowPart )>wTIME ){ if ( double( eTIME.QuadPart - sTIME.QuadPart )>wTIME ) 安易にこんなことしてましたが、>>20 の書き込みも参考にさせていただきます。 たとえゲームといえど、CPU100%つかうアプリは嫌いだな。 あとこっちは余計なお世話かもしれんが、高精度タイマなんて使わなくても timeGetTimeあたりで十分な気もする。 (タイムスライスの精度的に、どうせどこかでぶれるんだから。) >>23 ご指摘ありがとうございます。 確かにtimeGetTimeの精度を一番上げた状態でも十分ではあると思います。 先にあげたソースでは実装していませんが、計測した値の差と基準となる 値を割り算して(wTIME)基準値に対して、もし遅れが出ているようなら その値を移動係数に掛けるといった処理も、視野にいれてQueryPerformanceCounter を選択しました。(正しいかどうかは別にして) ところでtimeGetTimeの正体は何なのでしょう。 いわゆる昔からあるあの「ハードウェアタイマー割り込み」なのでしょうか? OSの内部的なタイマーという解説がありますが、その内部的なタイマーとはなんぞや? IRQ (Interrupt Request)使うアレなのだろうか... 少なくともQueryPerformanceCounterは昔からあるHWタイマーではなさそうですね。 (分解能からして、昔は無かったし<-コレ重要) さて QueryPerformanceCounterとtimeGetTimeはどっちが処理が重いのだろうか? timeGettimeの精度を上げた状態とはどういうことが起きているのだろうか? 単純に精度高い=処理が重い と決め付けるわけにもいかないと思います。 いろいろと疑問が湧いてきますねぇ。 (タイマーだけで1スレ潰してしまうな、こんな話始めたら(笑 ) >>16 単語の頭と、単語と単語の切れ目は大文字っていうルールでコーディングしてるんだったら、一貫してくれないと読みづらいね。 FSP60nonSYNCcall は FSP60NonSyncCallみたいに・・・・。 >>24 QueryPerformanceCounterを含む時間管理についてはこの辺が参考になる。 ttp://www.dwahan.net/nyaruru/programming/programming.html ttp://www.gamedev.net/community/forums/topic.asp?topic_id=195892 あと、環境によってはQueryPerformanceCounterが300ms以上帰ってこないという現象もあるらしい。 ttp://home.att.ne.jp/yellow/hide_n/old.html の2001/11/12。 上のURLにある問題点と関係してるのかも。 >>25 全角スペースインデントするなら、ちゃんとやれってことじゃない? 個人的な好みだけど、前回のループのカウンターサンプリングからの経過時間冲 を、実数で持ってたほうが何かと便利かも。おじさんの頃はFPUが遅かったので 固定小数点命だったろうけど、今じゃ、バリバリ浮動小数点使います。 Real fInversedFrequency; LARGE_INTEGER liPrevCount; void init( void ) { LARGE_INTEGER liFrequency; bResult = QueryPerformanceFrequency( &liFrequency ); errorCheck( !bResult ); //カウンターサポートなし。 fInversedFrequency= 1.0f / Real ( liFrequency ); liPrevCount = 0; } void gameLoop( void ) { LARGE_INTEGER liCount; Real dt; //凾 (sec) QueryPerformanceCounter( &liCount ); if( liPrevCount != 0 ) { dt = Real( liCount - liPrevCount ) * fInversedFrequency; } else { dt = 0; } 処理:UpdateAI(), Render(), etc..... } >>25 サンプルに自分が書いた部分を書き足すと、ちゃんぽんになってしまう事があります。 気をつけないといけませんね(汗 >>26 参考URL有難う! >fpsの調節をするためにビジーループでQueryPerformanceCounterを呼び出していると どのようなループか気になりますね。素でループしたら変な事になるのかも知れませんね。 あと対策はどのくらい遅れたか? を計測して「移動やその他計算処理に」 その係数を掛け算する程度しか思いつきません。 DirectXのサンプルのタイマーユーティリティを覗くと、高精度タイマーを使用しています。 dxutil.cpp 確か高精度タイマーを選択した最大の理由はコレでした(もう忘れかけてるorz 「サンプルで使ってるし大丈夫だろう!」 ご意見お待ちしています(チョットコワイ >>27 コードサンクス! オープンソースっぽくなってきましたね。 タイマーのブレをうまく吸収してくれそうですね。 ゲームの種類によっては、これが解決になるかも。 [タイマー系の処理は(時間が)くるまで動かないではなく 「(時間が)越えれば動く」ように設計する] ですかね^^ 何気なく覗いてみたけど良スレの予感。 親父PGさんがんばれ。 ども有難うガム張ります。 タイマーの話だけではアレなので(滝汗 私が目標にした全体の設計指針を書きます。 プログラム内部で登場するものは、全て同じ基底クラスを持ち Create 命令で作成され、その時に「オブジェクトハンドル番号」を返すようにする。 *ポリゴン ライト テクスチャなどは全てこれで管理する。 命令は全てオブジェクトハンドルを使って指示する。 Commander[i]._mesMoveObject(hOBJ,OBJtype,Counter); Commander[i]._mesShowObject(hOBJ,OBJtype,Counter); (Commanderクラスは_mesで始まるオブジェクト処理集合体クラス ビューポートごとに1つ定義される。) ポーリングループにおいて一定周期にコールが行われ、このときに カウンター(命令の回数)のデクリメントと各オブジェクトに記録されている 命令にしたがってデータを可変させる。また各クラスは動きマトリクスを一つ 内包していて、カウンタが尽きるまでマトリクス演算を繰り返す。 これによって ポリゴンやライトなどの制御が簡単に動的に処理する事ができる。 (RPG系のマクロ言語のサポートを視野に入れている) 各オブジェクトには(マウスが押された時など)に予め指定してある 番号をもって共通のインターフェース関数を呼ぶようにする。 これによってソースコードの奥深く(笑)で発生したトリガーが 一箇所に集約され、ここでも一括処理ができるようになる。 (ボタンやダイヤログ機能の実装)動的に作成されたものにも対応できる。 1枚のテクスチャの部分コピーをおこないテクスチャの管理を楽にする。 半年かけてこの辺までは作りました。データの扱いをメインにくんでいたせいか DorectXの機能っぽい部分に触っていません。orz いやこれからですコレから(汗 おまえらタイマーを何に使うか決まっててモノ言ってんのか? おまえら10秒でできる判断に1日かけてんじゃねーぞ? >>32 ゲームの物理世界は ∫f(t)dt ってことだよ。 >>34 アフォですか? 世界を1フレームに微分して捉えるのは、CPUの能力が有限である以上 当たり前だよな?それ以上の何がある? とんちんかんなシロートさん。 >>36 おもしろんじゃん。その新しい時間の概念とはなんだよ? 何にも提示するものはないのに一応偉ぶって見たいだけですか? どうせ逃げるんだろうケドナ。 こういう親父は せいぜいライブラリ作りで終わりそうな予感・・・ >>37 2,3年前で頭止まってんじゃねーの? 世の中進んでるのはグラフィクス技術だけじゃないぜw スレが伸び取る! 2ちゃん的に(w >>34 タイマーについては一度議論するのも悪くないと思います。もっともご指摘のように いつまでもすることではないですか(w >>41 ライブラリ作っていると「無駄に複雑」な仕様になりがちです。戒めて前に進まないとorz >>42 ゲームですが、キャラクターデータ−を中心に(制約はあるものの) ゲームの内容は後から追加できるように考えています。 まだ具体的にゲームの内容までは絞り込んでいません。 グラフィックは嫁にメタセコイア覚えさせないと(笑 スクリプトエンジンを設計して、実装したらゲームの具体的な部分を考えます。 プログラム初心者程度でも、データを設計できる難易度に落とし込みたいと考えています (野望)幾つかのモジュールはDLLで配布して他の方もゲームシナリオが作れるような環境も 提供していければなぁと。これってある意味ツクール的かも知れないですね。 3DもOK、かつスクリプト使うってことはRPGかな? 変な荒らしに負けずガンバレ >>45 どうも^^.. 荒しなんてUP前の仕様変更(納品後)に比べればなんともないですよ(笑 以前作ったライブラリを覗いたら、バグどころか設計そのものが間違えていた事が判明! 自分で仕様変更おこしてしまいましたorz ダメスギル 今回は論理フォントを作るクラスです class cFonttypes{ NONCLIENTMETRICSstNCMetrics; public: LOGFONT defFont; cFonttypes(){//Constractor stNCMetrics.cbSize = sizeof( NONCLIENTMETRICS ); ::SystemParametersInfo( SPI_GETNONCLIENTMETRICS, sizeof( NONCLIENTMETRICS ), &stNCMetrics, 0 ); memcpy( &defFont,&stNCMetrics.lfMessageFont,sizeof( defFont ) ); defFont.lfWeight=FW_MEDIUM; defFont.lfHeight=32; defFont.lfItalic=false; defFont.lfQuality=PROOF_QUALITY; } virtual ~cFonttypes_Barracks(){} BOOL SelectFontType(int _nType_,int _size_ ,bool _italic_ ); BOOL SelectFontType(char* _cFontName_,int _size_ ,bool _italic_ ); }; .cpp BOOL cFonttypes::SelectFontType(int _nType_,int _size_ ,bool _italic_){ //名前登録済み defFont.lfItalic=false; defFont.lfHeight=_size_; defFont.lfItalic=_italic_; switch( _nType_ ){ case 0:{lstrcpy( defFont.lfFaceName,"Arial" );break;} case 1:{lstrcpy( defFont.lfFaceName,"MS 明朝" );break;} case 2:{lstrcpy( defFont.lfFaceName,"MS ゴシック" );break;} case 3:{lstrcpy( defFont.lfFaceName,"HGP創英角ポップ体" );break;} case 4:{lstrcpy( defFont.lfFaceName,"HG丸ゴシックM-PRO" );break;} case 5:{lstrcpy( defFont.lfFaceName,"HG正楷書体-PRO" );break;} case 6:{lstrcpy( defFont.lfFaceName,"Impact" );break;} case 7:{lstrcpy( defFont.lfFaceName,"Times New Roman" );break;} default: lstrcpy( defFont.lfFaceName,"Arial" ); }// end of Switch if ( CreateFontIndirect(&defFont)!=0 ){//論理フォントの選択&作成 return(true); }else{ return(false);} } もう一つは割愛 フォントは環境に依存するので初期化ファイルにユーザーが登録できるようにする 仕様が望ましいのかなぁ。などといいつつプリセットを作ってる私でありますが。 こういうのを作った後で(最初はユーザーは難しいことさせるなという仕様なのに) 後からやっぱりユーザー定義で作って! なんて事はよくありますな。 仕様書作成=作る人 って楽で良いね(笑 訂正 if ( CreateFontIndirect(&defFont)!=0 ){//論理フォントの選択&作成 HFONT ReFont CreateFontIndirect(&defFont); return( ReFont ); 関数の型 BOOL > HFONT またやってしまったorz 落ち着け俺 既に環境依存してますって(汗) HG系はリコーの商用フォント。Windows標準では使用不可能 MS-Officeについてくるから勘違いされることが多いけどね フォントを複数種類使いたいならEnumFontFamiliesEx使ってフォントを列挙し、 ユーザーに選ばせるのが一番安全 ちょっと低レイヤー過ぎるような。 3Dっしょ?フォントとかそんなとこから作ってたら平成が終わっちゃうよ。 D3Dサーフェイスに乗せられるテキストボックスとかがいいんじゃね? >>49 >HG系はリコーの商用フォント。Windows標準では使用不可能 >MS-Officeについてくるから勘違いされることが多いけどね そうでしたが....Windows2000にも入っていたので標準かと思ってましたよorzダメスギル 少し改造すれば(最終的な)ユーザー選択可能にもできますので^^ そこはなんとかいたします >>50 この部分は(表示まで含む)以前に作った事があるのですが、のべで5日ぐらいでしたので大丈夫ですorzタブン それよりTextOutでビットマップに出力するとアンチシェアリングかかってないんですよね。 そのぶん速度も速いですが。 GetGlyphOutline を使うべきなのか.... ttp://www.mikenekoworks.com/develop/getglyphoutline.html このあたりは要求仕様によって変わりそうではありますが つかフォント(´д`)イラネ BMPで用意してケロ。 12x24、16x32の二つあれば十分でゲス。 >>52 (理論文字数65535文字) *12*24bit*8/8 18874080byte 1ピクセル深度8bitで計算 1.8Mですな(65535の部分はうそ臭い) まぁ1Mぐらいかな。昨今の環境では無問題かもね(汗 ということはプログラム開始時に作ってしまうのがいいのかな。 全フォントピクセルBMP(横に糞長いBMP) 全フォントBMPで管理する時、面倒なのはカーニングですねぇ。どうしましょ(W コードから半角を割り出すか(W 昔やったねコード判別で半角or全角判断 いっそカーニングデータ−にも対応して!(やばい泥沼だ 昔PC98のころはフォント用のLSIをからフォントデータ−を取得して表示してましたね。(サイズ固定) というかテキスト専用のVRAM(空間)があって、そこに2バイト書き込めば文字が出るというレイヤー構成だった。(グラフィックVRAMは別) グラフィックVRAMは微妙にメモリアドレス空間ズレテルシorz DOSVで文字データ−をメモリに載せるシステムを見た時!メモリ大丈夫か!と関心したものです。(当時の互換機はメモリ16Mが標準) 僕らより先輩の時代には、[コンピューター漢字不要論]なんてのもありましたorz....... 現時点でのFONT周りの基本動作 PG開始時 テキストBMP用作成 tbitmap以外で取得したリソースは全て破棄 論理フォント作成 指定フォントでBMPにtextoutで書き込み 文字貼り付け用ポリゴン作成 ポリゴンに書き込み 初期化終了/ループ開始 文字列に変更がない場合、BMPはそのまま 変更があった場合 BMP書き換え ポリゴンとテクスチャの貼り付け レンダリング 表示 ループエンド 追加機能 文字の後ろにはグラフィックが置ける 現在、OR加合処理 利点 (システムにあれば)どのようなFONTにも対応できる 動的に文字列を変化できる 比較的高速 カーニングはシステム任せ イタリック、太字なども関数へのパラメーターのみで対応できる 文字色も自由に変更できる(1文字ずつも可能) 文字データ−>テクスチャデータ−の時にエフェクトなどが付けられる(グラデーションとか) 欠点 アンチシェアリングがかかっていない為、3Dでポリゴンが視点に対して垂直でないと文字が崩れる。(これは考慮しないと他でも当てはまる) テキストっぽい(w (テキストだけどね) システムの環境に依存する 文字列の変化する時に、ループ内でGDI操作が発生する(BMPだけの書き換えで対応できるかな?? 後から長い文字列がきた場合の対応...) でかい文字はNG 列挙すると、現在の仕様での不備点は基本的に品質への問題が大きいみたいですね。なんだかテキストエディタ用のライブラリ作ってるみたいだ。 結局文字用のBMP用意から以降は、同じにできそうなので、文字用のBMP書き込みの部分を「文字の品質対する要求」パラメーターを追加して textOutかGetGlyphOutlineで用意するか切り分けると良いかな。 あとエリア書き込みには対応しないとね(汗 文字列にCRLFがあったら書き込み位置の移動。これは大丈夫だね。 プログラムは良いけど、まず企画が無いと設計できないんじゃ… >>55 まぁいいんじゃないの。自分の得意な所から切り込んで行くのは モチベーションを保つのに有効だと思う。 >>55 密かに「企画」はありますが、ここで公開するにはまだ未整理な部分があるので また公開していません。現在作っているところはどのような形態のゲームでも、 取り合えずは利用する汎用部分だと思っています。 ところで、スクリプトエンジンについては、これから設計を始めるのですが、 どのようか形がやり易いのでしょうかね? ターゲット>ゲームの企画(シナリオ)担当(if文の意味ぐらいは知っている人) サポート予定の機能 スクリプトで(ゲームから見た)下レイヤーに対するオブジェクト命令が可能 (このフォーマットで作成しているので実装済み WINDOWダイアログ、ボタンサイズ、ビューポートの数とサイズなどを 予めリソースエディタで編集可能(作成済み ボタンに割り当てるグラフィックを複数パターンの割り当てができる。 マウスMOVEでアニメーション マウスHITでアニメーション 常にアニメーション 等のボタンの実装(作成済み マウスクリック時の反応に、INDEX番号が割り付けることができる(実装済み ○問題はシナリオライター側の表現方法の実装方法 本体とは別のエディタを用意//Delphiで作成予定 1)ポインタがないC言語のような言語を書かせるタイプ 2)プリセット式してプルダウンメニューで一行ずつ書いていくタイプ 3)シーンごとに必用なデータ−を埋めていくタイプ どういうのがいいんだろうね? それこそゲームの企画ありきな話かもしれませんが^^ ご意見お待ちしています。 >>57 作るゲームが決まってなきゃスクリプトエンジンなど書けません。 何か最初の方は3Dゲー目指してる感じだったけど、スクリプトエンジンの 内容はノベルゲームを目指してるようにも聞こえるのだが… フォントとかってアクションゲームなら使わないし、イマイチ最終的に 何を作りたいのかが分からないのだが。 >>58 どんなゲームだろうとフォントを全く使わないって事はないだろう。 今までどんなゲームやってたのか知らんが、 お前さんのいうアクションゲームって たとえばどんなのよ? >>59 ここでは厳密なフォント周りが必要ないといってるだけでは? たとえばSTGなんかもスコアとかは表示するけどあれは 厳密なフォントのライブラリ使うようなもんじゃないだろってことかと 数字10種と「score」と表示するビットマップでいい そしてRPGやAVGのぞくとフォント周り意識するものはほとんどない 最初は遅くてもOS標準の描画でなんの問題もない やはり何作るか決まってないってのが一番の原因 403 :心得をよく読みましょう :04/04/01 03:32 ID:1xz8AXwW よろしくお願いします 【板名*】ゲ製作技術 【スレ名*】親父PGがゲームを作り始めるスレッド 【スレのURL*】http://pc5.2ch.net/test/read.cgi/gamedev/1080582036/ 【名前欄】 【メール欄】sage 【本文*】↓ 既に環境依存してますって(汗) HG系はリコーの商用フォント。Windows標準では使用不可能 MS-Officeについてくるから勘違いされることが多いけどね フォントを複数種類使いたいならEnumFontFamiliesEx使ってフォントを列挙し、 ユーザーに選ばせるのが一番安全 >>58 59 60 議論有難う。 ゲーム(種類)によって必用か不要であるかという議論は、確かにあると思います。 特に納期に追われている職業PGではなおさらでです。 その辺の議論は置いといて、「作ってしまえ!」のノリで8割型完成しましたorz フォントの種類については、ユーザーが後からいくらでも追加できるようにして 静的配列>STL(動的配列)に変更(フォント属性をまとめて記録) 構造体のコンペアをかけて同じフォント属性を登録しないチェック 呼出回数の記録をとって、使用頻度の低い論理フォントは破棄する。 (破棄しても次回呼出の時に、自動的に再登録される) ※ご指摘いただいた問題点がとても役に立ちました しかし、このへんはプログラマの趣味の世界に突入していますねぇ。 ゲームによってはまったく使わないかもしれなけどorz... 実は何を作りたいというのは漠然とはあるのです。 目標の物を作成する為には、FONT周りをきちんと整理しておかねばなりません。 ちょっと過去を話すとDTPの仕事(デザイナー)も経験がありまして 文字が汚いのはいやなのですorz また趣味の世界に突入してる.... >>遅くてもOS標準の描画 DirectXの描画ループでそれをやると、ちょっと問題が起こります。 いずれのゲームでも以下の処理は必要かと思われます。 テクスチャ作成>BMP作成>文字描画>ポリゴン貼り 内に秘めたり、趣味に走るのは全然問題無いのですが、 目的が分からないとアドバイスしようがないよ、という話だと思います。 >>63 なるほど、では今、思案中で是非アドバイスして欲しいことがあります >>57 にも書きましたが、ゲーム用のスクリプトの仕様決定の為の指針についてです。 ゲームは取り合えずRPG用と仮定してください。(カードゲームや其の他にも応用化) 画面形態はドラクエと仮定します。(画面形態は固定しない仕様を考えています) この場合、シナリオを作成する側はどのような機能が欲しいか? どのようなレベルまでPG的な事を理解できるか? ということです。 フラグ管理機能なども必要でしょうし; 文字列を解析してデータ−を作成するというのは、自作でコンパイラを作るようなものですねぇ。 数値計算とかポーランド記法。。。 いろいろ待っていそうですね(汗 そういえば昔、電卓作ったなw それとも今ではフリーのMASMのマクロで組むかな.... テキスト出力なら、 フォントサイズを計算 -> テクスチャの生成 -> GetGlyphOutlineのイメージをテクスチャ -> レンダリング 出力先の大きさを固定するのならサイズの計算はいらないけど。 BMP作成というのが意味不明。 >>65 素人は引っ込んでろよ。 >>64 文字主体のゲームだとしても漢字全部を入れる必要はないかと。 使用している文字吐き出して必要な分だけ抽出する仕組みを用意すれば効率いいよ。 だいたいBMP作成なんて訳の分からないことをしたら、 GetGlyphOutlineで得られるα成分はどうするの? なんちゃって玄人の>>66 よ、素人にも分かるように説明してくれ。 なんかBMPを画像(フォーマット)としてのBMPとかと勘違いしてる? >>68 GetGlyphOutlineのイメージをテクスチャ に転送する際に、 BMPがDIBや自分で確保したヒープであっても、 余計なものを経由して、わざわざ動作を遅くする理由は? >>69 DirectX経由の話であって、コンシューマーの話ではないはずだが、 何を言っているのかますます意味不明。 >>57 作業がしやすいなら(使いたい機能を感覚的に探せる)どんなタイプでもかまわない。 最低限の改行/改ページ指定の入った文章をスクリプト書式に変換(もしくはデータ化) でき、可能ならその逆(スクリプトからほとんど文章のみの形にする)もできるようにして欲しい。 校正しやすい形でシナリオを書きたいからね。 BMPを経由する理由というのがあるのなら、 その時点で私のよけいなお節介だったというだけの話なんだが。 話が別のところへ行きそうな予感。 いやもうウザイんで消えて。なにやるか判ってないのにアドバイスできると 思ってる池沼にはうんざり。 >>73 何故BMPなんて余計なものを経由するのか、明確な説明があれば即消えるけど。 なんで理由を書かずに、高圧的な書き込みだけ残していくの? 理由があればそれでよし、無駄な部分なら省けばいいだけの話題なんだが。 テクスチャを利用する場合は、アルファで透明色の設定が必要になるから、 例えば、 TextOut>DIB>テクスチャ なんかの場合は、透明色をテクスチャに設定し直さなければならないので、 GetGlyphOutlineからダイレクトの方が効率がいいのでは? 俺も>>68 とか意味がわからんので教えて欲しいな。 しかし、このスレはいろんな意味でマズーだなぁ・・。 いいのかこんなんで、みたいな。 結局なにも説明できず、煽ってごまかすことしかできないとは。 それがプロの仕事なのか? 文句があるのなら技術的に突っ込みを入れればいいだけなのに。 >>76 ダイレクトというのはこういう形ですよね 文字データ−GetGlyphOutline V DIB(背景)> OR加合 > テクスチャ>ポリゴン貼り付け (DIB(背景)はなくてもOK) ○TextOutを使う場合 透明色については単にORで演算すると抜けてくれますので大丈夫です。 DIB(BMP)そこに背景の画像も同時に保持する為です。 textoutの為に(内部に)BMPが必用なので作成しております。 ループ開始前にハンドルで保持できるという、運用上のメリットもあります。 ○GetGlyphOutline ループの中で文字データ−を作成するのは、文字列が変更した時意外は極力避けるべきなので 事前に何処かに置いておく必用があります。 TextOutの時にはBMPがありましたので、そこに保持しています。 (メモリと同じ扱いですね) 同じロジック上で動くならその上に置いておけばいいや!という考えなのですけどね... ところでこの関数は1文字ずつしか機能しないのですが、そのへんの速度って大丈夫なのでしょうか? まとめ 当初 TextOut命令でFONTデータ−を作成する仕様だったので、当然(内部)BMPを作って ハンドルを保持する形が生まれた。 しかしそれではアウトラインが汚いので、ユーザーが切り替えられる仕様を追加した。 既にBMP経由のロジックが出来ているので、単にGetGlyphOutlineデータ−を置いておくメモリとしてBMPを使用した。 ざっとこういう理由でBMPがこの中に残っています。 保持するBMPは1ピクセル8ビット深度フォーマットで作成。これなら両方のデータ−を収めることが可能 こんな感じかな... 俺はなにか間違えているのだろうか orz..... 根本的なところに考え方に食い違いがあるようなんだけど、 なぜレンダリング時にハードウェア側で背景とフォントを合成しないの? >文字列が変更した時意外 背景と分離しておけば、背景が動的に更新される場合も、 文字列に変更がなければ、文字列用のテクスチャを書き換える必要が無い。 背景は更新されないことが前提? >>71 校正の容易さについては重要な指針とさせてもらいます。 ============================================================== 言語仕様のプラン 1)Cライク if (fg[24]==25){ PUTMES(1,1,'メッセージ出力'); } 2)単純化したもの [24]==25,PUTMES,メッセージ出力; 3)EXCELを前提 PUTMES,'メッセージ出力'(24,=,25); こういう形よりWEBのツリー型の掲示板のような形のほうがいいのかなぁ... Parlで組むか!(orz スミマセン ジョウダンデス >>82 ごめんなさいorz データは背景用と文字用と2つ持っています。 レンダリング直前に加算してます。 レンダリング直前というのが謎なんだけど、 テクスチャを使っているのなら、なぜレンダリング時に、 ハードウェア側で合成をかけずに、その前過程で合成するのかが疑問。 >>85 ポリゴンに張り込むテクスチャ1枚目に、データ−を放り込んだらうまくいったからというのが理由です。深い意味はありませぬorz 加合用の2枚目のテクスチャをさらに別途用意して、データ−を他所からもってくるなら(他にいろんな可能性があるとはいえ) テクスチャは1枚でいいような気もするのですが... ハードウェアとソフトウェアでは合成速度に雲泥の差があるんだけど。 それにゲームの内容にもよるけど、サウンドノベルでもなければ、 普通は背景が一枚絵である場合は少ない。 複数のパーツを結合して背景やキャラクターを合成して、 一つのフレームを生成するわけなんだけど。 もしかして3Dデバイス経由でノベルのシステムを作るという話だったの? だったらすまなかった、この話は忘れて。 >>88 とりあえず目標はRPGらしいぞ だからフォントなんかで速度がネックになるところはないと思われ 最適化に目がいくのはいいが、さっさとゲーム作り始める方がいいような ネックになる場所とかもそれではじめてでてくるとかあるかもしれんし #そういや親父のわりに真っ昼間から時間あるんだな 普通D3Dなら、フォントテーブルはD3DFMT_A8で作って マルチテクスチャブレンディングで加工・表示するもんだと思っていたが。 確かに俺は素人だが、、、まあいいけどさ。 >>89 今日は非番で休みです。 明日は仕事ですorz... >>91 スマン 非番という言葉使っていることからタイムシフト系か つらそうだな >>92 93 どうもありがとう。その言葉を励みに頑張ります。 今仕事から戻ってきました。土曜日は電車が空いてるので、ひざの上でPG組んでました(w 電車には携帯電話禁止と書いてあるが、携帯パソコン禁止とは書いてないからな。 GetGlyphOutline って結構面倒ですね。まだ動きがおかしいorz 文字列からひとつひとつコードを取り出さないといけないし、 UINTに対応して上位バイトと下位バイトを入れ替えなど... ほんとにこんな処理をループ中にして大丈夫なのかな。 毎フレームやることじゃないな。この処理 ライブラリとかフレームワーク作るだけで力尽きないように SDLとか使うのもいいのではないかと。 DIBについてトリビアを発見しました。 BITMAPINFOHEDERのbiHeight メンバを−にしてDIBを作成すると 左上原点のボトムダウンDIBになる。 既に概出かもしれませんが.....orz それって10年前からやってたんだが そのまま書き出しても一部対応してないビューアとかあるけど 内部で使うだけなら問題ない 面白そうなので参加したいな。 当方C,C++,C#,VB,Java,Perl,ASM何でもOK。DirectX触った事なしです。 親父PG様の進行を妨げない、便利屋PGとして徹しますので。 >>97 1994年から? win3.1の頃からそうだっけ? orzオレハ10ネントテツモナクムダナコトヲシテタノカ.... >>98 おお!参加表明有難う。 もし、やってもらえるなら、前にも書きましたが シナリオエディタとデータ−規格の設計をお願いしたいです。 フラグ管理も「履歴」機能を追加して「過去4回きてれば」というようなものも欲しいですね。 データの規格が煮詰まれば、こちらでもツールを作ります。 ここでデータの設計を進めましょう。 現在動いている下位レイヤーでは、引数として 「対象ビューポート」、「対象オブジェクト」、「呼出タグ」などが設定できます。 ※ピューポート画面分割だと思ってください。 現在、プログラム起動時にビューポート数とその大きさ、「ボタン128個(反応レクト領域数)」、テクスチャファイル名 が入ったファイルを読み込んで画面が変化するようにしています。 またこのプロファイルは何度でも読み直しができます。(画面デザイン切替可能) (※以上は稼働中) 作成する(予定)の物は 昔、(今もか)ソーサリアンというゲームがありましたが、そのシステムを拡大.拡張する予定です。 (シナリオはヨコスクロールに限定しない) あと、DirectX SDK落としてきてサンプル覗いてみてください。 経験のある方なら動かすぐらいは簡単にできると思います。^^)|~ アイテムデータの作成は本体PGに持たずに、外部にDLLとして実装して、 他のアプリケーションからも使用可能にします。 うーむ勢いで...公言してしまった。orz ダイジョウブカナ... ソーサリアンの拡張版!? それは楽しみ。 絵とか音楽とか必要な段階になったら、 状況が許せばお手伝いします。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.0 2024/04/24 Walang Kapalit ★ | Donguri System Team 5ちゃんねる