Game Development Community

Resolved: Pixel artifacts in fxImageMapDatablock2d...

by Jason Cahill · in Torque Game Builder · 02/27/2005 (9:21 am) · 13 replies

I've probably done something stupid, but maybe not. I'm trying to create an fxAnimatedSprite2D with the following 4-frame PNG:

mysite.verizon.net/res8owqn/helicopters2.png

Here's the relevant code to load it:

function SetupImages()
{
	datablock fxImageMapDatablock2D(playershipImageMap)
	{
		mode = full;
		textureName = "~/client/images/playerShip";
	};

	datablock fxImageMapDatablock2D(enemyHelicopter)
	{
		mode = cell;
		texturename = "~/client/images/helicopters2";
		cellWidth = 24;
		cellHeight = 12;
		cellCountX = 4;
		cellCountY = 1;
	};
	
	datablock fxAnimationDatablock2D(enemyHeliAnim)
	{
		imageMap = enemyHelicopter;
		animationFrames = "0 1 2 3";
		animationTime = 0.3;
		animationCycle = true;
		randomStart = false;
	};
}

function CreateEnemy()
{
	%enemy = new fxAnimatedSprite2D() { scenegraph = t2dSceneGraph; } ;
	%enemy.setSize("10 5.21");
	%enemy.setPosition("0 0");
	%enemy.setWorldLimit(kill, "-75 -40 60 40");
	%enemy.playAnimation(enemyHeliAnim);
}

What I notice is that one of the frames has a slightly messed up image: See my frame grabbed animation of T2D:

mysite.verizon.net/res8owqn/heli-bug.jpg

The first two frames are fine, but the next two are one texel wider. Is there a better way for me to control this? It's as if the coordinate extraction or GL rendering is slightly off. Maybe there is some simple Torque flag I can play with?

#1
02/27/2005 (9:31 am)
Hmm,

That's weird. You shouldn't need to do more than you have done.

I will of course look at this very soon to see why it's happening.

Sorry for the problem.

Thanks Jason.

- Melv.
#2
02/27/2005 (9:31 am)
I've tried a few other things as well, but it didn't help. I made a version of my sprite PNG that was 128x16 (powers of two in size) where each sprite was 32 x 16 and changed %enemy.setSize("16 8"), but the problem still manifests itself.

... I'm wondering if this is just "rounding error" because my sprites are so low res and I'm magnifying them a lot? All of the sprites in the GG sample are drawn really high res and subsampled at render time...

After some more looking and playing it is definitely something wrong with the texels in the sprite and not related to the scale of the sprite drawn. The first two frames are just "different" than the next two.

Melv: Do you chop up individual images when loading? I'd imagine you wouldn't. I'd imagine you just load a single image and store coordinate sets to the individual frames? Actually, I guess I have the source code too. :-)
#3
02/27/2005 (9:48 am)
@Jason: You are correct, I don't section the images at all. T2D simply calculates texel regions for the frames, this is what T2D calls frame-acquisition; it is in fact just mapping out the images, hence the imageMap name. I'm actually looking at this now with your nice little helicopter running and I get the same effect.

I'll sort this for you, hold please... :)

- Melv.
#4
02/27/2005 (12:33 pm)
@Jason: This has been driving me nuts until I looked deeper. There isn't actually a problem with T2D, the problem is the bilinear interpolation errors.

To conclusively prove this, assuming you can build T2D, go into the class called "fxImageMapDatablock2D" and look for a function called "calculateImageMap" (line 123). Look for a piece of code that looks like this...
// Load Texture.
mImageMapTextureHandle = TextureHandle( mTextureName, BitmapKeepTexture, true );
... and add the following line afterwards...
// Use nearest-neighbour rendering
mImageMapTextureHandle.setFilterNearest();
... and build.

What you see here is that when the nearest neighbour mode is on, everything is perfect. Essentially, there's very little to be done here, apart from add the option to select nearest neighbour mode sampling.

Just in-case you think I might be pulling the wool over your eyes, I've put together an example below.

Looks like you may have to use slightly larger images, unless of course I can think of some way around this.

Sampling Artifact Example:-
www.subreal.net/vids/t2dhelp/t2dsampling.jpg.

- Melv.
#5
02/27/2005 (12:39 pm)
Melv,

That only took your a couple of hours. You seriously either A) spend way to much time in the innerworkings of Torque or B) You are a really really sick programmer.

You really never stop amazing me
#6
02/27/2005 (12:42 pm)
@Charlie: It actually took 35 mins because I promised my wife I'd spend all day with here but managed to find 5-10 minutes in bursts at the computer. ;)

Over the next few days I'll be spending more and more time helping out on these forums.

- Melv.
#7
02/27/2005 (12:43 pm)
Okay, I lied, the image above took me 15 mins. So that'd be 50 mins. :)

- Melv.
#8
02/27/2005 (1:06 pm)
Oh stop bragging. ;)

Really though, artifacts caused by image sampling are common and unavoidable, no matter your engine. Using the appropriate sampling method for your art, supported resolutions, and performance constraints is an important decision to make before finalizing your game.
#9
02/27/2005 (1:06 pm)
Wow! Thanks for the solution Melv!!

I need to do some digging now. I've seen this problem before in prior projects I've done with DirectX. I've also found a solution to it in the past. The hard part is that after I figure out the solution, it will be a DX solution. Then I'll have to figure out if there is a GL equivalent (there must be).

BTW, I notice that T2D doesn't seem to let me pick DirectX as my renderer on Windows. Perhaps if I put T2D inside my TGE code tree and build? I'm just curious if this is fixed in one API vs. another?

Thanks again for the help!
#10
02/27/2005 (1:29 pm)
I notice you're using true color png's. When I tested it the artifacts went away when I used a Palletized (8 bit) png. This probably isn't the optimal solution, but you may check and see if it helps you for now.
#11
02/27/2005 (1:39 pm)
OK. That's really weird.

That sounds like a bug in GL for sure.
#12
02/27/2005 (2:40 pm)
Did the artifacts go away for you as well?
#13
02/27/2005 (4:15 pm)
That's not a GL bug, that's the way filtering works. There's all sorts of artifacts you start recognizing. It's one of those "bugs" that the first time you see it it could take weeks, the next time you see it, you know what's wrong almost instantly.