Hi. I’m making a small game engine, and everything works fine on Debug mode, but on release mode the textures never display anymore. I built SDL2, SDL_image, and SDL_ttf statically and included the corresponding libraries in my project. I tried to rebuild everything from source, but still nothing happened. I’m using Visual Studio 2022. Intel C++ compiler (C++20).
I’d add code to check for a failure to load the image and add an SDL_ShowSimpleMessageBox which shows you what the error code is. My guess is you’ve set up VS so the Release build sets the default directory to somewhere different to the Debug build.
Does the Release build fail when you run it from VS, and does it fail if you copy the .exe file to a test folder with all your assets in it?
I tried writing a simple hello SDL in Main.cpp, and it worked on both debug and release builds. I rebuilt the project in release with debugging symbols, and found out that the texture variables have been optimized away, so I disabled the optimization options in C/C++ release configuration, and solved the problem. Do you know why this happens?
For some reason the compiler thinks the texture variables aren’t being used, so it’s removing them. As for how to fix this, it would depend on the source code. It’s possible that it’s a compiler bug. See if you can turn down the optimization level without turning it off.
Reminds me of the time there was a bug in the Linux kernel that was caused by a return value not being checked for NULL, except it was being checked in the source code. On further investigation, it turned out the compiler was optimizing away the NULL check!
I have no personal experience with VS, but in general, how useful is it to use a debugger with full optimizations turned on? Is it a problem in itself that the variable is “optimized away”? What does that even mean? It might store it in a register, or store it in two locations, or reuse some location that it used for some other variable that exists at the same time if it can and think it is beneficial.
If there is some strange optimization that makes the program misbehave it’s often because there is some UB in the program.
It’d be useful if you could provide the source code for a minimal app that demonstrated the problem so people could take a look.
If the optimization is optimizing away the texture pointers to the point where the textures are no longer being displayed, that’s a problem.
Now, if it’s because the OP’s code is weird, sure, then it’s still a problem with the OP’s code. But, as I pointed out with my Linux kernel example, it’s not unheard of for compiler optimizers to introduce subtle bugs with perfectly valid code, especially if the optimization level is turned way up.
We definitely need more info, and a “minimal working example” if possible.
Nothing happened even when turning down the optimization. I can’t provide a testable example, but an overview.
MainScene.cxx
void MenuScene::render()
{
...
Renderer::getInstance()->render(imgServer->getItem("mainbg"));
...
Here’s the problem
Renderer.cxx
void Renderer::render(Texture* texture)
{
SDL_RenderCopyExF(
m_renderer,
texture->getTexture(),
nullptr,
texture->getRect().getBase(),
texture->getAngle(),
nullptr, SDL_FLIP_NONE
);
display();
}
Here are my build options
I had the Optimization to Ox
If the optimization is optimizing away the texture pointers to the point where the textures are no longer being displayed, that’s a problem.
But there is nothing to suggest that that is what causes the problem here. That a variable is “optimized away” is nothing suspicious. It happens all the time.
Now, if it’s because the OP’s code is weird, sure, then it’s still a problem with the OP’s code. But, as I pointed out with my Linux kernel example, it’s not unheard of for compiler optimizers to introduce subtle bugs with perfectly valid code, especially if the optimization level is turned way up.
It’s possible, but I think a bug in the OPs code is far more likely and what should be investigated first.
Nothing happened even when turning down the optimization.
You mean you still get the same problem in release mode even when turning down (off?) the optimizations? Have you checked what SeanOConnor said about the paths? Are you checking, in your code, that surfaces, textures, etc. are loaded correctly, and if not you display a message? I think you might need to do that because the optimizations seems to interfer too much with the debug information to be able to read it from there.
Otherwise, the first thing I would do when having a problem like this would be to run the program through valgrind (I don’t think it supports Windows). Another alternative that might be even better if you can get it to work would be to use “sanitizers” (e.g. AddressSanitizer, UndefinedBehaviorSanitizer, etc.). The advantage with these kind of tools in my experience is that they often find problems early, at or near the true cause of problem, as opposed to where the problem is first noticed (which might be much later and in totally unrelated parts of the program).
I can’t provide a testable example, but an overview.
You might want to approach it from the opposite direction. Trying to create a new program from scratch that exhibit the same behaviour can be difficult because it might be caused by UB in unrelated parts of your program that you are not suspecting, so it might be easier to instead take your existing program and keep removing things (making sure the bad behaviour is preserved) until you have a “minimal working example”.