Have you considered or tried using: Canvas.drawBitmapMesh<http://developer.android.com/reference/android/graphics/Canvas.html#drawBitmapMesh%28android.graphics.Bitmap,%20int,%20int,%20float[],%20int,%20int[],%20int,%20android.graphics.Paint%29> ?
Maybe you can fake flame flickering by animating mesh vertices instead. On Tuesday, July 17, 2012 2:58:50 PM UTC-5, Matt Schoen wrote: > > Unfortunately I've already done your last suggestion. The images are > pretty small already. I'm still not convinced that the streaming would > work. For one thing, the flicker loops, and for another, the range of > frames changes quite often. For example: > > If the phone starts upright, we play images 90, 91, 92, 93, 94, 95, 90, > 91... > > Then, if you til it, it'll be like 90, 91, 92, 80, 81, 82, 60, 61, 62, 40, > 41, 120, 121, 140, 141... > ^ ^ > ^ ^ ^ > > The carats signify where the accelerometer value has changed so that the > "first" frame is different. This happens quite frequently (to make for a > smooth "bend") and is completely unpredictable. As far as I can tell, we'd > always get a hiccup when the accelerometer value changed. > > I'm really hoping that I can do what I was originally asking for. It > seems so simple to just force the loading of a different set of drawables. > > If I wanted to load the images some other way (not through the drawables > folder) how could I do that? > > On Tuesday, July 17, 2012 12:48:48 PM UTC-4, Nobu Games wrote: >> >> You still could go with the "streaming" idea. At any given time you would >> have a fixed size amount of frames in memory (let's say 15 bitmaps, just as >> an example). As the animation progresses you need to load the next batch >> and discard older ones. In order to prevent loading hickups you could >> proceed as follows: >> >> - Your "window" of animation bitmaps has 15 items. >> - As the animation counter reaches item #6 you would recycle the last >> 5 ones and load the next 5 ones that come after item #15 >> - Loading needs to be done in a background thread (AsyncTask) >> >> Of course you'd need to add special logic for your case, like allowing to >> loop a certain amount of animation frames and starting playback from any >> point of the sequence and so on. But this could be done with a fixed size >> window of frames. >> I think that's the only sane way to do that based on that huge bitmap >> sequence and you could even adjust the window size according to the >> available memory. Play around with these numbers in order to get the best >> result for your animation. >> >> By the way, I would just animate the flame itself and use a single, >> static bitmap for the lighter. That way you could use a low-resolution >> bitmap sequence of the flame and scale it up on devices with less memory. >> Lights and shadows could be faked in real time, too, by drawing overlays on >> the view's canvas. >> >> Maybe you can get away with that solution and don't need to implement a >> streaming technique. >> >> >> On Tuesday, July 17, 2012 9:28:59 AM UTC-5, Matt Schoen wrote: >>> >>> Hey, thanks for the reply. >>> >>> I guess I should have explained more clearly. This is a "lighter" type >>> animation, which responds to accelerometer input. The flame flickers >>> (plays from a start frame on a short loop) and when you tilt the phone, the >>> start frame is "swept" through an animation of the flame bending from one >>> side to another. >>> >>> Because of this, I'm not sure I could really "stream" anything since I >>> might need any one frame of the animation at any point. It just occurred >>> to me that maybe I could store only half the frames and flip them in >>> software (currently the "flip" is just rendered into the animation). >>> >>> This is why I'm just using a big image sequence (about 150 frames) as >>> drawables. Any advice? >>> >>> On Saturday, July 14, 2012 12:26:13 PM UTC-4, Nobu Games wrote: >>>> >>>> How many items are in your animation list? If it is really, really huge >>>> I'd add some "streaming" logic to your animation player, so older frames >>>> get recycled while future frames are loaded in the background. That way >>>> you >>>> have absolute control over a moving window of frames and you could size >>>> that window according to the available amount of free memory. You wouldn't >>>> risk OOM crashes on any device with that technique. >>>> >>>> Alternatively you could create a video based on your frames and play >>>> that one back instead. >>>> >>>> >>>> On Friday, July 13, 2012 10:54:46 PM UTC-5, Matt Schoen wrote: >>>>> >>>>> Hey there, >>>>> >>>>> I've tried to find info on this, but it seems like a pretty esoteric >>>>> case. I'll admit that I'm probably completely off-base to start, but the >>>>> app is 99% done, so I'd rather not change my implementation from it's >>>>> current state. I have an animation that I'm using a big list of >>>>> drawables >>>>> to display, and while it works fine on phones with enough RAM, I get "VM >>>>> out of memory" crashes on devices with basically 512 MB RAM and below. >>>>> >>>>> I've found the getMemoryClass() function, which seems to report "32" >>>>> for a device with 512MB. I tried overriding the density value, which >>>>> successfully avoided the crash, but also resized my whole view! All I >>>>> want >>>>> is to be able to programmatically tell the view framework to default to >>>>> the >>>>> low-res images. Is this possible? >>>>> >>>> > On Tuesday, July 17, 2012 12:48:48 PM UTC-4, Nobu Games wrote: >> >> You still could go with the "streaming" idea. At any given time you would >> have a fixed size amount of frames in memory (let's say 15 bitmaps, just as >> an example). As the animation progresses you need to load the next batch >> and discard older ones. In order to prevent loading hickups you could >> proceed as follows: >> >> - Your "window" of animation bitmaps has 15 items. >> - As the animation counter reaches item #6 you would recycle the last >> 5 ones and load the next 5 ones that come after item #15 >> - Loading needs to be done in a background thread (AsyncTask) >> >> Of course you'd need to add special logic for your case, like allowing to >> loop a certain amount of animation frames and starting playback from any >> point of the sequence and so on. But this could be done with a fixed size >> window of frames. >> I think that's the only sane way to do that based on that huge bitmap >> sequence and you could even adjust the window size according to the >> available memory. Play around with these numbers in order to get the best >> result for your animation. >> >> By the way, I would just animate the flame itself and use a single, >> static bitmap for the lighter. That way you could use a low-resolution >> bitmap sequence of the flame and scale it up on devices with less memory. >> Lights and shadows could be faked in real time, too, by drawing overlays on >> the view's canvas. >> >> Maybe you can get away with that solution and don't need to implement a >> streaming technique. >> >> >> On Tuesday, July 17, 2012 9:28:59 AM UTC-5, Matt Schoen wrote: >>> >>> Hey, thanks for the reply. >>> >>> I guess I should have explained more clearly. This is a "lighter" type >>> animation, which responds to accelerometer input. The flame flickers >>> (plays from a start frame on a short loop) and when you tilt the phone, the >>> start frame is "swept" through an animation of the flame bending from one >>> side to another. >>> >>> Because of this, I'm not sure I could really "stream" anything since I >>> might need any one frame of the animation at any point. It just occurred >>> to me that maybe I could store only half the frames and flip them in >>> software (currently the "flip" is just rendered into the animation). >>> >>> This is why I'm just using a big image sequence (about 150 frames) as >>> drawables. Any advice? >>> >>> On Saturday, July 14, 2012 12:26:13 PM UTC-4, Nobu Games wrote: >>>> >>>> How many items are in your animation list? If it is really, really huge >>>> I'd add some "streaming" logic to your animation player, so older frames >>>> get recycled while future frames are loaded in the background. That way >>>> you >>>> have absolute control over a moving window of frames and you could size >>>> that window according to the available amount of free memory. You wouldn't >>>> risk OOM crashes on any device with that technique. >>>> >>>> Alternatively you could create a video based on your frames and play >>>> that one back instead. >>>> >>>> >>>> On Friday, July 13, 2012 10:54:46 PM UTC-5, Matt Schoen wrote: >>>>> >>>>> Hey there, >>>>> >>>>> I've tried to find info on this, but it seems like a pretty esoteric >>>>> case. I'll admit that I'm probably completely off-base to start, but the >>>>> app is 99% done, so I'd rather not change my implementation from it's >>>>> current state. I have an animation that I'm using a big list of >>>>> drawables >>>>> to display, and while it works fine on phones with enough RAM, I get "VM >>>>> out of memory" crashes on devices with basically 512 MB RAM and below. >>>>> >>>>> I've found the getMemoryClass() function, which seems to report "32" >>>>> for a device with 512MB. I tried overriding the density value, which >>>>> successfully avoided the crash, but also resized my whole view! All I >>>>> want >>>>> is to be able to programmatically tell the view framework to default to >>>>> the >>>>> low-res images. Is this possible? >>>>> >>>> -- 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
