Java Applet not painting

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|646\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> C/C++/C#/Other -> Java Applet not painting
Sat, 19 Nov 2011, 10:16
shroom_monk	So I decided to try out Java a few weeks ago, and in spare time have begun putting together a game so I can get to know the language better. But I've fallen at the first hurdle. :/ I had a simple thread which repainted the applet several times per second, and it worked. And then I did some completely unrelated code, and it all stopped working. The paint and update methods were definitely being called, but they weren't actually drawing anything, or sometimes only drawing a single frame. I've cut out most of the code to try and pin down the issue, but I still cannot figure out why it's broken. Anyone got any idea? Thanks. import javax.swing.; import java.awt.; /** * The Game Engine. / public class GameEngine extends JApplet implements Runnable { /* * Member Variables / private boolean flag_showFPS = true; private long flag_FPScalc_lasttime = System.currentTimeMillis(); private long flag_FPScalc_thistime = System.currentTimeMillis(); private Thread runner; // Main thread /* * Constructs a new Game Engine / public GameEngine() { } /* * Initialises the Game Engine / @Override public void init() { } /* * Applet paint method * * @param g The graphics object for drawing / @Override public void paint(Graphics g) { update(g); } /* * Applet update method * * This method handles all rendering * * @param g The graphics object for drawing / @Override public void update(Graphics g) { // Prepare the back buffer Image offImage = createImage(getWidth(), getHeight()); Graphics offGraphics = offImage.getGraphics(); // Draw background offGraphics.setColor(Color.black); offGraphics.fillRect(0, 0, getWidth(), getHeight()); // Render FPS counter if (flag_showFPS) { offGraphics.setColor(Color.white); flag_FPScalc_thistime = System.currentTimeMillis(); long FPStemp = flag_FPScalc_thistime - flag_FPScalc_lasttime; if (FPStemp == 0) FPStemp = 1; offGraphics.drawString( "FPS: " + ((Long) (1000 / (FPStemp))).toString(), 0, 10 ); flag_FPScalc_lasttime = flag_FPScalc_thistime; } // Display the back buffer g.drawImage(offImage, 0, 0, null); } /* * Called on applet start or restart / @Override public void start() { // Start main thread if (runner == null) { runner = new Thread(this); runner.start(); } } /* * Called on applet stop / @Override public void stop() { // Terminate main thread if (runner != null) { runner = null; } } /* * Thread run method */ @Override public void run() { // Main thread code while (runner == Thread.currentThread()) { // Redraw everything repaint(); // Sleep thread try { Thread.sleep(20); } catch (InterruptedException e) { // Do nothing } } } } --v -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom!
Sat, 19 Nov 2011, 17:28
shroom_monk	Found the problem at last, and a tiny annoying one it was too. The line g.drawImage(offImage, 0, 0, null); in update() should have this instead of null. Fixed now. -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom!
Sun, 20 Nov 2011, 00:41
Afr0	Just so you know; this refers to the current instance of the current class. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Sun, 20 Nov 2011, 04:37
shroom_monk	What I'm not 100% sure about is what that this is doing. I know that field is meant to be an ImageObserver, and I can pass this because both my class and the ImageObserver class are ultimately derived from Object in one way or another, but I don't quite see what it's doing. -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom!
Mon, 21 Nov 2011, 08:45
JL235	As far as I can tell, the ImageObserver is a callback for when graphics needs to be drawn asynchronously. I'm guessing this is for times when the graphics stack is separated out from the main program a little, or when images are drawn incrementally. Having read up on it in the Java API, I still don't really get what it does or how it relates to this. But if I had to guess, I am thinking your applet doesn't really update when drawImage is called, and passing in the applet object to the drawImage method is allowing to call back and say 'hey, this section has been redrawn, make sure it goes on the screen'. The 'imageUpdate' method in the ImageObserver takes x/y/width/height parameters which hints this to me. In the 5 or 6 used I've been programming Java, including substantial usage of Java 2D, I have _never_ used an ImageObserver, or found a use for one. I always pass in null, and this has included when building applets. But your painting bug can be easily circumvented because your actually building your mainloop incorrectly. The standard paint method is there to be used by applications, where repaints are rare, occur essentially randomly (when the user interacts), and has lots of added boiler plate behind the scenes (like repainting children, z-indexing, update areas, things like that). In short, your constant repaints are fighting the applications standard repainting. For a mainloop you need to be drawing regularly, in a predictable way, with none of that boiler plate. Java offers this by allowing you to disable automatic repaints, and allowing you to build a 'buffer strategy' that you can setup on a component. Not only is this the 'proper' way to do active rendering, it'll also be far more efficient. You can find a guide to do this here on GameDev. If that's a problem, post and I'll dig through my own Java2D code on how I've done it. But Java2D is generally quite slow these days, and I've always found it's too slow for games (even simple ones). So I would advise taking a look at the alternatives. High level options, which hide OpenGL from you include Slick, which is active and used by lots of people, but I've never tried it, and my own SF Library which does everything I ever wanted (also includes a lot of the applet creation and structure bits for you). If you want to try OpenGL directly, then you can also look at LWJGL or JOGL. Both are separate projects for providing OpenGL bindings for Java, and both are active. There are a number of others knocking around, such as Java SDL, but they get very little usage and I don't know how active they are. Finally you'll also be able to find Java game help at Java Gaming.
Mon, 21 Nov 2011, 14:26
shroom_monk	Thanks for all that JL. Interesting to understand how it actually works now. -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom!