Thank you very much for this reply, your advice about not using a high quality png seemed to make all of the difference... My problem wasn't with the png really but was more the way that I was working with the png
I was loading the png into a bitmap, and then resizing that bitmap as needed for the background, BUT I was going about it all wrong.... Old Attempt m_backgroundBmp = Bitmap.createBitmap(backgroundWidth, backgroundHeight, Bitmap.Config.ARGB_8888); m_backgroundPngDrawable.setBounds(backgroundRect); Canvas c = new Canvas(backgroundBmp); m_backgroundPngDrawable.draw(c); New Attempt (from lunarlander) m_backgroundBmp = BitmapFactory.decodeResource(context.getResources(), R.drawable.background); m_backgroundBmp = Bitmap.createScaledBitmap(m_backgroundBmp , backgroundWidth, backgroundHeight, true); I didn't change any of my actual drawing code, just this bitmap loading/sizing code, and I went from about 24 fps to 60 fps, I guess that is teh difference between with with a 24 bit bitmap and a 32 bit bitmap I know I need to do some more profiling and work on my timestep code, but this definitely helps a lot, thanks. So in summary I am still not sure why I was seeing flickering when using very small rectangles, probably just errors in my code and not drawing the whole rectangle I guess. I am using the lockCanvas(dirtyRect) on a large region of the screen and am getting a nice performance increase over redrawing the whole screen Thanks again ---snctln On Feb 26, 3:05 am, Stoyan Damov <stoyan.da...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
