I wanted to consult you others that use agk before reporting this as an bugg?

But i discovered in my raycaster that uses alot of sprites that it uses 125 mb ram in the beginning and then dropps to under 70 after a short while ?

Have anyone else discovered this ?

This could be an mayor problem on some devices with limited main memory.
As it then chokes the device main memory before the app have any time to initiate.

I know you are generating a lot of sprites in your engine - not sure if it's really suited for that number?

What is "a lot" ?

What is "a lot" ?

only around 4000-5000 now after the last crunch.

I've not seen how much memory is used at all for any project I have tried. So no idea as such. However, 5000 sprites could take a fair bit of memory dependent on how much memory is taken up per sprite.
If each sprite say takes up 50kb, then 5000 of them would result in 250,000kb or 244 MB roughly. Obviously I doubt each sprite takes anywhere near 50k but you see my point.
Of course this doesn't explain the initial memory size difference. How much memory do you think should be used, taking into account each sprites memory size?

f course this doesn't explain the initial memory size difference. How much memory do you think should be used, taking into account each sprites memory size?

I belive the size the app adjusts it self to after a while is the correct one.
Must be something with when it creates the sprites that chunks up the memory.

I will have to do some more tests as the android player dont display my raycaster right at all?
Only the floor is raycasted correctly?

Still not had much chance to test on an android, but I did notice from my netbook tests, ^2 images are important. If you have a sprite of say 320,200, AppGameKit will automatically pad it out to 512,256 (on the netbook). On my main machine, which has a fairly new video card, it works fine either way. You can probably say the same for android (needing specific image sizes). I am very careful to keep sprites to within these sizes to avoid complications. Of course that may be difficult in this case.

iam always using 2 by 2

Well, I just started doing some cleardown routines and found that it's essential to keep track of everything you create dynamically.

..as in, the internal getnextID() routines don't always return the next free sprite/particle emitter/image or whatever, so you can't rely on looping from 10000 to x to find what's been assigned.

Memory-wise - haven't seen how much a sprite takes up (should be very small I would have thought) as it's not a full rendition of the image it refers to.. have you done a test then?

@dvader: Yes. well, expect non-2's comp images to get rounded up. This should be standard behaviour for all graphic image work, as somewhere down the pipe it's going to get upsized to a 2^ image.

On your "new card" it will have oodles of ram no doubt which won't reveal this problem when you deploy to mobiles.