Performance Loss When Recompiling Projects

[reepblue]

Before I released Vectronic's Demo, I've noticed that when recompiling the project even with the stock code, the game runs at a much slower framerate than the exe generated by the project manager. But now since the demo is out, and there is something to test it with I'd thought I would share this issue with the community, and hopefully find a fix.

 

Please download the Vectronic Demo if you don't have it already, then download this 7z file which contains two exe's. One recompiled titles "Vectronic_Recompiled" (Recompiled by me.) and the other "Vectronic_Stock" (Straight from the project manager). It also contains the Source and Project Folder. This should work regardless if you have the latest beta or not. I tried the exe's on the current standard release.

 

You'll notice that the stock executable runs at a higher framerate than the recompiled executable. I've not changed a single thing within the projects nor source code. What makes this different than the ones generated by the stock builds of the executables?

 

Thanks.

[nick.ace]

I feel like it's some sort of memory issue, possibly from different project configuration settings. I had similar problems and am still unable to solve it (after spending days looking at this, I kind of gave up):

http://www.leadwerks.com/werkspace/topic/12572-compiled-c-vs-default-lua-exe/page__hl__exe

 

Are you experiencing any of this? Like your game, my game was pretty demanding (you use a lot of lights while I use a lot of assets).

[reepblue]

The only difference here is the exe itself. I never noticed that the exe's are two totally different sizes. It seems to only be noticeable with busy scenes rather than simple games/prototypes. Hence why I waited till I released the demo to ask about this issue.

 

So it must be within the project files. I might try rebuilding an exe from scratch and see if there is any hiccups.

[nick.ace]

Any luck on this? I feel like it definitely has to be a difference in settings. Otherwise, the .exe would be the exact same size. I feel like a start to finish C++ compiling tutorial for Leadwerks would be beneficial.

[reepblue]

Hmm. I looked over the the project and everything seems to be right to me. I also tried cleaning up the main.cpp file (removing the AppData writes and calling App), and removed the app.cpp/,h files from the project. This still made the exe bigger than the auto generated one, but the game still works.

 

#ifndef OS_IOS
#ifndef _DLL
#ifndef BUILD_STATICLIB
#include "Leadwerks.h"
#endif
#endif
using namespace Leadwerks;
void DebugErrorHook(char* c)
{
int n=0;//<--------------------------- Add a breakpoint here to catch errors
}
#ifdef __APPLE__
int main_(int argc,const char *argv[])
{
#else
int main(int argc,const char *argv[])
{
#endif
//Set program path
System::AppPath = FileSystem::ExtractDir(argv[0]);
//Load command-line parameters
System::ParseCommandLine(argc, argv);
//Enable Lua sandboxing
if (String::Int(System::GetProperty("sandbox")) != 0) Interpreter::sandboxmode = true;
//Switch directory
std::string gamepack = System::GetProperty("game");
if (gamepack != "")
{
Package* package = Package::Load(gamepack);
if (!package) return 1;
}
//Add debug hook for catching errors
Leadwerks::System::AddHook(System::DebugErrorHook,(void*)DebugErrorHook);
//Load any zip files in main directory
Leadwerks::Directory* dir = Leadwerks::FileSystem::LoadDir(".");
if (dir)
{
 for (int i=0; i<dir->files.size(); i++)
 {
	 std::string file = dir->files[i];
std::string ext = Leadwerks::String::Lower(Leadwerks::FileSystem::ExtractExt(file));
	 if (ext=="zip" || ext=="pak")
	 {
		 Leadwerks::Package::Load(file);
	 }
 }
 delete dir;
}
#ifdef DEBUG
std::string debuggerhostname = System::GetProperty("debuggerhostname");
if (debuggerhostname!="")
{
//Connect to the debugger
int debuggerport = String::Int(System::GetProperty("debuggerport"));
if (!Interpreter::Connect(debuggerhostname,debuggerport))
{
Print("Error: Failed to connect to debugger with hostname \""+debuggerhostname+"\" and port "+String(debuggerport)+".");
return false;
}
Print("Successfully connected to debugger.");
std::string breakpointsfile = System::GetProperty("breakpointsfile");
if (breakpointsfile!="")
{
if (!Interpreter::LoadBreakpoints(breakpointsfile))
{
Print("Error: Failed to load breakpoints file \""+breakpointsfile+"\".");
}
}
}
else
{
// Print("No debugger hostname supplied in command line.");
}
#endif
if (FileSystem::GetFileType("Scripts/main.lua") == 1)
{
//Execute main script file
if (Interpreter::ExecuteFile("Scripts/main.lua"))
{
#ifdef DEBUG
Interpreter::Disconnect();
#endif
//if (!System::SaveSettings(settingsfile)) System::Print("Error: Failed to save settings file \"" + settingsfile + "\".");
Steamworks::Shutdown();
return 0;
}
else
{
#ifdef DEBUG
Interpreter::Disconnect();
#endif
Steamworks::Shutdown();
return 1;
}
}
}
#endif

 

I don't know how or why this is a problem. Maybe there is something with the settings. I'm gonna try building a project from scratch now.

[nick.ace]

I mean, I just recompiled the interpreter project that is included with each new project. What I'm saying is I think there may be a missing global configuration settings that were not included in the project. Visual Studio seems to have a ton of settings, and I wonder if something was left out of it. Either that or a different version of the VS compiler was used.

[reepblue]

Just tried a rebuild from a blank project and same problem. the only thing it did was reduced the size down by 20kb. My executable just tells main.lua to execute and the lua file once and the main.lua script handles it from there. Although my program is lighter, it's still righting slower.

 

And unless Josh joined the VS2015 beta, I'm sure he's still using VS2013 like the rest of us. Keep in mind he has more access to the engine than we do so it's possible that he is compiling the stock executables differently than us.

[Ma-Shell]

The microsoft compiler has some settings for optimization.

You will find them in VS 2013 by clicking

 

Debug -> [Project name] properties... -> Configuration Properties -> C/C++ -> Optimization

 

You should set the value of "Optimization" to "Maximize Speed (/O2)" and "Favor Size Or Speed" to "Favor fast code (/Ot)".

I am not sure, whether the other settings will also have a noticeable impact but these should be the most important ones.

Be sure to select the "Release"-Configuration in the Combobox at the top of the dialog window.

[thehankinator]

Seems unlikely but has anyone confirmed what update Josh has applied to VS2013 Express? Looks like they are up to Update 4 (soon 5). I just applied it and it did make changes to the windows SDK.

 

https://support.microsoft.com/en-us/kb/2829760