Slick Forums

I have a game that is running into memory problems (it's running on android). After profiling, I found that around 50% of the memory is in byte[] objects, so of course, I want to optimize whatever is creating byte arrays. Does slick use byte[] object often? If so, where?

_________________
"Artificial intelligence will never be a match for human stupidity" - "Jamos Kennedynos"

Most of it is probably from textures and sounds.

• Use the new InternalTextureLoader.getTextureCount() method to determine how many textures you have. If this is greater than what you're expecting (based on how many you are loading), then you have a lot of room for optimization.
• Ensure all of your images are power-of-two size to begin with
• Be sure to release images/sounds that are no longer used
• Stream music/sounds instead of loading them into memory, unless you need low latency
• Don't use ImageBuffer, Image.getGraphics, or Image.getColor -- these are expensive for Android purposes and require a lot of extra memory
• Some of the problem might lie in Slick's current manner of caching and holding texture data (for reloading on context switches, for example). In many cases you may have images that you don't need to be held/reloaded, but there is no easy way (that I can see).
• Change slick source and expose the buffer size in Slick-AE's GDXRenderer -- by default it allocates 50,000 floats (200,000 bytes) which might be more than you need for your game's rendering

imho cache all your stuff when preloading your game
a good performance test is to do a dump on your resourceloader, after pre-loading it shouln't load anything anymore on runtime
the rest should be streamed, also tweak the particle emmitter system if you run on slick