Announcement

Collapse
No announcement yet.

Scaleform: Know Its Limitations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Scaleform: Know Its Limitations

    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.

    #2
    eurosat7 says:
    September 13, 2010 at 3:37 am

    Just a question. What fps was set up in flash? Should not be above 30 fps.
    source: http://www.youtube.com/user/TheCoded.../2/3IeKb3X-Vf0

    Comment


      #3
      it can be above 30. theres no problem in a menu with higher fps rates. Especially since there is no tick function applied in most case and you can avoid onEnterFrame. Its something you have to plan first tho.

      I highly recommend using a Tween engine to make function calls or animation work on a purely time based scale. That way you dont get th fps drops associated with frame based animation.

      http://www.greensock.com/tweenlite/
      TweenLite works with Scaleform (I had to stop using scaleforms Tween class as it didnt perform) and does the job great. I havent tried this with a HUD yet so if someone wants to try it and let me know im interested to see how it performs in a game environment

      Comment


        #4
        Real time filters are very expensive. This is more of a limitation of Flash itself, than of Scaleform GFx. Like anything, there are correct ways to do things, and incorrect ways. ActionScript tends to be slow, and we advise avoiding it for time critical elements, particularly in the HUD. For front end stuff, it shouldn't be much of an issue. ActionScript tweening can be expensive, depending upon how it is implemented. There are some AS functions you just should never use, or should only use sparingly. (onEnterFrame events is one such example - alternatively, investigate setInterval, but it really depends upon how and where you use these functions).

        Your mileage with GFx will vary from project to project and task to task. You can overdo it just like you can overdo the poly count, texture sizes, overdraw, or material complexity in a level, thus causing performance issues. As game developers you have to balance quality with performance at all times, in every area of your game, including the UI. Learning when to use certain features of Flash and when not to can often require a trial and error approach; however, we'll try to continue to pump out tutorials and best practices documentation to help everyone figure out what the best approach is.

        Comment


          #5
          I have learned from past experience that if you want complex filters its best to replicate the effect your after with methods other than tweening filter values and pushing the filter array.
          For example. If you wanted a glow effect to animate like the flicker of a light you could set the filter properties and push the filter array OR you could photoshop the filter effect (because they are very similar in property controls), output a png (or a series) and animate them instead. The overhead is dropped dramatically for the same effect.

          With this method you can overcome filter limitations such as multiple filters and missing effects. You can also add filter style effects to movieclips although you lose the dynamic nature and have to be a bit more imaginative with code.

          Comment


            #6
            That's the method I would use. You could easily animate the opacity and/or tint of a photoshop created glow saved out as a PNG using Flash's tweening, rather than use a real time filter. Or you could use an image sequence as well. Of course the trade off with an image sequence is texture memory. Again, it all depends on where and when you use it. In some cases, real time filters might be just fine.

            Comment


              #7
              Matt, is the documentation you speak of available to the public? Its seems I have to be a paying developer/customer to get into any support sections at scaleform's site.

              Doublezer0:
              good points

              Comment


                #8
                Not all of the docs are available to the public; however, some of it has been released in various locations. For instance, I released several sections of our best practices document for ActionScript on this forum (the post is: Best Practices - ActionScript).

                We'll also try to answer your questions here on the forums as you ask them. As the UDK integration is still relatively new, the forums are still kind of lacking right now, but I'm sure that will change as more people start to use the integration.

                Also, we have many video tutorials planned, some of which will cover these topics and best practices.

                Comment


                  #9
                  matt, for the love of all things that are holy, dont make the scaleform tutorials video tutorials. Video tutorials are perfect for learning software like maya or the UDK editor. They drive me nuts when they are for programming.

                  A) the videos are usually so low resolution you cant even read the code
                  B) a lot are time capped so they skip explaining some of the code
                  C) its not easy to get to the information Im interested in

                  I dont want to listen to 5 minutes of video to get the one piece of information that will solve my problem.

                  I feel that video tutorials for coding have spawned from the popularity of video tutorials for software and art. They are just different beasts. In maya, its easier to show someone how to do something than type directions on how to do it. This is just not the case for coding.

                  Comment


                    #10
                    Agreed, and it's pretty time consuming when you have to pause a video and copy down the code, when the person who uploads the tutorials could just take an extra minute copying the code from the .fla and pasting it on the video description. Thanks!

                    Comment


                      #11
                      Personally I like the video approach. Its not hard to pause or rewind. The quality does matter tho. I certainly appreicate any form of tutorial that comes from Scaleform. Text or video there isnt enough information out there yet.

                      Comment


                        #12
                        'tis why all my video coding tutorials have code listings below them on their video pages. ^_^

                        Comment


                          #13
                          All of our video tutorials are done at 1280x720, so there should be no blurriness. However, I'll make a deal with you guys, any tutorials that involve code, I will also create a forum post here on UDK and post the code involved.

                          Comment


                            #14
                            back on topic:

                            Matt, you made a post on my site about what the scaleform project's FPS should be set to. Doesn't this depend on how you drive the scaleform? Example:

                            If you drive the UI 100% via unrealscript, then technically the project could be set to 0fps and it would still animate via timers in unrealscript. This would ideally correlate the UI fps/performance with that of the game. So if the game slows down, the UI slows down in turn, and vice versa. This would remove hard caps and keep the UI performance relative to the user's PC specs or personalized graphical settings.

                            Is what Im proposing accurate?

                            Now of course, there are cases where driving an animation via unrealscript would be quite difficult to set up. Example: image sequences. It's much easier to set these up as movieclips in flash then somehow cycle through them via unrealscript. This is when the animation would be affected by the fps settings in the project.

                            Comment


                              #15
                              If you drive the UI 100% via unrealscript you may as well use the old UI. The addition of flash means that a large chunk of your work will be done entirely in the flash interface. The unrealscript part only comes into play when you need to hook things up in the flash interface. Such as getting values from configs or datastores to set values in components or elements of your interface.

                              Flash permits frame rates ranging from 120 fps (the fastest) to 0.01 fps (the slowest)
                              The core classes in flash require framerate to function so I dont think the proposal is ideal although not impossible with the min framerate.

                              I wouldnt advise keeping the framerate of the UI sync'd with the game as you might find the UI slowing down your game pointlessly. You could always say "its not a bug its a feature" tho

                              Comment

                              Working...
                              X