Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 5 of 5

Thread: 3D model works fine from within VC++, but not in standalone EXE

Hybrid View

  1. #1
    Junior Member Newbie
    Join Date
    Sep 2013
    Posts
    5

    3D model works fine from within VC++, but not in standalone EXE

    Hi All,

    I have finished my graphing application and it works OK if I click on the debug button (or F5) from within VC++, in both the debug and release configurations.

    BUT when I run the standalone .exe (either the release config or the debug config) from the desktop, there is just a blank space where my model is supposed to be. The rest of the application is working fine.

    I include opengl32.lib and glu32.lid in both configurations, and I am using the /MT multithreaded (without DLL) build model so that the exe is completely portable.

    I suspect this is an environment issue rather than a debug vs release issue???

    Any help would be greatly appreciated,

    thanks,

    Peter

  2. #2
    Advanced Member Frequent Contributor
    Join Date
    Apr 2010
    Posts
    741
    Do you load data at runtime from disk? Your working directories could be different and you may not find your data at the (relative) path you expect.

  3. #3
    Junior Member Newbie
    Join Date
    Sep 2013
    Posts
    5
    Quote Originally Posted by carsten neumann View Post
    Do you load data at runtime from disk? Your working directories could be different and you may not find your data at the (relative) path you expect.
    No, the application has always been very much a standalone exe and doesn't load any files or DLLs on startup.

    I can open data files from the menu and see the data as a graph, but the 3d model (which is displayed perfectly with the VC++ express 10 environment) is just an empty black.

    I am using "draw to bitmap" and have had issues getting a black screen at larger bitmap sizes, so perhaps it's some kind of memory allocation issue that doesn't occur from within the environment???

  4. #4
    Junior Member Newbie
    Join Date
    Sep 2013
    Posts
    5
    Quick update on this - I gave up on DRAW_TO_BITMAP and drew my model to a window instead. Took me a while to fix all the bugs I introduced in the process (e.g. not clearing the depth buffer every time!) but the final result works really well and also solved the size limit issue (see my other thread).

    In short, I think the DRAW_TO_BITMAP in windows is totatlly flawed and should be avoided!

    Peter

  5. #5
    Advanced Member Frequent Contributor
    Join Date
    Apr 2010
    Posts
    741
    Well, the "real" replacement for it is FrameBufferObjects, see the wiki. The problem with "faking" off-screen rendering to a window is that if parts of the window are obscured (by other windows or just being moved off the desktop) the pixel ownership test will fail and those parts of the window will not be rendered to.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •