ハンドルからグラフィックのサイズを取得する
ハンドルからグラフィックのサイズを取得する
DXライブラリで、メモリに読み込んだ後で、グラフィックの縦と横のサイズを取得する方法はありますか?
毎回のループの中で呼び出しても速度劣化のない高速なものが良いのですが・・・
毎回のループの中で呼び出しても速度劣化のない高速なものが良いのですが・・・
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: ハンドルからグラフィックのサイズを取得する
DXライブラリのリファレンスを読むようにしましょう。
「DXライブラリ置き場 リファレンスページ」
http://homepage2.nifty.com/natupaji/DxLib/dxfunc.html
GetGraphSizeと言う関数があります。
「DXライブラリ置き場 リファレンスページ」
http://homepage2.nifty.com/natupaji/DxL ... html#R3N13
問題となる様な速度低下は無いと思います。
「DXライブラリ置き場 リファレンスページ」
http://homepage2.nifty.com/natupaji/DxLib/dxfunc.html
GetGraphSizeと言う関数があります。
「DXライブラリ置き場 リファレンスページ」
http://homepage2.nifty.com/natupaji/DxL ... html#R3N13
問題となる様な速度低下は無いと思います。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: ハンドルからグラフィックのサイズを取得する
迅速なご回答ありがとうございます。
別に変数を用意して代入するのではなく、
xxxx(handle).SizeX みたいに即出てくる、しかも高速な方法があるのかと思っていましたが・・・
速度低下があるかどうかは、自分で計測用プログラムを作って確認したいと考えています。
別に変数を用意して代入するのではなく、
xxxx(handle).SizeX みたいに即出てくる、しかも高速な方法があるのかと思っていましたが・・・
速度低下があるかどうかは、自分で計測用プログラムを作って確認したいと考えています。
Re: ハンドルからグラフィックのサイズを取得する
何でそのような方法があるものと思っていたのでしょう?veritas さんが書きました:迅速なご回答ありがとうございます。
別に変数を用意して代入するのではなく、
xxxx(handle).SizeX みたいに即出てくる、しかも高速な方法があるのかと思っていましたが・・・
お聞かせください。そう思った根拠があるはずですよね?
そもそも質問の経緯が分かりません。
別に変数を用意して代入してようがxxxx(handle).SizeX みたいに即(?)出てこようが、速度に差があるとは思えませんが。
(どちらにしろファイルから読み込んで情報を得ると言う点では同じだし、最近のコンパイラは最適化というものがあって書き方が違ってもコンパイラを通した後では同じようなアセンブリ出力の結果になることが多いからね?)
その心構えは正しいですが、どのようにして計測するのでしょうか?veritas さんが書きました:速度低下があるかどうかは、自分で計測用プログラムを作って確認したいと考えています。
わかってると思いますが、ファイルをロードする時間で無く、サイズを取得する時間ですよ。ここ間違えないでくださいね。
written by へにっくす
Re: ハンドルからグラフィックのサイズを取得する
DXライブラリのソースファイルをダウンロードしてGetGraphSizeからいらないコードを除いて使えばさらに高速かもしれないね。
GetGraphSizeはほぼ配列参照しているだけの、即出てくる、しかも高速な方法で実装されているように見えるけども。
DXライブラリでグラフィックというと元画像のことではないのだがそこんとこ間違えてないだろうか?
GetGraphSizeはほぼ配列参照しているだけの、即出てくる、しかも高速な方法で実装されているように見えるけども。
DXライブラリでグラフィックというと元画像のことではないのだがそこんとこ間違えてないだろうか?
Re: ハンドルからグラフィックのサイズを取得する
質問者本人です。
この質問の経緯をもう少し詳しく説明いたします。
ほとんどの描画関数は、画像の中心ではなく左上を出力先として指定します。
従って描画の度に、キャラの本当の座標から、縦横サイズの半分の値を引いて指定する必要があります。
それが必須の処理であり、なおかつこれがゲーム作りに適していると噂のライブラリならば、定石の手間を省く方法が用意されていても悪くはないと考えました。
これが用意されていないのは、おそらくほとんどの開発者が32×32などと事前にサイズを限定し、取得を不要としているからでしょう。
しかし自分は今回、サイズに規則性のない大量の画像を扱う予定です。
次に、速度について。
おそらくメモリ上のグラフィックは、リストのように連結されて格納されていると予測しています。
データにアクセスする際は、リスト先頭から順に辿って目的のコンテナを探し出し、そこから読み出すのだと思われます。
ここで、描画関数を使った場合、既にリスト辿りが実行されて、目的のコンテナをフォーカスしているはずです。
そのタイミングでサイズ情報にアクセスすれば、一番無駄がなく高速な取得ができるでしょう。
しかし、問題のサイズ取得関数は、いったいどんなタイミングで呼び出されるのか?
まさか、リスト辿りを無駄にもう1回実行してはいないのか?
今日のPC性能であれば、それぐらいの無駄はどうという事はないと思います。
ただ、妙な無駄は省きたいという事です。
そして、無駄を抱えるのであれば、それがどれくらいの無駄なのか知っておきたいという事です。
特に、何千のアニメパターンを扱ったり、何万の弾幕を飛ばしたりする場合は、塵も積もったりはしないのか?
最後に、計測プログラムについて。
大量の弾幕を飛ばすものを2つ作り、60FPSの限界を調査しつつ、フレーム間のスリープ待ち時間を参照します。
一方のプログラムでは、毎フレームにて全弾のサイズを1つ1つ関数で取得し描画関数に使用します。
もう一方は、実はサイズはある規則に基づいた数列(本番ではあり得ない条件だが)で、取得関数を使わずに記述します。
この2つの比較で、実用上に差が出るのかどうかわかると思います。
この質問の経緯をもう少し詳しく説明いたします。
ほとんどの描画関数は、画像の中心ではなく左上を出力先として指定します。
従って描画の度に、キャラの本当の座標から、縦横サイズの半分の値を引いて指定する必要があります。
それが必須の処理であり、なおかつこれがゲーム作りに適していると噂のライブラリならば、定石の手間を省く方法が用意されていても悪くはないと考えました。
これが用意されていないのは、おそらくほとんどの開発者が32×32などと事前にサイズを限定し、取得を不要としているからでしょう。
しかし自分は今回、サイズに規則性のない大量の画像を扱う予定です。
次に、速度について。
おそらくメモリ上のグラフィックは、リストのように連結されて格納されていると予測しています。
データにアクセスする際は、リスト先頭から順に辿って目的のコンテナを探し出し、そこから読み出すのだと思われます。
ここで、描画関数を使った場合、既にリスト辿りが実行されて、目的のコンテナをフォーカスしているはずです。
そのタイミングでサイズ情報にアクセスすれば、一番無駄がなく高速な取得ができるでしょう。
しかし、問題のサイズ取得関数は、いったいどんなタイミングで呼び出されるのか?
まさか、リスト辿りを無駄にもう1回実行してはいないのか?
今日のPC性能であれば、それぐらいの無駄はどうという事はないと思います。
ただ、妙な無駄は省きたいという事です。
そして、無駄を抱えるのであれば、それがどれくらいの無駄なのか知っておきたいという事です。
特に、何千のアニメパターンを扱ったり、何万の弾幕を飛ばしたりする場合は、塵も積もったりはしないのか?
最後に、計測プログラムについて。
大量の弾幕を飛ばすものを2つ作り、60FPSの限界を調査しつつ、フレーム間のスリープ待ち時間を参照します。
一方のプログラムでは、毎フレームにて全弾のサイズを1つ1つ関数で取得し描画関数に使用します。
もう一方は、実はサイズはある規則に基づいた数列(本番ではあり得ない条件だが)で、取得関数を使わずに記述します。
この2つの比較で、実用上に差が出るのかどうかわかると思います。
Re: ハンドルからグラフィックのサイズを取得する
DXライブラリのリファレンスで
DrawRotaGraphなどを調べてみてください。
DrawRotaGraphなどを調べてみてください。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: ハンドルからグラフィックのサイズを取得する
> 従って描画の度に、キャラの本当の座標から、縦横サイズの半分の値を引いて指定する必要があります。
STGなら、そのほうが好都合でしょうがRPGとかなら足元の座標のほうが便利です。
なので、素のDirectXの座標管理から加工されていない方が状況により加工できるので便利だと私は思います。
なおDXライブラリの回転系の描画関数は特に指定しない場合は中心座標で描画できますので、veritasさんの目的にピッタリだと思いますよ。
>これが用意されていないのは、おそらくほとんどの開発者が32×32などと事前にサイズを限定し、取得を不要としているからでしょう。
私は逆に汎用性を重視した仕様だと思います。
リファレンスを全部見ずに結論付けるのは急ぎ過ぎではないでしょうか?
>そして、無駄を抱えるのであれば、それがどれくらいの無駄なのか知っておきたいという事です。
自分でサイズ構造体を持てば解決できる問題な気がします。
ライブラリに頼りすぎる必要は無いのではないでしょうか。
> 特に、何千のアニメパターンを扱ったり、何万の弾幕を飛ばしたりする場合は、塵も積もったりはしないのか?
何をやっても処理落ちするときはします。GPUで処理落ちする可能性も高いです。
全体的なパフォーマンスが大事ですので、ここだけに拘られるのが不思議だったのです。
STGなら、そのほうが好都合でしょうがRPGとかなら足元の座標のほうが便利です。
なので、素のDirectXの座標管理から加工されていない方が状況により加工できるので便利だと私は思います。
なおDXライブラリの回転系の描画関数は特に指定しない場合は中心座標で描画できますので、veritasさんの目的にピッタリだと思いますよ。
>これが用意されていないのは、おそらくほとんどの開発者が32×32などと事前にサイズを限定し、取得を不要としているからでしょう。
私は逆に汎用性を重視した仕様だと思います。
リファレンスを全部見ずに結論付けるのは急ぎ過ぎではないでしょうか?
>そして、無駄を抱えるのであれば、それがどれくらいの無駄なのか知っておきたいという事です。
自分でサイズ構造体を持てば解決できる問題な気がします。
ライブラリに頼りすぎる必要は無いのではないでしょうか。
> 特に、何千のアニメパターンを扱ったり、何万の弾幕を飛ばしたりする場合は、塵も積もったりはしないのか?
何をやっても処理落ちするときはします。GPUで処理落ちする可能性も高いです。
全体的なパフォーマンスが大事ですので、ここだけに拘られるのが不思議だったのです。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: ハンドルからグラフィックのサイズを取得する
実際にDXライブラリのソースを読んで書いたのだけども分からないか?Mana さんが書きました:DXライブラリのソースファイルをダウンロードしてGetGraphSizeからいらないコードを除いて使えばさらに高速かもしれないね。
GetGraphSizeはほぼ配列参照しているだけの、即出てくる、しかも高速な方法で実装されているように見えるけども。
リストを先頭から順に辿っているというのは勝手な想像だろ?
だいいちグラフィックハンドルを作った直後にサイズ取得してオフセット計算して変数に入れておけばいいだろうに。
弾幕の弾が何万発表示されようが一種類の弾につき読み込み直後の一回しか呼ばないGetGraphSizeのコストが問題になるのか?
ライブラリの基準がどこだろうが自分で決めた基準を使うのに何ら不都合はない。
グラフィックのサイズが描画するたびに変わったりはしないしな。
事前にサイズを限定し取得を不要としているってのも勝手な想像だな。
異なる画像サイズの混在した何千のアニメパターンを扱う場合は事前にオフセットを求めている。
そうでなければひとつひとつのパターンをどこに表示していいかわからない。
やはり基準位置を求めるのは事前に求めたオフセットをロードした直後の一回だけでいい。
DrawRotaGraphなどの中心座標を指定する関数は汎用だから内部でGetGraphSizeの実装をいちいち呼び出している。
そんなにこだわるならソースコード読め。
Re: ハンドルからグラフィックのサイズを取得する
・・・orzveritas さんが書きました:これが用意されていないのは、おそらくほとんどの開発者が32×32などと事前にサイズを限定し、取得を不要としているからでしょう。
こんなの、誰が納得するの?
・・・orzveritas さんが書きました:おそらくメモリ上のグラフィックは、リストのように連結されて格納されていると予測しています。
データにアクセスする際は、リスト先頭から順に辿って目的のコンテナを探し出し、そこから読み出すのだと思われます。
実際にDXLIBのソースを見ての発言か?
Manaさんの発言を見てないのか?
「おそらく」と使っている時点で自分勝手な想像を元に持論を展開しているのがバレバレです。
DXライブラリのダウンロードの下の方に「改造希望の方へ」とあり、そこにDXLIBのソースを含んだプロジェクト一式があるんですけどねえ。
どうせなら自分勝手な想像でなく、事実に基づいた持論を展開してください。
ふつう、速度が気になるなら、真っ先にソース解析をするものですけどねえ。
written by へにっくす
Re: ハンドルからグラフィックのサイズを取得する
質問者本人です。
皆様、たくさんのご意見をありがとうございます。
今回の質問の意図について、さらに説明いたします。
まず弾幕について。
自分が今企画している案は、弾丸1つ1つが進化・変形していくという、少し変わったものです。
巨大化したり、ひょろ長い姿になったり、その画像サイズは可変なのです。
1万個の弾幕があった場合、それぞれが別の姿へ多様に変容していく、その進化パターンの多彩さ、膨大さを売りにしたいと考えています。
このため、弾丸1つのサイズを1度だけ調べれば他も済むという状態ではないとう事は、ご理解いただけるでしょうか。
前にも書いた通り、あらかじめサイズを決めうちして共通化する事はほとんどできないのです。
また、メモリ上にグラフィックを読み込めば、サイズデータがそこにあるのだから、取得はそこから行うべきです。
サイズを別に保管させて2重管理しようという案ですが、自分も一度ならず考えましたが、パターンの膨大さを思い躊躇しております。
次にソースについて。
このライブラリはダイレクトXをカプセル化したものです。
そのソースでリスト検索を行っていないからと言って、大元のダイレクトXやもっと上のウィンドウズの内部で行われていないという保障はあるのでしょうか。
事はオブジェクト指向のインスタンスがメモリ上にどう格納されているのか、それにどうアクセスしているかという事です。
元々ウィンドウズはブラックボックスを含み、中で何が行われているのか不明な部分が多々あります。
結局、実際に速度試験をするのが一番確実だと思うのですが、いかがでしょうか。
画像回転関数について。
これの出力先指定が画像の中心である事は当初より存じております。
ご指摘の皆様、ありがとうございます。
ただ、新参の自分には、これが普通の画像出力と同等の高速性があるのかどうか不明でした。
やはり、速度試験をして確かめる事にしたいと思います。
最後に、自分が色々な事を「勝手に決め付けている」という事に関して。
先輩の皆様に不快な思いをさせているとしたら、大変申し訳ありません。
例えば自分が、「恐らく○○なのでしょう」と推測を書くと、なぜか勝手な断定をしていると受け取られるようです。
ただの可能性を提案しているだけなのですが、では、「恐らく」が御法度であるなら、どう切り出せば断定でなくなるのでしょうか。
「こういう可能性もあるから、実際に速度試験をしてみないとわからないのではないですか?」と言いたいだけなのですが…。
こちらの掲示板の慣習等に疎いもので、波風の立たない書き方を先輩の皆様方にご教授いただければ幸いです。
それと、自分は自分の持論を人に納得させようとは全く考えておりません。
自分にあるのはただの仮説で、そこへ自己主張や己の存在価値を織り込むつもりはありません。
むしろ自分の仮説とは逆に、サイズ取得関数が充分に高速であって欲しいと願っているくらいです。
その確認が取れれば、安心して関数を使えますから。
ただ、「たぶん高速だよ」と言われても確実な事は判りませんので、「断定はできないので、実際に測定しましょう」と言っているだけです…。
この点はご理解いただけるでしょうか…。
自分の文章の拙さゆえか、本当にご迷惑をおかけしております。
繰り返し、ご意見を下さった皆様にお礼申し上げます。
皆様、たくさんのご意見をありがとうございます。
今回の質問の意図について、さらに説明いたします。
まず弾幕について。
自分が今企画している案は、弾丸1つ1つが進化・変形していくという、少し変わったものです。
巨大化したり、ひょろ長い姿になったり、その画像サイズは可変なのです。
1万個の弾幕があった場合、それぞれが別の姿へ多様に変容していく、その進化パターンの多彩さ、膨大さを売りにしたいと考えています。
このため、弾丸1つのサイズを1度だけ調べれば他も済むという状態ではないとう事は、ご理解いただけるでしょうか。
前にも書いた通り、あらかじめサイズを決めうちして共通化する事はほとんどできないのです。
また、メモリ上にグラフィックを読み込めば、サイズデータがそこにあるのだから、取得はそこから行うべきです。
サイズを別に保管させて2重管理しようという案ですが、自分も一度ならず考えましたが、パターンの膨大さを思い躊躇しております。
次にソースについて。
このライブラリはダイレクトXをカプセル化したものです。
そのソースでリスト検索を行っていないからと言って、大元のダイレクトXやもっと上のウィンドウズの内部で行われていないという保障はあるのでしょうか。
事はオブジェクト指向のインスタンスがメモリ上にどう格納されているのか、それにどうアクセスしているかという事です。
元々ウィンドウズはブラックボックスを含み、中で何が行われているのか不明な部分が多々あります。
結局、実際に速度試験をするのが一番確実だと思うのですが、いかがでしょうか。
画像回転関数について。
これの出力先指定が画像の中心である事は当初より存じております。
ご指摘の皆様、ありがとうございます。
ただ、新参の自分には、これが普通の画像出力と同等の高速性があるのかどうか不明でした。
やはり、速度試験をして確かめる事にしたいと思います。
最後に、自分が色々な事を「勝手に決め付けている」という事に関して。
先輩の皆様に不快な思いをさせているとしたら、大変申し訳ありません。
例えば自分が、「恐らく○○なのでしょう」と推測を書くと、なぜか勝手な断定をしていると受け取られるようです。
ただの可能性を提案しているだけなのですが、では、「恐らく」が御法度であるなら、どう切り出せば断定でなくなるのでしょうか。
「こういう可能性もあるから、実際に速度試験をしてみないとわからないのではないですか?」と言いたいだけなのですが…。
こちらの掲示板の慣習等に疎いもので、波風の立たない書き方を先輩の皆様方にご教授いただければ幸いです。
それと、自分は自分の持論を人に納得させようとは全く考えておりません。
自分にあるのはただの仮説で、そこへ自己主張や己の存在価値を織り込むつもりはありません。
むしろ自分の仮説とは逆に、サイズ取得関数が充分に高速であって欲しいと願っているくらいです。
その確認が取れれば、安心して関数を使えますから。
ただ、「たぶん高速だよ」と言われても確実な事は判りませんので、「断定はできないので、実際に測定しましょう」と言っているだけです…。
この点はご理解いただけるでしょうか…。
自分の文章の拙さゆえか、本当にご迷惑をおかけしております。
繰り返し、ご意見を下さった皆様にお礼申し上げます。
Re: ハンドルからグラフィックのサイズを取得する
DXライブラリが管理しているのは元の画像のサイズです。veritas さんが書きました: 自分が今企画している案は、弾丸1つ1つが進化・変形していくという、少し変わったものです。
巨大化したり、ひょろ長い姿になったり、その画像サイズは可変なのです。
1万個の弾幕があった場合、それぞれが別の姿へ多様に変容していく、その進化パターンの多彩さ、膨大さを売りにしたいと考えています。
このため、弾丸1つのサイズを1度だけ調べれば他も済むという状態ではないとう事は、ご理解いただけるでしょうか。
前にも書いた通り、あらかじめサイズを決めうちして共通化する事はほとんどできないのです。
また、メモリ上にグラフィックを読み込めば、サイズデータがそこにあるのだから、取得はそこから行うべきです。
サイズを別に保管させて2重管理しようという案ですが、自分も一度ならず考えましたが、パターンの膨大さを思い躊躇しております。
変形後のサイズについてはプログラマーが管理する必要があります。
もしWindowsの内部でリスト管理されていたとして、それをどうするつもりですか?veritas さんが書きました: 次にソースについて。
このライブラリはダイレクトXをカプセル化したものです。
そのソースでリスト検索を行っていないからと言って、大元のダイレクトXやもっと上のウィンドウズの内部で行われていないという保障はあるのでしょうか。
事はオブジェクト指向のインスタンスがメモリ上にどう格納されているのか、それにどうアクセスしているかという事です。
元々ウィンドウズはブラックボックスを含み、中で何が行われているのか不明な部分が多々あります。
結局、実際に速度試験をするのが一番確実だと思うのですが、いかがでしょうか。
OSを書き換えるのでしょうか?
断定しているか否かではなくて、根拠のない仮説を前提にして話を進めているのが問題だと思います。veritas さんが書きました: 例えば自分が、「恐らく○○なのでしょう」と推測を書くと、なぜか勝手な断定をしていると受け取られるようです。
ただの可能性を提案しているだけなのですが、では、「恐らく」が御法度であるなら、どう切り出せば断定でなくなるのでしょうか。
「こういう可能性もあるから、実際に速度試験をしてみないとわからないのではないですか?」と言いたいだけなのですが…。
こちらの掲示板の慣習等に疎いもので、波風の立たない書き方を先輩の皆様方にご教授いただければ幸いです。
内部構造に関してあれこれ推測するなら、ちゃんとDXライブラリのコードを読んでからにしてください。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: ハンドルからグラフィックのサイズを取得する
>弾丸1つのサイズを1度だけ調べれば他も済むという状態ではないとう事は、ご理解いただけるでしょうか。
>前にも書いた通り、あらかじめサイズを決めうちして共通化する事はほとんどできないのです。
初期化の読み込み後に情報は溜め込めると思いますが、そこを否定されている理由が良く分かりません。
描画時に調べる必要はないとみなさんが書いているのですが、ずっとその情報だけスルーされていると思われます。
>サイズを別に保管させて2重管理しようという案ですが、自分も一度ならず考えましたが、パターンの膨大さを思い躊躇しております。
読み込み処理が汎用化されているならサイズの取得も汎用化出来ると思います。
> そのソースでリスト検索を行っていないからと言って、大元のダイレクトXやもっと上のウィンドウズの内部で行われていないという保障はあるのでしょうか。
それを言い出すと計測自体が成り立たないと思いますが? リスト構造の検索速度は単純ではないと理解されていますよね?
なので実測自体の信頼性が揺らぐ可能性があるという認識なら構いません。
※ ハッシュリストであるとか、もっと高度なことしている可能性はあります。
気になるのなら、そう言う部分はできるだけ排除しては? と言う意味で提案させて頂いています。
> 例えば自分が、「恐らく○○なのでしょう」と推測を書くと、なぜか勝手な断定をしていると受け取られるようです。
文章の問題なので、どこの掲示板でも変わらないと思いますし、ここの掲示板ルールが有る訳ではないですが、どこのプログラマーでも大体似た反応をすると思います。
プログラマーとして特性かもしれません。
【補足】
Manaさんも書いてますが、面倒な方向に突き進んでいるように見えるというのが私の見解です。
>前にも書いた通り、あらかじめサイズを決めうちして共通化する事はほとんどできないのです。
初期化の読み込み後に情報は溜め込めると思いますが、そこを否定されている理由が良く分かりません。
描画時に調べる必要はないとみなさんが書いているのですが、ずっとその情報だけスルーされていると思われます。
>サイズを別に保管させて2重管理しようという案ですが、自分も一度ならず考えましたが、パターンの膨大さを思い躊躇しております。
読み込み処理が汎用化されているならサイズの取得も汎用化出来ると思います。
> そのソースでリスト検索を行っていないからと言って、大元のダイレクトXやもっと上のウィンドウズの内部で行われていないという保障はあるのでしょうか。
それを言い出すと計測自体が成り立たないと思いますが? リスト構造の検索速度は単純ではないと理解されていますよね?
なので実測自体の信頼性が揺らぐ可能性があるという認識なら構いません。
※ ハッシュリストであるとか、もっと高度なことしている可能性はあります。
気になるのなら、そう言う部分はできるだけ排除しては? と言う意味で提案させて頂いています。
> 例えば自分が、「恐らく○○なのでしょう」と推測を書くと、なぜか勝手な断定をしていると受け取られるようです。
文章の問題なので、どこの掲示板でも変わらないと思いますし、ここの掲示板ルールが有る訳ではないですが、どこのプログラマーでも大体似た反応をすると思います。
プログラマーとして特性かもしれません。
【補足】
Manaさんも書いてますが、面倒な方向に突き進んでいるように見えるというのが私の見解です。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: ハンドルからグラフィックのサイズを取得する
どう考えても進化した直後にサイズを更新して憶えておくだけで良いと思えるが。
ウィンドウズプログラムで縦横のサイズを憶えておくint型ふたつでたかだか8バイトですよ。
画像がメモリを圧迫するほうが早くやってくるに決まってますよね。
画像がメモリを圧迫し始めたらどうするかというとね、画像を小さくして拡大表示したりするわけですよ。
画像サイズとか何かに依存してるとそういうピンチに対応できないわけですよ。
DirectXやウィンドウズがオブジェクト指向のインスタンス持ってるってのはどこ情報ですか?
DirectXのインターフェースはそう見えるかもしれませんけどね。
ウィンドウズが生まれたときはまだマイクロソフトのC++コンパイラがなかったんですよ?
インサイドウィンドウズって本知ってます?
そもそもDirectXやウィンドウズの中でやってることについてはどうしようもない。
いくら検証したところで変わらない部分だしGetGraphSizeの実装の話から逸脱してます。
こっちはveritasさんが将来どんなピンチに陥るかということも予想できるしそれを踏まえてアドバイスしているのですよ。
目先の解決だけで良いのならあらかじめそう書いてください。
こちらは回答する時間を無駄にしないで済みますから。
「おそらく」自体が御法度じゃないのですよ。
事実を確認できるのにそれをしないで「おそらく」を使うからですよ。
そう書いてあるでしょ?
それも分からないのですか?
ウィンドウズプログラムで縦横のサイズを憶えておくint型ふたつでたかだか8バイトですよ。
画像がメモリを圧迫するほうが早くやってくるに決まってますよね。
画像がメモリを圧迫し始めたらどうするかというとね、画像を小さくして拡大表示したりするわけですよ。
画像サイズとか何かに依存してるとそういうピンチに対応できないわけですよ。
DirectXやウィンドウズがオブジェクト指向のインスタンス持ってるってのはどこ情報ですか?
DirectXのインターフェースはそう見えるかもしれませんけどね。
ウィンドウズが生まれたときはまだマイクロソフトのC++コンパイラがなかったんですよ?
インサイドウィンドウズって本知ってます?
そもそもDirectXやウィンドウズの中でやってることについてはどうしようもない。
いくら検証したところで変わらない部分だしGetGraphSizeの実装の話から逸脱してます。
こっちはveritasさんが将来どんなピンチに陥るかということも予想できるしそれを踏まえてアドバイスしているのですよ。
目先の解決だけで良いのならあらかじめそう書いてください。
こちらは回答する時間を無駄にしないで済みますから。
「おそらく」自体が御法度じゃないのですよ。
事実を確認できるのにそれをしないで「おそらく」を使うからですよ。
そう書いてあるでしょ?
それも分からないのですか?
Re: ハンドルからグラフィックのサイズを取得する
質問の意図はもう語らなくていいです。
貴方は頭よすぎです。
考えることが多すぎて、結局は何も作れない典型的なパターンに陥ってます。
いいですか、速度劣化があるないは、まず作品がある程度完成してから考えることなのですよ。
それを作品を作りもしないうちから、高速劣化の無いものを求めるのがそもそもおかしいのです。(※)
まずは作って完成させなさい。
頭で考えるな。まずは作れ。
話はそれからです。
(編集2回目)文面を多少変更。
貴方は頭よすぎです。
考えることが多すぎて、結局は何も作れない典型的なパターンに陥ってます。
いいですか、速度劣化があるないは、まず作品がある程度完成してから考えることなのですよ。
それを作品を作りもしないうちから、高速劣化の無いものを求めるのがそもそもおかしいのです。(※)
まずは作って完成させなさい。
頭で考えるな。まずは作れ。
話はそれからです。
オフトピック
※自分が今企画している案は、という文面から作品の実装には入っていないとふみました
written by へにっくす
Re: ハンドルからグラフィックのサイズを取得する
質問者本人です。
変形について。
これは画像を関数によって変形させるという意味ではなく、キャラクターや敵機のグラフィックを根本から変えるという事です。
姿を変えた様々な進化形の絵を、最初からたくさん描いておくという事です。
ヘビ型になったり、翼を生やしたり、超小型のスピード系になったり、色々です。
それらの画像サイズは、実に多様であるという事です。
数千パターン用意し、さらに追加拡張や、ユーザー自作のグラフィックも使用可能にします。
この場合、メモリに読み込んだグラフィックからサイズを取得し一元管理する事が、単純で最適だと思われます。
わざわざ別に管理する必要があるのでしょうか。
ただ、そのスピードロスがどれくらいなのか、知っておきたかっただけです。
ウィンドウズ内部の処理について。
そこまで踏み込んでも、別になにもする気はありません。
ただ、どれくらいのスピードロスがあるのかを実測し、それを頭に入れておきたいというだけです。
速度検証プログラムが完成し、実測テストをしました。
本当は前回の書き込み時に既に完成していました。
しかし、計測結果が予想の斜め上を行き、にわかには信じがたいものだったので、暫く再検証していました。
最初は何かのミスではないかと考えていました。
1000個の画像ファイルを用意し(これが一番大変だったかも)、1000個の弾幕を描画し、秒間フレーム数を一定にさせた上で、空いた余裕時間を累計し、平均速度を算出しました。
結果、判明したのは、サイズ取得関数を使用した方が、0.52パーセント高速になるという事です。
これは、一時的にそうなったという事ではなく、暫く放っておくと、時おり乱れるものの、その数値で安定していくという事です。
速度が遅くなるか、同じであるなら理解できました。
ですが、逆に速くなるのは驚くべき事です。
数値を直接決めうちで指定したり、別テーブルに入れておいたものを参照するよりも、関数をわざわざ呼んだ方が速いという事です。
なぜこのような現象が発生するのか、自分なりに仮説は立てています。
しかし、それをここで書いても、また批判を受けるだけでしょう。
結果のみを報告し、この質問を解決といたします。
ところで、インサイドなんとかさんという本を読めば、この現象を予測したり説明したりできるのでしょうか。
自分としては、単に「速度低下はないと思うよ」ではなく、実際に測定試験をした事がある人が、ひょっこり出てきてくれる事を期待していたのですが…。
試験をした事がないのであれば、以降はスルーして下されば良く、無理にお時間を使っていただく必要はなかったのですが…。
貴重なゴールデンウィークを奪ってしまい、大変申し訳ありませんでした。
本当は、この現象が自分の環境だけのものか、それとも広く共通した性質なのか、追試験をする方が出てくれば、興味深い情報が得られると考えていました。
自分が意図し、ここで質問したのは、こういう実測に基づいた情報を得て、皆様と共有したいからです。
ソースを読む事は大切でしょうが、それだけでは得られない事もあるのではないでしょうか。
ですが、誰も興味を持っていないようですし、これ以上皆様に不快な思いをさせるわけにもいかず、ここで終了といたします。
それにしても皆さん、熱く議論をなされますね。
この掲示板は、常にこのような論戦調なのでしょうか。
自分は腰を低く、穏やかな紳士を貫いておりますが、たった一人に対し皆様の容赦ない包囲網、痛み入ります。
あと、自分の行く末については、心配ご無用です。
「実測をしなければわからないのでは?」と言う自分に対し、先輩方が総ツッコミをなさるので、そのレスを返していただけです。
自分自身は何一つ迷走しておらず、実測を完了して解決し、次の課題へ向かっております。
変形について。
これは画像を関数によって変形させるという意味ではなく、キャラクターや敵機のグラフィックを根本から変えるという事です。
姿を変えた様々な進化形の絵を、最初からたくさん描いておくという事です。
ヘビ型になったり、翼を生やしたり、超小型のスピード系になったり、色々です。
それらの画像サイズは、実に多様であるという事です。
数千パターン用意し、さらに追加拡張や、ユーザー自作のグラフィックも使用可能にします。
この場合、メモリに読み込んだグラフィックからサイズを取得し一元管理する事が、単純で最適だと思われます。
わざわざ別に管理する必要があるのでしょうか。
ただ、そのスピードロスがどれくらいなのか、知っておきたかっただけです。
ウィンドウズ内部の処理について。
そこまで踏み込んでも、別になにもする気はありません。
ただ、どれくらいのスピードロスがあるのかを実測し、それを頭に入れておきたいというだけです。
速度検証プログラムが完成し、実測テストをしました。
本当は前回の書き込み時に既に完成していました。
しかし、計測結果が予想の斜め上を行き、にわかには信じがたいものだったので、暫く再検証していました。
最初は何かのミスではないかと考えていました。
1000個の画像ファイルを用意し(これが一番大変だったかも)、1000個の弾幕を描画し、秒間フレーム数を一定にさせた上で、空いた余裕時間を累計し、平均速度を算出しました。
結果、判明したのは、サイズ取得関数を使用した方が、0.52パーセント高速になるという事です。
これは、一時的にそうなったという事ではなく、暫く放っておくと、時おり乱れるものの、その数値で安定していくという事です。
速度が遅くなるか、同じであるなら理解できました。
ですが、逆に速くなるのは驚くべき事です。
数値を直接決めうちで指定したり、別テーブルに入れておいたものを参照するよりも、関数をわざわざ呼んだ方が速いという事です。
なぜこのような現象が発生するのか、自分なりに仮説は立てています。
しかし、それをここで書いても、また批判を受けるだけでしょう。
結果のみを報告し、この質問を解決といたします。
ところで、インサイドなんとかさんという本を読めば、この現象を予測したり説明したりできるのでしょうか。
自分としては、単に「速度低下はないと思うよ」ではなく、実際に測定試験をした事がある人が、ひょっこり出てきてくれる事を期待していたのですが…。
試験をした事がないのであれば、以降はスルーして下されば良く、無理にお時間を使っていただく必要はなかったのですが…。
貴重なゴールデンウィークを奪ってしまい、大変申し訳ありませんでした。
本当は、この現象が自分の環境だけのものか、それとも広く共通した性質なのか、追試験をする方が出てくれば、興味深い情報が得られると考えていました。
自分が意図し、ここで質問したのは、こういう実測に基づいた情報を得て、皆様と共有したいからです。
ソースを読む事は大切でしょうが、それだけでは得られない事もあるのではないでしょうか。
ですが、誰も興味を持っていないようですし、これ以上皆様に不快な思いをさせるわけにもいかず、ここで終了といたします。
それにしても皆さん、熱く議論をなされますね。
この掲示板は、常にこのような論戦調なのでしょうか。
自分は腰を低く、穏やかな紳士を貫いておりますが、たった一人に対し皆様の容赦ない包囲網、痛み入ります。
あと、自分の行く末については、心配ご無用です。
「実測をしなければわからないのでは?」と言う自分に対し、先輩方が総ツッコミをなさるので、そのレスを返していただけです。
自分自身は何一つ迷走しておらず、実測を完了して解決し、次の課題へ向かっております。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: ハンドルからグラフィックのサイズを取得する
その速度検証コードを提示してもらわな限りは、「そうですね」とも「違うかもしれませんよ」とも何とも言えない状況だとご理解ください。
今までの話は全てveritasさんの世界での出来事をveritasさんと言うフィルターを通してレポートですので、こちらからは迷走しているのでは?としか見えないと言うことです。
客観視可能なものが提示されれば話も変わって来たと思います。
今までの話は全てveritasさんの世界での出来事をveritasさんと言うフィルターを通してレポートですので、こちらからは迷走しているのでは?としか見えないと言うことです。
客観視可能なものが提示されれば話も変わって来たと思います。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: ハンドルからグラフィックのサイズを取得する
何を驚くことがあるの?
GetGraphSizeの実装は十分に速いものだって最初から書いてんじゃん。
どうやってそれよりも速くするのかって話してたんじゃないの?
これだけ速度にこだわってるveritas氏の書いた検証用コードがGetGraphSizeの実装よりも遅いってことが証明されたってことでしょ?
それを仮説を立てるだけで済ませてしまうんだね。
我々の書くコードもどうせ同程度だろうと思われてるんだろうね。
できればどうやって遅くしてるのか教えて欲しいよ。
反面教師にするからさ。
プログラムで加工しようがファイルを読み込もうが初期化時に一回で済むってのの何が決め打ちなの?
完全に誤解してるね。
期化時に一回だとフレームごとにかかるコストはゼロなんだよ?
検証が必要なの?
サイズじゃなくてオフセット計算して変数に入れておけばいいだろうにって書いたんだけどな。
あとからうっかり「縦横のサイズを憶えておくint型ふたつでたかだか8バイト」って書いちゃったな。
そっちに流れちゃったか。
どのみち意図を読み取る気はなさそうだからどうでもいいか。
グラフィックとオフセットをセットで扱ってるふうに見えなくて設計からして無駄だらけなんじゃないかと思えるのだけどそれもveritas氏にとってはどうでもいいことですよね。
プログラマがシステム作っておいてデザイナがあとからデータあげるのがふつうなんだから決め打ちなんてするわけがないんだよな。
自分のアイデアが他の誰も思い付いてないものだとか思い込んじゃうやつはろくでもないよ。
GetGraphSizeの実装は十分に速いものだって最初から書いてんじゃん。
どうやってそれよりも速くするのかって話してたんじゃないの?
これだけ速度にこだわってるveritas氏の書いた検証用コードがGetGraphSizeの実装よりも遅いってことが証明されたってことでしょ?
それを仮説を立てるだけで済ませてしまうんだね。
我々の書くコードもどうせ同程度だろうと思われてるんだろうね。
できればどうやって遅くしてるのか教えて欲しいよ。
反面教師にするからさ。
プログラムで加工しようがファイルを読み込もうが初期化時に一回で済むってのの何が決め打ちなの?
完全に誤解してるね。
期化時に一回だとフレームごとにかかるコストはゼロなんだよ?
検証が必要なの?
サイズじゃなくてオフセット計算して変数に入れておけばいいだろうにって書いたんだけどな。
あとからうっかり「縦横のサイズを憶えておくint型ふたつでたかだか8バイト」って書いちゃったな。
そっちに流れちゃったか。
どのみち意図を読み取る気はなさそうだからどうでもいいか。
グラフィックとオフセットをセットで扱ってるふうに見えなくて設計からして無駄だらけなんじゃないかと思えるのだけどそれもveritas氏にとってはどうでもいいことですよね。
プログラマがシステム作っておいてデザイナがあとからデータあげるのがふつうなんだから決め打ちなんてするわけがないんだよな。
自分のアイデアが他の誰も思い付いてないものだとか思い込んじゃうやつはろくでもないよ。
Re: ハンドルからグラフィックのサイズを取得する
C言語歴2週間の自分はこんな程度です。
先輩の皆様はぜひ、もっと優れたプログラムを組んで検証していただきたい。
というか、皆様はこれよりずっと上等なものを10分程度で作ってしまうのではないでしょうか。
60; //設定したFPS の部分は環境に応じて書き換える。
画像はa0000.PNGより、100枚ずつ、img000フォルダに入れ、フォルダ数を増やしていく。
面倒なら全て同じサイズの画像にする。
長くなるのでこのコードでは固定サイズにしてある。
「//●サイズ取得方法」 の部分参照。
この付近を書き換えて、サイズ取得方法を切り替え、それぞれ実行。
fpsと、mSleepSum が表示される。
後者が余裕時間の累積であり、実質的な速度。
表示が安定していくまで待つ。
例えば自分の古いノートの場合、以下の付近で安定した。
6144 関数取得の場合
6112 サイズ決めうち(直接指定)の場合
先輩の皆様はぜひ、もっと優れたプログラムを組んで検証していただきたい。
というか、皆様はこれよりずっと上等なものを10分程度で作ってしまうのではないでしょうか。
60; //設定したFPS の部分は環境に応じて書き換える。
画像はa0000.PNGより、100枚ずつ、img000フォルダに入れ、フォルダ数を増やしていく。
面倒なら全て同じサイズの画像にする。
長くなるのでこのコードでは固定サイズにしてある。
「//●サイズ取得方法」 の部分参照。
この付近を書き換えて、サイズ取得方法を切り替え、それぞれ実行。
fpsと、mSleepSum が表示される。
後者が余裕時間の累積であり、実質的な速度。
表示が安定していくまで待つ。
例えば自分の古いノートの場合、以下の付近で安定した。
6144 関数取得の場合
6112 サイズ決めうち(直接指定)の場合
#include "DxLib.h"
#include <math.h>
class Fps{
int mStartTime; //測定開始時刻
int mCount; //カウンタ
int mWaitTime; //1回の待ち時間
int mWaitTimeSum; //待ち時間の累積
int mSleepSum; //平均を取る間待った時間
float mFps; //fps
static const int N = 300; //600; //平均を取るサンプル数
static const int FPS = 30; //60; //設定したFPS
public:
Fps(){
mStartTime = 0;
mCount = 0;
mWaitTime = 0;
mFps = 0;
mWaitTime = 0;
mWaitTimeSum = 0;
mSleepSum = 0;
}
bool Update(){
if( mCount == 0 ){ //1フレーム目なら時刻を記憶
mStartTime = GetNowCount();
}
if( mCount == N ){ //一定フレーム目なら平均を計算する
int t = GetNowCount();
mFps = 1000.f/((t-mStartTime)/(float)N);
mCount = 0;
mStartTime = t;
mSleepSum = mWaitTimeSum;
mWaitTimeSum = 0;
}
mCount++;
mWaitTimeSum = mWaitTimeSum + mWaitTime;
return true;
}
void Draw(){
DrawFormatString(50, 300 - 32, GetColor(255,255,255), "%.1f", mFps);
DrawFormatString(50, 300 + 32, GetColor(255,255,255), "%d", mSleepSum);
}
void Wait(){
int tookTime = GetNowCount() - mStartTime; //かかった時間
mWaitTime = mCount*1000/FPS - tookTime; //待つべき時間
if( mWaitTime > 0 ){
Sleep(mWaitTime); //待機
}
}
};
int WINAPI WinMain(HINSTANCE,HINSTANCE,LPSTR,int){
int gmWidth = 1290;
int gmHeight = 600;
SetGraphMode( gmWidth , gmHeight , 32 );
ChangeWindowMode(TRUE), DxLib_Init(), SetDrawScreen( DX_SCREEN_BACK ); //ウィンドウモード変更と初期化と裏画面設定
int GX , GY; // 画像サイズ
int FoldMax = 10; //フォルダ数
int NumMax = 100 * FoldMax; //100 * FoldMax 繰り返し最大数
int ax[ 5000 ] , ay[ 5000 ] , aax[ 5000 ] , aay[ 5000 ]; // 画像位置保存 移動方向
int Handle[ 5000 ]; // 画像格納用ハンドル
for(int j = 0; j < FoldMax; j++){
for(int i = 0; i < 100; i++){
char FileName[64];
sprintf_s(FileName , 64, "img%03d/a%04d.PNG", j , i );
Handle[ i + 100 * j ] = LoadGraph( FileName ); // 画像のロード
ax[ i + 100 * j ] = GetRand( gmWidth );
ay[ i + 100 * j ] = GetRand( gmHeight );
aax[ i + 100 * j ] = GetRand( 2 ) * 2 -1;
aay[ i + 100 * j ] = GetRand( 2 ) * 2 -1;
}
}
Fps fps; // クラス使用開始
// while( 裏画面を表画面に反映, メッセージ処理)
while( ProcessMessage()==0 && ClearDrawScreen()==0 ){
for(int i = 0; i <NumMax; i++){
// ●サイズ取得方法
//GX = 163; GY = 163;
GetGraphSize( Handle[ i ] , &GX , &GY ); // サイズを得る
// ●描画方法
DrawGraph( ax[ i ] - GX / 2 , ay[ i ] - GY / 2 , Handle[ i ] , TRUE );
//DrawRotaGraph( ax[ i ] , ay[ i ] , 1.0 , 0.0 , Handle[ i ] , TRUE, FALSE);
ax[ i ] = ax[ i ] + aax[ i ] ;
if (ax[ i ] <= 0) {
aax [ i ] = 1;
}
if (ax[ i ] >= gmWidth - 1) {
aax [ i ] = -1;
}
ay[ i ] = ay[ i ] + aay[ i ] ;
if (ay[ i ] <= 0) {
aay [ i ] = 1;
}
if (ay[ i ] >= gmHeight - 1) {
aay [ i ] = -1;
}
}
fps.Update(); //更新
fps.Draw(); //描画
ScreenFlip();
fps.Wait(); //待機
}
DxLib_End(); // DXライブラリ終了処理
return 0;
}
Re: ハンドルからグラフィックのサイズを取得する
コードの投稿がうまくいかないので再度
#include "DxLib.h"
#include <math.h>
class Fps{
int mStartTime; //測定開始時刻
int mCount; //カウンタ
int mWaitTime; //1回の待ち時間
int mWaitTimeSum; //待ち時間の累積
int mSleepSum; //平均を取る間待った時間
float mFps; //fps
static const int N = 300; //600; //平均を取るサンプル数
static const int FPS = 30; //60; //設定したFPS
public:
Fps(){
mStartTime = 0;
mCount = 0;
mWaitTime = 0;
mFps = 0;
mWaitTime = 0;
mWaitTimeSum = 0;
mSleepSum = 0;
}
bool Update(){
if( mCount == 0 ){ //1フレーム目なら時刻を記憶
mStartTime = GetNowCount();
}
if( mCount == N ){ //一定フレーム目なら平均を計算する
int t = GetNowCount();
mFps = 1000.f/((t-mStartTime)/(float)N);
mCount = 0;
mStartTime = t;
mSleepSum = mWaitTimeSum;
mWaitTimeSum = 0;
}
mCount++;
mWaitTimeSum = mWaitTimeSum + mWaitTime;
return true;
}
void Draw(){
DrawFormatString(50, 300 - 32, GetColor(255,255,255), "%.1f", mFps);
DrawFormatString(50, 300 + 32, GetColor(255,255,255), "%d", mSleepSum);
}
void Wait(){
int tookTime = GetNowCount() - mStartTime; //かかった時間
mWaitTime = mCount*1000/FPS - tookTime; //待つべき時間
if( mWaitTime > 0 ){
Sleep(mWaitTime); //待機
}
}
};
int WINAPI WinMain(HINSTANCE,HINSTANCE,LPSTR,int){
int gmWidth = 1290;
int gmHeight = 600;
SetGraphMode( gmWidth , gmHeight , 32 );
ChangeWindowMode(TRUE), DxLib_Init(), SetDrawScreen( DX_SCREEN_BACK ); //ウィンドウモード変更と初期化と裏画面設定
int GX , GY; // 画像サイズ
int FoldMax = 10; //フォルダ数
int NumMax = 100 * FoldMax; //100 * FoldMax 繰り返し最大数
int ax[ 5000 ] , ay[ 5000 ] , aax[ 5000 ] , aay[ 5000 ]; // 画像位置保存 移動方向
int Handle[ 5000 ]; // 画像格納用ハンドル
for(int j = 0; j < FoldMax; j++){
for(int i = 0; i < 100; i++){
char FileName[64];
sprintf_s(FileName , 64, "img%03d/a%04d.PNG", j , i );
Handle[ i + 100 * j ] = LoadGraph( FileName ); // 画像のロード
ax[ i + 100 * j ] = GetRand( gmWidth );
ay[ i + 100 * j ] = GetRand( gmHeight );
aax[ i + 100 * j ] = GetRand( 2 ) * 2 -1;
aay[ i + 100 * j ] = GetRand( 2 ) * 2 -1;
}
}
Fps fps; // クラス使用開始
// while( 裏画面を表画面に反映, メッセージ処理)
while( ProcessMessage()==0 && ClearDrawScreen()==0 ){
for(int i = 0; i <NumMax; i++){
// ●サイズ取得方法
//GX = 163; GY = 163;
GetGraphSize( Handle[ i ] , &GX , &GY ); // サイズを得る
// ●描画方法
DrawGraph( ax[ i ] - GX / 2 , ay[ i ] - GY / 2 , Handle[ i ] , TRUE );
//DrawRotaGraph( ax[ i ] , ay[ i ] , 1.0 , 0.0 , Handle[ i ] , TRUE, FALSE);
ax[ i ] = ax[ i ] + aax[ i ] ;
if (ax[ i ] <= 0) {
aax [ i ] = 1;
}
if (ax[ i ] >= gmWidth - 1) {
aax [ i ] = -1;
}
ay[ i ] = ay[ i ] + aay[ i ] ;
if (ay[ i ] <= 0) {
aay [ i ] = 1;
}
if (ay[ i ] >= gmHeight - 1) {
aay [ i ] = -1;
}
}
fps.Update(); //更新
fps.Draw(); //描画
ScreenFlip();
fps.Wait(); //待機
}
DxLib_End(); // DXライブラリ終了処理
return 0;
}
Re: ハンドルからグラフィックのサイズを取得する
何度やっても貼り付けに失敗するのでタグを使用しないで再度
#include "DxLib.h"
#include <math.h>
class Fps{
int mStartTime; //測定開始時刻
int mCount; //カウンタ
int mWaitTime; //1回の待ち時間
int mWaitTimeSum; //待ち時間の累積
int mSleepSum; //平均を取る間待った時間
float mFps; //fps
static const int N = 300; //600; //平均を取るサンプル数
static const int FPS = 30; //60; //設定したFPS
public:
Fps(){
mStartTime = 0;
mCount = 0;
mWaitTime = 0;
mFps = 0;
mWaitTime = 0;
mWaitTimeSum = 0;
mSleepSum = 0;
}
bool Update(){
if( mCount == 0 ){ //1フレーム目なら時刻を記憶
mStartTime = GetNowCount();
}
if( mCount == N ){ //一定フレーム目なら平均を計算する
int t = GetNowCount();
mFps = 1000.f/((t-mStartTime)/(float)N);
mCount = 0;
mStartTime = t;
mSleepSum = mWaitTimeSum;
mWaitTimeSum = 0;
}
mCount++;
mWaitTimeSum = mWaitTimeSum + mWaitTime;
return true;
}
void Draw(){
DrawFormatString(50, 300 - 32, GetColor(255,255,255), "%.1f", mFps);
DrawFormatString(50, 300 + 32, GetColor(255,255,255), "%d", mSleepSum);
}
void Wait(){
int tookTime = GetNowCount() - mStartTime; //かかった時間
mWaitTime = mCount*1000/FPS - tookTime; //待つべき時間
if( mWaitTime > 0 ){
Sleep(mWaitTime); //待機
}
}
};
int WINAPI WinMain(HINSTANCE,HINSTANCE,LPSTR,int){
int gmWidth = 1290;
int gmHeight = 600;
SetGraphMode( gmWidth , gmHeight , 32 );
ChangeWindowMode(TRUE), DxLib_Init(), SetDrawScreen( DX_SCREEN_BACK ); //ウィンドウモード変更と初期化と裏画面設定
int GX , GY; // 画像サイズ
int FoldMax = 10; //フォルダ数
int NumMax = 100 * FoldMax; //100 * FoldMax 繰り返し最大数
int ax[ 5000 ] , ay[ 5000 ] , aax[ 5000 ] , aay[ 5000 ]; // 画像位置保存 移動方向
int Handle[ 5000 ]; // 画像格納用ハンドル
for(int j = 0; j < FoldMax; j++){
for(int i = 0; i < 100; i++){
char FileName[64];
sprintf_s(FileName , 64, "img%03d/a%04d.PNG", j , i );
Handle[ i + 100 * j ] = LoadGraph( FileName ); // 画像のロード
ax[ i + 100 * j ] = GetRand( gmWidth );
ay[ i + 100 * j ] = GetRand( gmHeight );
aax[ i + 100 * j ] = GetRand( 2 ) * 2 -1;
aay[ i + 100 * j ] = GetRand( 2 ) * 2 -1;
}
}
Fps fps; // クラス使用開始
// while( 裏画面を表画面に反映, メッセージ処理)
while( ProcessMessage()==0 && ClearDrawScreen()==0 ){
for(int i = 0; i <NumMax; i++){
// ●サイズ取得方法
//GX = 163; GY = 163;
GetGraphSize( Handle[ i ] , &GX , &GY ); // サイズを得る
// ●描画方法
DrawGraph( ax[ i ] - GX / 2 , ay[ i ] - GY / 2 , Handle[ i ] , TRUE );
//DrawRotaGraph( ax[ i ] , ay[ i ] , 1.0 , 0.0 , Handle[ i ] , TRUE, FALSE);
ax[ i ] = ax[ i ] + aax[ i ] ;
if (ax[ i ] <= 0) {
aax [ i ] = 1;
}
if (ax[ i ] >= gmWidth - 1) {
aax [ i ] = -1;
}
ay[ i ] = ay[ i ] + aay[ i ] ;
if (ay[ i ] <= 0) {
aay [ i ] = 1;
}
if (ay[ i ] >= gmHeight - 1) {
aay [ i ] = -1;
}
}
fps.Update(); //更新
fps.Draw(); //描画
ScreenFlip();
fps.Wait(); //待機
}
DxLib_End(); // DXライブラリ終了処理
return 0;
}
#include "DxLib.h"
#include <math.h>
class Fps{
int mStartTime; //測定開始時刻
int mCount; //カウンタ
int mWaitTime; //1回の待ち時間
int mWaitTimeSum; //待ち時間の累積
int mSleepSum; //平均を取る間待った時間
float mFps; //fps
static const int N = 300; //600; //平均を取るサンプル数
static const int FPS = 30; //60; //設定したFPS
public:
Fps(){
mStartTime = 0;
mCount = 0;
mWaitTime = 0;
mFps = 0;
mWaitTime = 0;
mWaitTimeSum = 0;
mSleepSum = 0;
}
bool Update(){
if( mCount == 0 ){ //1フレーム目なら時刻を記憶
mStartTime = GetNowCount();
}
if( mCount == N ){ //一定フレーム目なら平均を計算する
int t = GetNowCount();
mFps = 1000.f/((t-mStartTime)/(float)N);
mCount = 0;
mStartTime = t;
mSleepSum = mWaitTimeSum;
mWaitTimeSum = 0;
}
mCount++;
mWaitTimeSum = mWaitTimeSum + mWaitTime;
return true;
}
void Draw(){
DrawFormatString(50, 300 - 32, GetColor(255,255,255), "%.1f", mFps);
DrawFormatString(50, 300 + 32, GetColor(255,255,255), "%d", mSleepSum);
}
void Wait(){
int tookTime = GetNowCount() - mStartTime; //かかった時間
mWaitTime = mCount*1000/FPS - tookTime; //待つべき時間
if( mWaitTime > 0 ){
Sleep(mWaitTime); //待機
}
}
};
int WINAPI WinMain(HINSTANCE,HINSTANCE,LPSTR,int){
int gmWidth = 1290;
int gmHeight = 600;
SetGraphMode( gmWidth , gmHeight , 32 );
ChangeWindowMode(TRUE), DxLib_Init(), SetDrawScreen( DX_SCREEN_BACK ); //ウィンドウモード変更と初期化と裏画面設定
int GX , GY; // 画像サイズ
int FoldMax = 10; //フォルダ数
int NumMax = 100 * FoldMax; //100 * FoldMax 繰り返し最大数
int ax[ 5000 ] , ay[ 5000 ] , aax[ 5000 ] , aay[ 5000 ]; // 画像位置保存 移動方向
int Handle[ 5000 ]; // 画像格納用ハンドル
for(int j = 0; j < FoldMax; j++){
for(int i = 0; i < 100; i++){
char FileName[64];
sprintf_s(FileName , 64, "img%03d/a%04d.PNG", j , i );
Handle[ i + 100 * j ] = LoadGraph( FileName ); // 画像のロード
ax[ i + 100 * j ] = GetRand( gmWidth );
ay[ i + 100 * j ] = GetRand( gmHeight );
aax[ i + 100 * j ] = GetRand( 2 ) * 2 -1;
aay[ i + 100 * j ] = GetRand( 2 ) * 2 -1;
}
}
Fps fps; // クラス使用開始
// while( 裏画面を表画面に反映, メッセージ処理)
while( ProcessMessage()==0 && ClearDrawScreen()==0 ){
for(int i = 0; i <NumMax; i++){
// ●サイズ取得方法
//GX = 163; GY = 163;
GetGraphSize( Handle[ i ] , &GX , &GY ); // サイズを得る
// ●描画方法
DrawGraph( ax[ i ] - GX / 2 , ay[ i ] - GY / 2 , Handle[ i ] , TRUE );
//DrawRotaGraph( ax[ i ] , ay[ i ] , 1.0 , 0.0 , Handle[ i ] , TRUE, FALSE);
ax[ i ] = ax[ i ] + aax[ i ] ;
if (ax[ i ] <= 0) {
aax [ i ] = 1;
}
if (ax[ i ] >= gmWidth - 1) {
aax [ i ] = -1;
}
ay[ i ] = ay[ i ] + aay[ i ] ;
if (ay[ i ] <= 0) {
aay [ i ] = 1;
}
if (ay[ i ] >= gmHeight - 1) {
aay [ i ] = -1;
}
}
fps.Update(); //更新
fps.Draw(); //描画
ScreenFlip();
fps.Wait(); //待機
}
DxLib_End(); // DXライブラリ終了処理
return 0;
}
Re: ハンドルからグラフィックのサイズを取得する
コードの投稿はしましたが、行そろえがおかしくなっています。
まぁ、内容は伝わるだろうから、これで代用とさせていただきます。
どうやら自分がここに来る度に、先輩方は敵意をむき出しにして、集団で襲い掛かってこられるようですね。
右も左もわからない新米に、見事な歓迎振りで、感服します。
その集団暴行を、副管理人と名乗るお方が放任、いやむしろ加担しているのは大したものです。
それがこの掲示板のやりかたなのであれば、自分にも友人や交流の場は選ぶ権利があります。
今回で本当の最後の投稿とさせていただき、以後、2度と来ない事にします。
コードを新米に要求するのもおかしな話ですね。
皆様が言う程の猛者ならば、もっと優れた検証プログラムをさっと作って実証すればいいだけの話です。
検証をC++開始2週間の新入りにまかせきりで、出来上がったら差し出せと。
口先だけで何も作らないだろうと仰っていた名人様もおられますが、何もしないのはどちら様なのでしょう。
自分はそのような達人様を見習うつもりはなく、こちらから絶縁させていただきます。
最後に、自分が作っているのはシューティングではありません。
非常に特殊な処理を行うのを、短い文章で可能な限り理解しやすくするために、進化やユーザーエディットの例え話を使ったまでです。
本当のジャンルを書いて、本当の処理内容を書けば、もっと理解されないでしょう。
というか、もう理解されないでいいです。
それでは皆様、ごきげんよう。
まぁ、内容は伝わるだろうから、これで代用とさせていただきます。
どうやら自分がここに来る度に、先輩方は敵意をむき出しにして、集団で襲い掛かってこられるようですね。
右も左もわからない新米に、見事な歓迎振りで、感服します。
その集団暴行を、副管理人と名乗るお方が放任、いやむしろ加担しているのは大したものです。
それがこの掲示板のやりかたなのであれば、自分にも友人や交流の場は選ぶ権利があります。
今回で本当の最後の投稿とさせていただき、以後、2度と来ない事にします。
コードを新米に要求するのもおかしな話ですね。
皆様が言う程の猛者ならば、もっと優れた検証プログラムをさっと作って実証すればいいだけの話です。
検証をC++開始2週間の新入りにまかせきりで、出来上がったら差し出せと。
口先だけで何も作らないだろうと仰っていた名人様もおられますが、何もしないのはどちら様なのでしょう。
自分はそのような達人様を見習うつもりはなく、こちらから絶縁させていただきます。
最後に、自分が作っているのはシューティングではありません。
非常に特殊な処理を行うのを、短い文章で可能な限り理解しやすくするために、進化やユーザーエディットの例え話を使ったまでです。
本当のジャンルを書いて、本当の処理内容を書けば、もっと理解されないでしょう。
というか、もう理解されないでいいです。
それでは皆様、ごきげんよう。
Re: ハンドルからグラフィックのサイズを取得する
もうこないそうなので見ないのでしょうけれど。
ここにいる人たちは管理人さんも含め学校の先生という扱いではないので
わざわざコードを作ってまで書き込みたがる人がいないのは当然ですよ。
なにせ質問掲示板ですから。
そもそも、コード云々に関しては質問者さんが検証したとおっしゃったからそのコードを見せてほしいとなったのだと思いますよ。
出来上がったらよこせという流れでは無いと思うのです。
ここにいる人たちは管理人さんも含め学校の先生という扱いではないので
わざわざコードを作ってまで書き込みたがる人がいないのは当然ですよ。
なにせ質問掲示板ですから。
そもそも、コード云々に関しては質問者さんが検証したとおっしゃったからそのコードを見せてほしいとなったのだと思いますよ。
出来上がったらよこせという流れでは無いと思うのです。
オフトピック
回答者様の方々へ
一応フォーラムルールに敬語でお願いします。とありますし、気をつけていきましょ?
伝わりにくい環境でヒートアップしそうになるのはとても理解できますけれど・・・
一応フォーラムルールに敬語でお願いします。とありますし、気をつけていきましょ?
伝わりにくい環境でヒートアップしそうになるのはとても理解できますけれど・・・
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: ハンドルからグラフィックのサイズを取得する
Manaさんは言葉遣いを丁寧にお願いします。
veritasさんには、うまく伝わらなかったので申し訳ないです。
veritasさんが何を考えているかわからない以上は、veritasさんにコードを書いてもらうしかありません。
基本的に質問者がコードを用意しないと進まないと思ってください。
コードは後ほど確認させていただきます。
【補足】
投稿内容を見なおしたところ,C言語を初めて2週間とのこと。
ただ、ここまでコードが書けているならプログラム歴が2週間とは思えませんが、もし本当にプログラム歴も2週間なら脅威の熟達度だと思います。
話の印象から、何年もプログラムをしていて強固な思い込みをされている方だという印象で私は返答をしておりました。
違っていたなら申し訳ありません。
veritasさんには、うまく伝わらなかったので申し訳ないです。
veritasさんが何を考えているかわからない以上は、veritasさんにコードを書いてもらうしかありません。
基本的に質問者がコードを用意しないと進まないと思ってください。
コードは後ほど確認させていただきます。
【補足】
投稿内容を見なおしたところ,C言語を初めて2週間とのこと。
ただ、ここまでコードが書けているならプログラム歴が2週間とは思えませんが、もし本当にプログラム歴も2週間なら脅威の熟達度だと思います。
話の印象から、何年もプログラムをしていて強固な思い込みをされている方だという印象で私は返答をしておりました。
違っていたなら申し訳ありません。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: ハンドルからグラフィックのサイズを取得する
[youtube][/youtube]
私にはこの動画のようなことをやろうとしているようにしか読めなかったのですが。
動画では弾の画像に関するパラメータをランダムで変化させ、
パラメータに対応する画像をDrawRotaGraphで描画しています。
シューティングではないのに弾丸や弾幕なんて言葉を使った理由がわかりません。
ヘビ型、翼(鳥?)、超小型のスピード系(虫?)から
シムアースみたいな生態系シミュレーションの作成中だったんでしょうか?
「自分は腰を低く、穏やかな紳士を貫いております」
と書いていますが慇懃無礼って言葉を知っていますか?
DXライブラリそのものへの疑問は
DXライブラリ置き場にある掲示板を使うといいでしょう。
私にはこの動画のようなことをやろうとしているようにしか読めなかったのですが。
動画では弾の画像に関するパラメータをランダムで変化させ、
パラメータに対応する画像をDrawRotaGraphで描画しています。
シューティングではないのに弾丸や弾幕なんて言葉を使った理由がわかりません。
ヘビ型、翼(鳥?)、超小型のスピード系(虫?)から
シムアースみたいな生態系シミュレーションの作成中だったんでしょうか?
「自分は腰を低く、穏やかな紳士を貫いております」
と書いていますが慇懃無礼って言葉を知っていますか?
DXライブラリそのものへの疑問は
DXライブラリ置き場にある掲示板を使うといいでしょう。
Re: ハンドルからグラフィックのサイズを取得する
こちらもジャンルに関係なく応用できることを書いているのに読み取る気がないから読み取れないのでしょうね。
シューティングじゃなかったらどうだというのでしょうか。
シューティングはシューティング専門にプログラムを作っているとでも思っているのでしょうか。
そういうのを決め付けと言うのですが。
同じことを何回繰り返すつもりなのでしょうか。
非常に特殊な処理ってのは新しいギャグですか?
最低このくらいやってくれないと検証する価値もないと思いますけども。
他の環境ではどうだか分かりませんがこちらでは不思議な数値の混じったおもしろい結果が出ました。
この結果について議論したら有意義なのではないでしょうかね。
画像ファイルは不要です。
シューティングじゃなかったらどうだというのでしょうか。
シューティングはシューティング専門にプログラムを作っているとでも思っているのでしょうか。
そういうのを決め付けと言うのですが。
同じことを何回繰り返すつもりなのでしょうか。
非常に特殊な処理ってのは新しいギャグですか?
最低このくらいやってくれないと検証する価値もないと思いますけども。
他の環境ではどうだか分かりませんがこちらでは不思議な数値の混じったおもしろい結果が出ました。
この結果について議論したら有意義なのではないでしょうかね。
画像ファイルは不要です。
► スポイラーを表示
Re: ハンドルからグラフィックのサイズを取得する
横から突っ込む形になって申し訳ないです。
回答者さんは皆、あなたがとてもできる方だと思って今まで答えていたに違いありません。
なにせご自分で計測用プログラムを作るとおっしゃっていますし。
ですが、それは同様にあなたが回答者さんの回答について触れなかったことが要因の一つではないでしょうか?
答えてあげているのに無視されているように感じてしまいます。
また結局どれが質問なのか分かりづらくなっています。
速度を早くする方法→変数を用意して代入すれば?→○○みたいに即出てくる方法があると思った→なぜそう思った?→説明→説明→…
この間に多数の回答がありました。参考になられたでしょうか?
あなたはコードを挙げたときに初めてC言語歴2週間だと公表しました。veritas さんが書きました:コードを新米に要求するのもおかしな話ですね。
回答者さんは皆、あなたがとてもできる方だと思って今まで答えていたに違いありません。
なにせご自分で計測用プログラムを作るとおっしゃっていますし。
あなたが回答者さんの回答についてほとんど触れずに話を進めているためです。veritas さんが書きました:どうやら自分がここに来る度に、先輩方は敵意をむき出しにして、集団で襲い掛かってこられるようですね。
確かに、文面からして挑発的なものもあります。これはまずい。veritas さんが書きました:口先だけで何も作らないだろうと仰っていた名人様もおられますが、何もしないのはどちら様なのでしょう。
ですが、それは同様にあなたが回答者さんの回答について触れなかったことが要因の一つではないでしょうか?
答えてあげているのに無視されているように感じてしまいます。
また結局どれが質問なのか分かりづらくなっています。
速度を早くする方法→変数を用意して代入すれば?→○○みたいに即出てくる方法があると思った→なぜそう思った?→説明→説明→…
この間に多数の回答がありました。参考になられたでしょうか?
結果的にsoftyaさんのおっしゃる通りになってしまいます。softya(ソフト屋) さんが書きました:veritasさんが何を考えているかわからない以上は、veritasさんにコードを書いてもらうしかありません。
Dango San