none
OPENGLの表示がx64では荒くなってしまう

    質問

  • OPENGLを使用して3Dを表示させているのですが、WIN32では綺麗に濃淡のある表示がされているのですが、x64にすると表示が濃淡がなくすべて同じ色に塗りつぶした表示になってしまいます。

    ただし、x64でもデバッグモードでは綺麗に表示されます。

    グラフィックボードの設定で、ハイクオリティに設定すると綺麗に表示する場合があります。

    使用していっるメモリーが大幅に変更されたか為かといろいろ試してみたのですが理由がわかりません。

    どなたか何かわかる方いませんでしょうか

    2017年11月4日 12:03

回答

すべての返信

  • 「x86 では問題ない」、「x64 でもデバッグビルドだと問題ない」と言うことを聞くと、メモリ配置の問題の可能性もありそうですね。
    ただ、現状はコードも何も提示されていない状態ですから、原因の特定は難しいかと。
    2017年11月4日 12:47
    モデレータ
  • 怪しい部分は以下の大きなメモリが問題かと思い

    BOOL _DList[DMAX];   //DMAX 15000

    ここを、newでメモリ確保したり

    BOOL *_DList;

    _DList = new BOOL[DMAX];

    また、_DList = CUIntArray(); でオブジェクトにしてメモリ確保したり

    試したのですが、改善されません

    ここら辺ではないようです。他にどのような点が変更されたか考えるとダイアログを新たについかしたとか

    定義したクラスの内部の変数を多少追加したことぐらいなのでが

    2017年11月4日 14:13
  • 例示された部分ではないでしょうね。
    単純なプリミティブの配列を連続して確保しているところはリスクが低いと考えています。

    逆に変更してないがゆえに、問題があるコードも残っているかもしれません。

    2017年11月4日 22:59
    モデレータ
  • 変更した部分は

    class CNsheet : public CObject
    {
    public:
    CNsheet();
    virtual ~CNsheet();
    public:
    int son;
    CStringA name;//シート名称
    int index;
    int grp;
    int pos;
    int dsp;//表示/非表示モード
    int col;//単一色モード/単一色
    int paper;//ペーパー空間モード
    int m_PaperSizeNo;//用紙サイズ
    int m_PaperMuki;//用紙向き
    int m_PaperScaleNo;//縮尺番号
    double m_PaperScale;//縮尺
    double px0;//ペーパー空間の枠の場所
    double py0;
    double pz0;
    double w;
    double h;
    double z;
    double mpx0;//モデルの位置の座標
    double mpy0;//
    double mpz0;
    double mw;//モデル空間の表示範囲
    double mh;
    double mz;
    double mdx;//枠からの離れx
    double mdy;
    int m_Kaisu;//20140318
    int _3Dtoumei;//20171029
    };

    この中の最後の項目

    int _3Dtoumei;//20171029

    このクラスを何度かnewしたり

    NsheetTmp = new CNsheet();//20120922

    グローバルに使用したりしています。

    CNsheet GL_NsheetArray[100];

    を追加したころからおかしくなったのですが

    その前は何ともなかった感じです。

    _(アンダーバー)の変数名がNG?

    そのほかグローバルに以下のものを追加しただけなのですが

    EXTERN int GL_SHEETMODE;//20171028
    EXTERN int GL_SHEET_NO;//20171029
    EXTERN int GL_R2_XORPEN;//20171102

    複数ファイル(数百)を使用しているのですが、グローバルに定義している部分が少し散乱してのが影響しているのか?

    問題が残っているコードと思い警告も見ていったのですが変数型の変更代入で型落ちしますくらいで特に見当たりません

    2017年11月5日 0:50
  • きちんと事実関係を整理してください。

    「x86 ではきちんと動作する」「x64 はデバッグでのみ動作し、リリースではおかしくなる」という2点を最初の投稿で説明されていました。
    ところが、後の投稿では「追加したころからおかしくなった」とありますが、それは事実ですか?
    「だと思う」ではなく、きちんと検証し、正しい情報を共有してください。
    たとえば、「追加した頃から」なら、その前のソースコードを復元し、問題の有無を検証するべきでしょう。それができていないなら、「追加したことからおかしくなった」は不確定の想像にすぎません。

    現状は情報が断片的であり、かつ正しくない情報を含む可能性がある以上、的確な助言を得ることはできないと考えてください。

    ところで、「_(アンダーバー)の変数名がNG?」なんて書かれていますが、関係ありません。
    もし、自分で疑わしいと考えているのなら、その場で試して白黒つけましょうよ。フォーラムで聞くよりよっぽど速く結果が手に入りますよ。

    2017年11月5日 7:17
    モデレータ
  • 「追加したころからおかしくなった」ですが

    この現象に気が付いていなくて

    以前のリリースモードのEXEを調べたのですが、1週間前のものはx64のリリースでも正常に動作しているが分かったのです

    変更箇所は、大体は可能な限りコードに日付をつけているので、そう表現しました。

    復元ができれば特定できると思うのですが、アンドーで小規模なやり直しは普通に行っていますが、1週間前のコードまでどのようにして復元するのでしょうか。

    2017年11月5日 7:59
  • バージョン管理システムを使っていれば容易ですが、そういう疑問を呈すると言うことは利用されていないのですね。
    そして、履歴を自分でバックアップを取っていないのなら、復元は不可能でしょう。

    あとは、ご自身で試行錯誤して怪しい部分を取り除くしかないかと思います。
    断片的な情報では助言できませんので。

    -----

    断片的な情報なので確実には言えませんが、今提示されている範囲でおかしくなるとは思えません。
    32bit/64bit の違い、デバッグ・リリースの違いなど、いろいろとみていくしかありませんが、C/C++ における落とし穴は無数にあるので、第三者がポイントを示すのは難しいですね…。
    (思いもよらぬコードを書かれていれば、気づけませんので…)

    2017年11月5日 8:59
    モデレータ
  • 問題に助言いただきありがとうございます。

    こちらもどうすればこうなるという現象が突き止めることができず申し訳ありません。

    32ビットで問題なく,x64でもちょっと前までは問題なく

    表示が荒くなったのは、

    ①立ち上げ時点でメモリを消費しすぎてOPENGLのシステムが

    メモリを軽くするために表示を荒くしたのではないか

    ②もしくは、OPENGLで3Dを表示する際のコードの変更が微妙に影響しているか

    いろいろ試行錯誤しています。

    ボードの設定をハイグレードにすると問題ないマシンがあるのでとても微妙な部分なのか?

    5年以上前に、ヘッダで外部変数の定義の数を大きくなりすぎ、突然システムがおかしくなったことがあるのですが

    今回もそのようなリミットに到達したのかといろいろ考えています。

    もうしばらく考えてみます。

    ありがとうございました

    2017年11月5日 10:23
  • もしかしてですがプロパティの設定を変えればうまくいくかと思い

    構成プロパティ-全般

    MFCの使用:共有DLLでMFCを使う

    にしてビルドしてみたのですが、以下のエラーが表示されました

    Please use the /MD switch for _AFXDLL builds

    /MDのスイッチは[リンカー]-[コマンドライン]の追加オプションで/MDを指定するかと思ったのですが

    そうではないようです。どこでこの設定をすればいいのでしょうか

    2017年11月5日 11:26
  • なぜその発想になるのでしょうか?
    前に動いていたときにそうなっていたのですか?、今動いているほかのビルド構成の設定がそうなっているのですか?
    そういった材料がない場合は、そこは元に戻した方がいいと思いますよ。
    (整合性を取るのが大変なので)

    なお、/MD オプションのことは調べれば何か得られると思いますし、そうしていない理由はなぜでしょうか?
    よくわからずに適当に触ることが悪であると考えて、理解できないことにいきなり手を出さず、きちんと Web で調査してください。

    苦言になってしまいますが、C/C++ での開発で適当に触って良化することはまれです。一時的に良化することはあっても、最終的には何らかの問題が出るでしょうし、コードを制御できていない状態はプログラマーとして「負け」といえる状態です。

    2017年11月5日 11:34
    モデレータ
  • /MD オプションをヘルプで探しても検索できないから探しているだけです

    であれば、Google などで「C++ /MD」と開発言語とそのキーワードで探すと良いでしょう。

    また、デバッグでOKでリリースでNGなのはどこが違うかと探していたところ
    特に設定を触っているのではないのですが
    MFCの使用の項目が異なっていたのでそれをデバッグモードに合わせてみたいだけです

    なるほど、それが正しそうと言うことであれば、C/C++ → コード生成から適切に調整してください。
    詳しい場所は前述したように Google で探せば1番最初にヒットするはずですので試してみてください。

    2017年11月5日 11:51
    モデレータ
  • /MDの設定が分かりました

    やはりMFCの使用を変更するとリリースモードでも綺麗に表示されました。

    はやり、x64のリリースモードとOPENGLには微妙な関係があるかもしれないですね

    プログラムの更新途中にどこが原因なのか特定はできませんでしたが

    ただし、大きな問題があり、使用予定のプロテクタキーのDLLは/MDでは起動しないという

    困った問題です。

    こちらは解決は難しいです。

    これまでの助言ありがとうございました

    2017年11月5日 13:02
  • そもそもOpenGLはどこから入手したものなのでしょうか? 
    2017年11月5日 13:25
  • やはりMFCの使用を変更するとリリースモードでも綺麗に表示されました。

    はやり、x64のリリースモードとOPENGLには微妙な関係があるかもしれないですね

    全体像が見えないので断言はできませんが、設定値がどうのこうのというよりは、ソリューション内のプロジェクト構成が不一致でアドレスがずれたとか、そういった問題のように思えます。

    うわべの事象だけで断定しない方がいいですよ。
    なぜなのか?どうしてなのか?を追求するスタンスの方が、応用が利くと、私は思っています。

    2017年11月5日 13:28
    モデレータ
  • 十数年前から使っているものなので今は記憶にないのですが、書籍に記載されているネットのダウンロードではないかと思います。

    もしかすると最新のものを入手すると結果はよくなるかもしれませんね。当時はx64などありませんでしたからかなり変わっている可能性は高いですね。

    そもそもそれが原因かも

    gl.h  opengl.lib等20年前の1997.10のものでした。

    かれこれその部分はさっぱり触っていませんでした。最新のものをどのように組み込むか調べてみます


    2017年11月5日 13:30
  • 今後について尋ねたわけではありません。「OPENGLの表示がx64では荒くなってしまう」がどのような環境なのかを尋ねました。それに対して入手元不明だが動かない、と言われましても、質問の前提が成り立っていないということを理解されていますか?
    2017年11月5日 14:14
  • そうですね、これまで長い間普通に使い続けてきておりOPENGL自体OSに含まれているような感覚でおり。まったくそこに考えが向いていなかったですね。ご意見を寄せられた方申し訳ありません。かなり昔なのでネットも発達していなかった頃ですから、書籍の付録のCDについていたものをそのまま使用していたかもしれません。

    最新のものを入手し動作確認をしてました、[GLUTによる手抜き4OPENGL入門(和歌山大学)]に記載のある方法で最新のGLUTを入手しLIB,dll等をツールで作成し使用しました

    するとx64でも表示が綺麗になりました。

    ただまた問題が発生し、デバッグモードでは問題ないのですが、リリースモードでは大きなデータを扱うとメモリ不足のエラーになってしまいました、この部分は慎重に調べてみます。

    ------------------------------------------------------------

    最新のGLUTのlibを使用したところ

    大きなサイズのデータを読み込むと[メモリが不足しています]のエラー表示がなされ

    3Dは表示されなくなる

    タスクマネージャーでメモリの使用量を調べるとプログラム単独で635MBの使用量

    全体で32%しか消費していない


    2017年11月5日 23:40