Atlas, TexGen & General TSE Issues
by James Dunmow · in Torque Game Engine Advanced · 06/07/2005 (10:31 am) · 8 replies
Was originally going to post this in the TexGen thread, but I wandered onto some general TSE/TGE issues so I'm plunking it in here ;)
A few issues I've had with Atlas/TSE over the last week.
First, though I guess it's not really a bug, is the error handling. Seems TSE will crash and close up if I give it a misspelt filename/path. This seems to happen with this code as well as the TQT/CHU generator.
Second, can we have a message from the console telling us the shadowmap generation is done? Usually, I'd just watch the CPU cycles to see if it's still working on it or not, but since TSE takes up all the CPU cycles anyway the only way to tell if it's done is to actually attempt to move the mouse cursor around or type in the console. A simple message (in colour?) would be great. I'd do it myself but...I'd hardly be the only one to benefit from this ;)
Third, and this is a general problem with TSE/TGE, can we have it so that the engine will actually look in a directory for a file? Right now it seems that TSE/TGE will load up the index for the subdirectories at load and then becomes blind to any files added afterwards. So if I load up TSE, muck with a map, save it out, edit it quickly and save it with a different filename, then try to get TSE to process it, it won't do it. Right now it's costing me a fair bit of time to have to move or rename scads of files around to get TSE to 'see' them.
Other than these three issues things seem to be alright for the most part. Strugging a bit with this pipeline in general (and most of that is with importing my maps into Terragen), but that's a different topic methinks.
Good work though, thanks guys.
A few issues I've had with Atlas/TSE over the last week.
First, though I guess it's not really a bug, is the error handling. Seems TSE will crash and close up if I give it a misspelt filename/path. This seems to happen with this code as well as the TQT/CHU generator.
Second, can we have a message from the console telling us the shadowmap generation is done? Usually, I'd just watch the CPU cycles to see if it's still working on it or not, but since TSE takes up all the CPU cycles anyway the only way to tell if it's done is to actually attempt to move the mouse cursor around or type in the console. A simple message (in colour?) would be great. I'd do it myself but...I'd hardly be the only one to benefit from this ;)
Third, and this is a general problem with TSE/TGE, can we have it so that the engine will actually look in a directory for a file? Right now it seems that TSE/TGE will load up the index for the subdirectories at load and then becomes blind to any files added afterwards. So if I load up TSE, muck with a map, save it out, edit it quickly and save it with a different filename, then try to get TSE to process it, it won't do it. Right now it's costing me a fair bit of time to have to move or rename scads of files around to get TSE to 'see' them.
Other than these three issues things seem to be alright for the most part. Strugging a bit with this pipeline in general (and most of that is with importing my maps into Terragen), but that's a different topic methinks.
Good work though, thanks guys.
About the author
#2
In core/resManager.cc replace ResManager::find () with:
in platform/platform.h somewhere around line 262 (in struct Platform) add:
in platformWin32/winFileio.cc around line 610 add:
in platformMacCarb/macCarbFileio.cc around line 1001 add:
in platformX86UNIX/x86UNIXFileio.cc around line 900 add:
These code changes will allow you to load a file that wasn't picked up by the initial file scan or one that is external to the modPaths.
06/07/2005 (5:47 pm)
Quote:
Third, and this is a general problem with TSE/TGE, can we have it so that the engine will actually look in a directory for a file?
In core/resManager.cc replace ResManager::find () with:
ResourceObject *ResManager::find (const char *fileName)
{
if (!fileName)
return NULL;
StringTableEntry path, file;
getPaths (fileName, path, file);
ResourceObject *ret = dictionary.find (path, file);
if (!ret)
{
if (Platform::isFile(fileName))
{
ret = createResource (path, file);
dictionary.pushBehind (ret, ResourceObject::File);
ret->flags = ResourceObject::File;
ret->fileOffset = 0;
S32 fileSize = Platform::getFileSize(fileName);
ret->fileSize = fileSize;
ret->compressedFileSize = fileSize;
return ret;
}
fileIsMissing(fileName);
}
return ret;
}in platform/platform.h somewhere around line 262 (in struct Platform) add:
static S32 getFileSize(const char *pFilePath);
in platformWin32/winFileio.cc around line 610 add:
//--------------------------------------
S32 Platform::getFileSize(const char *pFilePath)
{
if (!pFilePath || !*pFilePath)
return -1;
// Get file info
WIN32_FIND_DATA findData;
HANDLE handle = FindFirstFile(pFilePath, &findData);
FindClose(handle);
if(handle == INVALID_HANDLE_VALUE)
return -1;
// if the file is a Directory, Offline, System or Temporary then FALSE
if (findData.dwFileAttributes &
(FILE_ATTRIBUTE_DIRECTORY|
FILE_ATTRIBUTE_OFFLINE|
FILE_ATTRIBUTE_SYSTEM|
FILE_ATTRIBUTE_TEMPORARY) )
return -1;
// must be a real file then
return findData.nFileSizeLow;;
}in platformMacCarb/macCarbFileio.cc around line 1001 add:
//-----------------------------------------------------------------------------
S32 Platform::getFileSize(const char *pFilePath)
{
if (!pFilePath || !*pFilePath)
return -1;
OSErr err = noErr;
CInfoPBRec catinfo;
U8 macpath[MAX_MAC_PATH_LONG];
U32 size;
size = makeMacPath(pFilePath, (char*)(macpath+1));
if (size>MAX_MAC_PATH)
return -1;
macpath[0] = size; // set PString length.
// clear the paramblock.
dMemset((void*)&catinfo, 0L, sizeof(catinfo));
// fill in paramblock.
catinfo.dirInfo.ioVRefNum = macpath[1]==':'?platState.volRefNum:0;
catinfo.dirInfo.ioDrDirID = macpath[1]==':'?platState.dirID:0;
catinfo.dirInfo.ioNamePtr = macpath;
err = PBGetCatInfoSync(&catinfo);
if (err!=noErr)
return -1; // !!!!TBD should log?
if (CAT_IS_FOLDER(catinfo))
return -1;
return catinfo.hFileInfo.ioFlLgLen;
}in platformX86UNIX/x86UNIXFileio.cc around line 900 add:
//-----------------------------------------------------------------------------
S32 Platform::getFileSize(const char *pFilePath)
{
if (!pFilePath || !*pFilePath)
return -1;
// Get file info
struct stat fStat;
if (stat(pFilePath, &fStat) < 0)
return -1;
// if the file is a "regular file" then true
if ( (fStat.st_mode & S_IFMT) == S_IFREG)
return fStat.st_size;
// must be some other file (directory, device, etc.)
return -1;
}These code changes will allow you to load a file that wasn't picked up by the initial file scan or one that is external to the modPaths.
#3
06/07/2005 (6:27 pm)
BTW The latest release of Atlas Texture Generator addresses your first 2 issues.
#4
06/07/2005 (6:29 pm)
Matthew thats a real jewel. Thanks!
#5
06/07/2005 (7:03 pm)
Woah! I'm glad I click on this thread. I've been stuck on the new file(s) issue with my TSE RPG. :D
#6
06/08/2005 (10:13 am)
Awesome guys! Thanks a ton.
#7
06/08/2005 (2:40 pm)
It would rock if you would post this as a resource, Matt.
#8
@ atlashHeightField.cpp --- bool AtlasHeightfield::loadRawU16(Stream &s) line 43
atlasTQTFile.cpp -- StreamJPEGReader::open() line 306
~neo
07/13/2005 (1:58 am)
I've found a couple of leaks and crash culprits as well:@ atlashHeightField.cpp --- bool AtlasHeightfield::loadRawU16(Stream &s) line 43
...
// Read a raw heightfield from a file. It had best be right size!
// First read the data, then blast it out.
U16 *tmp = new U16[realSize() * realSize()];
if(!s.read(realSize() * realSize() * sizeof(U16), tmp))
{
Con::errorf("AtlasHeightfield::loadRaw16 - Failed to read data!" );
delete[] tmp; <<----- added this, or tmp doesn't get deleted if read error
return false;
}
...atlasTQTFile.cpp -- StreamJPEGReader::open() line 306
...
mStream = new File();
if(mStream->open(image, File::Read) != File::Ok)
{
//delete mStream;
SAFE_DELETE(mStream); <<-- changed to this or SAFE_DELETE() in destructor will pagefault as it tries to delete non-zero mStream pointer
return false;
}
...~neo
Torque Owner John Vanderbeck
VanderGames
The texture generator shouldn't crash as long as you check your returns. If addLayer() fails to find the specified file, it will return -1. Or should anyway. But i'll look into tidying up error checking more. No doubt it does need it.
If you are typing the command into the console, then you will know its done because the console input line will clear. IE the command you typed will be cleared from the input once its done. However adding a message is no big deal and I will put that in for this next release.