VC7 Weirdness? Link Problem? Skybox?
by Prairie Games · in Torque Game Engine · 04/19/2002 (6:04 pm) · 9 replies
Compiling a release build both on 1_1_1 and HEAD under VC7 causes some weirdness
In release build:
The link time is in excess of _6_ minutes on an athlon 1400 with 768 megs running XP... I also have a 4 drive stripped RAID .. release produces a 1.89 meg exe
The skybox is corrupt with strange uv pinching (perhaps lack of texture too?)... I can make a screenshot if needed..
In debug build:
The skybox works as expected...
The link time is no longer than expected.. producing a 4.86 megabyte exe...
-J
In release build:
The link time is in excess of _6_ minutes on an athlon 1400 with 768 megs running XP... I also have a 4 drive stripped RAID .. release produces a 1.89 meg exe
The skybox is corrupt with strange uv pinching (perhaps lack of texture too?)... I can make a screenshot if needed..
In debug build:
The skybox works as expected...
The link time is no longer than expected.. producing a 4.86 megabyte exe...
-J
#2
04/20/2002 (9:09 am)
hmm, I don't have VC7, but Mark does and he hasn't mentioned any problems, wierd. Sounds like some kind of compiler bug. Are many people running into this?
#3
-J
04/20/2002 (4:46 pm)
There are posts on the forums regarding betas of the VC7 compiler dying on that code... it appears that the final version doesn't die... instead it compiles it incorrectly and seems to cause a very bizarre link problem...-J
#4
04/23/2002 (10:43 am)
Mark's been able to reproduce this on his home machine... He'll try out the fix and check it in to cvs.
#5
04/23/2002 (10:49 am)
Speaking of which, any word on possible .net workspace files? ;p
#8
I had so many issues with it, I went back to VS6.
As everyone guessed, vs7 generates very mangled code when optimizations are turned on for this line.
F32 per = (mPoints[index].z - renderPoints[3].z) / length;
After looking at the generated asm, it looks like this could be an actual compiler bug, because I cant think of a single situation where what it's doing would be beneficial, or even generate working code.
Inlining the asm found in the cod file generated by compiling under vs6 relieves the problem and leaves the code optimized. (If anyone cares)
05/04/2002 (6:02 pm)
Does anyone know if there are there plans for "officially" adding a Visual C .NET solution file?I had so many issues with it, I went back to VS6.
As everyone guessed, vs7 generates very mangled code when optimizations are turned on for this line.
F32 per = (mPoints[index].z - renderPoints[3].z) / length;
After looking at the generated asm, it looks like this could be an actual compiler bug, because I cant think of a single situation where what it's doing would be beneficial, or even generate working code.
Inlining the asm found in the cod file generated by compiling under vs6 relieves the problem and leaves the code optimized. (If anyone cares)
#9
05/05/2002 (2:12 pm)
Thank you so much for posting the above code snipplet..After all day trying to figure out what was going wrong I came here and put in the code and it worked like a champ.....This is all it takes to make Torque work in .net correctly 
Torque Owner Prairie Games
Prairie Games, Inc.
Changing part of sky.cc to the below has fixed the uv problem... I found this is another post.. maybe the fix should make it to the CVS or something?
Oddly it seems to have fixed the abysmal link time I was experiencing too...
The change:
#ifndef _DEBUG
#pragma optimize( "g", off )
#endif
void Sky::calcTexCoords(Point2F* texCoords, Point3F* renderPoints, S32 index)
{
for(S32 x = 0; x < 4; ++x)
texCoords[x].set(mTexCoord[x].x, mTexCoord[x].y);
S32 length = mFabs(mPoints[index].z) + mFabs(mPoints[index + 5].z);
F32 per = (mPoints[index].z - renderPoints[3].z) / length;
texCoords[3].y = texCoords[2].y = per;
}
#ifndef _DEBUG
#pragma optimize( "g", on )
#endif _DEBUG