• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

prophecy

[java] Increasing Animation performance

16 posts in this topic

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
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites
Why do you use the System.currtimeMillis() function? Why not just sleep the thread for however many milliseconds you want?

prophecy
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites