On Thu, Feb 26, 2009 at 5:53 AM, snctln <catlin.s...@gmail.com> wrote: > > Stoyan, > > I appreciate the reply (especially because I believe we have competing > games up on the paid market).
np :) It's not that I'm sharing a trade secret here. > > I will go back and look at my code again, I am probably doing it > wrong... > > currently I have 4 approaches to updating the screen > > Approach #1 - (Original Approach) Update the whole surface, this works > ok (30 fps) when I just have a solid color background , but once I add > in a complex bitmap to the background the performance falls to about > 18-20 fps Are you doing too many updates (as opposed to drawings)? 30 fps doesn't look right. With < 50 blocks and music (not sfx) turned off I'd get ~60 fps. Now here's a trade secret ;) -- careful with the background, I wouldn't use a high quality .png. You need to time the time you spend in updates and the time in drawing - if it's something like ~70 (drawing) / ~30 (updates) you'll probably get high fps. > > Approach #2 - Specify A large dirty rect that encompasses all possible > areas of update (things that can change multiple times a second), this > yields great results for solid color background (60 fps), but still > only gives me 24fps or so for a complex bitmap background This is the approach I use although a bit modified because of the specifics of my game - I have 2 dirty rectangles which I switch every now and then - one is bigger than the other and encompasses it. > > Approach #3 - Draw the current screen state to a bitmap member > variable, and make multiple calls to lockCanvas(DirtyRect) and specify > only the areas that have changed and then do a drawBitmap and copy the > regions from the screen bitmap member variable to the canvas, this > approach seems to be the worst as it has the most flicker and > artifacts I wouldn't do that. How many fps have you squeezed using this approach (if you do use it)? > > Approach #4 - Draw to a bitmap like in approach #3, but rather than > doing multiple lockCanvas calls, just add all of the rectangles > together to get one large rectangle that encompasses all of the areas > that need to be updated and call lock canvas on that then draw to that > area from the bitmap, this seems to work better the #3 but stil leaves > artifacts.... Haven't tried that either. > > Did you take any of these approaches? > > I probably have holes in my code and will be going over it all > tonight. You need to profile your game - basically my advice to anyone doing optimizations is to think instead of looking at profiling tools output, but every once in a while (including a case w/ my game on Android) you can see stuff in the profile output which you couldn't have possibly expected. > > thanks again for the reply You're welcome > > ---snctln > > > On Feb 25, 7:34 pm, Stoyan Damov <stoyan.da...@gmail.com> wrote: >> I can't give you a solution - there's no problem. The bug was, I said >> in the post link you pasted, in my code - I was not drawing what I had >> to. Basically, if you follow the single rule (draw all pixels on the >> invalidated rectangle) you'll be fine. >> >> Just sprinkle a few log statements to see what your'e supposed to draw >> and where are you drawing it and you'll see your mistake. >> >> Cheers >> >> On Wed, Feb 25, 2009 at 10:45 PM, snctln <catlin.s...@gmail.com> wrote: >> >> > So I am trying to do all I can to increase the FPS on one my games. >> >> > When trying to draw a bitmap to the background of a canvas, and then >> > call unlockAndPost() on that canvas the fps rate goes down about 30% >> > So I am trying to work with thelockCanvas(dirtyRect) function, but it >> > doesn't seem to behave the way I would think it should. >> >> > It seems as though this function works, but it is just about useless >> > because of the double buffer nature of the surfaceHolder, ie i can >> > redraw an area on one buffer, but because it only invalidates one of >> > the buffers some artifacts are seen when the next buffer draws. >> >> > Here are the posts describing the double buffer nature of >> > surfaceHolder, but they don't seem to answer my question >> > - >> >http://groups.google.com/group/android-developers/browse_thread/threa... >> > - >> >http://groups.google.com/group/android-developers/browse_thread/threa... >> >> > and this posts mentions the exact same problem I am having but doesn't >> > have a solution posted >> > - >> >http://groups.google.com/group/android-developers/browse_thread/threa... >> >> > So my question is, what am I doing wrong? Is there a reason why >> > calling unlock and Post on a canvas that has a bitmap drawn on 70% of >> > the background get drawn slower than a canvas that just wipes the >> > screen clear with a call to drawColor(color)? What is the proper way >> > to call locakCanvas(dirtyRect) so that both buffers are updated? >> >> > thanks for any answers, suggestions, or pointers >> >> > ---snctln >> >www.snctln.com > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
