Game Development Community

TGEA 1.8.0 BUG Atlas Terrain failed wrtiting bitmap

by Randy Hearn - Magnum · in Torque Game Engine Advanced · 12/24/2008 (7:14 pm) · 33 replies

Created a Atlas terrain and got the following error trying to compile the opacity in 1.8.0. Took the same Atlas files and it compiled fine in 1.7.

atlasGenerateTextureTOCFromTiles(4, $Opacity, $OpacityAtlas, 1);


Fatal-ISV: (..\..\..\..\..\engine\source\atlas\resource\atlasTexChunk.cpp @ 138) AtlasTexChunk::write - failed writing bitmap!


Using the AtlasDemo from both builds. I could try and recompile the Atlas Demo later, perhaps the atlasdemo.exe is just not built form the latest source.


And no. I am not working on Christmas Eve, I am playing with new Atlas Terrain Tools:)


UPDATE: I actually did get this to compile in 1.7 and moved the files over and was able to load the terrain in 1.8. I just can't get past the opacity issue above.

About the author

Technical Product Designer (Mechanical Design) for Boeing for over 25 years working with CAD and PLM systems. I have a Associates Degree in Business and a partial B.S. in Game and Simulation, just couldn't see paying the costs for some of the classes.

Page«First 1 2 Next»
#21
01/01/2009 (7:08 pm)
Would this work?

Resource = GBitmap::load(buff);
GBitmap *bmp = bitmap->this;

templates make my head spin :)
#22
01/01/2009 (7:16 pm)
Not sure. I think we are having two different issues. Mine is similar to this..

http://www.garagegames.com/mg/forums/result.thread.php?qt=50678

For some reason, I think that line is correct, but it is something swapping the RGB or not correctly identifying it.
#23
01/02/2009 (10:36 am)
It appears that the problem is resulting from GBitmap::mInternalFormat being either incorrectly defined or corrupted during the AtlasTexChunk creation. The value that is being returned by bitmap->getFormat() is invalid. For a jpeg texture mInternalFormat should be GFXFormatR8G8B8 whose value is 8. In version 1.7.1 the correct value is returned, in version 1.8.0 it isn't.

bitmapJpeg.cpp:
static bool sWriteJPG(GBitmap *bitmap, Stream &stream, U32 compressionLevel)
{
   TORQUE_UNUSED(compressionLevel); // compression level not currently hooked up

   GFXFormat   format = bitmap->getFormat();         [b]<== value of format is invalid[/b]

   // JPEG format does not support transparency so any image
   // in Alpha format should be saved as a grayscale which coincides
   // with how the readJPEG function will read-in a JPEG. So the
   // only formats supported are RGB and Alpha, not RGBA.
   AssertFatal(format == GFXFormatR8G8B8 || format == GFXFormatA8,
	            "GBitmap::writeJPEG: ONLY RGB bitmap writing supported at this time.");
   if (format != GFXFormatR8G8B8 && format != GFXFormatA8)       
      return false;

   // maximum image size allowed
   #define MAX_HEIGHT 4096
   if (bitmap->getHeight() > MAX_HEIGHT)
      return false;

Somewhere between AtlasTexChunk creation in AtlasImportTiles.cpp and the attempt to write the jpeg bitmap in bitmapJpeg.cpp the value of mInternalFormat is incorrectly set or being corrupted. Note that mInternalFormat is originally set to GFXFormatR8G8B8 at startup.

Unfortunately I don't have any more time to dig today.
#24
01/02/2009 (10:53 am)
OK I have a fix for the bitmap problem but now the atlas geometry file seems to have a similar problem.

change in ConsoleFunction(atlasGenerateTextureTOCFromTiles
GBitmap *bmp = GBitmap::load(buff);

To

GBitmap *bmp;// = GBitmap::load(buff);
		 Resource<GBitmap> newBM = GBitmap::load(buff); 

		    if(newBM != NULL)
				bmp = new GBitmap(*newBM);

This will allow you to create the texture atlas file but later on in atlasGenerateUniqueTerrain the geomtry file fails to load at
inGeometryFile = AtlasFile::load(argv[2]);

Looks familiar doesn't it.

I will post the fix for it as soon I figure it out.
#25
01/02/2009 (1:17 pm)
Every thing works fine now.
My build was created by the SetupNewProject.exe and it has a slight bug in it that makes it create a build without any reference to atlas files as well as not having the preprocessor TORQUE_ATLAS defined.
I corrected my build and the fix I posted above works fine.
#26
01/02/2009 (1:40 pm)
Thanks Bill, will try this later tonight.

On the setupnewproject I thought it pulls from whatever is defined in the Template file. So if you want the Atlas terrain, you would need to add it to the Template Directory build? That is what I have done, except for my Atlas conversions I have simply been using the Atlas demo.

Thanks for running this down, will post later if I have success as well:)
#27
01/02/2009 (2:19 pm)
Worked great for me. Thanks Bill!
#28
01/03/2009 (7:52 am)
While my fix above works it will produce a warning about a "potentially uninitialized local variable", and it bothers me, a better way to do it would be

change in ConsoleFunction(atlasGenerateTextureTOCFromTiles


bmp = GBitmap::load(buff);

To

Resource<GBitmap> newBM = GBitmap::load(buff); 
		 

	 if(newBM == NULL)
         {
            Con::errorf("atlasGenerateTextureTOCFromTiles - unable to open tile '%s'! Aborting!", buff);
            return;
         }
               GBitmap *bmp = [b]new GBitmap(*newBM);

Edited incorrect code
#29
02/08/2009 (3:46 pm)
Hi,

what do you mean by

"change in ConsoleFunction(atlasGenerateTextureTOCFromTiles"

could someone tell me which file needs to be edited in order to fix this, would be very much appreciated.

thanks
#30
02/08/2009 (5:14 pm)
@Nick - Do a search in the source code for
ConsoleFunction(atlasGenerateTextureTOCFromTiles

find
bmp = GBitmap::load(buff);

in that function and change it to

Resource<GBitmap> newBM = GBitmap::load(buff); 
		 

		 if(newBM == NULL)
         {
            Con::errorf("atlasGenerateTextureTOCFromTiles - unable to open tile '%s'! Aborting!", buff);
            return;
         }
               GBitmap *bmp = new GBitmap(*newBM);

Then recompile and it should work.
#31
02/10/2009 (7:39 am)
Thanks again Bill for the info
#32
02/27/2009 (9:19 am)
Great fix Bill. This saved me a whole lot of trouble. Thanks

#33
03/12/2009 (2:04 pm)
Awesome, Bill, thanks! Good work. It's unbelievable how such a small glitch can sometimes cause such an amount of trouble...
Page«First 1 2 Next»