If that part is redundant, how can I get the g object for drawing? I'll research it. It's ironic that the flicker occurs in the supposedly cheapest part of the game, talking in CPU time. It makes me doubt about
Any code in your draw that does not have to do with actually displaying the image on the screen needs to be removed
Although I'll research about the bufferedImage stuff
What I'm seeing is that you are trying to do some type of active rendering and not being very successful at getting it to do so without flicker. The flicker is brought about by overrunning your dead time between screen writes, or by clearing and then taking too long to write your graphics. This should be elevated by using SWING as the SWING components are double buffered by default. What you are doing still remains a mystery to me as you have not provided graphics execution path code, just snippets. In animation you are literally multitasking fast enough to fool the eye, but in the case of flicker, you're illusion is breaking down because the writes to the screen as prolonged by sluggish routines. The animation portion of your routines have to be very tight in order to sustain the illusion.
Edited by: morgalr on Mar 9, 2010 6:51 PM -- the follwing added:
You get your gaphics object by doing a: getGraphics() or createGraphics on your display component.
Morgalr, I've been researching about the "canonical" way of drawing in java, and I found that the code I have isn't very good because I'm drawing constantly all the elements in the scene. I'm changing my program (bufferedimages, override paint method of the panel class, etc), I'll post this evening and I tell you, but I'm optimistic regarding to this