from http://www.alexander-fisher.com/?p=142
Before you spend hours and hours coding your UI, you need to know ahead of time what scaleform can and can’t do. And when I say can, I don’t mean capable. For example: we used a tween to scale a number from large to small for a countdown. Testing it worked perfectly, however once in game, the UI would hick up. Sometimes the animation would play perfectly, and others it would pause or stutter. This takes away from the polish of your UI. So while scaleform was capable and indeed supported this tween animation, we couldn’t really use it because it was inconsistent. At the end of the day, scaleform has performance issues inside the UDK. If you add filters like drop shadows or glow, expect to see some problems with performance.
I’ll give another example, illustrating scaleform’s performance woes. Our game has a timer in it. It updates every millisecond, decreasing in time. Testing this outside of UDK showed no issues what so ever. However, once inside UDK, the timer seemed capped at a certain speed, so rather than a second on our timer correlating with a second in real time, it actually matched with about 2 seconds of real time. This is VERY VERY bad, especially in a time based game. So how do we avoid these issues? Scaleform should do only one thing: display the user interface. So it should never do the following: do calculations, run timers, run enter frame events, or track and hold data. You should rarely if ever update the UI from within scaleform, it should always be updated via Unrealscript. If you know about design patterns, think of it like Model-View-Controller. Unrealscript should handle the model and controller. View is then handled by scaleform.
So knowing all this before hand, you should never end up in a situation like I did: having to recode your entire user interface after it’s already been created. And of course, there will be cases where you will need to use a timer or enter frame event in your scaleform, and that’s ok. Im just saying you should keep those practices to a limit, or more specifically, do them only when necessary.
I’ll give another example, illustrating scaleform’s performance woes. Our game has a timer in it. It updates every millisecond, decreasing in time. Testing this outside of UDK showed no issues what so ever. However, once inside UDK, the timer seemed capped at a certain speed, so rather than a second on our timer correlating with a second in real time, it actually matched with about 2 seconds of real time. This is VERY VERY bad, especially in a time based game. So how do we avoid these issues? Scaleform should do only one thing: display the user interface. So it should never do the following: do calculations, run timers, run enter frame events, or track and hold data. You should rarely if ever update the UI from within scaleform, it should always be updated via Unrealscript. If you know about design patterns, think of it like Model-View-Controller. Unrealscript should handle the model and controller. View is then handled by scaleform.
So knowing all this before hand, you should never end up in a situation like I did: having to recode your entire user interface after it’s already been created. And of course, there will be cases where you will need to use a timer or enter frame event in your scaleform, and that’s ok. Im just saying you should keep those practices to a limit, or more specifically, do them only when necessary.
Comment