Laggy City Interface

[EmperorFool]

These arrays are being scanned when drawing the build icons? WTH!

 

[Afforess]

These arrays are being scanned when drawing the build icons? WTH!

Yes. The descriptions get loaded when the icons are created... The descriptions have some rather...inefficient code.

 

[EmperorFool]

That's very odd given that the descriptions aren't cached for use in the popups. Is the code that loads the descriptions in the SDK or the EXE? I suspect the latter or you'd have disabled that already.

 

[Afforess]

That's very odd given that the descriptions aren't cached for use in the popups. Is the code that loads the descriptions in the SDK or the EXE? I suspect the latter or you'd have disabled that already.

EXE.

Anyway, my solution works fairly well. A bit on the hacky side of things, but it works.

 

[EmperorFool]

If you'd like an extremely hacky solution, check this out.

1. From Python before you start the loop to draw the icons, call a new function in the SDK: setIgnoreBuildingDescriptions(True) which sets a global variable in CvInitCore or wherever to the value passed in (true).
2. In CvGameTextMgr, check this value and at the start of the setBuildingHelp() function and return immediately if it is true.
3. At the end of the loop call setIgnoreBuildingDescriptions(False).

 

[phungus420]

AND Revisions 145 and 146, right? A reduction 800ms to 200 should be enough to make it worth including in the Unofficial Patch I'd think.

Yeah, definitely get this in the UP once you guys are happy with it.

 

[Afforess]

If you'd like an extremely hacky solution, check this out.

1. From Python before you start the loop to draw the icons, call a new function in the SDK: setIgnoreBuildingDescriptions(True) which sets a global variable in CvInitCore or wherever to the value passed in (true).
2. In CvGameTextMgr, check this value and at the start of the setBuildingHelp() function and return immediately if it is true.
3. At the end of the loop call setIgnoreBuildingDescriptions(False).

We would need to do that with the civilopedia, and worldbuilder too. I noticed that both of those were affected too.

 

[EmperorFool]

If the total lag time is down to 200ms, I think doing this extra hack solution wouldn't be worth it. Most people won't notice one fifth of a second. I think your usage-detection flag is sufficient at this point and far less problematic. For one thing it is SDK-only which means there is less room for error.

 

[jdog5000]

Afforess -

Working on getting this into the UP and checking to make sure I understand correctly ... am I right that you found that in CvGameTextMgr::setBuildingHelp, the lines:

	for (iI = 0; iI < GC.getNumSpecialistInfos(); ++iI)
	{
		szFirstBuffer = gDLL->getText("TXT_KEY_BUILDING_FROM_IN_ALL_CITIES", GC.getSpecialistInfo((SpecialistTypes) iI).getTextKeyWide());
		setYieldChangeHelp(szBuffer, L"", L"", szFirstBuffer, kBuilding.getSpecialistYieldChangeArray(iI));
	}

	for (iI = 0; iI < GC.getNumBonusInfos(); ++iI)
	{
		szFirstBuffer = gDLL->getText("TXT_KEY_BUILDING_WITH_BONUS", GC.getBonusInfo((BonusTypes) iI).getTextKeyWide());
		setYieldChangeHelp(szBuffer, L"", L"", szFirstBuffer, kBuilding.getBonusYieldModifierArray(iI), true);
	}

were taking a large percentage of the overall computation time of the function? And just turning these off using a new member boolean in CvBuildingInfo for when the fields are defined would save significant time in plain BTS?

 

[Afforess]

Yep. It's because they are 2-d arrays, and take a lot of iterations.

I was lazy, and added several public boolean variables to CvBuildingInfo, which were set to true when the game was parsing the XML, here:

					if (gDLL->getXMLIFace()->SetToChildByTagName(pXML->GetXML(),"YieldChanges"))
					{
						// call the function that sets the yield change variable
						pXML->SetYields(&m_ppaiSpecialistYieldChange[k]);
						gDLL->getXMLIFace()->SetToParent(pXML->GetXML());
[COLOR="Red"]						m_bAnySpecialistYieldChanges = true;[/COLOR]
					}

It will be set to true even when there are just 0's in the XML, but better a false positive then a false negative.