Announcement

Collapse
No announcement yet.

Everything is tied to framerate I guess?

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

    Everything is tied to framerate I guess?

    So I need a fixed framerate for my game unfortunately and what I'm discovering is that literally everything in my game is tied to framerate. So if the framerate is locked at 90 then the game runs really slow, but at 90 fps, 60 is weird too, does anyone know how to fix this? I know the problem's cause has something to do with using event tick and axis events, but beyond that I don't know how to fix it or what to do.

    #2
    You said that the game runs slow at 90 FPS, what do you mean when you say runs slow?
    Marketplace Assets

    Advanced Mobile Input: Marketplace Page | Support Thread ――― Easy Input Remapping: Marketplace Page | Support Thread
    Multiplayer Blueprint Chat System: Marketplace Page | Support Thread ――― Closing Credits System: Marketplace Page | Support Thread
    Minesweeper Template: Marketplace Page | Support Thread ――― Maze Creator: Marketplace Page | Support Thread

    Comment


      #3
      It should normally run faster at a higher fps rather than slower. You need to decouple your events from the tick event or you can use the delta time but best practice is to use timelines instead of using the tick to move actors etc.

      Comment


        #4
        I'm sorry I know it's confusing, but the whole game just runs in slow motion at 90. Falling is really slow, movement left and right is really slow, everything just gets really slow. The framerate is actually at 90, I don't know what's going on. Can someone explain how to decouple the events from tick?

        Comment


          #5
          Can you give an example of the blueprints that use tick heavily?

          Comment


            #6
            Originally posted by Chef_Seth View Post
            Can someone explain how to decouple the events from tick?
            You usually want to multiply stuff like speed, turning speed, etc. with DeltaSeconds. That way you decouple that stuff from the framerate.

            Comment


              #7
              I know exactly what you've done. in Project Settings/Game Settings you've enabled 'Fixed Frame Rate'. Don't do this. I think that this forces the game to render 90 frames (or whatever) per second, and if the engine can't update at that rate then it makes a second take longer if you see what I mean. Imagine in 3dsmax or something you're making a 30 second animation at 25fps. It will take a lot longer than 30 seconds to render but you get 30x25 perfect frames.

              What you might want to do instead is alter the framerate cap in the console (t.MaxFPS) (it might be locked at 60, but you can unlock it or set it to 90 - although it sounds like your game can't perform at this speed).

              Dan

              Comment


                #8
                hi, if your game is running @ 90 fps or even @ 60 fps then you have issues that need to be resolved.

                first, the temptation to use the Tick Event is what you need to avoid as much as possible. (there is also an editable/adjustable tick in engine now too, btw)
                use Timers or Timelines or Custom Events whenever possible, to avoid Tick. (avoid it all together whenever you can)

                with your game slowing down that much, you need to try to find what you are doing wrong as well, because it might not all be Tick.
                avoid using the Delay node in the wrong place for instance, at times this can almost bring a game to a stand still. Also be careful with stuff like Shaders & Post Processing.

                to avoid some of these things or to fix them, isolating them is about the only option. The Unreal Engine has many ways to do this, use of the Profiler is an ideal way, but to start with you can actually watch the game run in the Editor and actually Watch values, personally I love using Print String a lot just to see when & even how fast something is running or even if it's working at all. (I know sounds too easy but it works)

                another thing to keep in mind, is although we want everything in our games at once, all games & game engines have limitations on what they can do and we all have to be realistic and make compromises at least until we learn to do them better and faster. a major part game creation is all about being realistic, making choices and sometimes even compromises until we can do better.
                a good idea is just do one thing at a time when creating a game, whenever possible, this way you instantly know when something is wrong.

                all in all, I think that your problem is the Tick event and a possible solution is described above in the 2nd paragraph.
                I highlighted in Bold most of the major points to make it easier to Google them (just search Unreal Engine 4 then the subject), you can also do the same in the Unreal Docs: https://docs.unrealengine.com/latest/INT/

                hope this leads you in the right direction & helps, good luck.
                Last edited by ayretek; 09-30-2015, 09:55 AM.

                Comment


                  #9
                  That is what delta seconds is for. It compensates for different frame rates, or tells you how much time passed since last tick.

                  But for all not time critical things (like ai decissions, animations, delays) that go nuts on high/low framerate i found making new dispatcher that ticks every 1/25th second is much better than accommodating for delta seconds in every place where you use tick.

                  Comment


                    #10
                    I'm not updating anything on tick. I spawn objects up high and let them fall using physics. How do I get that to not run in slow motion?

                    Comment


                      #11
                      Again, why would UE4's *internal* physics be bound to the tick rate and how can we make it FPS-independent?

                      Comment


                        #12
                        Sounds like a really simple case of using a physics volume to increase the maximum fall speed, maybe just increasing gravity or something too. You're talking about a lot of completely different things here, all of which are probably being affected by different things in how you set it up. Nothing you're experiencing though is the fault of the engine from the sound of it, which is good, it means fixing these things in your project shouldn't be too bad.

                        Comment


                          #13
                          Originally posted by Jin_VE View Post
                          Again, why would UE4's *internal* physics be bound to the tick rate and how can we make it FPS-independent?

                          Good to see I'm not the only one who's had this problem. I've gotten a lot of unhelpful responses that seem to be in denial of the fact that some of UE4's physics are FPS dependent. I might have to abandon my game after 5 months because of this.
                          Last edited by Jarbles; 03-16-2017, 05:38 PM.

                          Comment


                            #14
                            You are forcing a 90fps rate, but you've left the physics engine ticking at its default time step of 60fps.
                            Adjust physics simulation accordingly with sub-stepping.

                            PhysX is not dependent on the FPS, otherwise you wouldn't experience what you see.
                            | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

                            Comment


                              #15
                              Sub-stepping doesn't effect physics processes that are for some reason considered "non-physics" like the character movement component. I eventually figured out how to get around some of the more game-breaking problems that are inherent to character movement by cheating with certain things, but as far as I can tell the character movement component is a seemingly versatile but ultimately broken piece of unreal since it ignores physics.
                              Last edited by Jarbles; 03-16-2017, 05:39 PM.

                              Comment

                              Working...
                              X