Jump to content
  • Advertisement

EasyCoder

Member
  • Content Count

    53
  • Joined

  • Last visited

Everything posted by EasyCoder

  1. In my Android game, I am playing short sound effects using AudioManager and SoundPool.   While this works fine on Samsung Galaxy Tab 10.1, when I ported the game to Samsung Galaxy SIII, I am experiencing strange lock-ups of the screen and crashes of the application with re-booting of the phone, when I am trying to play the sound from the SoundPool.   It behaves quite erratically and one of 4 things happen (in no particular order):   (1) Application starts as normal and all sounds play normally.   (2) Application crashes completely and mobile reboots.   (3) Application freezes shortly (3-5 seconds) upon trying to play the sound, then continues normally, but sounds don't work.   (4) Application starts as normal, but none of the sounds plays. *   * There is a strange twist to the 4th case. None of the sounds plays, but when I activate game background music (which plays via MediaPlayer, not via AudioManager/SoundPool) this somehow 'flushes down' the stuck sound effects which should play at the beginning of the game, and now they all catch-up and play at once. This 'flushing down' somehow returns everything back to normal and from this point on all the sound effects from the SoundPool play normally, as they should.   The error which I am getting is:   AudioTrack: obtainBuffer timed out (is the CPU pegged?) "CPU pegged" what the hell does it even mean ???   Note that the problems happen at the point in the game when I am attempting to play the sounds from the soundpool by SoundPool.play, not when I am loading them by SoundPool.load.   I tried just about everything and now I am at the end of my wits. Did anybody have the same problem? Any help is highly appreciated.    
  2. I have spent on this problem now over a week, took the whole class apart, modified, changed parameters, removed bits which I thought could cause the problem... No improvement. Re-sampled all sounds to the lowest sampling rate possible... No improvement either.   I am getting really fed up with this problem and starting to think I might dump the whole unreliable SoundPool and replace it with some other way of playing sounds...   Does anybody have any suggestions as to what is the best and most reliable way of playing sounds in Android? (not music - short sound effects).
  3.   It happens immediately after start of the app, when I attempt to play the first sound.
  4. I have several 2D objects (simple squares with bitmaps on them) which I need to rotate on y axis (i.e. from left to right) all at the same angle. However, when I use glRotatef command, the objects on the right side of the screen are rotated the most, and progressively towards the left side of the screen, they rotate less and less. If I have let say 15 objects side-by-side, the difference in rotation between the leftmost and rightmost object is quite substantial and clearly visible. I assume this is something to do with the perspective, but cannot figure out what I am doing wrong. Just for interest, if I rotate the same objects on x axis (i.e. from forward to backward) the angle is the same for all of them ! Anybody knows how to achieve rotation at the same angle for all the objects on y axis ? Thanks in advance for any suggestions.
  5. EasyCoder

    glRotatef behaves strange

    Cool - so then this topic can be closed
  6. EasyCoder

    glRotatef behaves strange

    Yes, your explanation makes perfect sense to me. And gluOrtho2D works like a charm ! Now all 15 objects rotate exactly at the same angle. Thanks for your help & suggestion. Only one more question: can you swap back and forth between gluOrtho2D and gluPerspective within the onDrawFrame ? This is for a game which I am developing, and the engine is already finished and working fine in gluPerspective, so I am not very keen to change it to gluOrtho2D. I just want to do that rotation effect in gluOrtho2D, then get rid of the objects and swap back to gluPerspective. Is this possible ?
  7. EasyCoder

    glRotatef behaves strange

    I see. Is there any way to change the perspective, so they all appear the same ?
  8. EasyCoder

    glRotatef behaves strange

    [attachment=10267:glRotatef-y.jpg] So this is how it looks like, when I use the above code. I am using GL_MODELVIEW in glMatrixMode and fovy (field of view angle in y direction) in gluPerspective is set to 45.0f. Could it have anything to do with fovy, as it is also in y direction ?
  9. EasyCoder

    glRotatef behaves strange

    This is how the code looks like: while (column <= 15) { gl.glLoadIdentity(); gl.glPushMatrix(); gl.glBlendFunc(GL10.GL_SRC_ALPHA, GL10.GL_ONE_MINUS_SRC_ALPHA); gl.glEnable(GL10.GL_BLEND); gl.glTranslatef(column, row, -5.0f); gl.glRotatef(45.0f, 0.0f, 1.0f, 0.0f); gl.glScalef(0.25f, 0.25f, 0.0f); object.draw(gl, bitmap_index); gl.glPopMatrix(); } The 15 objects are identical 2D squares with the same bitmap mapped on them.
  10. EasyCoder

    glRotatef behaves strange

    No, you did not get me - it is not happening on all the axes - that is the weird thing. Of course I meant it is not happening when I rotate around those two axes, i.e. when I use: gl.glRotatef(45.0f, 1.0f, 0.0f, 0.0f) or gl.glRotatef(45.0f, 0.0f, 0.0f, 1.0f) All 15 objects rotate at the same angle, no accumulation there. And the code is the very same - that is what confuses me.
  11. EasyCoder

    glRotatef behaves strange

    I of course use glLoadIdentity as well as glPushMatrix & glPopMatrix. [/quote] Yes, after some experimenting I found that the rotations really ad up. I started with glRotatef(45.0f, 0.0f, 1.0f, 0.0f) and I got objects on the right side of the screen rotated the most and on left side the least (just what would you expect if the rotations gradually add up) Just to confirm that, I then tried gl.glRotatef(675.0f, 0.0f, 1.0f, 0.0f) (as I have 15 objects => 15 * 45 = 675) and lo and behold, now it was opposite - i.e. objects on the left side of the screen were rotated the most and on right side the least !!! So that is clear. Now there are just 2 questions remaining: 1) Why is this not happening with x or z axis, only with y ?!? 2) How to avoid this adding-up of rotation ?
  12. EasyCoder

    glRotatef behaves strange

    I of course use glLoadIdentity as well as glPushMatrix & glPopMatrix.
  13. I have tried all combinations of GL_CLAMP_TO_EDGE and GL_REPEAT for S and T coordinates without any change. But thanks for pointing me in this direction, because I have looked on the tutorial where I took some of the code from, again and found this comment by someone: I was trying to implement a similar functionality using glDrawArrays. However, I’m unable to get it running on Android. I’m trying port an existing iPhone application to Android. The same openGL code works fine on iPhone. I am also using glDrawArrays, so I suspect this will be the root of my problem. I will try replacing glDrawArrays with glDrawElements and see if that makes any difference.
  14. Anybody knows how to roll a texture over the face of an object in OpenGL ES ? (not rotate the whole object, just roll the texture over the object's face) It means that the topmost line of pixels will be removed, all lines will be shifted 1 pixel up, and the topmost line of pixels will be added at the very bottom, etc, etc... until the texture ends up in original state. That will cause the rolling effect of texture over the face of an object, as demonstrated below. from this: 000XX000 00X00X00 0X0000X0 X000000X to this: 00X00X00 0X0000X0 X000000X 000XX000
  15. I am returning to this problem after long time as I still haven't quite cracked it. I already thought I have figured it out. When I gradually increase roll variable, texture nicely rolls over the object (square) as desired. float[] texCoords = { 0.0f, 1.0f + roll, // A - left-bottom 1.0f, 1.0f + roll, // B - right-bottom 0.0f, 0.0f + roll, // C - left-top 1.0f, 0.0f + roll // D - right-top }; However, only in the emulator (on Eclipse). If I run the same code on the actual device, the texture does not roll continuously over the square (what I am trying to achieve), but scrolls of the square gradually completely until it disappears. For better understanding, instead of desired effect: from this: 000XX000 00X00X00 0X0000X0 X000000X to this: 00X00X00 0X0000X0 X000000X 000XX000 I get: 00X00X00 0X0000X0 X000000X X000000X then: 0X0000X0 X000000X X000000X X000000X then: X000000X X000000X X000000X X000000X Basically, I get scrolling, instead of rolling I suspect it is something in the way how I am wrapping the texture over the square, but I cannot figure out what parameter I have to change to get the desired rolling effect. Anybody has tried this already before and knows how to achieve the rolling of the texture over the square ? What I am trying to achieve is that the topmost line of pixels will be removed, all lines will be shifted 1 pixel up, and the topmost line of pixels will be added at the very bottom, etc, etc... until the texture ends up in original state, and then the whole process starts again. Thanks for any help.
  16. I am designing an Android game, and as the games go, they contain lots of bitmaps. Mine is not exception and I am loading them via BitmapFactory by the following instruction: bitmap = BitmapFactory.decodeStream(context.getResources().openRawResource(imageFileIDs[IndexOfBitmapHere])); Everything goes great, until certain amount of calls to the above instruction - then the app keels over with the Out Of Memory message. Thing is, that after uploading let say 40 bitmaps of the same size, I have still 70% of Memory Free. Then I upload just one more additional bitmap of the same size, which should take me comfortably to some 69% and instead all goes bang - OOM !!! The garbage collector suddenly reports it has only 3-2-1% of memory left, then OOM crash. There is obviously some bug in Android (I am running this on 3.0) and I cannot figure out what it is. I have tried just about everything and now I am stuck with this annoying issue already 2 weeks. Does anybody know what causes it and what is the way around ? Any help is highly appreciated.
  17. Of course !!! Sometime you are looking for a solution and cannot see that which is right under your nose. It is because I program in Android / Java environment only a couple of months and still cannot get used to some of its quirks. I am now loading the level-dependent bitmaps via functions in Activity, but I am calling these from my main game loop which is in onDrawFrame. I did not use your approach of writing the dedicated class for handling the bitmaps (though it may be neater solution) as my game is now 99% finished and this would mean substantial rewriting of everything and further delays with finishing the game. Application still struggles at the startup, going as low as 1% of the available memory (as in above log), but then recovers and increases to some 74% - that with 95% of all bitmaps required for the game already in. I am a bit concerned about this startup struggling, but I have run it yesterday about 50 times on the actual device and it did not go OOM a single time, so I guess this is some inherent feature of Android. Thank you for all your help and patience Fiallen !
  18. Many thanks Fiallen This looks very promising. I will do some tests based upon your suggestions through this weekend and then let you know how did it go.
  19. As you can see, there is no way how 50 bitmaps take 29% of the memory and then only 1 additional bitmap takes remaining 71% - there must be something else going on, most likely too many allocations too quickly, as we both concluded above. This is why I would prefer to load only bitmaps for one level at a time which would completely solve all my problems. But how to do it, if I need for that the damned Context and I cannot get it within onDrawFrame function ??? Both apps related to the above logs were running on the emulator. Then I tried to run it on the actual device, and it loads some 10 bitmaps more before it goes OOM. This probably relates to speed of GC which would be much quicker on the device than on the emulator. This still does not solve my problem though, as that is still only about 1/3 of all the bitmaps which I need to load for the whole game. In fact, I am trying to load all the bitmaps which I need for the whole game. I don't think this is the right thing to do, I would much more prefer to load only the bitmaps which I need for the first level, and load bitmaps for another level as and when I start that particular level, but I don't know how to do it either - to load the bitmaps later, I need the Context and I don't know how to pass it into onDrawFrame function, where is my main game loop (as explained in my other post http://www.gamedev.net/topic/619474-how-to-pass-context-into-ondrawframe/page__fromsearch__1
  20. I am designing a game in Open GLES on Android in Java. Obviously I am using lots of textures and soon I will run out of memory. I am quite new to Android and Java, but I figured that the easiest way to go round this problem is to destroy the objects with bitmaps, which I don't need at the moment, let the garbage collector reclaim the memory which they occupied, then re-create those objects at the late stage when I again need the respective textures. Something like this: background = null; then when I need the textures in background object: background = new Background(context); seems pretty straighforward, except that is, that the context (which I need for my class background to function, as it loads the textures from it via BitmapFactory) is not passed into onDrawFrame(GL10 gl) function where my main game loop is and where I need it ! If I try to add context as a second parameter after GL10 gl, I get an error - this does not seem to be possible. Does anybody know how to pass context into onDrawFrame, or other way how to clear the context objects from memory and then reinstate them again ? Thanks in advance for any help.
  21. Now is midnight and I am still looking into this. Just found this interesting article from Google I/O 2011: ERRATUM: I’d like to correct one mistake I made in the Q&A, answering a question at 49:33 in the video. I said that “garbage collection is fundamentally kind of asynchronous; if you’re really close to the limit there can be times that you’re trying to allocate so fast that the garbage collector can’t keep up.” That isn’t really true. Dalvik will always perform a full, synchronous GC before thowing an OutOfMemoryError. What I was referring to here was finalization. [color=#ff0000]Finalization is asynchronous, so if you are close to your heap limit and allocating a lot of objects, you may run out of memory before finalizable objects can be freed. Could this be related to my problem ?
  22. I never doubted that / thought that, respectively.
  23. LOG - CRASH 02-01 21:00:18.361: D/dalvikvm(596): GC_FOR_ALLOC freed 48K, 5% free 6254K/6531K, paused 341ms 02-01 21:00:18.453: I/dalvikvm-heap(596): Grow heap (frag case) to 8.034MB for 1925136-byte allocation 02-01 21:00:18.551: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 4% free 8134K/8455K, paused 59ms 02-01 21:00:18.661: D/dalvikvm(596): GC_CONCURRENT freed <1K, 4% free 8134K/8455K, paused 3ms+12ms 02-01 21:00:19.201: D/dalvikvm(596): GC_EXPLICIT freed 9K, 4% free 8124K/8455K, paused 2ms+2ms 02-01 21:00:19.253: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 4% free 8145K/8455K, paused 53ms 02-01 21:00:19.281: I/dalvikvm-heap(596): Grow heap (frag case) to 9.889MB for 1925136-byte allocation 02-01 21:00:19.432: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 4% free 10025K/10375K, paused 62ms 02-01 21:00:19.522: D/dalvikvm(596): GC_CONCURRENT freed <1K, 4% free 10025K/10375K, paused 3ms+2ms 02-01 21:00:20.121: D/dalvikvm(596): GC_EXPLICIT freed 2K, 4% free 10023K/10375K, paused 3ms+2ms 02-01 21:00:20.191: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 4% free 10043K/10375K, paused 63ms 02-01 21:00:20.211: I/dalvikvm-heap(596): Grow heap (frag case) to 11.746MB for 1925136-byte allocation 02-01 21:00:20.291: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 4% free 11923K/12295K, paused 48ms 02-01 21:00:20.411: D/dalvikvm(596): GC_CONCURRENT freed <1K, 4% free 11923K/12295K, paused 3ms+3ms 02-01 21:00:21.593: D/dalvikvm(596): GC_EXPLICIT freed <1K, 4% free 11923K/12295K, paused 3ms+3ms 02-01 21:00:21.683: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 3% free 11944K/12295K, paused 90ms 02-01 21:00:21.721: I/dalvikvm-heap(596): Grow heap (frag case) to 13.601MB for 1925136-byte allocation 02-01 21:00:21.871: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 3% free 13824K/14215K, paused 89ms 02-01 21:00:22.043: D/dalvikvm(596): GC_CONCURRENT freed <1K, 3% free 13824K/14215K, paused 3ms+4ms 02-01 21:00:22.711: D/dalvikvm(596): GC_EXPLICIT freed <1K, 3% free 13824K/14215K, paused 3ms+5ms 02-01 21:00:22.781: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 3% free 13845K/14215K, paused 60ms 02-01 21:00:22.801: I/dalvikvm-heap(596): Grow heap (frag case) to 15.458MB for 1925136-byte allocation 02-01 21:00:22.941: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 3% free 15725K/16135K, paused 58ms 02-01 21:00:23.551: D/dalvikvm(596): GC_EXPLICIT freed <1K, 3% free 15725K/16135K, paused 2ms+3ms 02-01 21:00:23.611: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 3% free 15746K/16135K, paused 56ms 02-01 21:00:23.631: I/dalvikvm-heap(596): Grow heap (frag case) to 17.314MB for 1925136-byte allocation 02-01 21:00:23.801: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 3% free 17626K/18055K, paused 74ms 02-01 21:00:24.391: D/dalvikvm(596): GC_EXPLICIT freed <1K, 3% free 17626K/18055K, paused 5ms+3ms 02-01 21:00:24.461: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 3% free 17646K/18055K, paused 59ms 02-01 21:00:24.481: I/dalvikvm-heap(596): Grow heap (frag case) to 19.170MB for 1925136-byte allocation 02-01 21:00:24.661: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 3% free 19526K/19975K, paused 82ms 02-01 21:00:25.261: D/dalvikvm(596): GC_EXPLICIT freed <1K, 3% free 19526K/19975K, paused 3ms+3ms 02-01 21:00:25.321: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 3% free 19547K/19975K, paused 60ms 02-01 21:00:25.343: I/dalvikvm-heap(596): Grow heap (frag case) to 21.027MB for 1925136-byte allocation 02-01 21:00:25.511: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 3% free 21427K/21895K, paused 79ms 02-01 21:00:26.121: D/dalvikvm(596): GC_EXPLICIT freed <1K, 3% free 21427K/21895K, paused 3ms+5ms 02-01 21:00:26.221: D/dalvikvm(596): GC_EXPLICIT freed <1K, 2% free 21487K/21895K, paused 3ms+3ms 02-01 21:00:26.343: D/dalvikvm(596): GC_EXPLICIT freed <1K, 2% free 21550K/21895K, paused 3ms+5ms 02-01 21:00:26.461: D/dalvikvm(596): GC_EXPLICIT freed <1K, 2% free 21614K/21895K, paused 9ms+3ms 02-01 21:00:26.581: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 21677K/21895K, paused 3ms+3ms 02-01 21:00:26.701: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 21740K/21895K, paused 3ms+3ms 02-01 21:00:26.821: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 21803K/21959K, paused 3ms+3ms 02-01 21:00:26.941: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 21866K/22023K, paused 2ms+6ms ...HERE MANY MORE LINES JUMPING BETWEEN 1-3% free 02-01 21:00:30.232: D/dalvikvm(596): GC_EXPLICIT freed <1K, 3% free 32993K/33671K, paused 3ms+6ms 02-01 21:00:30.362: D/dalvikvm(596): GC_EXPLICIT freed <1K, 3% free 33546K/34247K, paused 2ms+4ms 02-01 21:00:30.492: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 34099K/34247K, paused 3ms+3ms 02-01 21:00:30.622: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 34653K/34823K, paused 3ms+3ms 02-01 21:00:30.814: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 35009K/35207K, paused 2ms+3ms 02-01 21:00:30.992: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 35346K/35591K, paused 2ms+3ms 02-01 21:00:31.072: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 1% free 35402K/35591K, paused 78ms 02-01 21:00:31.311: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 37327K/37575K, paused 3ms+4ms 02-01 21:00:31.383: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 1% free 37327K/37575K, paused 74ms 02-01 21:00:31.411: I/dalvikvm-heap(596): Grow heap (frag case) to 38.434MB for 1971216-byte allocation 02-01 21:00:31.601: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 1% free 39252K/39559K, paused 95ms 02-01 21:00:31.801: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 39253K/39559K, paused 5ms+3ms 02-01 21:00:31.911: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 1% free 39253K/39559K, paused 100ms 02-01 21:00:31.931: I/dalvikvm-heap(596): Grow heap (frag case) to 40.314MB for 1971216-byte allocation 02-01 21:00:32.121: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 1% free 41178K/41543K, paused 99ms 02-01 21:00:32.371: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 41178K/41543K, paused 2ms+4ms 02-01 21:00:32.441: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 1% free 41178K/41543K, paused 78ms 02-01 21:00:32.471: I/dalvikvm-heap(596): Grow heap (frag case) to 42.194MB for 1971216-byte allocation 02-01 21:00:32.681: D/dalvikvm(596): GC_FOR_ALLOC freed 0K, 1% free 43103K/43527K, paused 114ms ...HERE MANY MORE LINES JUMPING BETWEEN 1% free 02-01 21:00:36.701: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 43914K/44039K, paused 3ms+3ms 02-01 21:00:36.951: D/dalvikvm(596): GC_CONCURRENT freed <1K, 1% free 45855K/46023K, paused 4ms+3ms 02-01 21:00:37.423: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 45855K/46023K, paused 3ms+4ms 02-01 21:00:38.141: I/dalvikvm-heap(596): Clamp target GC heap from 48.717MB to 48.000MB 02-01 21:00:38.141: D/dalvikvm(596): GC_EXPLICIT freed <1K, 1% free 47735K/47943K, paused 3ms+6ms 02-01 21:00:38.241: I/dalvikvm-heap(596): Clamp target GC heap from 48.718MB to 48.000MB 02-01 21:00:38.241: D/dalvikvm(596): GC_FOR_ALLOC freed <1K, 1% free 47735K/47943K, paused 100ms 02-01 21:00:38.241: I/dalvikvm-heap(596): Forcing collection of SoftReferences for 1925136-byte allocation 02-01 21:00:38.351: I/dalvikvm-heap(596): Clamp target GC heap from 48.716MB to 48.000MB 02-01 21:00:38.351: D/dalvikvm(596): GC_BEFORE_OOM freed 1K, 1% free 47734K/47943K, paused 109ms [color=#ff0000]02-01 21:00:38.351: E/dalvikvm-heap(596): Out of memory on a 1925136-byte allocation. 02-01 21:00:38.351: I/dalvikvm(596): "main" prio=5 tid=1 RUNNABLE 02-01 21:00:38.351: I/dalvikvm(596): | group="main" sCount=0 dsCount=0 obj=0x4001e6b0 self=0x115b8 02-01 21:00:38.351: I/dalvikvm(596): | sysTid=596 nice=0 sched=0/0 cgrp=default handle=-1342909328 02-01 21:00:38.361: I/dalvikvm(596): | schedstat=( 16874792266 2631344068 909 ) utm=1557 stm=130 core=0 02-01 21:00:38.361: I/dalvikvm(596): at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method) 02-01 21:00:38.361: I/dalvikvm(596): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:483) 02-01 21:00:38.361: I/dalvikvm(596): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:549) 02-01 21:00:38.361: I/dalvikvm(596): at Atomix.apk.Background.<init>(Background.java:57) 02-01 21:00:38.361: I/dalvikvm(596): at Atomix.apk.GLRenderer.<init>(GLRenderer.java:65) 02-01 21:00:38.361: I/dalvikvm(596): at Atomix.apk.AtomixActivity.onCreate(AtomixActivity.java:49) 02-01 21:00:38.361: I/dalvikvm(596): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1048) 02-01 21:00:38.361: I/dalvikvm(596): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1700) 02-01 21:00:38.361: I/dalvikvm(596): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1752) 02-01 21:00:38.361: I/dalvikvm(596): at android.app.ActivityThread.access$1500(ActivityThread.java:123) 02-01 21:00:38.361: I/dalvikvm(596): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:993) 02-01 21:00:38.361: I/dalvikvm(596): at android.os.Handler.dispatchMessage(Handler.java:99) 02-01 21:00:38.361: I/dalvikvm(596): at android.os.Looper.loop(Looper.java:126) 02-01 21:00:38.361: I/dalvikvm(596): at android.app.ActivityThread.main(ActivityThread.java:3997) 02-01 21:00:38.361: I/dalvikvm(596): at java.lang.reflect.Method.invokeNative(Native Method) 02-01 21:00:38.361: I/dalvikvm(596): at java.lang.reflect.Method.invoke(Method.java:491) 02-01 21:00:38.361: I/dalvikvm(596): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841) 02-01 21:00:38.361: I/dalvikvm(596): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599) 02-01 21:00:38.361: I/dalvikvm(596): at dalvik.system.NativeStart.main(Native Method) 02-01 21:00:38.371: D/skia(596): --- decoder->decode returned false 02-01 21:00:38.371: D/AndroidRuntime(596): Shutting down VM 02-01 21:00:38.371: W/dalvikvm(596): threadid=1: thread exiting with uncaught exception (group=0x40014760) [color=#ff0000]02-01 21:00:38.381: E/AndroidRuntime(596): FATAL EXCEPTION: main 02-01 21:00:38.381: E/AndroidRuntime(596): java.lang.OutOfMemoryError 02-01 21:00:38.381: E/AndroidRuntime(596): at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:483) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:549) 02-01 21:00:38.381: E/AndroidRuntime(596): at Atomix.apk.Background.<init>(Background.java:57) 02-01 21:00:38.381: E/AndroidRuntime(596): at Atomix.apk.GLRenderer.<init>(GLRenderer.java:65) 02-01 21:00:38.381: E/AndroidRuntime(596): at Atomix.apk.AtomixActivity.onCreate(AtomixActivity.java:49) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1048) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1700) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1752) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.app.ActivityThread.access$1500(ActivityThread.java:123) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:993) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.os.Handler.dispatchMessage(Handler.java:99) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.os.Looper.loop(Looper.java:126) 02-01 21:00:38.381: E/AndroidRuntime(596): at android.app.ActivityThread.main(ActivityThread.java:3997) 02-01 21:00:38.381: E/AndroidRuntime(596): at java.lang.reflect.Method.invokeNative(Native Method) 02-01 21:00:38.381: E/AndroidRuntime(596): at java.lang.reflect.Method.invoke(Method.java:491) 02-01 21:00:38.381: E/AndroidRuntime(596): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841) 02-01 21:00:38.381: E/AndroidRuntime(596): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599) 02-01 21:00:38.381: E/AndroidRuntime(596): at dalvik.system.NativeStart.main(Native Method)
  24. LOG - NO CRASH 02-01 20:54:58.323: D/dalvikvm(542): GC_FOR_ALLOC freed 48K, 5% free 6254K/6531K, paused 295ms 02-01 20:54:58.391: I/dalvikvm-heap(542): Grow heap (frag case) to 8.034MB for 1925136-byte allocation 02-01 20:54:58.561: D/dalvikvm(542): GC_FOR_ALLOC freed <1K, 4% free 8134K/8455K, paused 60ms 02-01 20:54:58.661: D/dalvikvm(542): GC_CONCURRENT freed <1K, 4% free 8134K/8455K, paused 3ms+2ms 02-01 20:54:59.211: D/dalvikvm(542): GC_EXPLICIT freed 9K, 4% free 8124K/8455K, paused 3ms+5ms 02-01 20:54:59.271: D/dalvikvm(542): GC_FOR_ALLOC freed <1K, 4% free 8145K/8455K, paused 50ms 02-01 20:54:59.291: I/dalvikvm-heap(542): Grow heap (frag case) to 9.889MB for 1925136-byte allocation 02-01 20:54:59.451: D/dalvikvm(542): GC_FOR_ALLOC freed 0K, 4% free 10025K/10375K, paused 69ms 02-01 20:54:59.551: D/dalvikvm(542): GC_CONCURRENT freed <1K, 4% free 10025K/10375K, paused 4ms+2ms 02-01 20:55:00.253: D/dalvikvm(542): GC_EXPLICIT freed 2K, 4% free 10023K/10375K, paused 3ms+5ms 02-01 20:55:00.321: D/dalvikvm(542): GC_FOR_ALLOC freed <1K, 4% free 10043K/10375K, paused 64ms 02-01 20:55:00.344: I/dalvikvm-heap(542): Grow heap (frag case) to 11.746MB for 1925136-byte allocation 02-01 20:55:00.421: D/dalvikvm(542): GC_FOR_ALLOC freed 0K, 4% free 11923K/12295K, paused 48ms 02-01 20:55:00.551: D/dalvikvm(542): GC_CONCURRENT freed 0K, 4% free 11923K/12295K, paused 4ms+2ms 02-01 20:55:01.742: D/dalvikvm(542): GC_EXPLICIT freed <1K, 4% free 11923K/12295K, paused 2ms+3ms 02-01 20:55:01.902: D/dalvikvm(542): GC_FOR_ALLOC freed <1K, 3% free 11944K/12295K, paused 151ms 02-01 20:55:01.954: I/dalvikvm-heap(542): Grow heap (frag case) to 13.601MB for 1925136-byte allocation 02-01 20:55:02.083: D/dalvikvm(542): GC_FOR_ALLOC freed 0K, 3% free 13824K/14215K, paused 98ms 02-01 20:55:02.212: D/dalvikvm(542): GC_CONCURRENT freed <1K, 3% free 13824K/14215K, paused 3ms+2ms 02-01 20:55:02.792: D/dalvikvm(542): GC_EXPLICIT freed <1K, 3% free 13824K/14215K, paused 5ms+3ms 02-01 20:55:02.852: D/dalvikvm(542): GC_FOR_ALLOC freed <1K, 3% free 13845K/14215K, paused 59ms 02-01 20:55:02.872: I/dalvikvm-heap(542): Grow heap (frag case) to 15.458MB for 1925136-byte allocation 02-01 20:55:03.032: D/dalvikvm(542): GC_FOR_ALLOC freed 0K, 3% free 15725K/16135K, paused 69ms 02-01 20:55:03.643: D/dalvikvm(542): GC_EXPLICIT freed <1K, 3% free 15725K/16135K, paused 5ms+3ms 02-01 20:55:03.701: D/dalvikvm(542): GC_FOR_ALLOC freed <1K, 3% free 15746K/16135K, paused 59ms 02-01 20:55:03.732: I/dalvikvm-heap(542): Grow heap (frag case) to 17.314MB for 1925136-byte allocation 02-01 20:55:03.872: D/dalvikvm(542): GC_FOR_ALLOC freed 0K, 3% free 17626K/18055K, paused 57ms 02-01 20:55:04.472: D/dalvikvm(542): GC_EXPLICIT freed <1K, 3% free 17626K/18055K, paused 3ms+5ms 02-01 20:55:04.532: D/dalvikvm(542): GC_FOR_ALLOC freed <1K, 3% free 17646K/18055K, paused 57ms 02-01 20:55:04.552: I/dalvikvm-heap(542): Grow heap (frag case) to 19.170MB for 1925136-byte allocation 02-01 20:55:04.721: D/dalvikvm(542): GC_FOR_ALLOC freed 0K, 3% free 19526K/19975K, paused 77ms 02-01 20:55:05.331: D/dalvikvm(542): GC_EXPLICIT freed <1K, 3% free 19526K/19975K, paused 2ms+3ms 02-01 20:55:05.421: D/dalvikvm(542): GC_EXPLICIT freed <1K, 2% free 19586K/19975K, paused 6ms+3ms 02-01 20:55:05.532: D/dalvikvm(542): GC_EXPLICIT freed <1K, 2% free 19650K/19975K, paused 3ms+3ms 02-01 20:55:05.651: D/dalvikvm(542): GC_EXPLICIT freed <1K, 2% free 19713K/19975K, paused 3ms+3ms 02-01 20:55:05.771: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 19776K/19975K, paused 3ms+3ms 02-01 20:55:05.891: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 19839K/20039K, paused 3ms+2ms ...HERE MANY MORE LINES JUMPING BETWEEN 1-3% free 02-01 20:55:09.311: D/dalvikvm(542): GC_EXPLICIT freed <1K, 3% free 31092K/31751K, paused 6ms+4ms 02-01 20:55:09.441: D/dalvikvm(542): GC_EXPLICIT freed <1K, 3% free 31645K/32327K, paused 4ms+4ms 02-01 20:55:09.571: D/dalvikvm(542): GC_EXPLICIT freed <1K, 3% free 32198K/32903K, paused 2ms+6ms 02-01 20:55:09.691: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 32752K/32903K, paused 2ms+3ms 02-01 20:55:09.881: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 33108K/33287K, paused 2ms+3ms 02-01 20:55:10.061: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 33446K/33671K, paused 2ms+3ms 02-01 20:55:10.321: D/dalvikvm(542): GC_CONCURRENT freed <1K, 1% free 35427K/35655K, paused 9ms+13ms 02-01 20:55:10.481: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 35427K/35655K, paused 3ms+3ms 02-01 20:55:10.721: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 37352K/37639K, paused 3ms+6ms 02-01 20:55:10.801: D/dalvikvm(542): GC_FOR_ALLOC freed <1K, 1% free 37352K/37639K, paused 74ms 02-01 20:55:10.821: I/dalvikvm-heap(542): Grow heap (frag case) to 38.458MB for 1971216-byte allocation 02-01 20:55:11.001: D/dalvikvm(542): GC_FOR_ALLOC freed 0K, 1% free 39277K/39623K, paused 88ms 02-01 20:55:11.252: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 39277K/39623K, paused 3ms+3ms 02-01 20:55:11.321: D/dalvikvm(542): GC_FOR_ALLOC freed <1K, 1% free 39277K/39623K, paused 74ms 02-01 20:55:11.351: I/dalvikvm-heap(542): Grow heap (frag case) to 40.337MB for 1971216-byte allocation 02-01 20:55:11.541: D/dalvikvm(542): GC_FOR_ALLOC freed 0K, 1% free 41202K/41607K, paused 100ms 02-01 20:55:11.791: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 41202K/41607K, paused 3ms+4ms ...HERE MANY MORE LINES 1% free 02-01 20:55:15.521: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 42013K/42119K, paused 3ms+4ms 02-01 20:55:15.811: D/dalvikvm(542): GC_CONCURRENT freed <1K, 1% free 43954K/44103K, paused 9ms+3ms 02-01 20:55:16.281: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 43954K/44103K, paused 5ms+6ms 02-01 20:55:16.951: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 45834K/46023K, paused 3ms+3ms 02-01 20:55:17.501: I/dalvikvm-heap(542): Clamp target GC heap from 48.698MB to 48.000MB 02-01 20:55:17.501: D/dalvikvm(542): GC_EXPLICIT freed <1K, 1% free 47714K/47943K, paused 5ms+3ms 02-01 20:55:17.641: D/MEMORY(542): Max Memory: 49152 KB 02-01 20:55:17.772: D/libEGL(542): egl.cfg not found, using default config 02-01 20:55:17.772: D/libEGL(542): loaded /system/lib/egl/libGLES_android.so 02-01 20:55:17.891: D/LOADED:(542): Start: Level 1 02-01 20:55:19.441: D/SCREEN SIZE(542): ScreenX: 1280, ScreenY: 752 02-01 20:55:19.601: I/ARMAssembler(542): generated scanline__000001B7:030101C4_00001404_00000000 [ 65 ipp] (130 ins) at [0x49a281e8:0x49a283f0] in 3250574 ns 02-01 20:55:19.821: I/ARMAssembler(542): generated scanline__000001B7:035454C4_00001404_00000000 [ 97 ipp] (183 ins) at [0x49a283f8:0x49a286d4] in 1737577 ns 02-01 20:55:19.953: I/ARMAssembler(542): generated scanline__000001B7:035454C4_00009404_00000000 [160 ipp] (246 ins) at [0x49a286d8:0x49a28ab0] in 1681797 ns 02-01 20:55:24.431: I/ARMAssembler(542): generated scanline__000001B7:035454C4_00001401_00000000 [105 ipp] (191 ins) at [0x49a28ab8:0x49a28db4] in 1772941 ns 02-01 20:55:48.503: D/dalvikvm(542): GC_CONCURRENT freed 34563K, 71% free 14376K/49095K, paused 9ms+44ms 02-01 20:56:13.161: D/dalvikvm(542): GC_CONCURRENT freed 1932K, 71% free 14367K/49095K, paused 10ms+16ms ...HERE MANY MORE LINES 71% free 02-01 20:59:33.453: D/dalvikvm(542): GC_CONCURRENT freed 1923K, 71% free 14367K/49095K, paused 3ms+3ms 02-01 21:00:03.051: D/dalvikvm(542): GC_CONCURRENT freed 1923K, 71% free 14367K/49095K, paused 4ms+3ms
  25. Thanks Fiallen, for trying to help me with this. You seem to know what are you talking about (as opposed to Antheus above, who just googles and stabs in the dark) This is my first game in Android and I already thought I have a fully working game engine, which I was designing by myself from scratch, and can concentrate on the level design, when this setback with textures, which sent me right back to the square one Yeah, sure I use that from beginning, it's extremely useful, and now when you mentioned it, I've looked into it really in detail again, but still cannot figure out what I am doing wrong. This is where I am really getting confused. I was originally allocating well less than width x height x 4, and it still worked (see first log) and when I increased that significantly, it seemed to make no difference in amount of allocated memory. As you will see from log there is always this magical number 1925136 bytes floating around, even I increase allocation by thousandfold. For clarity, I am posting 2 logs in following two posts. 1st log is where the game starts fine, about 50 or so textures ranging in size from 80x80 to 1280x752 load just fine and everything works great. This works whether I put to allocation ridiculously small numbers, or their thousedfold values (width * height * 4 does not work, that crashes immediately, but I put there anything from 12 * 4 to width * 4 and it did not seem to make an iota of difference - all textures loaded and game ran). As you can see though there is something strange going on there - it seems like Android is running out of puff there, having 1-2-3% of memory free, then suddenly reclaims up to 71%! 2nd log is the same situation, I did not change memory allocation, only added one more object loading one more 1280x752 texture. That is where it crashes. I figured that I just can null some texture objects/classes and reinstate them later when I need them, but I cannot figure out how to do it either. See: http://www.gamedev.n...__fromsearch__1 Either Android/Java is extremely difficult environment, or I am a lousy programmer I am stuck with this problem now about 2 weeks and will be very grateful if you could show me the way out of this mess.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!