You're welcome ;) Cheers
On Thu, Feb 26, 2009 at 6:58 PM, snctln <catlin.s...@gmail.com> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
