/* Renders a tile. * * xp = the starting pixel's x position * yp = the starting pixel's y position * xa = the x position of the pixel being rendered * ya = the y position of the pixel being rendered * tile = the tile to be rendered */

What graphics lib are you using? I am assuming it is Java2D, yes? If you are, then take a look at BufferCapabilities (off the top of my head) not sure if there is an option there or not, I haven't used Java2D in a long time.

Other than than, with my quick scan of your code, I didn't find any logic errors.

I just checked out the java docs for BufferedCapabilities, and there is no vsync option there, the only way to get vsync in Java2D that I know of is to use a GraphicsDevice and a GraphicsEnvironment, then set fullscreen and it is enabled by default (I think)

Aside from that the first thing you should do is cast your Graphics g into a Graphics2D object

I just checked out the java docs for BufferedCapabilities, and there is no vsync option there, the only way to get vsync in Java2D that I know of is to use a GraphicsDevice and a GraphicsEnvironment, then set fullscreen and it is enabled by default (I think)

Aside from that the first thing you should do is cast your Graphics g into a Graphics2D object

Hi mizzath,Java 2d has no functionality to mitigate screen tearing. But java fx has, and the user shannon smith tried it out and reported his results in a thread on these forums. I would search it for you but I'm on my phone right now.Alternatively, instead of switching to java fx and it's scene graph, you could use open gl or libgdx which can be used to get rid of screen tear.Cheers, keith

Maybe the attempt to get a Hardware Double Buffer failed. It doesn't always succeed, particularly when running windowed (or if there isn't any spare graphics memory). Check BufferCapabilities.isFlipping(). You can use BufferStrategy.GetCapabilities() to obtain the capabilities structure. Also check whether your memory card has enough memory to double buffer at your chosen screen resolution.

If it's double buffering by blitting (spell checker keeps changing that to blotting - bad spell check, down boy, down boy), you will get tearing when the window gets above a certain size. It's most noticeable if you have sideways scrolling that scrolls in big increments, or objects that move very fast.

On the whole, I've been most successful with BufferStrategy when going fullscreen. Otherwise, particularly for applets, I often just draw onto a bufferedImage and then draw that to the screen with one call. It still tears if the image is big enough. I rely on not clearing the background every frame and a high frame rate, so that the image doesn't change much between frames. Admittedly I got into that habit for writing 4k games. The BufferStrategy method ought to be better as in some circumstances one might get a hardware double buffer.

Maybe the attempt to get a Hardware Double Buffer failed. It doesn't always succeed, particularly when running windowed (or if there isn't any spare graphics memory). Check BufferCapabilities.isFlipping(). You can use BufferStrategy.GetCapabilities() to obtain the capabilities structure. Also check whether your memory card has enough memory to double buffer at your chosen screen resolution.

If it's double buffering by blitting (spell checker keeps changing that to blotting - bad spell check, down boy, down boy), you will get tearing when the window gets above a certain size. It's most noticeable if you have sideways scrolling that scrolls in big increments, or objects that move very fast.

On the whole, I've been most successful with BufferStrategy when going fullscreen. Otherwise, particularly for applets, I often just draw onto a bufferedImage and then draw that to the screen with one call. It still tears if the image is big enough. I rely on not clearing the background every frame and a high frame rate, so that the image doesn't change much between frames. Admittedly I got into that habit for writing 4k games. The BufferStrategy method ought to be better as in some circumstances one might get a hardware double buffer.

Sounds good; however, how does one debug efficiently whilst working in full screen mode? I generally enjoy the convenience of being able to see the console and write various messages to it.

There is a second glitch in your screenshot. It's a bit smaller than the highlighted one.

Ideas:

- dump the tile positions to stdout and check if they match your expectations- check your tile.render() method if it draws outside the expected are- change the tile.render() method to show outlined squares so you can see overlaps better- check if there is a race condition in your painting code (only if you use several threads)

Lol, I didn't realise that the screen shot square showed the 'tear'. Looks like there's another one a little lower and to the left.I'd say you're not drawing straight lines and that's why the edge is jagged.I agree with varkas that you should just print the points you're drawing and look for the one with a strange y-coord.Good luck!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org