I've been playing around with various drawing techniques myself and came across a few things that might help you (and others). It seems that the preferred color mode of the G1 is RGB_454 if you don't specify another type for your surface, and it runs much faster in this mode. When drawing on such a surface it is much faster if your bitmaps are RGB_454 or ARGB_4444. To take advantage of this as much as possible I keep an in-memory RGB_454 bitmap the size of the screen that has the background and anything that is relatively static already drawn on it. Drawing the entire screen from the static bitmap only takes 3ms which leaves plenty of time to draw your dynamic pieces on top and you don't even have to worry about fencing off dirty rectangles (although I'm sure that would help speed things up even more).
On Feb 26, 11:58 am, 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 -~----------~----~----~----~------~----~------~--~---
