I have an odd problem with my iPhone game. My slows down only in the first level, after going through the menus to start the game.
If I take the menus out of the build the level works fine. If i publish with the menus the. First level bogs down, although oddly if I choose from. The menus a different level, that level runs fine.
Has anyone seen this?
I’m using guiTextures, over a simple game screen. I destroy all elements after the player chooses what they want.
Yes i had simmiliar problem, in last project (Which was cancelled) When I show gui game slows down a bit if i open and close it then again and again it gets slower and slower.
Solution was implementing my own gui, which worked fine.
But now i purchased EzGui which works great. That ended my all gui problems.
I think there might be a bit more to it than that … plenty of people use GUI textures without issue. How many textures are you using, how big are they, etc
Ah well yes I hope so, and I do notice that Penelope works just fine with them.
I have two different unity scenes that come up, both are very simple. Some background geometry comes up, with a sky dome I made.
I have a texture in the first startup menu that is my logo and title, the image may be too large, 512x512 png image that weighs in at 368kb currently.
There are three buttons that give choices before loading up the either a “how to” level, a saved game or starting again.
The Menu level generally comes up next to choose from seven levels of the game (this really just for testing purposes so I can go to any level at will). The logo is there again I see, the same 512x512 png image and the buttons.
My next test tonight was to rebuild my menus and see if I had done something wrong, I guess I’ll start with turning off the textures.
Any other suggestions would be appreciated but thanks so far for the pointed questions that have me analyzing my data more.
Okay, gui textures. You want to keep them non-square (because typically they’ll look bad without compression) and as tightly cropped as you can muster. Every pixel means another pixel of overdraw and another pixel of alpha computation.
Try keep them at 1 to 1 resolution, so if your logo covers only a 3rd of the screen at the top, it’s likely only going to be maybe 300x100.
The easiest way to get them to optimal size is with photoshop, take your PNG and (assuming you have a transparent image), select all and copy. Make a new file, and paste… Photoshop automatically ignores superflous pixels, so that’ll be cropped edge to edge, even with glows/shadows etc.
Smaller. RGBA16bit if you can get away with it. Smaller.
I understand that is big, but I thought without textures being in the format of 256 square, 512 square etc, that they would not compress at all. That’s the warning I always get.
I don’t stretch my image once in, it has an alpha channel (it’s a png image) and thus just sits over my background.
I take your point about keeping it tight though and not having extraneous size or data.
I am not clear on what you said though about the size issue for compression reasons though, i.e. to be in the compression format it has to be square from what I understand.