Announcement

Collapse
No announcement yet.

Good practice for slate ?

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

    Good practice for slate ?

    Hi there,

    I have a very heavy slate UI, lots of nested elements on many levels, tens of elements on screen.

    The result is that it's practically unusable, i can get up to 10s of refresh time when it's displayed in its full glory.

    Yet, it seems so basic compared to what the editor (also using slate apparently) can do, and the editor runs super smooth.

    So it is clear to me that i am walking a very wrong path.

    I know i'm gonna have to rewrite a lot of code but at least i would like to have a direction.

    Slate documentation in c++ is very sparse (not to mention styles), making it a pure nightmare for beginners, all very frustrating.

    So how is it done for the editor ?

    What would be the general strategy to adopt when aiming very heavy UIs ?

    I could really use a best practice guide :-)

    In case screenshots might help, i opened some time ago a question on the answerhub:
    https://answers.unrealengine.com/que...ance-drop.html

    It is so frustrating to see how easily and wonderfully UE4 handles 3D, and how slow a bunch of textboxes and buttons can be.

    Thanks

    Cedric

    #2
    Originally posted by uced View Post
    Slate documentation in c++ is very sparse (not to mention styles), making it a pure nightmare for beginners, all very frustrating.
    You're right about that. Best chance to learn Slate is to actually dig into the code of the editor. Just pick on part you want to learn about and have a look at how it was done. You can also have a look at the games examples, like the Vehicle game or the Shooter Game and have a look how they've done things.

    A great way to dissect the UI of the editor is the Widget Reflector. With it you can find out which widgets are actually being used.

    So right now the path to learn Slate isn't an easy one

    Comment


      #3
      Yep, i read all i could find in google/wiki, and even spent some time in the shooter code.
      At the end, i spent countless hours going through a routine of "trying to decode the api doc" + "trials and errors".
      Lots of time for each tiny new feature in my UI.
      Pity.

      As a very inexperienced programmer, i was hoping to avoid the plunge into the allmighty editor code, it's kind of scary, but i guess at a point this is just unavoidable :-)

      Thanks for you answer !

      Comment


        #4
        I'm a fairly experienced developer, and I've found slate to be somewhat hard to grasp.

        That being said, even though I generally prefer code over visual options, for doing UI, a visual option has a lot of benefits, and UMG sits on top of slate, so my recommendation would be to not bother with slate and use UMG for your UI stuff. It's really coming along nicely.

        Comment


          #5
          You are right, from the little i have seen of UMG, it looks like a really nice and handy tool. Amazing job as always^^

          Problem is my UI is fairly complex (lots of rules about what widget to show/hide depending on what's going on in the game and in other widgets), and many widgets are filled proceduraly.

          Not sure baby UMG could do it all, not to mention remaining simple to use, so i decided to go for the code.
          At least with the code, no bad surprise, you *know* it's gonna be a pain :-D

          Cheers

          Cedric

          Comment


            #6
            Actually I think Slate is a pretty cool system. Just takes some time to get used to it.

            UMG is also great. But I believe the real strenght in UMG lies in the fact that you can write your own widgets for UMG in Slate. Espacially for stuff where your UI gets filled dynamically this is a great additon. So it's not a waste to learn slate

            Comment


              #7
              Ok, i finally found my mistake, in case anyone bumps into this problem.

              Long story short: there was no default font defined in my styles.

              The long story is in the answerhub thread (url in my initial question hereabove).

              With a default font specified, everything runs full 70+++ fps, and the UI cost is absolutely unnoticeable, as it should be, which is great :-)

              So the first best practice on my requested list is now: "Specify a font and the rest is of no importance"^^

              Cheers

              Cedric

              Comment

              Working...
              X