Leaks everywhere

Unity Engine
,
1

I’m very frustrated – after getting Instruments Leak finally getting to work with my app, I realize there are plenty of leaks. After playing all 18 levels of my game, there is about 5MB of dead memory. Starting with a memory consumption of about 20MB it runs up to 25MB …

It seems, most if not all of the leaks come from bugs in Unity (or its libraries) itself. I see many GeneralBlock-16 caused by the buggy Physx lib.

But there is more – many of the leaks are GUITexture related. My GUITextures are all of a power of 2, all uncompressed 16bit RGBA, some are of square dimensions, some not (e.g. 512x64).

Some examples:

ShaderLab::Subshader leaks 1kb

GeneralBlock-384:
4 GUITexture::RenderGUIElement(Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
3 GUITexture::smile:rawGUITexture(Rectf const, Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
2 FillGuiTextureVBOChunk(Rectf const, Texture*, Rectf const, int, int, int, int, ColorRGBA32)
1 DynamicGLESVBO::GetChunk(unsigned long, unsigned long, unsigned long, DynamicVBO::RenderMode, void**, void**)

GeneralBlock-176:
7 GUILayer::PostRender(Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
6 GUITexture::RenderGUIElement(Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
5 GUITexture::BuildSheet()
4 Shader::MakeProperties() const
3 ShaderLab::IntShader::MakeProperties() const
2 ShaderLab::PropertySheet::PropertySheet(ShaderLab::PropertySheet const)
1 libstdc++.6.dylib operator new(unsigned long)

GeneralBlock-176:
8 RenderManager::RenderCameras()
7 Camera::RenderCamera(int, Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
6 Camera::smile:oRenderLastLayers(Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
5 GUILayer::PostRender(Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
4 GUITexture::RenderGUIElement(Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
3 GUITexture::smile:rawGUITexture(Rectf const, Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
2 FillGuiTextureVBOChunk(Rectf const, Texture*, Rectf const, int, int, int, int, ColorRGBA32)
1 DynamicGLESVBO::GetChunk(unsigned long, unsigned long, unsigned long, DynamicVBO::RenderMode, void**, void**)

DynamicGLESVBO (80 Bytes):
7 Camera::RenderCamera(int, Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
6 Camera::smile:oRenderLastLayers(Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
5 GUILayer::PostRender(Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
4 GUITexture::RenderGUIElement(Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
3 GUITexture::smile:rawGUITexture(Rectf const, Shader*, std::basic_string<char, std::char_traits, std::allocator > const)
2 GfxDevice::GetDynamicVBO()

So – what to do? Cancel the whole project, because it’s embarassing to release such a leaking game? Months of useless work?

Any ideas how I could prevent at least the GUITexure leaks?

What is your experience with iPhone Apps, leaks, releasing such apps … ?

Questions and more questions. :cry:

Jörg

2

I may be wrong, but it seems that GUI class herited are becoming more and more deprecated. Some Unity iPhone dev clearly stated on this forum not to use GUI interface ingame, only for simple menus.

I made several tests with the GUItexture things ingame, and came to completely recode it with 3D quads, from scratch. This rewarded me with 2 draw calls saved, a 10 fps gain and animated buttons.

3

I think you’re stressing out a bit too much… scrapping the whole project because you think you have game-crippling memory leaks? For starters, even at 25 mb, you’re well within the constraints of the device. As long as you’re under 40mb you won’t be crashing anyone’s iPhone/Pod. Further, “normal” behavior for an app is to fluctuate by about 4mb anyway - its almost impossible to avoid tiny memory allocations from script to occur on a frame by frame basis (this is especially bad in javascript). After a few minutes of play your game will bloat by a few megs, run garbage collector, and repeat.

There are some known issues with Unity iPhone right now, most of which have already been fixed and we’re just patiently awaiting the next release. While it may be frustrating to work with tools that are not perfectly optimized, such is the price of using and relying upon someone else’s tech. Your situation sounds far from an embarassing cataclysmic disaster though.

4

It was stated on the forum (by ReJ I think) that Unity iPhone leaks 16 bytes per frame thanks to a bug in Physx. As for what to do – I’m not dropping Unity because of it.

5

Yes, Physx leaks continuously …

I was able to fix a problem with the GUIText: material was not set – no problem at first sight, but leaks memory. So leaks are still there, but less than before.

GUITextures / GUIText are great and leaking is no reason not to use them. Perhaps there is a certain performance hit, but performance is OK in my game.

You’re right, Unity is great and we certainly will continue using it. Hopefully the iPhone version has full attention, now that 2.5 is released.

Will do another test run and release the game as is.

Thanks for your comments – I’ll stop whining :slight_smile:

6

Once again I may be wrong, but I think Unity is not the cause of GUI.xxx slowness. It seems that the iPhone OpenGL ES is optimized for 3D objects essentially. Everything in 2D seems to be processed by CPU, which is not a great hardware on iPhone.

That’s why every iPhone dev here redirect their 2D routines toward 3D objects.

7

I could imagine GUI pulls performance down, because of the additional graphic layer … on the other hand how are you handling in-game text? Render a texture, beforhands? Thinking of localized games, GUIText really makes sense.

I’m already using GUIText/GUITexture instead of the OnGui thing, because it’s faster …

GUILayout.xxx < GUI.xxx < GUIText / GUITextures < 3D “billboards”

8

I don’t think it’s the layer, as my new quadded 3D HUD is using a second camera, on a second layer. For the text (a timer in my case), I just mapped 2 x 10 quads with 0 to 9 textures, moved them offscreen, and will transform the right number in the right offset on demand.

9

well, welcome to my world, i have now two finished games that i cannot sell because of such bugs… month of work unpayed, support still ignores me. anyone out there want to make iphone games? don’t use unity or you’re doomed :frowning:

two month without income, two finished games with major (different) bugs of the engine, guess which engine i will use NOT for my next project

have a look at

http://sio2interactive.com/HOME/HOME.html
http://www.stonetrip.com/shiva/shiva-3d-game-engine.html

thats where i will be to find, because i bet support cannot be worse as unity technoligies (infact, as of stonetrip, i know that they wont ever ignore paying customers for 1.5 month)

10

In my experience, none of Unity iPhone’s bugs are show stoppers - any issues I’ve encountered I’ve been able to work around. It’s not perfect yet, but it beats the hell out of making your app from the ground up in objective C, and it only takes a passing glance at Unity’s competitors to see where they don’t measure up. What project-halting bugs have you run into?

11

hm, did i mention, that i have finished 3 games in unity, where all 3 had major bugs i suffered from, one i managed to make a workaround… two, despite of beeing in game development for (calculating) 18 years (!) (yes, i released my first commercial game on a commodore 64 in pure assembler) i did not find any workaround, i reported bugs, keep beeing ignored by support… i guess its a question of how deep you dig… as long as you plan to make the 1 millionth sudoku clone you are fine. but don’t dig deeper :-/

12

Just as a note, I understand your frustration, and I certainly agree that most of these issues should have been fixed before they even released Unity for iPhone…

However, I do have to speak up and state that UT customer support has always been responsive, polite, helpful and cheerful for me. I have been here since Unity 1.1, and I have no complaints about the support at all.

Just remember also that they will not reply to each and every bug report. The report is meant to tell them what the bug is, and they really only should reply if they need more info from you, etc.

The only other company I have dealt with that has comparable customer support is Fastspring. That says a lot for both companies.

-Jeremy

13

I case people don’t know it… PirateNinjaAlliance is the developer of one the top selling games on the App Store (Zombieville), which was written in Unity. Whatever leaks Unity iPhone may have are not showstoppers.

14

so you say, that one guy having the luck not to stumble over a critical bug is more worth, than one guy, stumbled over 3 bugs, 2 preventing him to sell his stuff?

you know, i know a lot of people, that would swear, that they never had any problem using vista… and yeah, thats pretty much one league we are talking about here… although… if you count critical bugs i came over, unity has most of them.

15

Can you explain in a little more detail?

16

Well, I was able to make something quite a bit more complex and successful than another sudoku clone, for what its worth. It wasn’t just dumb luck - I ran into some engine bugs along the way and worked around them. What bugs are preventing you from selling your apps?

17

I think the point is that we’re basically on our owns with those bugs. If there were no forum I bet not half as many games had been realized.

Unity Technologies should provide a list of serious known bugs / show stoppers and provide work-arounds as long they’re not fixed. It’s really a pain to work for weeks and months to find out in the end you have to work another few weeks to work around bugs.

Second the documentation in general could be far more comprehensive …

18

I don’t think that UT technologies are suppose to be cookie cutter, they figure that the developer has a brain and either a desire or background to figure things out for themselves. Some of the bugs that get mentioned in the forums may or may not get fixed in the next version and who is to know that the bugs the original poster is complaining about are not unity bugs, but bad coding or execution of the engine. A lot of people seem to think you should be able to run before walk with Unity and that isn’t fair to UT.

The fact is it may take some ingenuity to get a project off and running and into customers iPhones. UT can’t account for everything someone wants to implement in their game. The system will get ironed out, people shouldn’t give up because of “show stoppers”, figure out away around it for the time being, you will learn so much more about the technology in the process.

19

I would fully agree, if Unity3D was for free.

I want to get my job done, not mess around with know bugs. That’s the point. I’m always grateful to learn and I have no problems with fixing my own bugs. There is a learning curve, but why make it harder than it has to be? The reason we use Unity is, that we expect faster iPhone development than using Objective-C.

20

Please file a bug report and report a case number on this thread, and i’ll make sure it gets taken care of. We do give out custom builds for bugs that are critical, especially memory leaks.