Why AngelFont on iPad is so slow?
Monkey Targets Forums/iOS/Why AngelFont on iPad is so slow?
| ||
| Hi I am using AngelFont in our game and it looks like it is real performance killer. Our game is quite graphics intensive, but not that much per game stage (stage = title screen, map screen or game screen). For example on title screen we get just 30 FPS and title screen draws one 512x512 texture stretched to 1024x768, one fullscreen texture with transparent parts and just 5 calls to AngelFont.DrawText, printing Play, Freeplay, Options, Exit and "Hello Player, if that's not you click here". We use 2 font textures for that (256x256). That's less that 10MB for that stage. In game stage where we draw background image 1024x768, gui from 1024x768, cards from 1024x768 texture (sometimes two textures) we are able to get >40 FPS up to 60 FPS when there is lower amount of cards to draw (but there is not much text drawn). So why title screen would be sooo slow? Or actually Angel Font? Any ideas how we can improve performance? cheers Roman |
| ||
| AngelFont creates an Image per character, so the more letters you have on screen the more images, the more images the slower the game gets... I found the same issue with Pirates - I decided on "hard" drawing my text into images... |
| ||
| Well, it's not quite true. AngelFont draws each letter separately, but it uses just one texture for all letters and DrawImageRect to draw them. That's why I am surprised it is slower than expected. |
| ||
| Yeah thats right - but each DrawImage will cost you some performance, it doesnt matter that it is using the same texture. |
| ||
| One thing I find suspiscious is the local definition of variables inside the for loops when Angelfont draws a text. While that shouldn't be a problem with compiled targets like C++, I imagine that this could be a problem on targets like Android. Are JAVA's scope rules the same like LUA's? There a local definition inside a FOR loop is local to that loop. So if you define each loop a new local var, then the garbage collector could kick in easily. But that could be easily testet. Move the var definitions to the top of the methods and just set them inside the loop. The texture size for the font is 512x512, so that should be fine. |
| ||
| Sorry, forgot that you are using it on the IPAD. So GC is not that much of a problem. Still, I would test this. |
| ||
| I just run another test. Magic store: two 1024x768 textures drawn + some texts. With 6 texts drawn (total of 30 letters) it still draws near 60 FPS, but adding one more text "You can't afford that" with SetColor 255, 0, 0 drops frame rate to 30 FPS. Weirdly with SetColor 255, 255, 255 it slows down just a bit to 55 FPS. Could it be that SetColor is sooooooo slow on iPad? |
| ||
| Dont know? I released PS before we got SetColor for images ;) |
| ||
| with SetColor 255, 0, 0 drops frame rate to 30 FPS. Weirdly with SetColor 255, 255, 255 it slows down just a bit to 55 FPS. I'd imagine that would have to be the image coloring... |
| ||
| What a crap :D I coded font manager to make it easier managing loading fonts. Because there are many "LoadFont" calls the function searched if font was already loaded or not (we can like 30 calls to LoadFont for one font). But trying to optimize the function a bit I used wrong variable name for searching for fonts, so the function always loaded new font. In the end we had like 50 256x256 fonts loaded, almost every element used different font (since LoadFont returned new pointer) and this caused a low of memory swapping and huge performance drop. Once I fixed font manager we gained performance and title screen and other parts are 60 FPS again! Hurrayyy. So the lesson here is to make sure you don't use too much RAM and that you load things properly. |
   |