Actually it's RGB_565, but yeah this is the format of the G1 screen so you really really want to work with things in that format when possible.
On Thu, Feb 26, 2009 at 1:37 PM, Sarnoth <jesse.st...@gmail.com> wrote: > > 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 > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
