What is the best ways to increase animation performance. I have been looking around, but I''m not finding much good info. I am pretty sure the best way to do it would be to only redraw the areas that have changed, but what is the best way to do this? prophecy

I think i answered my own question.

If you set the clip on the Graphics2D object you can substantially increase performance.

g2.setClip()

Set this to only draw the background area that needs to be drawn, then draw your new changes with the clip set back to the full size.

prophecy

Any suggestions on how to deal with scrolling backgrounds? I''m using clipping to copy the least amount to the screen, but when I scroll around my map (tile based RTS game) I have to go back to fullscreen (full-window) repaints. I currently have a kludge in place that only moves the screen once in a while (not every time step), but it means it seems unresponsive.

I guess one way to do it, might be to just to do a copyRect to move the bulk of the screen and correct the edges as I go. I don''t care if it mess-up a bit (i.e. objects appear not to move when you scroll), as I am more concerned with fast scrolling, if the player wants see whats at a certain place they can stop scrolling.

Anyway ...

cheers,
John

I think the best bet for you here would be to have the entire (if it''s not too big of course) map in an BufferedImage object then when you are drawing to the screen, just clip the area of that image into the Graphics object.

BufferedImage map ...
mapg.setClip(x,y,w,h); // depending on what you want to show, width and height would be displayable area.

then draw that to the Graphics2D object.

Try that and let me know if it works for you.


prophecy

But what kind of performance are you getting with full scrolling backgrounds anyway??
I''m writing a game at the moment that has full-screen scrolling involved practically all of the time and I''m getting it to run at 35 fps in a 512*512 area on a PII-400, but this isn''t an applet.. I don''t know how much difference that would make.

The biggest problem I''m having (or at least on Windows systems) is overcoming the low resoulution of System.currentTimeMillis(), the value returned only changes 18/19 times a second which means that without doing some clever trickery my frame rate is going to max out at around 18, there was a thread about this a few months ago... My whole game hangs on the value returned by this so there isn''t really a way I can change it.

Dewi.

Fullscreen scrolling on a PIII 450 (Win NT) was dropping to 15fps or so, sometimes less. Whereas on a G3 400 (MacOS 9) the fps drop is hardly noticeable.
The whole map is either 32*32 or 64*64 tiles big, where each tile is 64*64 pixels, so it''s too big to fit into one image.

The other thing is that I''m restricted to java 1.1, for compatibility purposes. This is because most of my development at home is on an mac and java 2 support is only in OS X, which is not out for another month, and because I like to at least write and compile the code (not run the game) on my psion, which does not do java 2 either.

I''ve tried out the copyRect, it seems to work well enough, but the tricky bit is deciding what to do with the areas that has not been updated (around the edges), at the moment I am blacking it out, but it''s not perfect.

So how are you doing scrolling backgrounds?

As for the currentMillis thing, you could try adding up the time taken for each step, over say 10 steps and compare it to the "real" time those 10 steps took. You could then use that to correct the following timesteps. Obviously you could sample more frequently (say every 2 timsteps) but it''ll get less accurate.

Why do you use the System.currtimeMillis() function? Why not just sleep the thread for however many milliseconds you want?

prophecy

because you don''t know how long to sleep. If you want say 20 frames a minute how long do you sleep? 50? Only if your game loop takes 0 time. If it takes 10 ms, then you want to sleep for 40. It it takes 30 ms sleep for 20. Each time it loops through it might take a different amount of time. So what you want to do is time how long it takes to finish. So you check what time it is at the start of your game loop, then figure out the time at the end, and substract to find out how long it has been. loopTime = endTime-startTime. Then you need to figure out how long to sleep. sleepTime = totalTime-time. Or you could combine the two: sleepTime = totalTime-endTime+startTime.

Yeah, like someone else said, I have to use System.currentTimeMillis(), but I''ve been looking in to implementing some kind of system where it calculates how long each frame takes (that''s updating and drawing) and use a time based on this value, correcting on the fly comparing against the system clock as it goes. I think you should be able to do this as long as you haven''t got any optimisations in place for not drawing anything to the screen if nothing has changed for example...

But this is how I draw to the screen, it''s doublebuffered, but I''m just using a simple Image object as opposed to going through the BufferedImage object-there seemed to be a lot of crap in there that you didn''t need, so I draw everything to the 512*512 double buffer, and everything is in 24 bit colour, I found 32 bit made quite a big difference, and then it draws the buffer to the screen. Most of the stuff I''m drawing to the buffer are ''pre-compiled'' Images, but I''m having to create some through MemoryImageSource because of the restrictions I''ve placed on having 24 bit colour.
I hope I explained that reasonably well...

That method worked pretty well, if not better on version 1.1 of the JDK, I think, because I was using 1.1 until fairly recently in development but then I migrated to using Swing for the level editor...

Dewi.

Yeah, like someone else said, I have to use System.currentTimeMillis(), but I''ve been looking in to implementing some kind of system where it calculates how long each frame takes (that''s updating and drawing) and use a time based on this value, correcting on the fly comparing against the system clock as it goes. I think you should be able to do this as long as you haven''t got any optimisations in place for not drawing anything to the screen if nothing has changed for example...

But this is how I draw to the screen, it''s doublebuffered, but I''m just using a simple Image object as opposed to going through the BufferedImage object-there seemed to be a lot of crap in there that you didn''t need, so I draw everything to the 512*512 double buffer, and everything is in 24 bit colour, I found 32 bit made quite a big difference, and then it draws the buffer to the screen. Most of the stuff I''m drawing to the buffer are ''pre-compiled'' Images, but I''m having to create some through MemoryImageSource because of the restrictions I''ve placed on having 24 bit colour.
I hope I explained that reasonably well...

That method worked pretty well, if not better on version 1.1 of the JDK, I think, because I was using 1.1 until fairly recently in development but then I migrated to using Swing for the level editor...

Dewi.