you cant possibly imagine how frustrated I am by now Im trying to make a tile map to render to the screen and using a texture atlas with 0pixels of separation between tiles yesterday I finished to make the renderer, everything seemed fine until I developed a camera system and started moving around my scene. Some glitches appeared, namely some green lines that in my opinion is texture information from a neighbor tile. after searching the internets I found this http://www.ziggyware.com/forum/viewthread.php?forum_id=12&thread_id=12762&rowstart=0 where some guys explains more or less the same problem I was having. so I took the time to read the whole thread and got to the conclusion that a separation between tiles was needed in order to avoid this glitch. today I edited my tile editor to produce a tileset with separations of 1px between tiles, and guess what happened after spending the whole day coding the render method inside the engine the effin glitch WAS STILL THERE! a couple of screenshots for the ones that dont feel to read the whole post

This happened to me as well. It was an easy fix, for me, anyhow. Try modifying the size of the tile - in my case, if the tile used an odd number as its width and height, it rendered with spaces between tiles. If that doesn't work, then it's definitely a problem with your rendering code.

hi fatso thanks for the reply

Im not trying to bash your comment but that didnt make any sense from a logical point of view

in case you wanted to know what the problem really was the camera that used floats to move around the scene :S

anyways good job on your xna game fatso keep it up

bye

you see this problem only appeared as soon as I started moving the camera round but if I leaved the camera on its start position or just returned it to 0,0 after moving it around , the glitches disspeared

Quote:Original post by Moe
So wait, you are saying that using floating point numbers to keep track of your camera resulted in this problem? Something seems a bit fishy with that.

It makes perfect sense. If you offset an integer pixel position (like the tile) by the floating point camera, you wind up with a floating point pixel position. Since that's physically impossible, the GPU will perform some filtering on the texture. Once it does that, you're liable to see artifacts like this. That's why, when working in 2D, it's generally recommended that you round all positions to integers for rendering (of course, you can still store them as floats for physics and such; the rounding is only needed for rendering).

Quote:Original post by NickGravelyn

Quote:Original post by Moe
So wait, you are saying that using floating point numbers to keep track of your camera resulted in this problem? Something seems a bit fishy with that.

It makes perfect sense. If you offset an integer pixel position (like the tile) by the floating point camera, you wind up with a floating point pixel position. Since that's physically impossible, the GPU will perform some filtering on the texture. Once it does that, you're liable to see artifacts like this. That's why, when working in 2D, it's generally recommended that you round all positions to integers for rendering (of course, you can still store them as floats for physics and such; the rounding is only needed for rendering).

This is exactly what my problem was during development. By clamping to only even numbers for tile sizes, I eliminated the possibility of a fractional pixel position. Since I was cutting odd numbers in half for rendering, the resulting float would be something point 5, which is physically impossible. That makes a heck of a lot more sense than what I thought earlier.