Ogre Forums

Ogre Version: : 1 13 6 5:
Operating System: :Windows 11:
Render System: :OpenGL3+

Finally I have built the fresh opendungeons-plus binary for Windows. I have for sure all DLL's needed. But to the point : when the binary is RUN I get MessageBox saying that Ogre::Exception has occured at Ogre::createResource() assertion failed : resource name cannot be empty. I understand that. But Why is that ? Why on the Linux it goes fine , while on Windows it tries to create a resource without name , when the game's resources are the same on both systems ?
Would love to debug, but my MSVSC skills too poor .... How do I start the binary in debug mode of this env. ? I have built the project to fresh directory say opendungeons-plus-2026 and when I press the button RUN DEBUG I get some file not found .....

 ( Unable  to start the program : C:\OpenDungeonsPlus-2026\x64\RelWithDebInfo\ALL_BUILD' Access Denied)

. Please help cause I would love to see the backtrace of the program when the exception occurs.

In Visual Studio, you must right click on a project and press "Set as Startup Project", and it seems your current startup project is the ALL_BUILD project, which might be incorrect.

Also, Windows and Linux are very different, since uppercase vs lowercase letters of files might work for one but not the other if they are not exact. For example, if you try in C++ to open a file with fopen and the filename is not exact with its upper/lower-case, it might not work on one platform but it might work on the other.

OKI thanks, I made some progress again and now I am stuck with CEGUI :
this function seeems to try createResource() with empty name :

void OgreRenderer::constructor_impl(Ogre::RenderTarget& target)
{
    d_pimpl->d_renderSystem = d_pimpl->d_ogreRoot->getRenderSystem();

d_pimpl->d_displaySize.d_width  = target.getWidth();
d_pimpl->d_displaySize.d_height = target.getHeight();

d_pimpl->d_useGLSLCore = ( d_pimpl->d_renderSystem->getName().compare(0, 8, "OpenGL 3") == 0 ) ;

// create default target & rendering root (surface) that uses it
d_pimpl->d_defaultTarget =
    CEGUI_NEW_AO OgreWindowTarget(*this, *d_pimpl->d_renderSystem, target);

#ifdef CEGUI_USE_OGRE_HLMS
    d_pimpl->d_renderTarget = ⌖
#endif

#if OGRE_VERSION >= 0x10800
    #ifdef CEGUI_USE_OGRE_HLMS
        bool isFixedFunctionEnabled = false;
    // Check if built with RT Shader System and if it is: Check if fixed function pipeline is enabled
    #else
        bool isFixedFunctionEnabled = d_pimpl->d_renderSystem->getCapabilities()->hasCapability(Ogre::RSC_FIXED_FUNCTION);

    d_pimpl->d_material = Ogre::MaterialManager::getSingleton().create(
        "__cegui_internal_material__",
        Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);
    
    Ogre::Pass* pass = d_pimpl->d_material->getTechnique(0)->getPass(0);
    pass->setLightingEnabled(false);
    pass->setDepthCheckEnabled(false);
    pass->setDepthWriteEnabled(false);
    pass->setCullingMode(Ogre::CULL_NONE);
    pass->setFog(true, Ogre::FOG_NONE);
    pass->setVertexColourTracking(Ogre::TVC_DIFFUSE);
    Ogre::TextureUnitState* tus = pass->createTextureUnitState();
    tus->setTextureFiltering(Ogre::TFO_BILINEAR);
    tus->setTextureAddressingMode(Ogre::TextureUnitState::TAM_CLAMP);
    tus->setColourOperationEx(Ogre::LBX_MODULATE, Ogre::LBS_TEXTURE, Ogre::LBS_DIFFUSE);
    tus->setAlphaOperation(Ogre::LBX_MODULATE, Ogre::LBS_TEXTURE, Ogre::LBS_DIFFUSE);

    #ifndef RTSHADER_SYSTEM_BUILD_CORE_SHADERS
        if (!isFixedFunctionEnabled)
            CEGUI_THROW(RendererException("RT Shader System not available but trying to render using OpenGL 3.X+ Core."
            "When GLSL shaders are necessary, the RT Shader System component of Ogre is required for rendering CEGUI."));
    #endif
#endif

// Default to using shaders when that is the sane thing to do.
// We check for use of the OpenGL 3+ Renderer in which case we always wanna (because we have to) use shaders
if (!isFixedFunctionEnabled)
    setUsingShaders(true);
#endif

// hook into the rendering process
#if !defined(CEGUI_USE_OGRE_COMPOSITOR2)
    d_pimpl->d_ogreRoot->addFrameListener(&S_frameListener);
#endif

}

First of all MSVSC seems to be totally confused as where is the execution point : it shows at line :

        d_pimpl->d_material = Ogre::MaterialManager::getSingleton().create(
            "__cegui_internal_material__",
            Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);

but all code block from #if OGRE_VERSION >= 0x10800 to #endif is in pale gray , suggesting the preprocessor code didn't provide this code piece...
and one more thing : how do I know what;s the OGRE_VERSION under debugging session and other preprocessor constants ? As usual the Windows way of Hoover mouse or CLICK philosophy does not succeed --- it simply shows nothing....

It is hard to say what causes it to crash there, but my guess is that the OgreRenderer::constructor_impl is called from a NULL pointer or that Ogre::MaterialManager::getSingleton() is using a NULL pointer before you use ".create".
Because it showing up as an empty string makes no sense, since it even uses a constant string that is non-empty in your code.

The preprocessors can sometimes show up as incorrect in Visual Studio, but if you debug and it goes into a code, even if it is grayed out because of the preprocessor thingy, it does execute that code. It is just that it shows up as gray visually (incorrectly).

It is sometimes hard to know what value a preprocessor has, for example the ogre version.
Sometimes you can press F12 on it after you have selected it to find it, and sometimes you must if it yourself.

It is easy to check if preprocessor works correctly. Just add line

#error wtf

into the condition you check (the "grayed" block) and try compiling. if it prints "error: wtf" and compilation stops, the block is used,
if it goes on and not prints that thing - it is not.

OKi, thanks for all the help in here. I have a running binary by now, except one has to fix the way it finds the maps' files in the main menu..... ( resolve the proper path for it..).

So my next question is : where do I find some cooperative www site or webservice , which would take in my binary for Windows 10/11, so my effort does not go wasted ?

I thought about MajorGeeks.com -- they leave my forum's post without an answer or sourceforge.org --- did anyone had something to deal with them ?

https://itch.io/ ?

Now it almost works , except the GUI sometimes crashes. the GUI logic seems flawed , when I work with buttons ( clicking it ) there is 50% chance randomly that the application wil crash. That makes some probable that the game would crash after first click into 'Single Player' menu entry or one can as well go through all menus to the actual gameplay. Any idea why is that , apart that something wrong going with CEGUI ? ChatGPT suggests it has to be deletion of some menu widget plus later call from the subsriber code for that widget ..... ANY CEGUI expert on board ? Even the claims of ChatGPT are true, how it is so that it works on Linux just fine ?
EDIT : THIS happens only when the binaries are run by OS not by debugger.

I just have switched from the STBI to FreeImage codec, cause I thought that the infamous malloc and delete[] mismatch at first was the issue ( as shown by the code sanitizer on Linux... ) .
To my sorrow the GUI bug seems to prevail !

You basically have a bug that only happens on release, and not on debug, correct?

That does happen sometimes to me as well, but most of the time you can still debug it by using a release-debug build.

The only difference between a release-debug build and a normal release build are these settings in Visual Studio, so try them and recompile and then run using F5 to debug it in release:
C/C++ -> Optimization -> Optimization -> Disabled
Linker -> Debugging -> Generate Debug Info -> Yes

More info about it here:
https://learn.microsoft.com/en-us/cpp/b ... w=msvc-170

I've followed your advice and have setup MSVSC to desired state.
However the described Heisenbug remains as it was !
What tools I have at hand under Windows to resolve this ? I have heard about about code sanitizers like ASAN (?), but to use it properly here I would have to rebuild entire boost library for what I have little time...

There were other "warnings" from address sanitizer as well on Linux, which I ignored. That was a mistake. As Chatgpt suggests that would only make more place for more UB. So I roll up my sleeves and mend those "warnings" ....

On the other hand , after searching I found that memory leaks does not cause undefined behaviour , it make only your memory run out faster !
I need to rebuild my game with the older CEGUI anyway, and here's the question : I noticed that building my game takes over 7 minutes, while on Linux with make -j40 it's 40-50 seconds! ( I already enabled parallel builds for MSVSC ) . SO what are your patents to have faster builds on Windows ?

Now I fight with the std::cout being used not in synchronization in diffrent threads. I almost fixed it, but OGRE way of logging brings problems. It uses the std::cout to output it's messages, no matter what I try to suppress the use of the std::cout and std::cerr ! Is there a way of either suppressing the use of std::cout by OGRE or to use some syncing mechanism on par with what's in the game logging mechanism ?

EDIT : This is needed to get a healthy output from valgrind : helgrind. So far this tool reports about "Possible data race" ( for std::cout ) . I would like to start from the clear page / case ......

I answer my own question ( I was fooled because there is similar code snippet in OD already , but INACTIVE).

    Ogre::LogManager ogreLogManager;
    ogreLogManager.createLog("Ogre.log", true, false, false);[
    // Signature: createLog(name, defaultLog, debuggerOutput, suppressFileOutput)
    // 
    // defaultLog = true:          Make this the default target for Ogre logs
    // debuggerOutput = false:     CRITICAL: Disables std::cout / std::cerr output
    // suppressFileOutput = false: Keep the "Ogre.log" file on disk

Now, I try to get a reasonable output from valgrind :helgrind while there is a lot of spam messages regarding the syncing of LogMessages from Ogre ( it throws from multiply code sites and threads). Any idea how to overcome this apart from recompiling the Ogre3d library to use only one thread ?
And one thing more : chatgpt claims there is a suppress file , with the special language to suppress certain type of messages coming from the debugged program... It advises to create such file :

helgrind.supp
{
   pipewire_pw_log_level
   Helgrind:Race
   fun:pw_log_set_level
   ...
}

{
   pipewire_spa_ringbuffer
   Helgrind:Race
   fun:spa_ringbuffer_*
   ...
}

{
   pipewire_thread_loop
   Helgrind:Race
   fun:pw_thread_loop_*
   ...
}

{
   pipewire_loop
   Helgrind:Race
   fun:pw_loop_*
   ...
}

and run :

 valgrind --tool=helgrind \
  --suppressions=helgrind.supp \
  --log-file=helgrind.log \
  ./opendungeons-plus

This "supressions" command simply does not work ! Is chatGPT hallucinating ?

valgrind --tool=helgrind --version
valgrind-3.26.0

My valgrind version 3.18 knows about --supressions option. Maybe they renamed it later?

Thanks for the reply,

The problem seems to be in the script not the option. However after grepping all the occurances of data races , I clearly see that the only source was Ogre Logging. That way I am at the starting point again with the CEGUI button crashing my app under Windows 10/11 ( please read the above posts). I will now try the general valgrind, maybe it would detect some anomalies ...

Seems NOT REBUILDING all libraries and components might be a culprit. Now I try to rebuild boost libraries with current compiler. And here is ugly suprise : the boost 1_71_0 don't want to build properly on my computer ! The chatgpt claims :

THE REAL ROOT CAUSE (now 100% confirmed)

You do not have a true Boost 1.71.0 source tree.

You likely have one of these:

a git clone of Boost with updated submodules

a repackaged Boost tree (vcpkg / distro / mirror)

a directory named boost_1_71_0 but containing new Boost.Build

Boost 1.71 cannot be built with Boost.Build 4.0.
When you try, it silently no-ops → exactly what you see.

This explains everything:

why bootstrap.bat “works”

why b2 runs

why it always finds targets but skips builds

why nothing ever compiles

If Boost 1.71 cannot be built with Boost.Build 4.0. where I am supposed to take the source files from ? because it is downloaded from here :

https://www.boost.org/releases/1.71.0/

The proper link was : https://archives.boost.io/release/1.71.0/source/ for some reason. Now It works, I have to rebuild everything.
P.S. Do you know a way of getting a history to he x64 native tools command prompt under Windows 11 ? Chatgpt suggests this tool : https://github.com/chrisant996/clink/releases. It seems fine .... finally I would have the old history of cmds at hand ! ( I keep using x64 native tools because for many tools under Windows it is a must to have).

Every install of boost I try is somehwat flawed . Most of the time it is using :

C:\boost_1_84_0\boost_1_84_0>.\b2 --version
B2 4.10-git

But chatgpt Keeps saying I should use / have at that point : Boost.Build 4.1.x

Why so popular library as boost is so badly served and usually broken ? !

Because it is handled by repositories/packaging systems most of time.

So which repository or packaing system do you advice in my situation ?

I don't know about windows but I remember MSVS had vcpkg, there is also conan... The problem with boost is more or less universal and that one I prefer to get pre-packaged even though I am quite used to packaging myself as it is not trivial. Or I look into package systems for build instructions to repeat process manually. I think you should have pretty good chance with vcpkg to rebuild boost.

I have installed boost by choco package manager. I am almost on Finish line. What is getting on my nerves is how the cmake-gui works ( this time both on Windows and Linux). When one changes the CmakeList.txt he has to delete the CMakeCache.txt and loose everything which was introduced via the window with fields named after the variables .... How to avoid that ? Copy back the CmakeCache.txt or Take screenshots ? And refill the editboxes once again ? I would like to avoid that.