Well I will be giving away one of my fav java coding secrets but here goes....

In applets the paint method sucks!

Don''t bother as it can be confusing to run multiple threads and they run slower, my paint update and repaint methods are all {}

I get the main graphics base in the init() in a global private gm = this.getGraphics()

Now all you have to do it is gm.draw .... to write to the main display, remember you must null lify repaint and update else you will get gray flickers in your painting.

This is faster than a con current paint as the applet has to process two threads....

So go for it! ditch paint, repaint and update, draw stuff real time!

:-)

I''ve tried setting the priority to minimum but this has not helped. I don''t think that there is a problem with synchronization (not that I can see anyway!). I''m going to try just using one thread for the paint and movement, hopefully this will make a difference.

Also, I''m using the sleep method between calls to repaint() and after moving the tank, is that all I need to do to release the CPU? What else could cause the thread that actually updates the screen to become starved? Cyberg mentions processing operating messages in the game code, I''m not sure what he meens by this?

The JVMs I am using to run this is whatever the standard ones that come with JDK 1.1.6 for Windows and Solaris. At the moment I am running it using Appletviewer (and Netscape on Solaris, MS IE5.5 on Windows).

Thanks for the idea of dropping the paint and update method but one of the things I am marked on is code style and I''d prefer to keep them. Also, this has very simple graphics so the paint method does not take long to execute.

If all else fails I can just give specify that it has to be run under Windows (although I''d prefer not to have to do that).

Just out of idle curiosity Dogbert, which Uni are you studying at?

Waassaap!!

University of Sussex in england

Ahh.

I was wondering.
I''m off to Lincoln & Humberside in September (Computing, Games, Simulation, & VR), and having to do everything in Java was one of the things I was told I''d be doing.

What course you on? - I checked all over for games-related courses.

Waassaap!!

I''m doing computer science. Its not a game programming course, I just chose to do a game as part of my 3rd year project (dissertaion type thing).

Good luck with what ever you choose to do

Hey I'm an ex-COGie, well sort of I did Maths and AI at Sussex. Gradudated in '99, I'm now working at the innovation centre (at the top of COGs car park).

Anyway, so what is the actual code you have? Sounds like it's a bug, rather than thread starvation (seeing as you say you are setting the threads to sleep and all).

John

p.s. some friends and I are working on a top down RTS (lots of tanks), see http://ds.dial.pipex.com/town/road/xpm78/duncan/javagame/

Edited by - lilspikey on April 9, 2001 10:44:01 AM

I''ve discovered the cause of the problem. I''m using double buffering to draw to the screen to prevent flickering. When I remove the double buffering it works fine (except for the really annoying flickering!).

To do the double buffering I''m drawing to an offscreen image then drawing that to the screen using graphics.drawImage(offscreenImg). Does anyone know of a more efficient method that wouldn''t cause the problem?

Thanks

Just thought I should let you know I''ve fixed the problem. My paint method was taking too long to execute as I was drawing the offscreen image in the paint method. I''ve moved it out so that now the thread that calls repaint, calls a method to update the offscreen image first. This seems to have solved the problem, thanks for all the help everyone.

Now I just have to get the networking done and debug the collision detection!

Execellent!

I still prefer to ditch paint altogether and grab the base graphics in the applet init!

Let us know when it''s up and

:-)