[過去ﾛｸﾞ]
親父PGがゲームを作り始めるスレッド (668ﾚｽ)
親父PGがゲームを作り始めるスレッド http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
53: 親父PG [] 04/04/02 01:02 ID:5nHc263h >>52 （理論文字数65535文字） *12*24bit*8/8 18874080byte 1ピクセル深度８bitで計算 1.8Mですな（６５５３５の部分はうそ臭い） まぁ１Mぐらいかな。昨今の環境では無問題かもね（汗 ということはプログラム開始時に作ってしまうのがいいのかな。 全フォントピクセルBMP(横に糞長いBMP) 全フォントBMPで管理する時、面倒なのはカーニングですねぇ。どうしましょ（W コードから半角を割り出すか（W 昔やったねコード判別で半角or全角判断 いっそカーニングデータ−にも対応して！（やばい泥沼だ 昔PC98のころはフォント用のLSIをからフォントデータ−を取得して表示してましたね。（サイズ固定） というかテキスト専用のVRAM（空間）があって、そこに２バイト書き込めば文字が出るというレイヤー構成だった。（グラフィックVRAMは別） グラフィックVRAMは微妙にメモリアドレス空間ズレテルシorz DOSVで文字データ−をメモリに載せるｼｽﾃﾑを見た時！メモリ大丈夫か！と関心したものです。（当時の互換機はメモリ１６Mが標準） 僕らより先輩の時代には、[コンピューター漢字不要論]なんてのもありましたorz....... http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/53
54: 親父PG [] 04/04/02 01:43 ID:5nHc263h 現時点でのFONT周りの基本動作 PG開始時 テキストBMP用作成 tbitmap以外で取得したリソースは全て破棄 論理フォント作成 指定フォントでBMPにtextoutで書き込み 文字貼り付け用ポリゴン作成 ポリゴンに書き込み 初期化終了/ループ開始 文字列に変更がない場合、BMPはそのまま 変更があった場合 BMP書き換え ポリゴンとテクスチャの貼り付け レンダリング 表示 ループエンド 追加機能 文字の後ろにはグラフィックが置ける 現在、OR加合処理 利点 （ｼｽﾃﾑにあれば）どのようなFONTにも対応できる 動的に文字列を変化できる 比較的高速 カーニングはシステム任せ イタリック、太字なども関数へのパラメーターのみで対応できる 文字色も自由に変更できる（１文字ずつも可能） 文字データ−＞テクスチャデータ−の時にエフェクトなどが付けられる（グラデーションとか） 欠点 アンチシェアリングがかかっていない為、３Dでポリゴンが視点に対して垂直でないと文字が崩れる。（これは考慮しないと他でも当てはまる） テキストっぽい（ｗ （テキストだけどね） システムの環境に依存する 文字列の変化する時に、ループ内でGDI操作が発生する（BMPだけの書き換えで対応できるかな？？ 後から長い文字列がきた場合の対応...） でかい文字はNG 列挙すると、現在の仕様での不備点は基本的に品質への問題が大きいみたいですね。なんだかテキストエディタ用のライブラリ作ってるみたいだ。 結局文字用のBMP用意から以降は、同じにできそうなので、文字用のBMP書き込みの部分を「文字の品質対する要求」パラメーターを追加して textOutかGetGlyphOutlineで用意するか切り分けると良いかな。 あとエリア書き込みには対応しないとね（汗 文字列にCRLFがあったら書き込み位置の移動。これは大丈夫だね。 http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/54
57: 親父PG [] 04/04/02 07:24 ID:5nHc263h >>55 密かに「企画」はありますが、ここで公開するにはまだ未整理な部分があるので また公開していません。現在作っているところはどのような形態のゲームでも、 取り合えずは利用する汎用部分だと思っています。 ところで、スクリプトエンジンについては、これから設計を始めるのですが、 どのようか形がやり易いのでしょうかね？ ターゲット＞ゲームの企画（シナリオ）担当（if文の意味ぐらいは知っている人） サポート予定の機能 スクリプトで（ゲームから見た）下レイヤーに対するオブジェクト命令が可能 （このフォーマットで作成しているので実装済み WINDOWダイアログ、ボタンサイズ、ビューポートの数とサイズなどを 予めリソースエディタで編集可能（作成済み ボタンに割り当てるグラフィックを複数パターンの割り当てができる。 マウスMOVEでアニメーション マウスHITでアニメーション 常にアニメーション 等のボタンの実装（作成済み マウスクリック時の反応に、INDEX番号が割り付けることができる（実装済み ○問題はシナリオライター側の表現方法の実装方法 本体とは別のエディタを用意//Delphiで作成予定 １）ポインタがないC言語のような言語を書かせるタイプ ２）プリセット式してプルダウンメニューで一行ずつ書いていくタイプ ３）シーンごとに必用なデータ−を埋めていくタイプ どういうのがいいんだろうね？ それこそゲームの企画ありきな話かもしれませんが^^ ご意見お待ちしています。 http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/57
62: 親父PG [] 04/04/02 11:20 ID:5nHc263h >>58 59 60 議論有難う。 ゲーム(種類)によって必用か不要であるかという議論は、確かにあると思います。 特に納期に追われている職業PGではなおさらでです。 その辺の議論は置いといて、「作ってしまえ！」のノリで８割型完成しましたorz フォントの種類については、ユーザーが後からいくらでも追加できるようにして 静的配列＞STL（動的配列）に変更（フォント属性をまとめて記録） 構造体のコンペアをかけて同じフォント属性を登録しないチェック 呼出回数の記録をとって、使用頻度の低い論理フォントは破棄する。 （破棄しても次回呼出の時に、自動的に再登録される） ※ご指摘いただいた問題点がとても役に立ちました しかし、このへんはプログラマの趣味の世界に突入していますねぇ。 ゲームによってはまったく使わないかもしれなけどorz... 実は何を作りたいというのは漠然とはあるのです。 目標の物を作成する為には、FONT周りをきちんと整理しておかねばなりません。 ちょっと過去を話すとDTPの仕事（デザイナー）も経験がありまして 文字が汚いのはいやなのですorz また趣味の世界に突入してる.... >>遅くてもＯＳ標準の描画 DirectXの描画ループでそれをやると、ちょっと問題が起こります。 いずれのゲームでも以下の処理は必要かと思われます。 テクスチャ作成＞BMP作成＞文字描画＞ポリゴン貼り http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/62
64: 親父PG [] 04/04/02 12:08 ID:5nHc263h >>63 なるほど、では今、思案中で是非アドバイスして欲しいことがあります >>57 にも書きましたが、ゲーム用のスクリプトの仕様決定の為の指針についてです。 ゲームは取り合えずRPG用と仮定してください。（カードゲームや其の他にも応用化） 画面形態はドラクエと仮定します。（画面形態は固定しない仕様を考えています） この場合、シナリオを作成する側はどのような機能が欲しいか？ どのようなレベルまでPG的な事を理解できるか？ ということです。 フラグ管理機能なども必要でしょうし； 文字列を解析してデータ−を作成するというのは、自作でコンパイラを作るようなものですねぇ。 数値計算とかポーランド記法。。。 いろいろ待っていそうですね(汗 そういえば昔、電卓作ったなｗ それとも今ではフリーのMASMのマクロで組むかな.... http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/64
80: 親父PG [] 04/04/02 15:26 ID:5nHc263h >>76 ダイレクトというのはこういう形ですよね 文字データ−GetGlyphOutline V DIB（背景）＞ OR加合 ＞ テクスチャ＞ポリゴン貼り付け （DIB（背景）はなくてもOK） ○TextOutを使う場合 透明色については単にORで演算すると抜けてくれますので大丈夫です。 DIB（BMP）そこに背景の画像も同時に保持する為です。 textoutの為に（内部に）BMPが必用なので作成しております。 ループ開始前にハンドルで保持できるという、運用上のメリットもあります。 ○GetGlyphOutline ループの中で文字データ−を作成するのは、文字列が変更した時意外は極力避けるべきなので 事前に何処かに置いておく必用があります。 TextOutの時にはBMPがありましたので、そこに保持しています。 （メモリと同じ扱いですね） 同じロジック上で動くならその上に置いておけばいいや！という考えなのですけどね... ところでこの関数は１文字ずつしか機能しないのですが、そのへんの速度って大丈夫なのでしょうか？ まとめ 当初 TextOut命令でFONTデータ−を作成する仕様だったので、当然（内部）BMPを作って ハンドルを保持する形が生まれた。 しかしそれではアウトラインが汚いので、ユーザーが切り替えられる仕様を追加した。 既にBMP経由のロジックが出来ているので、単にGetGlyphOutlineデータ−を置いておくメモリとしてBMPを使用した。 ざっとこういう理由でBMPがこの中に残っています。 保持するBMPは１ピクセル８ビット深度フォーマットで作成。これなら両方のデータ−を収めることが可能 こんな感じかな... 俺はなにか間違えているのだろうか orz..... http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/80
83: 親父PG [] 04/04/02 15:58 ID:5nHc263h >>71 校正の容易さについては重要な指針とさせてもらいます。 ============================================================== 言語仕様のプラン 1)Cライク if (fg[24]==25){ PUTMES(1,1,'メッセージ出力'); } 2)単純化したもの [24]==25,PUTMES,メッセージ出力； 3)EXCELを前提 PUTMES,'メッセージ出力'(24,=,25); こういう形よりWEBのツリー型の掲示板のような形のほうがいいのかなぁ... Parlで組むか！（orz ｽﾐﾏｾﾝ ｼﾞｮｳﾀﾞﾝﾃﾞｽ http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/83
84: 親父PG [] 04/04/02 16:00 ID:5nHc263h >>82 ごめんなさいorz データは背景用と文字用と２つ持っています。 レンダリング直前に加算してます。 http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/84
87: 親父PG [] 04/04/02 16:20 ID:5nHc263h >>85 ポリゴンに張り込むテクスチャ１枚目に、データ−を放り込んだらうまくいったからというのが理由です。深い意味はありませぬorz 加合用の２枚目のテクスチャをさらに別途用意して、データ−を他所からもってくるなら（他にいろんな可能性があるとはいえ） テクスチャは１枚でいいような気もするのですが... http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/87
91: 親父PG [] 04/04/02 17:05 ID:5nHc263h >>89 今日は非番で休みです。 明日は仕事ですorz... http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/91
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.017s