I have recently started developing in Java.. which I think is a great language and decided to do some graphic applications (games).so I began doing something which uses double buffered graphics, the game consists a falling ball which avoids obstacles by pulling itself up whenever space is pressed (a tribute to a friend of mine who did it in VB ), anyway.. the mechanics are all done and i want to replace my ball (filled oval) with an image of a ball, I've tried different techniques to load an image and draw it to a Graphics2D object, but no luck.. so could anyone explain how to do it?

My second question relates to the double buffering technique, I know it is used to prevent flickering. but my obstacles (which are currently empty 3DRects) are tearing as they move (I switched to draw3DRect from fill3DRect because i wanted to hide the tearing effect,

My technique is as follows - i get the graphics from an Image, render my ball, obstacles etc. to it and then calls repaint(), I have overrided paintCompotent(Graphics g), so it should be ok (It is explained in a book about java games programming).

I haven't used J2D in a while, but the tearing effect is common to all games that dont sync their frame rate with the monitor's refresh rate.

The monitor refreshes the screen from the top left working its way down and right, the frequency of the monitor is how many times it can do that in a second. What happens whe you have a frame rate that is higher than that of the monitor's refresh rate is that when the monitor is refreshing, the data is updated, its draw the last frame, but by the time its gotten to the new row, the data has been updated, the rectangle is in a different position, and thus the lower half of the rectangle is in a different position, hence the tearing. The best way to avoid this is to cap your FPS to that of the monitor's refresh rate.

I think you can only use vsync in fullscreen exclusive mode with swing, seems like it was enabled when I had the ogl pipeline enabled though... Also, will using a redraw rate less than the monitors refresh rate really solve the problem? Certainly the problem would be less, but you could get tearing at any refresh rate just as long as the screen contents is being changed in the middle of a refresh, right?

Repaint is asynchronous. You have no idea when its going to occur. You need to wait for the image to have been painted before you can start drawing the next frame to it.

You could solve this by overriding paint() and using a mutex-wait type logic, but honestly this starts beigna lot of work to do it in a bad way. The better way to do all of this is to use buffer strategy and active rendering. See this article for more details:

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