Jump to content

  • Log In with Google      Sign In   
  • Create Account


[java] Increasing Animation performance


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 prophecy   Members   -  Reputation: 122

Like
Likes
Like

Posted 12 February 2001 - 02:34 PM

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

Sponsor:

#2 prophecy   Members   -  Reputation: 122

Like
Likes
Like

Posted 12 February 2001 - 05:45 PM

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

#3 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 12 February 2001 - 11:27 PM

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

#4 prophecy   Members   -  Reputation: 122

Like
Likes
Like

Posted 13 February 2001 - 05:24 AM

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

#5 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 15 February 2001 - 12:20 AM

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.

#6 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 15 February 2001 - 05:42 AM


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.

#7 prophecy   Members   -  Reputation: 122

Like
Likes
Like

Posted 15 February 2001 - 09:24 AM

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

prophecy

#8 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 15 February 2001 - 11:06 AM

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.

#9 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 16 February 2001 - 05:15 AM

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.

#10 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 16 February 2001 - 05:17 AM

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.

#11 Jerry Lynn   Members   -  Reputation: 122

Like
Likes
Like

Posted 16 February 2001 - 09:05 AM

We have a FAQ entry on the timing resolution issue...

http://games.cpbinc.com/faq/theory.asp#t2

#12 Jiim   Members   -  Reputation: 136

Like
Likes
Like

Posted 18 February 2001 - 10:48 PM

Mmmm... I ain''t keen on any of the alternatives mentioned in the FAQ, I want to keep it pure Java, which rules out all the alternatives except for the JFM, and it is debatable if the JFM is more pure Java than any of the others.

I reckon that what I''ve got in mind should work fine, I tried it on my machine, hard-coding a value for the time increment for each frame and it worked very well, I just need to write a piece of code that is going to calculate and correct this value on the fly so that it is uniform across different machines, shouldn''t be too difficult.

Dewi.

#13 c_wraith   Members   -  Reputation: 122

Like
Likes
Like

Posted 19 February 2001 - 06:30 AM

quote:

We have a FAQ entry on the timing resolution issue...

http://games.cpbinc.com/faq/theory.asp#t2



Hey! That quote you start that section in the FAQ with is from me, not Jacob Marner.

http://www.gamedev.net/community/forums/topic.asp?topic_id=31877

You of course have my permission to use it... Could you just straighten out the crediting?

#14 Jerry Lynn   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 February 2001 - 03:37 AM

Corrected : )

#15 c_wraith   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 February 2001 - 04:04 AM

Thanks. =)

#16 javanerd   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 February 2001 - 10:20 AM

I''ve said this before and I think someone else has noticed this too: The JMF timers are no better than the System.currtimeMillis() function. The resolution is unfortunately the same.

#17 Jiim   Members   -  Reputation: 136

Like
Likes
Like

Posted 27 February 2001 - 12:21 AM

I implemented the method I described in a previous post and it has worked very well as a work-around to the low resoulution of the timer. Although the complexity of each level varied, on any given level the frame rate was stable enough for me to be able to do what I described with quite astounding effect. I found that the best kind of time-frame to use was something in the region of 4-5 seconds with sampling the frame rate once a second, the game would run slightly faster than it should do sometimes due to a low frame-rate in the previous second but using a time-frame of 4-5 seconds would overcome this.

I don''t mind but I could write a short piece about this if there was an interest??

Dewi Williams.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS