Announcement

Collapse
No announcement yet.

Scaleform: Know Its Limitations

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

  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    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

    Leave a comment:


  • started a topic Scaleform: Know Its Limitations

    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.
Working...
X