| Re: SetChangeScreenModeGraphicsSystemResetFlagについて ( No.1 ) |
- 名前：管理人 日時：2024/07/26 03:05
> その必要性がない方が色々と便利そうですが、本来は、何か根本的にグラフィックハンドルを再作成する必要性があったり、
> 再作成した方が良い理由などはあるのでしょうか？
あまりリファレンスなどでは言及されていませんが、グラフィックハンドルは SetGraphMode で指定されたカラービット数の
画像フォーマットで作成されますので、例えば SetChangeScreenModeGraphicsSystemResetFlag( FALSE ); で
グラフィックハンドルをリセットしない設定を使用した場合で、
起動時には SetGraphMode( 1280, 720, 16 ); と 16bitカラーで動作させた状態で LoadGraph などで画像を読み込み、
その後 SetGraphMode( 1280, 720, 32 ); で 32bitカラーに変更した場合は
画面は 32bitカラーになりますが、グラフィックハンドルの画像は 16bitカラーのままとなります
対して、デフォルトの SetChangeScreenModeGraphicsSystemResetFlag( TRUE ); の場合は画面切り替え時に
グラフィックハンドルは全て削除されてしまうので改めて LoadGraph などで読み込まれることとなり、
そのグラフィックハンドルは 32bitカラーになるので前述のような問題は発生しません
とはいえ、今どき 16bitカラーを使用するということはほぼ無いので、上記の問題は実際には気にすることは無いのですが…
また、SetChangeScreenModeGraphicsSystemResetFlag は後から追加したものの他の関数に比べてあまりテストが
できていないので、あまり大きく紹介し辛いというのもあります
などなど、上記のような理由で『なんとなく積極的に前面に出す気になれない関数』なので今のような状況になっています (・・;
|
| Re: SetChangeScreenModeGraphicsSystemResetFlagについて ( No.2 ) |
- 名前：Saucer 日時：2024/07/29 08:22
管理人様、いつもいつもご丁寧に解説くださり、本当に有難うございます！
なるほど、割と複雑なんですね…
そのカラービット数の食い違いは、深刻なエラーが発生しうるのでしょうか？
例えば画面が32bitで画像が16bit、あるいはその逆の場合、画像が描画
されなくなったりするのでしょうか？
でも仰る通り、やはり16bitを使用する必要性は今時あまり無いのなら、
もっと気軽にグラフィックの設定をアプリ内でユーザー(プレイヤー)側から
変えられる機能の実装を色々と試したいと思います！
…でも、今でも16bitの対応が必要と想定すべき環境というのは、何か
あったりしますかね？
また、通常のSetChangeScreenModeGraphicsSystemResetFlag( TRUE );
であり、グラフィックを再度読み込む処理を実装する場合、グラフィック読み込みの
諸々の関数を一つの大きい？関数にまとめて、グラフィックの設定を変える度に
そのまとめた関数を呼ぶ、というのがセオリー(？)だったりするのでしょうか？
|
| Re: SetChangeScreenModeGraphicsSystemResetFlagについて ( No.3 ) |
- 名前：管理人 日時：2024/07/29 23:25
> そのカラービット数の食い違いは、深刻なエラーが発生しうるのでしょうか？
いえ、深刻なエラーは発生しません
> 例えば画面が32bitで画像が16bit、あるいはその逆の場合、画像が描画
> されなくなったりするのでしょうか？
描画されないということはありませんが、例えば画面が32bitで画像が16bitの場合
画面が1677万色( 24bitカラー( 8bitは使用されません ) )の表現力がある画面モードなのに、
画像が65536色( 16bitカラー )しかないので 1677万色の表現力が活かされないことになります
画面が65536色で画像が1677万色の場合は、画像は1677万色なのにも関わらず画面が65536色の表現力しか無いので、
描画され、画面に表示される画像は65536色のものとなってしまいます
> …でも、今でも16bitの対応が必要と想定すべき環境というのは、何か
> あったりしますかね？
極端に GPU の性能が低い環境もターゲットとする場合は処理負荷軽減の面で意味があるかもしれませんが、
逆に 16bit の画面モードが想定されておらず正常に動作しない可能性もありますので、現在は 16bit の対応が
必要となる環境はほぼ無いと思います
> また、通常のSetChangeScreenModeGraphicsSystemResetFlag( TRUE );
> であり、グラフィックを再度読み込む処理を実装する場合、グラフィック読み込みの
> 諸々の関数を一つの大きい？関数にまとめて、グラフィックの設定を変える度に
> そのまとめた関数を呼ぶ、というのがセオリー(？)だったりするのでしょうか？
はい、ちゃんと対応するソフトの場合はそのような処理になります
２Ｄのゲームの場合は画面解像度が固定のものも多いので、そのような処理を実装しないソフトも沢山あると思いますが…
( ゲーム起動後に画面設定を変更することを想定しない )
|
| Re: SetChangeScreenModeGraphicsSystemResetFlagについて ( No.4 ) |
- 名前：Saucer（解決） 日時：2024/08/04 04:44
管理人様、またまたご丁寧に教授くださり、誠に有難うございます。
SetChangeScreenModeGraphicsSystemResetFlagの詳細を少し理解できた今、
プログラム起動中でのグラフィックの設定を気軽に変更できるメニューなどを
いつか実装してみたいと思います！
特に、ウィンドウモードと（疑似）フルスクリーンモードの切り替えと、
描画の拡大比率？の変更を自由にできるようにしてみたいです。
また、マウスでウィンドウのサイズを、画面を正しく描画しながら
クリックとドラッグ？で変えられる機能が実装できるか、実験してみたいです。
ではこれにて本スレッドを解決とさせていただきます。
親切なご対応、本当にありがとうございました！
これからも宜しくお願いいたします！
|
