Control Terrain Repeating through World Editor
by John Vanderbeck · 04/17/2004 (1:18 pm) · 35 comments
Download Code File
This MPG Video shows how this works in the world editor. Essentially it adds a new property that you can toggle to control whether or not the terrain is repeated endlessely when rendered. The change takes place immediately after hitting APPLY so you don't have to reload the mission. When the terrain is set to NOT repeat endlessley, then there will be water covering the rest of the world endlessly. I guess I could have fixed that as well, but I didin't look into it. Seemed to me that you need "something" else out there if you don't repeat the terrain.
Applying this is pretty simple, and there are two ways you can do it. Via a patch or by hand.
Applying the patch
Note: The patch was built from a HEAD checkout 4/17/04
Applying the patch should be realtivly easy if your version of Torque is close to or the same as the one I used to build the patch. You can find instructions on applying patches [url=http://www.garagegames.com/docs/torque.sdk/gstarted/patches.html]here[/url. That page deals with both making and applying patches, so just ignore the parts that cover making them.
Applying the code by hand
Applying the code by hand is pretty easy, as there are only 3 files you have to touch. All code added for this is commented cleaerly. The code below will contain some of the original code before and after the changed/added code for context. This was applied to a HEAD version from about the end of March so there may be slight differences.
1) torque/engine/terrain/terrData.h
We need a variable to control our repeating option, so we add a new member variable to the TerrainBlock class.
2) torque/engine/terrain/terrData.cc
Now that we have the new variable, we need to add the code to set that variable, as well as the code to properly transmit it over the network. There are 4 places where we add code in this file.
First, we just need to initialize a default value (We default to repeating the terrain) in the constructor.
Next, we need to add our new variable to the initPersistantFields() method. This is what allows it to be controled via the editor.
The TerrainBlock now knows about the new variable and it can be set, however we also need to add in the networking for this new variable. IF we don't then it will never get properly "ghosted". To do this we add in code to write the variable over the network and to read it from the network. This is done in packUpdate() and unpackUpdate()
First we'll take care of packUpdate(). This is where we write the variable to the network.
And lastly, we add code to read our variable from the network in unpackUpdate()
Now what we've got is a new variable in the TerrainBlock that can be altered through the world editor and is properly "ghosted" over the network interface. The last step is to actually use this new variable to control the rendering of our terrain.
3) torque/engine/terrain/terrRender.cc
What we want to do here is alter the renderBlock() method to control if we should render the whole thing, or just the main block.
That's all the changes. Re-compile Torque and you should be all set to go.
How to Control Terrain Repeating
The video linked at the top of this resource shows exactly how to control this in the world editor, but for those who don't want to download the video, or can't, here are the baiscs.
1) Open the World Editor.
2) Go to the Mission Inspector.
3) Select the terrain block.
4) Expand the "Misc" group.
5) The field "repeatTerrain" controls the repeating. Select (repat) or unselect (dont' repeat) the field and then click APPLY.
6) Save the mission.
This MPG Video shows how this works in the world editor. Essentially it adds a new property that you can toggle to control whether or not the terrain is repeated endlessely when rendered. The change takes place immediately after hitting APPLY so you don't have to reload the mission. When the terrain is set to NOT repeat endlessley, then there will be water covering the rest of the world endlessly. I guess I could have fixed that as well, but I didin't look into it. Seemed to me that you need "something" else out there if you don't repeat the terrain.
Applying this is pretty simple, and there are two ways you can do it. Via a patch or by hand.
Applying the patch
Note: The patch was built from a HEAD checkout 4/17/04
Applying the patch should be realtivly easy if your version of Torque is close to or the same as the one I used to build the patch. You can find instructions on applying patches [url=http://www.garagegames.com/docs/torque.sdk/gstarted/patches.html]here[/url. That page deals with both making and applying patches, so just ignore the parts that cover making them.
Applying the code by hand
Applying the code by hand is pretty easy, as there are only 3 files you have to touch. All code added for this is commented cleaerly. The code below will contain some of the original code before and after the changed/added code for context. This was applied to a HEAD version from about the end of March so there may be slight differences.
1) torque/engine/terrain/terrData.h
We need a variable to control our repeating option, so we add a new member variable to the TerrainBlock class.
U32 mTextureCallbackKey; void processTextureEvent(const U32 eventCode); S32 mMPMIndex[10]; S32 mVertexBuffer; // JWV BEGIN added for control over terrain repeating bool mRepeatTerrain; // JWV END added for control over terrain repeating private: Resource<TerrainFile> mFile; GridSquare *gridMap[BlockShift+1]; GridChunk *mChunkMap; U32 mCRC; public:
2) torque/engine/terrain/terrData.cc
Now that we have the new variable, we need to add the code to set that variable, as well as the code to properly transmit it over the network. There are 4 places where we add code in this file.
First, we just need to initialize a default value (We default to repeating the terrain) in the constructor.
mCRC = 0; flagMap = 0; mVertexBuffer = -1; // JWV BEGIN added for control over epeating terrain mRepeatTerrain = true; // JWV BEGIN added for control over epeating terrain }
Next, we need to add our new variable to the initPersistantFields() method. This is what allows it to be controled via the editor.
void TerrainBlock::initPersistFields()
{
Parent::initPersistFields();
addGroup("Media"); // MM: Added Group Header.
addField("detailTexture", TypeFilename, Offset(mDetailTextureName, TerrainBlock));
addField("terrainFile", TypeFilename, Offset(mTerrFileName, TerrainBlock));
//CW - bump mapping stuff
addField("bumpTexture", TypeFilename, Offset(mBumpTextureName, TerrainBlock));
//CW - end bump mapping stuff
endGroup("Media"); // MM: Added Group Footer.
addGroup("Misc"); // MM: Added Group Header.
addField("squareSize", TypeS32, Offset(squareSize, TerrainBlock));
addField("emptySquares", TypeS32Vector, Offset(mEmptySquareRuns, TerrainBlock));
//CW - bump mapping stuff
addField("bumpScale", TypeF32, Offset(mBumpScale, TerrainBlock));
addField("bumpOffset", TypeF32, Offset(mBumpOffset, TerrainBlock));
addField("zeroBumpScale", TypeS32, Offset(mZeroBumpScale, TerrainBlock));
//CW - end bump mapping stuff
// JWV BEGIN added for control of repeating terrain
addField("repeatTerrain", TypeBool, Offset(mRepeatTerrain, TerrainBlock));
// JWV END added for control of repeating terrain
endGroup("Misc"); // MM: Added Group Footer.
removeField("position");
}The TerrainBlock now knows about the new variable and it can be set, however we also need to add in the networking for this new variable. IF we don't then it will never get properly "ghosted". To do this we add in code to write the variable over the network and to read it from the network. This is done in packUpdate() and unpackUpdate()
First we'll take care of packUpdate(). This is where we write the variable to the network.
U32 TerrainBlock::packUpdate(NetConnection *, U32 mask, BitStream *stream)
{
if(stream->writeFlag(mask & InitMask))
{
stream->write(mCRC);
stream->writeString(mTerrFileName);
stream->writeString(mDetailTextureName);
//CW - bump mapping stuff
stream->writeString(mBumpTextureName);
//don't have negative bump scale and don't have one too small
if (mBumpScale <= 0)
{
Con::errorf("Bump scale cannot be less than or equal to 0. Setting to 0.0001.");
mBumpScale = 0.0001;
}
stream->write(mBumpScale);
stream->write(mBumpOffset);
stream->write(mZeroBumpScale);
//CW - end bump mapping stuff
stream->write(squareSize);
// JWV BEGIN added for control over terrain repeating
stream->write(mRepeatTerrain);
// JWV END added for control over terrain repeating
// write out the empty rle vector
stream->write(mEmptySquareRuns.size());
for(U32 i = 0; i < mEmptySquareRuns.size(); i++)
stream->write(mEmptySquareRuns[i]);
}
else // normal updateAnd lastly, we add code to read our variable from the network in unpackUpdate()
void TerrainBlock::unpackUpdate(NetConnection *, BitStream *stream)
{
if(stream->readFlag()) // init
{
stream->read(&mCRC);
mTerrFileName = stream->readSTString();
mDetailTextureName = stream->readSTString();
//CW - bump mapping stuff
mBumpTextureName = stream->readSTString();
stream->read(&mBumpScale);
stream->read(&mBumpOffset);
stream->read(&mZeroBumpScale);
//CW - end bump mapping stuff
stream->read(&squareSize);
// JWV BEGIN added for control over terrain repeating
stream->read(&mRepeatTerrain);
// JWV END added for control over terrain repeating
// read in the empty rle
U32 size;
stream->read(&size);
mEmptySquareRuns.setSize(size);
for(U32 i = 0; i < size; i++)
stream->read(&mEmptySquareRuns[i]);
}
else // normal updateNow what we've got is a new variable in the TerrainBlock that can be altered through the world editor and is properly "ghosted" over the network interface. The last step is to actually use this new variable to control the rendering of our terrain.
3) torque/engine/terrain/terrRender.cc
What we want to do here is alter the renderBlock() method to control if we should render the whole thing, or just the main block.
mDynamicTextureCount = 0;
mTextureSpaceUsed = 0;
mUnusedTextureCount = 0;
mStaticTextureCount = 0;
mLevelZeroCount = 0;
mFullMipCount = 0;
mStaticTSU = 0;
F32 worldToScreenScale = dglProjectRadius(1,1);
F32 zeroDetailDistance = (mSquareSize * worldToScreenScale) / (1 << 6) - (mSquareSize >> 1);
F32 zeroBumpDistance = (mSquareSize * worldToScreenScale) / (1 << mCurrentBlock->mZeroBumpScale) - (mSquareSize >> 1);
F32 blockSize = mSquareSize * TerrainBlock::BlockSquareWidth;
// JWV BEGIN change to terrain rendering so as to not endlessley repeat the terrain
/* OLD CODE
S32 xStart = (S32)mFloor( (mCamPos.x - mFarDistance) / blockSize );
S32 xEnd = (S32)mCeil ( (mCamPos.x + mFarDistance) / blockSize );
S32 yStart = (S32)mFloor( (mCamPos.y - mFarDistance) / blockSize );
S32 yEnd = (S32)mCeil ( (mCamPos.y + mFarDistance) / blockSize );
S32 xExt = (S32)(xEnd - xStart);
S32 yExt = (S32)(yEnd - yStart);*/
S32 xStart;
S32 xEnd;
S32 yStart;
S32 yEnd;
S32 xExt;
S32 yExt;
if (block->mRepeatTerrain)
{
xStart = (S32)mFloor( (mCamPos.x - mFarDistance) / blockSize );
xEnd = (S32)mCeil ( (mCamPos.x + mFarDistance) / blockSize );
yStart = (S32)mFloor( (mCamPos.y - mFarDistance) / blockSize );
yEnd = (S32)mCeil ( (mCamPos.y + mFarDistance) / blockSize );
xExt = (S32)(xEnd - xStart);
yExt = (S32)(yEnd - yStart);
}
else
{
xStart = 0;
xEnd = 1;
yStart = 0;
yEnd = 1;
xExt = (S32)(xEnd - xStart);
yExt = (S32)(yEnd - yStart);
}
// JWV END change to terrain rendering so as to not endlessley repeat the terrain
#if 0
{
SquareStackNode2 *st = (SquareStackNode2 *)
FrameAllocator::alloc(sizeof(SquareStackNode2) *
(xExt * yExt + TerrainBlock::BlockShift*4) );
for(S32 y = 0; y < yExt; y++)That's all the changes. Re-compile Torque and you should be all set to go.
How to Control Terrain Repeating
The video linked at the top of this resource shows exactly how to control this in the world editor, but for those who don't want to download the video, or can't, here are the baiscs.
1) Open the World Editor.
2) Go to the Mission Inspector.
3) Select the terrain block.
4) Expand the "Misc" group.
5) The field "repeatTerrain" controls the repeating. Select (repat) or unselect (dont' repeat) the field and then click APPLY.
6) Save the mission.
#2
This is exactly the kind of thing I wanted to do, but don't quite have the programming skills to do yet.
04/17/2004 (4:03 pm)
Great resource as usual John. :) This is exactly the kind of thing I wanted to do, but don't quite have the programming skills to do yet.
#3
04/17/2004 (4:18 pm)
You seem to have forgotten to update the collision code ;) 
#4
I posted this a while back and am curious what's different:
www.garagegames.com/mg/forums/result.thread.php?qt=2471
04/17/2004 (4:33 pm)
John, Does your code control repetition and collision? I haven't looked it over yet.I posted this a while back and am curious what's different:
www.garagegames.com/mg/forums/result.thread.php?qt=2471
#5
04/17/2004 (4:44 pm)
Hmm i'd honestly never seen that Desmond. So many people where whining about this I assumed it hadn't been done before :p 
#6
Anyway sounds useful, I'll give it ago many thanks!
04/17/2004 (8:56 pm)
Will this be added to HEAD?Anyway sounds useful, I'll give it ago many thanks!
#7
04/17/2004 (8:57 pm)
Might want to make this work with repeating water as well. Just a suggestion.
#8
We (read: John) should stop the water from repeating as well. What you would see back there is the skybox. Carefully crafted you should be able to make the visible distance appear much, much greater. Plus you can have maps with extreme elevation changes from one side to the other.
thx jv.
I wasn't whining for the record. Professionals bitch. Amatuers whine ; )
04/18/2004 (6:49 pm)
As far as my usage goes collision toggle isn't really neccesary becasue the mission area will be contained within one hieghtmap tile. Thats the whole point really.We (read: John) should stop the water from repeating as well. What you would see back there is the skybox. Carefully crafted you should be able to make the visible distance appear much, much greater. Plus you can have maps with extreme elevation changes from one side to the other.
thx jv.
I wasn't whining for the record. Professionals bitch. Amatuers whine ; )
#9
==============================================================================
(1) torque/engine/terrain/fluid.h
==============================================================================
// SM BEGIN added for control over water repeating
//void Render ( bool& EyeSubmerged );
void Render ( bool& EyeSubmerged, bool& RepeatWater );
// SM END added for control over water repeating
------------------------------------------------------------------------------
// SM BEGIN added for control over water repeating
//void RunQuadTree ( bool& EyeSubmerged );
void RunQuadTree ( bool& EyeSubmerged, bool& RepeatWater );
// SM END added for control over water repeating
==============================================================================
(2) torque/engine/terrain/fluidQuadTree.cc
==============================================================================
// SM BEGIN added for control over water repeating
// void fluid::RunQuadTree( bool& EyeSubmerged )
void fluid::RunQuadTree( bool& EyeSubmerged, bool& RepeatWater )
// SM END added for control over water repeating
------------------------------------------------------------------------------
// Push 9 reps of the fluid onto the stack.
// SM BEGIN added for control over water repeating
/*
for( j = J-1; j <= J+1; j++ )
for( i = I-1; i <= I+1; i++ )
*/
s32 J1 = 0;
s32 J2 = 0;
s32 I1 = 0;
s32 I2 = 0;
if (RepeatWater) {
J1 = J - 1;
J2 = J + 1;
I1 = I - 1;
I2 = I + 1;
}
for( j = J1; j <= J2; j++ )
for( i = I1; i <= I2; i++ )
// SM END added for control over water repeating
==============================================================================
(3) torque/engine/terrain/fluidRender.cc
==============================================================================
// SM BEGIN added for control over water repeating
//void fluid::Render( bool& EyeSubmerged )
void fluid::Render( bool& EyeSubmerged, bool& RepeatWater )
// SM END added for control over water repeating
------------------------------------------------------------------------------
// SM BEGIN added for control over water repeating
//RunQuadTree( EyeSubmerged );
RunQuadTree( EyeSubmerged, RepeatWater );
// SM END added for control over water repeating
==============================================================================
(4) torque/engine/terrain/waterBlock.cc
==============================================================================
mSpecPower = 6;
// SM BEGIN added for control over water repeating
mRepeatWater = true;
// SM END added for control over water repeating
}
------------------------------------------------------------------------------
// And RENDER!
{
// SM BEGIN added for control over water repeating
//mFluid.Render( CameraSubmergedFlag );
mFluid.Render( CameraSubmergedFlag, mRepeatWater );
// SM END added for control over water repeating
}
------------------------------------------------------------------------------
addField( "specularPower", TypeF32, Offset( mSpecPower, WaterBlock ) );
// SM BEGIN added for control of water repeating
addField("repeatWater", TypeBool, Offset(mRepeatWater, WaterBlock));
// SM END added for control of water repeating
endGroup("Misc"); // MM: Added Group Footer.
------------------------------------------------------------------------------
stream->write( mSpecColor );
stream->write( mSpecPower );
// SM BEGIN added for control over water repeating
stream->write(mRepeatWater);
// SM END added for control over water repeating
// MM: Editor Applied Flag.
------------------------------------------------------------------------------
stream->read( &mSpecPower );
// SM BEGIN added for control over water repeating
stream->read(&mRepeatWater);
// SM END added for control over water repeating
// MM: Calculate Depth Maps if needed.
==============================================================================
(5) torque/engine/terrain/waterBlock.h
==============================================================================
// MM: Depth-map Resolution.
enum WaterAttributes
{
eDepthMapResolution = 512,
};
// SM BEGIN added for control over water repeating
bool mRepeatWater;
// SM END added for control over water repeating
==============================================================================
Cheers.
04/22/2004 (11:22 am)
Here's the code mods (by hand) to control the repeating water...==============================================================================
(1) torque/engine/terrain/fluid.h
==============================================================================
// SM BEGIN added for control over water repeating
//void Render ( bool& EyeSubmerged );
void Render ( bool& EyeSubmerged, bool& RepeatWater );
// SM END added for control over water repeating
------------------------------------------------------------------------------
// SM BEGIN added for control over water repeating
//void RunQuadTree ( bool& EyeSubmerged );
void RunQuadTree ( bool& EyeSubmerged, bool& RepeatWater );
// SM END added for control over water repeating
==============================================================================
(2) torque/engine/terrain/fluidQuadTree.cc
==============================================================================
// SM BEGIN added for control over water repeating
// void fluid::RunQuadTree( bool& EyeSubmerged )
void fluid::RunQuadTree( bool& EyeSubmerged, bool& RepeatWater )
// SM END added for control over water repeating
------------------------------------------------------------------------------
// Push 9 reps of the fluid onto the stack.
// SM BEGIN added for control over water repeating
/*
for( j = J-1; j <= J+1; j++ )
for( i = I-1; i <= I+1; i++ )
*/
s32 J1 = 0;
s32 J2 = 0;
s32 I1 = 0;
s32 I2 = 0;
if (RepeatWater) {
J1 = J - 1;
J2 = J + 1;
I1 = I - 1;
I2 = I + 1;
}
for( j = J1; j <= J2; j++ )
for( i = I1; i <= I2; i++ )
// SM END added for control over water repeating
==============================================================================
(3) torque/engine/terrain/fluidRender.cc
==============================================================================
// SM BEGIN added for control over water repeating
//void fluid::Render( bool& EyeSubmerged )
void fluid::Render( bool& EyeSubmerged, bool& RepeatWater )
// SM END added for control over water repeating
------------------------------------------------------------------------------
// SM BEGIN added for control over water repeating
//RunQuadTree( EyeSubmerged );
RunQuadTree( EyeSubmerged, RepeatWater );
// SM END added for control over water repeating
==============================================================================
(4) torque/engine/terrain/waterBlock.cc
==============================================================================
mSpecPower = 6;
// SM BEGIN added for control over water repeating
mRepeatWater = true;
// SM END added for control over water repeating
}
------------------------------------------------------------------------------
// And RENDER!
{
// SM BEGIN added for control over water repeating
//mFluid.Render( CameraSubmergedFlag );
mFluid.Render( CameraSubmergedFlag, mRepeatWater );
// SM END added for control over water repeating
}
------------------------------------------------------------------------------
addField( "specularPower", TypeF32, Offset( mSpecPower, WaterBlock ) );
// SM BEGIN added for control of water repeating
addField("repeatWater", TypeBool, Offset(mRepeatWater, WaterBlock));
// SM END added for control of water repeating
endGroup("Misc"); // MM: Added Group Footer.
------------------------------------------------------------------------------
stream->write( mSpecColor );
stream->write( mSpecPower );
// SM BEGIN added for control over water repeating
stream->write(mRepeatWater);
// SM END added for control over water repeating
// MM: Editor Applied Flag.
------------------------------------------------------------------------------
stream->read( &mSpecPower );
// SM BEGIN added for control over water repeating
stream->read(&mRepeatWater);
// SM END added for control over water repeating
// MM: Calculate Depth Maps if needed.
==============================================================================
(5) torque/engine/terrain/waterBlock.h
==============================================================================
// MM: Depth-map Resolution.
enum WaterAttributes
{
eDepthMapResolution = 512,
};
// SM BEGIN added for control over water repeating
bool mRepeatWater;
// SM END added for control over water repeating
==============================================================================
Cheers.
#10
04/24/2004 (9:46 am)
Awesome Shannon!
#11
I don't understand the code logic in this section of your post:
05/12/2004 (10:34 am)
@ShannonI don't understand the code logic in this section of your post:
/*
for( j = J-1; j <= J+1; j++ )
for( i = I-1; i <= I+1; i++ )
*/
s32 J1 = 0;
s32 J2 = 0;
s32 I1 = 0;
s32 I2 = 0;
if (RepeatWater) {
J1 = J - 1;
J2 = J + 1;
I1 = I - 1;
I2 = I + 1;
}
for( j = J1; j <= J2; j++ )
for( i = I1; i <= I2; i++ )If NOT RepeatWater, how are J1, J2, I1, and I2 set (other than having been set to 0)? Or will the for loops simply do one pass when RepeatWater is null?
#12
When RepeatWater is false, both loops loop from 0 to 0 (once).
05/12/2004 (11:57 am)
Your are correct in your assumption...When RepeatWater is false, both loops loop from 0 to 0 (once).
#13
05/13/2004 (4:32 pm)
ok, got it..thx But rather than initialize J1, J2, I1, and I2, couldn't you just set the values in the loops to 0 for efficiency? e.g. (for(j=0;j<=0;j++) ...
#14
if (RepeatWater) {
for( j = J-1; j <= J+1; j++ )
for( i = I-1; i <= I+1; i++ )
... the code ...
} else {
for( j = 0; j <= 0; j++ )
for( i = 0; i <= 0; i++ )
... the code ...
}
Although you could make "... the code ..." a separate function to avoid repetition, I prefer not to break up simple segments, leaving the logic easily readable. Also, having the loops dependant upon a varaible allows the modification of the variables through external means. For example, what if the user wanted to control the number of reps of their terrain in each direction rather than relying on the visibility algorithm which currently decides that?
Certainly it makes more sense, in terms of efficiency, to "hard code" the loops to limit the number of comparisons ...j <= J2... when dealing with large loops, but in this case the loop size is fairly restricted.
05/14/2004 (6:46 am)
Yes, but then I would need to create two separate sets of loops and duplicate the code contained inside the second loop so that the code can still respond to when the user decides to turn the repeating terrain on or off:if (RepeatWater) {
for( j = J-1; j <= J+1; j++ )
for( i = I-1; i <= I+1; i++ )
... the code ...
} else {
for( j = 0; j <= 0; j++ )
for( i = 0; i <= 0; i++ )
... the code ...
}
Although you could make "... the code ..." a separate function to avoid repetition, I prefer not to break up simple segments, leaving the logic easily readable. Also, having the loops dependant upon a varaible allows the modification of the variables through external means. For example, what if the user wanted to control the number of reps of their terrain in each direction rather than relying on the visibility algorithm which currently decides that?
Certainly it makes more sense, in terms of efficiency, to "hard code" the loops to limit the number of comparisons ...j <= J2... when dealing with large loops, but in this case the loop size is fairly restricted.
#15
With some wrenching I got this in.
Works with the latest HEAD (Downloaded a month ago, dunno what ver).
This made "Zones" possible for us at Broke-Ass Games!
Thank you, thank you!
I've been flipping about about the water getting messed up at terrain sizes higher than 8x8.
I see a post above though that should help.
Thanks Shannon, I'll post feedback when it's in.
Current test "Zone" is 4.1 square miles, I didn't need repeating.
Good work!
This resource has been assimilated!
Ari Rule (Programmer and Modeller)
07/14/2004 (9:58 pm)
Thanks John,With some wrenching I got this in.
Works with the latest HEAD (Downloaded a month ago, dunno what ver).
This made "Zones" possible for us at Broke-Ass Games!
Thank you, thank you!
I've been flipping about about the water getting messed up at terrain sizes higher than 8x8.
I see a post above though that should help.
Thanks Shannon, I'll post feedback when it's in.
Current test "Zone" is 4.1 square miles, I didn't need repeating.
Good work!
This resource has been assimilated!
Ari Rule (Programmer and Modeller)
#16
09/22/2004 (7:00 pm)
Very nice work. I assume I can do these edits in 1.2.2, and in 1.3 when it's released, if the edits are not already built into it.
#17
Thanks dude!
cheers
09/23/2004 (5:53 am)
Aye, it works in 1.1.2. No extra modifications required. Works great on the blue guy. Comparing the differences between the blue guy and the avatars we are using. Will keep you posted on the progress.Thanks dude!
cheers
#18
Silky smooth.
Ari Rule (Lead Programmer)
"I'll sleep when I'm dead."
12/09/2004 (1:17 am)
Just patched 1.3 and then added Shannon's mod.Silky smooth.
Ari Rule (Lead Programmer)
"I'll sleep when I'm dead."
#19
Question:
Instead of modifying the fps in the Torque Engine demo, I am actually building my name from the example game provided in Ken Finnley's 3D game programming book....
Since I'm using that, I am no sure how to insert the patch provided here or how to modify .h and .cc files and to recompile (where to find them at least).... is it the .h and .cc files that are located within the main torque engine that I should be modifying?
Also, www.garagegames.com/docs/torque.sdk/gstarted/patches.html only talks about making patches... but where are the instructions to APPLY them?
Many thanks!
01/13/2005 (7:20 am)
This is exactly what I've been looking for - thank you!Question:
Instead of modifying the fps in the Torque Engine demo, I am actually building my name from the example game provided in Ken Finnley's 3D game programming book....
Since I'm using that, I am no sure how to insert the patch provided here or how to modify .h and .cc files and to recompile (where to find them at least).... is it the .h and .cc files that are located within the main torque engine that I should be modifying?
Also, www.garagegames.com/docs/torque.sdk/gstarted/patches.html only talks about making patches... but where are the instructions to APPLY them?
Many thanks!
#20
03/01/2005 (1:49 pm)
@Kayley Ummm AFAIK there are no .cc or .h files in the starter.fps those are always engine mods. 
Torque Owner John Vanderbeck
VanderGames
I recommend applying it by hand if you want to learn a bit about the engine and/or understand how this works. It is really very easy to apply by hand.